User avatar
By dk2079
#388227
Hi Jeremy,

there are a few things about the rhino-FIRE interaction that I am not quite sure about, right now I am seeing some strange updates with subD options so I'll start with this:


1- subdivison: when it is unchecked Fire does restart but still shows subdivided mesh. same goes for crease/interpolation setting; FIRE restarts on a change but actually nothing changes until a full reload.

another strange thing with subD: if I assign a material to an object, start fire, assign a new material to it, and then change any subD setting of the object, FIRE will restart showing the previous material assigned.

a little workflow wish: when FIRE is running and subD is enabled on an object it is automatically set to Catmull. However this is often not the desired option, and may produce errors/stop fire. It would be helpful if we could access the options without the check set.

2- subdivison errors: is there a way to select the meshes/objects that cause subD to fail when FIRE starts? right now I only see the warning but finding the questionable objects is often difficult once subD is turned on for many objects. External maxwell will render anyway, but I have had situations where FIRE would get stuck, in fact I think inside Studio FIRE will not work when there are subD errors detected in comparison to FIRE in Rhino.

3- pretesselated displacement: when there is an object with pre tesselated displacement assigned rendering in FIRE, the change of any other scene material's parameter triggers a full FIRE restart. (displacement precalculated again)
so basically FIRE can't be used with that type of displacement, everything gets really slow.
Checking inside Studio with the same scene, this problem does not show itself.
Last edited by dk2079 on Fri Sep 18, 2015 6:21 pm, edited 2 times in total.
By JDHill
#388228
I confirm the issue with subdivided objects not being swapped back to normal when subdivision is disabled. This will have to do with something in the engine itself, regarding how it tracks the original mesh (which must be saved), along with the subdivided one (which changes with changes to any subdivision parameters). If you follow that logic, you'll see the reason I'd also attribute the material problem you mention (and which I also confirm) to the same root cause. I'll see if I can put together a repro for this, using Studio.

On changing the default value of the interpolation, I'm not sure, because a) the Studio default is Catmull-Clark, and b) if I change the default, that would change how existing files are rendered, when objects have had subdivision enabled, but have not had interpolation changed to Loop.
User avatar
By dk2079
#388229
Hi,
thanks for the fast confirmation. makes sense that the same issue causes both problems.
JDHill wrote:
On changing the default value of the interpolation, I'm not sure, because a) the Studio default is Catmull-Clark, and b) if I change the default, that would change how existing files are rendered, when objects have had subdivision enabled, but have not had interpolation changed to Loop.
I actually don't mean to change the default, just the fact that the Catmull/loop option is greyed out until it is actually enabled in the rhino properties. I would just like to set the right option before enabling it, when fire is running; From my limited user perspective I do not see how that would affect the "default" :)
By JDHill
#388230
True, you did not specifically say to change the default, but I operate under the assumption that good UI design requires parameters to be hidden or disabled when they cannot have any effect. And unless we go against that, exposing all the subdivision parameters even when subdivision is disabled, the only remaining option is to change the default.

Subdivision in Studio is done via an extension, so it is shown in a UI that has limitations which prevent parameters from being disabled or hidden (you'll find this is the case with anything appearing in the Modifiers sub-panel in Studio's Object Parameters panel, as well as with any so-called Extension Objects, such as MaxwellParticles, etc), but the plugin's Object Properties page does not have that problem.

So, I would have to think about this a bit. A better option may be for me to add a hidden user option (i.e. exposed via a Rhino command), which would let you set your own custom default for the interpolation (or perhaps for all the subdivision parameters, while we're at it).
User avatar
By dk2079
#388231
ok ok, I thought you had something else in mind.., and I agree on the logic of the UI, although personally I am fine with only a color change alone, like it also happens when a layer is turned off inside a material but the functionality remaining the same.(without it causing any effect)

I think FIRE is "messing" up the old non-realtime logic a bit. eg. I often have the situation where I would like to adjust displacement settings while the layer is turned off, so that I can bring it back into FIRE on the fly with the right settings without full restart.
User avatar
By dk2079
#388232
btw. leaving alone the UI logic, a custom defaul via rhino command would be a welcome alternative.
I just often have tris left in the geometry I have to deal with so I'd prefer a Loop setting.


edit:
*added another question 2 in top Post.

thanks
By JDHill
#388238
On the additional question (2), sorry, but it's not possible, because the plugin doesn't know precisely what is wrong (the error messages come directly from the engine itself).
User avatar
By dk2079
#388240
I see, thanks for the info.
the thing is inside rhino i have not yet found a reliable way to prevent bogus meshes from being exported with subD on.
I have had objects passing rhinos -meshRepair as "good" but still having the coincident vertex problem.
By JDHill
#388241
You may want to try using the Maxwell_CheckFixAndReportBadGeometry command. This will run through the document and try to find/fix any issues. Meshes found to be bad will be selected in the viewport after running the command, and a full report of what was found will be printed in the plugin's log viewer window.
User avatar
By dk2079
#388284
thanks for the tip, I know the command and it helps in some cases but to me it seems more when there is something wrong with UVs and not so much topology. maybe there is some way to deconstruct the mesh in grasshopper and scan for coincident vertices, the mesh tools inside Rhino have improved but are still limited.

I also added nr.3 to the questions on post 1, if you find the time.

thanks!
By JDHill
#388289
Ultimately, it will be opensubdiv, within Maxwell's SubdivisionModifier (used internally by pretesselated displacement in materials), that is complaining about your mesh, which means that neither Rhino nor the plugin will necessarily find/fix certain classes of degeneracy, and therefore, it may indeed be necessary to use a special approach (i.e. script, grasshopper, etc).

Regarding your third question, I see what you mean, and will take a look. Regardless how Studio may work, I seem to remember that I had to force a more thorough update than otherwise necessary, to avoid some other problem (it was a memory leak, I think).
Will there be a Maxwell Render 6 ?

Let's be realistic. What's left of NL is only milk[…]