Maxwell.dll and Maxwell.UI.dll are in the GAC on every install (shared by the Rhino & SolidWorks plugins, if both are installed), but the location of Maxwell.Rhino.rhp is arbitrarily decided by the user during install, so you would need to locate that yourself at runtime (just like Rhino does, you could use the registry). However, you should not need that reference in many cases (more on this later).
As far as distributing something like this, as I wrote above, it is simply and completely unsupported; I commonly have to make changes that might arbitrarily break your code (for example, there were a lot of internal changes required when Maxwell Fire was added, or when I added support for Extrusion objects, etc, etc). Understanding that, though, I am not going to stop you playing around with this stuff.
All that aside, I see a couple of changes you could make to help it work a bit better. First, calling Init() is not going to be a good plan -- that will clear everything out, but it also resets the internal ID of the object. This is why your grasshopper component is creating superfluous materials sometimes. A way around it is to take a slightly different approach -- rather than always clearing out the material, only create the Layers & Bsdfs when they don't previously exist. Here is some code that does it that way:
Maxwell.Helpers.zip
If you use this code, you can remove the reference to Maxwell.Rhino.rhp, firstly because it accesses the scene through Scene.CurrentInstance instead of the plugin's mxGlobal, which at this point is just a redirect to CurrentInstance, and secondly because it adds materials using mxObjectServer. The plugin is always listening to the server, and if it hears about a new material being added, it will perform the necessary fixups. Thirdly, you have here a GetFirstRhinoMaterialIndexFor(Maxwell.Material) method that either finds the first matching Rhino material, or adds a new one and returns the index for that. Put together, these allow you to drop the reference to the actual plugin rhp.
On leaving existing Layers & BSDFs alone, in most cases, your user has probably not messed around with your created material, but in the case that they have, you are not screwing around with any changes they may have made. So, if I have put a bump map into the BSDF, it is still there after you update the refl0, refl90 and roughness. This also results in fewer events, and therefore, less throttling for Maxwell Fire (and the material preview). It might not be your intention to allow that, though, in which case, once you have your reference to the material, just loop through and remove unnecessary Layers and Bsdfs.
So, using these methods, your GH_MaxwellMaterial::MaterialIndex becomes:
Code: Select allpublic int MaterialIndex
{
get { return Maxwell.Helpers.GetFirstRhinoMaterialIndexFor(Value); }
}
MaterialList::ApplyMaterialToObject becomes:
Code: Select allprivate Material ApplyMaterialToObject(RhinoDoc doc, RhinoObject obj, Maxwell.Materials.Material mat)
{
Material result = null;
int materialIndex = Maxwell.Helpers.GetFirstRhinoMaterialIndexFor(mat);
if (materialIndex > -1)
{
result = doc.Materials[materialIndex];
obj.Attributes.MaterialSource = ObjectMaterialSource.MaterialFromObject;
obj.Attributes.MaterialIndex = materialIndex;
obj.CommitChanges();
}
return result;
}
And, for example, MaxwellDiffuseMaterial::SolveInstance uses this call:
Code: Select allmxMaterial = Maxwell.Helpers.EnsureRgbMaterial(name, diff0, diff90);
So play around with that and let me know how it goes.
You do not have the required permissions to view the files attached to this post.
- By hwolfejr
- By choo-chee