MR: BSP-tuning

[nisus]

Hi All,

 

Can anyone give me a short and quick explanation about BSP-tuning in MR?

I've tried some test over the weekend, but the results I got, are far from what I expected. (Basicly, they don't match my expectations: i.e. the settings I thought would definately work, didn't... and the ones I was almost sure that would not render, somehow did... upside world for now...)

So can anyone explain me a bit what's goin on?

 

What I would like to know in better detail:

- how to interpret the BSP diagnostics (for both size and depth)

- how the size and depth change the memory allocation (and what is best used in a particulair scene (and of course why?))

- how to fine-tune step-by-step, i.e. a workflow for tuning

 

If no one can explain these things for now, can anyone at least give some rough settings for different type of scenes? and a brief description when to stop tweaking (i.e. when there is NO red left, or little, or should I go to green only... and what about the ram in both situations?)

 

tnx & rgds,

 

nisus

[psv1]

as a rule of thumb this extremely scene dependent.

and it`s a trade -off between rendering time and memory consumption.

increasing depth can increase memory consumptions but a scene with a lot of geometry coherence and intensive ray tracing can benefit from that.

60 for example for a large dense scene can speed up things considerably

 

on the other hand for the diagnostic a fast visual guideline is to change the values for depth and size til you optain an even mix between the two colors

*red and green*

 

it is frustating i know to tune BSP tree,

 

best regards

Sorin

[nisus]

And what about LargeBSP?

 

This weekend I've tested several settings (all combinations of Size: 10-50 and Depth 10-50) both for LargeBSP and BSP... Strangely enough, NONE of the Large* BSP images got rendered... To have an idea of the model: think large exterior shopping/retail centre, with tons of trees, cars and people... 9,5M polygons...

 

Any further thoughts?

 

Can anyone make a few BSP-diagnostics images with some directions for finetuneing? tnx

 

rgds,

 

nisus

 

 

*edit: none of the Large BSP got rendered! Where I would expect a Large to work, and a normal not...

[William Alexander]

BSP- algorythm that breaks down 3D space into subdivided nested sets of voxels. Boxes with triangles in them. Controlling-accelerating the potentially unlimitied process of ray tracing. LOL anti-Maxelwell thinking

 

Size- Maximum number of triangles in a voxel

 

Depth- how often voexel will be subdivided into smaller voxels: BSP diagnostic view gives a visual display of what's going on...

 

Memory- Upper limit for BSP memory. Used ofr unusally long preprocessing times. Try it but.....it's intented for the very rare cases where memory has to be controlled and does not control the depth of the BSP tree.

 

The 'suggested' settings for depth 25 smaller scenes, typical 40 and large 50. Any more than 50...."danger Will Robinson"-pretty obvious the processing times and memory will go exponential.

 

From my humble experience BSP settings can be of value for animations. Single views the time it takes to tweak it, is longer than the time you save for rendering.

Best workflow is use the BSP Diagnostic to view the depth, the task manager to watch memory & disk writing and the MR message window with as much info being posted as possible-the best way to grasp what MR is doing. The figures in there can shed some light on memory-time-all the things MR does to break down the rnedering of a scene.

 

The Driemeyer Rendering With Mental Ray book/s "can" be of some benefit at these levels of figuring what the "____" mental is actually doing. Though it still takes trial and error to get a good feel oabout controlling the beast.

 

My take on it

WDA

[anthony cortez]

Understood this after attending Chris Bullen's class at Autodesk University last year...

The diagnostics are showing you how the scene is being divided for memory purposes. The depth is showing you how much recursion is occurring. The range goes from black, depth = 0 to red, max depth. This corresponds with your BSP settings. If you have the depth set too low, you'll run into huge recursions which can be taxing for the renderer. This will show up as red in the diagnostics render. If the depth is set too high, you are using more memory allocation than needed and as such are not being efficient with your memory usage. You typically want the image to show a fairly consistent balanced color range from blue to red. With regards to size, this just shows you how many polygons/vertices are being processed at once. This diagnostic render is not as useful as the logic behind why you choose a specific size.

You can think of it similar to digging a hole, if you have a large shovel (BSP size) you can dig a hole faster, but you have to have a lot of strength (RAM), alternatively if you have a small shovel, it will take you longer to dig the hole but you won't require a lot of strength.

With everything in mr, it's a tradeoff.

Use your mental ray message window with the information and progress boxes checked and look to see what the average leaf size and depth are for the renderer and use that as your starting point. From there you may want to do a diagnostics render to see how your depth setting is. Remember to get an even distribution of blue and red.

[nisus]

Tnx guys! That helped a bit already. I do like the comparison with the shovel... ;-) It makes sense!

 

Anyway, here is my (new) prob: my scene won't render with DBR, but when I tweak BSP settings, it can render... I do not care so much for rendertime, than i do for the fact that it DOES render or NOT...

 

(render time, split on two machines: 3-4hours for a half, so 6-8hours / will not render on one machine with DBR)

(after tweaking BSP: DBR: about one hour...) (but as I said, my values don't make sense... I'm rendering out the diagnostics for these values... (the diagnostics take longer than the whole scene!!!)

This is what I see for now:

- Size: almost all blue, and a bit of turqois

- Depth: almost all red, a small bit of green

 

Does that make sense?

 

So basicly, I'm trying to find a good way to setup my scene with less memory usage... Any real tips for that strategy??

 

rgds,

 

nisus

 

 

ps: To Render or Not To Render: thàt is the question!!!

[psv1]

then Large BSP

 

to render

[nisus]

hi psv1,

 

I've checked my post and found a mistake: LargeBSP did NOT render, BSP did... strange, because all documentation says "Large BSP, 15-20% slower, but can render large scenes..."

Any idea why?

 

rgds,

 

nisus

[anthony cortez]

Hi Nisus,

 

Just trying to get an idea of your scene. When you say that it did not render, did you get any error messages?

 

When it does render, what info do you get for your average depth/leaf size in the mr messages window?

 

Are you trying to render your whole scene all at once? Perhaps breaking up the scene in passes and comping it afterwards would work?

 

There may be other issues that may factor into your scene crashing...calculations of your texture maps/ shadow maps/ etc.

[nisus]

Hi Anthony,

 

Not really any error messages than the normal: an error has occured... (basicly I think this is a memory issue)

 

I had written down the average depth/size during the test, but don't remember well now (i think 6 and 45). The numbers changed when I used other settings.

 

Yes, all at once, because there is too much overlap in the scene... What works best for these scenes is to render one LEFT and one RIGHT image, of the half resolution +200pixels. These files DO render, but not DBR... The whole scene ALSO renders at once, but not DBR ;-(( Tweaking BSP made me render the whole thing in one pass, with DBR... but the numbers that worked are FAR from what I expected to work... (20 20 worked! / 10 20 too, but x9 slower)

I'm using this scene to understand BSP, which I don't for now...

 

rgds,

 

nisus

[psv1]

hi nisus

http://www.lamrug.org/resources/chardiags.html

best regards

sorin