Maxwell Render | Official public forum

Hi Guys- I got my file size down to 253K from the 600K that I had previously. The 600k file would export and render correctly just waaaay to slow, so I went back and re blocked my diamonds from the beginning... voila 253K. Now however the file crashes when the voxelization hits 22%. I have never had this happen before - I have had things crash before they got Maxwell opened but never after voxelization has started so I am a little puzzled. Any thoughts?

Have you taken a look at how much memory mxcl.exe is using when the issue occurs? What resolution are you trying to render; what if you reduce the resolution, to find whether that's the issue, or if it's something else?

Hi JD- That is what I have been doing. It is a bit strange because I have rendered much larger file sizes and have felt a BIG drag on my machine and often very long voxelization times as well as length before the render starts.... this time none of that. I will watch the task manager this time but I don't think it is consuming too much memory. I have lowered the resolution down and taken off multilight and it is still crashing at 22%. I have a feeling that the issue is with the blocks but for the life of me I can't figure where. I guess I will have to start over and see where it goes.

O.K. just checked and on my 253k file Rhino is using 727K just idling...

Yes, the on-disk size of a file doesn't have much bearing on what it requires when opened; using instances can have the effect of reducing the memory requirement of Maxwell drastically, but the same is not true of Rhino and its blocks. From your description, this is probably related to instances somehow. Do any blocks have emitter materials assigned to them? That's not allowed, and the plugin should be replacing any it finds with the default material and leaving a note about the action in the log viewer. If you want to, do the export, open the log viewer, then right-click and choose 'Send Email Report'...I'll take a look and see if I see anything that looks odd.

Hi JD- Thanks- I have finally got it to stop crashing at 22% I think that it was a combination of multi light and resolution.

I think I am a bit confused as to how blocks interact both with Rhino and with Max. It seems like the blocks can reduce the memory with Rhino- 600-700k file down to 250k, but when it comes to meshing to get the files out of Rhino it seems like the memory usage goes higher than expected 1.5-1.8mB.

Then when opening Maxwell render the memory usage as in Rhino climbs to 1.8mb and then after rendering starts drops back down to 845k- still strange for a 250k file.

I guess where I was confused was in thinking that as long as I block say 1 single diamond and then copy and array that same stone that both Rhino and Maxwell would still see say 900 stones as 1 stone. So even though I have a scene with 66 diamonds on each section repeated 14 times that it would still render as just 66 diamonds not 900. Unfortunately Maxwell still seems to have to deal with all 900 stones so even though I can get the scene into Maxwell it is prohibitively slow. I think I am on SL 1.34 after 40 minutes.

Oh and none of the blocks has an emitter assigned just the diamonds and the actual jewellery piece itself.

Thanks JD- after all that I think that I will have to render only a section of the bracelet- for now anyway

The difference has to do with math. Maxwell will take x-amount longer to render an instance because it only uses the memory that's holding the original, then it transforms all the physical data so it's located at the instance location. Rhino has different requirements - it has to show things in real time in the display, so, as far as I can tell, it has to have display entities in memory for each block instance. There's no way to get around that, and the plugin obviously just operates from within Rhino, so where the mxs file it's writing may be much smaller due to use of instances, Rhino has still prepared all the actual render meshes; the plugin doesn't need them - it just needs their locations - but there they are.

The other thing to think of, if I'm reading you correctly, is that in scenarios like this, you definitely don't want to be in Rhino and just click the Render button. When you're on the edge, just write the MXS file, then close down Rhino, open Maxwell, load the mxs file, then start the render.

Hi JD- Thanks for your input- I will definitely have to figure out how to work Maxwell stand alone! That way I will just import the meshes and render when I am at the wall.. it doesn't happen often but when it does it will be good to have the option. Thanks again for the insight.

Hi Cary,

I have two points:

One, let me see if you got this right: You create one single block with a meshed diamond and the you spread this one block around thse part, and you never explode the blocks. This is what will take adventage of using blocks. Blocking each part after they where placed is no good.

Two, after the crash, you can close rhino, open mxcl and the open the MXS from there for rendering. Better yet to restart the system.

Ricardo

Hi Ricardo- Initially I would array one diamond around a circle and then block that as one unit, then I would array that unit (block). It works but you still have a fairly large file size.

Now I block one diamond and then array that in a circle and then I array that unit. Much smaller Rhino file now.

With this workflow my mesh export from Rhino works like a charm.

However, once I get it into Maxwell it still takes the same amount of time... if not longer to render.

Last night I deleted half of the bracelet and then just focused in on the front section and rendered. Even though I had a fairly small file size the render took FOREVER to get to SL3 or 4. I think that it was because of the blocked diamonds. I had maybe 200 diamonds in the scene - I have rendered similar scenes with unblocked diamonds MUCH faster.

So now my conclusion is that blocking diamonds/stones helps your mesh transfer and Rhino file but will probably actually increase your render time inside Maxwell. I could be wrong but anecdotally this is what I seem to be seeing/experiencing.

caryjames wrote: So now my conclusion is that blocking diamonds/stones helps your mesh transfer and Rhino file but will probably actually increase your render time inside Maxwell. I could be wrong but anecdotally this is what I seem to be seeing/experiencing.

With blocks 1000 diamonds should render as fast as one of them.
I just did a test with more than 800 diamonds as blocks and it renders with decent speed. Filesize is btw 1.81mb.

Cary - just remembered, avoid intersecting geometry when using instances; as I recall, that will slow down the engine a bunch.

Thanks guys- JD I did have intersecting geometry.... I booleaned the stones from the claws - usually I scale the stones down a bit to create more of a separation but this time I had 4 intersections where the claws go over the stones. I will re model and then block and see what happens. Thanks Polyxo- that was my understanding with blocks - I was shaking my head as to the benefit of using them last night .

Check also if you don't have any materials with displacemente. These really increase the pre-rendering times.

Hi guys- THANKS so much for all your advice... turns out it was the four intersections (really just two faces in contact) on each stone that was causing the problem. Once I eliminated the contact the scene renders fine!