[f64cg]

The model we've been working with for the last few weeks is now taking 3 hours to generate meshes for mxs export/render. This same model was taking 3 minutes (at the most) at this stage in v2.1.

Nothing has changed in the scene.

Anybody have a clue whats going on?

The scene has 26395 meshes, the rhino file is just shy of 1 gb and the resulting mxs is arround 1.5 gb. These are fairly large and do tax our machines, but again, we weren't having this problem yesterday. Now we're waiting hours for both the mesh creating and the rendering process.

[JDHill]

Well, an update like this does require deep changes, but no changes like what you describe are expected. So, it would be a bug, but I will need more clues, or a file, in order to diagnose it. May I assume you are using instances where possible? Also, which version of Rhino are you using? I assume V5 x64, since you probably can't handle a scene like that in Rhino 4.

[f64cg]

Thanks for the speedy reply JD.

Your assumptions are all correct. This model doesn't have much instancing, however, this wasn't a problem before. I am running some more tests to see if I can isolate the problem in the model. When we throw quick models together and test render everything seems to be acting as expected.

It seems like now in 2.5 the meshes (on our big model) generate to 40% at similar speeds to 2.1 and then everything slows to a crawl and I can watch the memory usage in the task manager (sloooooowly) grow as the meshes continue to generate.

Testing materials, and parts of the model next....

[JDHill]

The only time I recall seeing a weird issues like this, I found one piece of degenerate NURBS geometry in the scene. In that example, the object was not even visible in the viewport, SelAll would not select it, and the render mesh it generated was huge. You can generally fence off unknown issues like that by hiding things on a decreasing half-model basis, remembering that export can be cancelled by holding down CTRL+ALT+SHIFT. In other words, hide half the model, export -- if it looks looks good, stop it, un-hide, Invert the selection, Hide again, and export again. When you find the bad half, repeat the process again. I can generally find any issue in a few minutes this way.

[kami]

hi JD
I got the same problem.
A scene with a lot of instances now takes 203 seconds for the export (11 seconds for the mesh and the rest for the blocks). The same scene testes on an the identical machine with 2.1 still installed takes 14 seconds total. So it now takes 15 times longer than before ... (Instance Export disabled)
Should I send you the scene (10MB zipped) ?
cheers, kami

[JDHill]

Yes, that would be good -- it must cause a certain code path to execute which has been negatively affected by the changes I've made to accommodate Fire. (my email is jeremy at nextlimit dot com)

[f64cg]

After going through our model I did find a few areas that seem to slow things down way more than others. However, there's no rhyme or reason to it as far as I can see.

I have uploaded an exported section of our model that is acting as described to our ftp (~85mb).
This particular section is taking about 13 minutes to mesh in 2.5. Before this same section would mesh in well under a minute.

I'll send a link to your email. Perhaps it will help.

Thanks JD

[JDHill]

Thanks much, I'll check it out.

[kami]

I've sent you the scene as well.

[JDHill]

Hi kami & f64cg -- thanks much for the models you sent me, they helped me identify the issue, and as a result, the export speed should be much improved in the 2.5.1 release preview I just announced.