[Wynott]

Hey Jeremy

Would be nice to be able to switch between V3 and V4 trial as I evaluate. As of now have to uninstall to do actual work, then reinstall to test V4.

Getting some artifacts in GPU fire... Which seem to be related to additive material layers. Is there a roadmap for this?

To be honest (other than falling behind on development) I'm not seeing anything about v4 at this stage that's worth $700 or whatever the price is for upgrade. Am I missing something? I need a sales pitch.

Any hope on the horizon for cleaning up the way the plugin handles materials from linked external blocks? so I don't always end up with this in my materials tab:

Stainless steel
Stainless steel (2)
Stainless steel (3)
Stainless steel (4)
Stainless steel (5)
Stainless steel (6)
Stainless steel (7)
Stainless steel (8)
Stainless steel (9)

Really I'd love to just be able to hide materials that are from files getting linked in.

[JDHill]

Sorry, but it's not technically possible to let you switch between v3 & v4 plugins. A plugin has a unique ID, and is only allowed to read its own data when you open a 3DM; since the plugin ID must therefore remain constant across versions, and since you can't load two plugins with the same ID, it is necessary to install only the desired version.

Sales pitch-wise... not being in sales, I guess I'd just say the main thing for v4 is indeed GPU, which may be a bigger deal for some than others. There is a GPU roadmap published here, and a v4 features list here. For some people, I imagine that being able to let customers download the standalone Multilight application and play with .mxi files should be a pretty attractive feature. Beyond this I'll just say that having a fairly open development model, with substantial features being added in no-charge point releases (for example, Maxwell FIRE itself was added in a point release), it can happen that you get a release with few "new" features, especially when they involve substantial work like the GPU engine. Maxwell 3 was released around 3 years ago... I suppose we could artificially pad each new release by holding features back from point releases, but I don't think that would be too cool. For me, major release numbers are just an artificial marketing concept, which unfortunately can have a real effect when it comes to sales; the reality is that you have x-number of people continually working on a piece of software, where whatever the perception of customers may be, the only real question is whether you end up with sales enough to continue. Whether people generally prefer them or not, I think subscription models reflect the actual nature of things more accurately.

Regarding the question about linked block materials, I'm sure it seems like a simple-enough thing to address from the outside, but actually, it turns out to be not so trivial. Maybe it can help to suggest imagining that, rather than add a "(2)" to each repeated material name, the plugin instead changed the name to some random value. Because when it does that, it is only because it has no way of guaranteeing that the two "Stainless steel" materials actually bear any relation to each other. This will not be the case if the two literally are the same material -- have the same internal ID -- but you will generally only encounter this case when you copy a 3DM and then insert both the original, and the copy, into a third document.

There is, however, a special case I can look into supporting, and that would be where you link to an MXM file. Because, if you link to an MXM, the path to that MXM is guaranteed to be unique, and it would be possible for the plugin, while Rhino is reading the linked documents, to replace any references to "duplicate" materials with references to whichever material already exists, and references the same MXM.

Outside that possibility, there is also the plugin's "material grouping" feature that you might use to make the existing situation more manageable. If, in the file to be linked, you select the materials, right-click, choose Set Group and enter some name, and save the document, then when you subsequently link it into another document, those materials will appear in the specified group.

Note that there is a detail here too, also pertaining to linking MXMs; the grouping feature also works with MXMs by means of a subtle hack (since the MXM format supports no such thing): the group name is appended to the material description. This means both that the group name will not survive re-reading of the MXM, if it has no group name, and that it will be born with a group name, if the MXM has one. Which means, if you use MXM linking, and if you edit your MXM file descriptions to have groups, then they'll always appear grouped when you bring them into new documents.

[JDHill]

Regarding the special case mentioned above (i.e. considering materials to be "the same" if they link to the same MXM file), it looks like this can be made to work without much risk of breaking anything else.

[Wynott]

Thanks Jeremy, I appreciate your comments.

GPU roadmap seems to be devoid of any actual information.

Not to be contrary, but i've had the option of switching between versions of other plugins, so they must be doing something differently. Not really a big deal to me, but just limits the amount of playing with V4 I do because it's a nuisance. Not worth any development time now but something to keep in mind next go-around.

The grouping helps... hadn't picked up on that before. Is appending the group name something that could be done with a rhino script? I have a script that does a bunch of routine file tidy-up stuff at save time and would be awesome if could add to it so that would put all the materials in the file into a group named the file name.

As for deleting duplicate linked MXMs with same path... Is that something that's happening now or you would have to do some work on it? I.e. will never see this in V3. I can't upgrade until Ranch Computing does.

[JDHill]

Well, there may be ways for some class of plugin, but I don't see how here, aside from our plugin data being keyed on plugin ID, it would be possible for Rhino to decide, when you give, for example, the Maxwell_ShowFireWindow command (commands also have unique IDs), whether to call that command on the v3 or the v4 plugin (were it possible to load them both at the same time).

There may be a pretty hacky way of automating the grouping, let me fiddle around in python for a bit and see.

Regarding materials that link to the same mxm, it's not so much about deleting them, as it is about never creating them; basically, when the plugin is asked to read a 3DM (as happens when a file is linked-in), for each material it reads, it would scan through all the already-existing materials, and either add that material, if no matches (going by mxm link path) are found, or else go through the document data and replace references to that material with references to the one found to match. This is definitely something that is not happening now, but it would be possible to upload another v3 plugin with it, as time permits, and after I've determined that it's safe to perform this modification.

[dk2079]

hi

hope you are doing fine

I'll be opportunistic and just chime in for a wish in the grouping feature here:

it really helps, I sometimes have similar material import problems like Wynott, often getting hundreds of materials..
grouping kinda helps to order them, but I don't see any option to hide them in the material tree.

if it was possible like the screenshot suggests, to click on the name header of the group (it already highlights) and by click collapse it that would really be a workflow improvement, scrolling an endless material tree even with groups is still pretty tiring after a while

thanks!
daniel

[JDHill]

Hmm, the panel is a .NET list view, and it doesn't expose any group-collapsing functionality. Google shows people apparently having success in hacking it to enable collapsing on vista and up, but I hesitate to invest the time, given that this plugin is a dead end.

[dk2079]

Hmm, the panel is a .NET list view, and it doesn't expose any group-collapsing functionality. Google shows people apparently having success in hacking it to enable collapsing on vista and up, but I hesitate to invest the time, given that this plugin is a dead end.

i see thanks,
are you referring to the non-.net version which will replace the current plugin at some point?
I have not installed or upgraded to v4 yet, but I guess the v4 plugin is still similar to v3.

[JDHill]

The v4 plugin for windows is very similar to the v3 plugin. Then, there is the v4 plugin for mac rhino, which is very different. Both are .NET plugins, but use different SDKs: the windows plugin uses Rhino_DotNET, which is being deprecated for V6, and the plugin for mac rhino uses RhinoCommon, which is the replacement for Rhino_DotNET, and is the only SDK available for mac rhino. The future for this plugin is for it to be cross-platform, based on RhinoCommon, and on a new Maxwell SDK.

[Wynott]

Thanks Jeremy. Issues understood.

Very open to hacky python automated grouping.