[Wynott]

It renders okay on it's own but when I insert it into the scene as a mxs reference (or a block instance) maxwell crashes during voxelization. Thoughts?

Here's the offending model:

http://wynott.ca/parts.zip

[Wynott]

When I insert this in a blank scene it renders okay. Not sure how to troubleshoot this.

[JDHill]

I'm not seeing any problem here, either, so I'll need to see something closer to the real scenario, or a set of steps by which I can reproduce a crash.

[Wynott]

OK here is a scene and the mxs... Seems to be crashing.

[Wynott]

Forgot the link: http://wynott.ca/problemscene.zip

[JDHill]

Thanks, but still no luck. There are lots of missing textures, though, so perhaps there is a corrupt image being referenced. It looks like most of the missing textures are located in a particular folder -- you could try closing Rhino, temporarily renaming that folder, re-opening the model, and rendering, just to see if it makes any difference.

Aside from that, I'll need to start asking for more info: plugin version, version and architecture of Rhino being used, whether it is FIRE that is crashing or Maxwell Render, or both, and whether you are able to reproduce the crash by exporting to Studio and rendering there, whether in FIRE, the viewport, or by sending it from there to Maxwell Render.

[numerobis]

I experienced the same today after upgrading to 3.0.1. but with the Sketchup plugin (v3.0.1)
It does not occur every time i press the render button. It is possible that it works one time, then the next 3 o 4 times it crashes and then it works again without changing anything.
It also happens with network rendering where it is possible that one node crashes two or three times and then runs through.

Some of the references are trees with backside materials exported from Max - when i disabled them i got no crashes even with some other references enabled. But maybe it was only a coincidence and it would have worked these times also with the trees. I think i have to examine this a bit further.

It would be good to know if this is a plugin or engine issue. If i remember correctly i updated both (Engine and plugin) at the same time to 3.0.1.
But v3.0.0.6 worked ok for me. Maybe i should go back... would i have to uninstall v3.0.1 completely or can i just run the 3.0.0.6 installer on every node?


edit: I got this error while the MXIs of a cooperative job where transferred:

Code: Select all

[01/April/2014 23:03:16] ERROR: TCP message from manager is not a XML message!
[01/April/2014 23:03:16] ERROR: Data type:2641

but the merged mxi and image files (render, material, object) seem to be ok.

[JDHill]

Please let me know if you find a way of consistently reproducing such an issue, since without being able to observe it directly, anything I could say would be nothing but speculation. As far as installing an older version over a newer one, I have no idea how well that would work (and it wouldn't be supported, in any case).

Just in case it helps you identify factors, you should know that the engine used in the (SketchUp) plugin had not changed from the initial 3.0.0 release, until the most recent 3.0.5 version of the plugin, which uses the Maxwell 3.0.1 binaries.

[numerobis]

ok, i think it is the backface material in my case. I have deleted it now in max and re-exported without it and for now i had no more crashes.
I have tried the official 3.0.1 release, sketchup plugin v3.0.5 and the latest max plugin 3.0.29. But nothing changed.

[JDHill]

Thanks for the info, I'll see if I can reproduce it that way. Did you happen to notice anything out of the ordinary with the backface material in question? For example, whether it perhaps referenced an MXM, or had textures missing, or other similar factors?

[Wynott]

OK well this is working now. I stupidly changed two variables though without testing in between so I don't know what the fix was. Pasted the geometry from the crashing files into new files and overwrote the old ones. Also upgraded to the new maxwell release. Problem gone.