VRAY_Procedural questions

[Stalkerx777]

Hi. Couple of questions regarding VRAY_Procedural.

 

As we know mantra procedural can generate geometry in 2 ways:

• When ray hits bounding box, if bounding box is defined
• Always generate if bounding box is not defined (as stated in houdini help)

My first question is: How to tell my procedural to ignore bounding box? I cant find a way. If i'm not set bbox size > 0 in my initialize() method, render() method will not be called at all.

 

The second question is about advisability of computing correct bounding boxes for mantra procedural, considering using PBR trace engine. I understand that in case of REYES rendering, this is very useful, since no raytracing occurs in scene and geometry will only be generated if render bucket hits procedural's bounding box. When geometry goes out of camera, it will be discarded, and this all make sense.

In case of raytracing, any ray type can cause procedural to generate geometry right? So 99% chance that it will be generated right at the beginning of rendering. Considering this, is there any profit to compute bounding boxes for my vray_procedural, beside "delayed" generation? 

 

Thanks!

[nicholas_yue]

Hi Alexey,

 

  I have started learning about Mantra procedural recently. I see the benefit of bounding box differently.

 

  In addition to it's useful in REYES-like algorithm, the bounding box may be useful (in ray-tracer like PBR) for e.g

  (1) Determining the relative level-of-detail so it can decide on geometry generation techniques, quality and/or quantity

  (2) Possibly subdivide (like octree) to smaller chunk for more efficient memory foot print.

 

  Naturally, the feasibility of the above will depend largely on the inputs (upstream source or external file etc) and influence to some extent by the production pipeline constraints.

 

Cheers

[Stalkerx777]

Hi Nicolas, thx for reply!

Yes, i forgot about level-of-detail, although i don't really understand what this mean for raytracing. In RYES for example, this means manipulating with shading-quality (dicing).

Correct bbox for building Octree can definitely be useful, agree.

Consider the following scene setup:

 

Before, any shading begins, i assume that mantra should initialize all bounding boxes of all procedurals. When the first render bucket starts rendering , mantra should call render() on Procedural 2 (since it occludes light source), and Procedural 3( since it should be visible in reflections). So, if i'm right, in case of raytracing, before actual sampling begins, mantra should call render() on all procedurals and keep geometry in memory, and in this case, there should be no  difference between rendering 3 procedurals or exporting same geometry from houdini sops to mantra. Am i right here?

 

I thought that i understand this very good, but when i started to write my GPattern procedural, i notice that rendering speed drops down by half, compared to straight houdni geometry rendering.

 

Edward, need help 

Edited December 30, 2014 by Stalkerx777

[edward]

I'm not a person to be asking about rendering which is why I've been quiet. Part of the problem *might* be that if you're generating a lot of procedurals, then it might be less efficient because an octree will need to be separately built for each piece of geometry instead of doing it all at once for the full geometry. To test that, you can try generating more geometry per procedural. Are you able to do instancing for the geometry you generate? I think that would be the biggest win for doing a mantra procedural if it's possible.

[lisux]

Yep you are right stalker, generating lots of procedurals is not good.

So, if you have to create let's say, lots of instances is much better to do that inside the same procedural rather than calling to nested procedurals for every new instance.

In terms of design makes sense to use nested procedurals, but it usually have a huge impact in performance.