mantra start time

[foetz]

i recently ran into rather lengthy startup times with mantra. here's the log:

[08:34:38] Generating Image: ip (1024x768)
[08:34:38]  Plane[C]: 0 Cf+Af[4] (32-bit float)
[08:34:38]     SampleFilter: alpha
[08:34:38]     PixelFilter:  gaussian -w 2.2
[08:34:38]     VEX Type:     vector4
[08:34:38]     Gamma:        1
[08:34:38]     Dither:       0.5
[08:34:38]     Gain:         1
[08:34:38]     White point:  1
[08:34:38]  Plane[Op_Id]: 0 Op_Id[1] (16-bit float)
[08:34:38]     SampleFilter: closest
[08:34:38]     PixelFilter:  minmax idcover
[08:34:38]     VEX Type:     float
[08:34:38]     Gamma:        1
[08:34:38]     Dither:       0.5
[08:34:38]     Gain:         1
[08:34:38]     White point:  1
[08:34:38]  Plane[Prim_Id]: 0 Prim_Id[1] (16-bit float)
[08:34:38]     SampleFilter: closest
[08:34:38]     PixelFilter:  minmax idcover
[08:34:38]     VEX Type:     float
[08:34:38]     Gamma:        1
[08:34:38]     Dither:       0.5
[08:34:38]     Gain:         1
[08:34:38]     White point:  1
[08:34:38]   reading geometry from /tmp/houdini_temp/ifds/storage/638_165.1_000_1584.bgeo.sc
...
[08:34:38] Deleting temporary geometry '/tmp/houdini_temp/ifds/storage/638_165.1_000_1636.bgeo.sc'
...
[08:34:39] Load Time:
Frame Wall Clock Time: 0:00:00.97
Total Wall Clock Time: 0:00:00.97
       Total CPU Time: 0:00:03.55
 System CPU Time Only: 0:00:01.14
    Peak Memory Usage: 135.15 MB
    page rclm : 77201      flts: 0
    # swaps   : 0
    blocks in : 0       out: 10
    switch ctx: 13      ictx: 13666
	[08:34:39] VEX Shaders Loaded:
         op:/shop/body op:/shop/body
...
[08:34:39]
[08:34:39] Thread Count: 28
[08:34:44] mantra: [RAY_ProcGT] procedural warning: Optimization not run on geometry (this may be ok)
[08:34:44] Creating geometry (/obj/sub1/body)
...
[08:34:48] Rendering: X(-1, 46) Y(767, 768)
...

everything looks fine until "Thread Count". after that it does nothing for 5 seconds. then "Creating geometry" takes another 4 seconds before the first pixel finally shows up. so in total it takes 10 seconds everytime i hit the render button. that's not an ideal situation.

the scene in question here is no monster at all. in fact it's not even a full scene but just a lookdev rig with 3 lights and one model. polycount is about one million, the geometry is loaded from external bgeos from an ssd and switching the file node to "packed disk primitive" made no difference.

now this is a common situation and the usual fix is to create archives. i tried the ifdarchive rop but it made no difference. i'm not sure though that i did it right since i didn't load the bgeos created by the rop anywhere. unfortunately i couldn't find any proper info about this subject anywhere and i'm not even sure that would be the right solution.
 

[flcc]

I was just about to post the same question.
By following some tutorials I realized that while in the video the renderings was almost instantaneous, mines always took some time to wait before rendering the first pixels.
This is very similar to what you describe.
As I'm not comfortable with mantra (redshift user), I guess there's probably a setting somewhere, because my configuration is supposed to be not too bad, and is quite recent.

[Houdini7]

yeah, have the same problem. startup times are really large, 20 secs or so. renderman and 3delight is faster. but how can one improve mantra?

[toadstorm]

There's a few ways you can decrease time to first pixel. First thing I'd do is switch over as much geometry as possible to packed disk primitives... just cache your shit to disk as .bgeo and then load it back in via a File SOP in Packed Disk Primitives mode. This means your IFDs don't need to actually contain any geometry; they'll just point to the cached geometry on disk instead.

Second, try to avoid using lots of unlocked materials or packing your materials in such a way that you need to use "Save all materials" under "Declare Materials" on the Mantra ROP, in case you're doing that. In bigger scenes with lots of materials that can seriously bloat your IFD size.

Third, disable displacement if you can. Displacement means you have to generate all that geometry at runtime, instead of streaming it from disk. It can honestly be faster in some cases to just subdivide your geometry in SOPs and then cache, rather than running a displacement shader.

[foetz]

switch over as much geometry as possible to packed disk primitives

i tried that already as mentioned.

Second, try to avoid using lots of unlocked materials or packing your materials in such a way that you need to use "Save all materials" under "Declare Materials" on the Mantra ROP, in case you're doing that. In bigger scenes with lots of materials that can seriously bloat your IFD size.

Third, disable displacement if you can. Displacement means you have to generate all that geometry at runtime, instead of streaming it from disk. It can honestly be faster in some cases to just subdivide your geometry in SOPs and then cache, rather than running a displacement shader.

not an issue in my case either because, as mentioned as well, it's a really small scene.

[foetz]

having another look at the log again, it seems that RAY_ProcGT takes 5 seconds. a quick search led me to this: https://www.sidefx.com/docs/hdk/class_r_a_y___proc_g_t.html#details

i don't know what GT primitives are but i have neither instances nor procedurals in my scene. at least not knowingly. so if somebody could shed some light on that ...

[foetz]

after some more testing with different houdini versions it turned out that, across the board, the major bottleneck are external files. as soon as i save everything in the hip, mantra's startup times get shortened by 80% and more.

quite unfortunate because it means that for every save the whole thing has to be written. the extra time that takes aside, in times of flash based drives that also means a lot more wear.