[kami]

Hello
Lately I very often get a 'bad' mesh. A lot on opening old files which I remember rendered fine back then. Has there anything changed with the rhino plugin, or is it a change in Rhino5 which is causing this?
Thanks for any help,
kami

[JDHill]

I doubt it is specifically related to Rhino 5. The checking routine got stricter in its rewrite for Maxwell Fire, such that there can be cases of meshes (usually brought in from outside Rhino) with no texture coordinates which it will kick out. Moving forward, it will be loosened up again to allow these to get through.

[kami]

Thanks for the info.

There is this model of a bed which I have imported from sketchup a while ago and it did render fine one year ago (http://www.deiters.ch/maxwell/bed.zip). Would you mind having a look at it?
Is there anything, I could do to make it work again?

I also had a weird experience with bad meshes from rhino objects. I modelled a complex object - lofted curves with thinkness (offsetsrf). The object itself rendered fine, but when I copied it and rotated+scaled it, some of the instances weren't rendered. How can this be possible?

[JDHill]

On the first issue, turns out that it has nothing to do with the plugin; you can see in the log viewer that the errors reported are:

Code: Select all

* line 92: listing errors - invalid objects:
* line 93: mesh_object, id=e46664e5-5459-4dfe-9033-83114b1505dc, error={ON_Mesh.m_F[19010] has degenerate float precision vertex locations.}
* line 94: mesh_object, id=add20b24-4658-4036-b832-e1d0a3486657, error={ON_Mesh.m_F[16] has degenerate float precision vertex locations.}

Rhino is tagging this as a bad mesh, due to the conditions listed; the plugin won't even attempt to export such a mesh.

On the second issue, if, by scale+rotate, you mean this was a block which you scaled and rotated, that would not make much sense; all blocks have scale/rotation, and changing the values shouldn't be a problem, unless the scale factor went to zero or something like that. However, if you mean that you modified a piece of complex NURBS geometry using Scale, then that could potentially present a problem -- any deformation you perform would require calculation of a new render mesh, and depending on render mesh settings, it's entirely possible that this mesh would not be a good one, where the mesh you had before the deformation was. I'm just guessing here, though.

[kami]

I have no idea, what "degenerate float precision vertex locations" means but I guess there is no cure for it?
Strange though, that this exact object did render fine with maxwell one year ago!

[JDHill]

I saved it as a V4 file and opened it in Rhino 4, and it renders there. Those messages in the report are from Rhino, not me, so either (a) saving as V5 breaks something in the file, (b) saving as V4 fixes something in the file, or (c) Rhino 5 employs more thorough error-checking than Rhino 4.

[f64cg]

We are getting a bunch of these "degenerate float precision vertex locations" errors on random bits of geometry throughout our models as well.
Its been easy to deal with some of these pieces...just explode and rejoin and they're no longer flagged as maxwell bad objects.

The biggest problems we're encountering is when some of these issues show up within blocks/instances in the model. I can explode the blocks, rejoin the polysurfaces etc. and do MaxwellCheckFixandReport.... and everything comes up valid and good....when I re-block the exploded/rejoined geometry and run the check again its shows up as being bad once again.....its become a feedback loop of doom.

As you was your experience JD, I tried saving some of the problem geometry as a V4 object and in V4 Maxwell doesn't detect any objects that have degenerate float precision vertex locations....GREAT band name btw.

We're currently trying to put together a new model with imported STEP geometry and these issues are making it nearly impossible to get a complete render....sometimes objects make it through the Maxwell/Rhino check process and are visible in the render and sometimes the same objects will suddenly start being flagged as a bad object and no longer show up in subsequent renders.

Seems like this all started with the Rhino V5 release after the 5-31-2011 version...I was doing renders last week with the same model and having no issues. Updated to the 6-21-2011 version and everything is broken. Can't go back to the older version (5-31) because its "expired".

So much frustration for a Friday.

[JDHill]

I can explode the blocks, rejoin the polysurfaces etc. and do MaxwellCheckFixandReport.... and everything comes up valid and good....when I re-block the exploded/rejoined geometry and run the check again its shows up as being bad once again.....its become a feedback loop of doom.

There may be something here: after fixing the geometry, but before blocking, try setting up the healed object with custom meshing parameters -- I assume the geometry should retain its custom parameters inside the block definition. If you don't do that, it's conceivable that there would be some block-optimized re-meshing going on during blocking, and that this would be using the document meshing parameters. It's something to consider, anyway.

If, after V5 is released, we still find Rhino producing and reporting this class of mesh error, I will consider putting in a hidden 'export bad stuff at your own risk' command, which would bypass various levels of verification -- the implication being that by using it you might produce bad MXS files, or crashes, or what have you.

[bjorn.syse]

I'm having lots of extra hours of work just going through all the surfaces that doesn't fit the check, exploding and re-joining, rebuilding edges, re-trimming since this more strict control was introduces,.

tedious..

[JDHill]

Please check again with the latest WIP; the above issues were due to a more recent change in core Rhino, which has now been rolled back. If you still see similar behavior, please let me know specifically what the plugin's export log shows.

[bjorn.syse]

aha, will do right away!