Hi everyone! i am using HOUDINI 18.0 + RESHIFT 3+ as the main setup.

been testing SOLARIS/LOP/USD with REDSHIFT.

i have a very simple scene (with some spheres) setup in SOLARIS, managed to set up everything and seeing the result rendered in REDSHIFT in the viewport at expected speed (fast).

however, once i setup a ROP to render the images out, rendering is taking about 30seconds per frame on my RTX3090, where i would guess it should take about few seconds per frame to render.

i am guessing this is an overhead from "translating/preparing" USD to render in REDSHIFT?

however, the beauty of REDSHIFT is its very fast render times with optimized settings, and having 20+ seconds overhead per frame is quite a lot.

also, i would assume once the USD is "translated" the subsequent frames should render faster, but my test shows that each frame is taking about 30 seconds per frame.

was wondering if it is something i have done wrong?

is there anything i can do to speed up the process?

i have tried "render all frames with a single process", but getting below error. will this help render animation faster? also, is there something i am missing?
<b style='color: red;'> Error: Output file 'C:/Users/alter/Desktop/test/test.0001.exr' should have variables</b>

an argument could be that USD is really for complex scenes, where 20 second overhead could mean little, but my USD setup is very simple (few spheres, single light).

thank you in advance for any help!

Hi everyone, just wanted to update the post with more findings.

i have managed to setup the scene with KARMA as well, and ran some animation render test.

i have setup the render so the actual render it self takes about 10 seconds per frame.

however, when i render the same scene via KARMA_ROP to render out the image sequence, similar "time overhead" occurs.

so each frame will take about 40 second on average to render out. so similar to REDSHIFT test, there seems to be about 20-30 second overhead per frame.

i am assuming this is the USD translation or interpretation phase?

my question is as per previous post

1. is this an expected behaviour? anything i can change to speed things up?

2. i don't mind the overhead on HUSK launch and USD interpretation, but the overhead on every frame really adds up, is there anything i can do to save this time inbetween frames in animation?

Thank you all in advance!

Using render all frames in a single process can substantially eliminate overhead for very simple scenes where launching a separate process for each frame has a non-negligible time.

The error message means your output path doesn't contain a frame token. I think <F> or <F4> is needed in place of the frame number for husk to substitute the frame number.

Hi. The thing I have found testing Octane for Solaris is any instancing really slows it down. It is better to cook the instances down to a usd file and bring it back in. I am not sure if you have any instancing at all or if that helps.

Best Mark

Thank you for response!

thing is i am just testing SOLARIS out, so my test scene literally has a SPHERE and a box. no instancing.
so with very basic USD stage, still has about 20-30second overhead.

i have also downloaded a scene from VERAMIX's "SOLARIS WITH 3RD PARTY RENDERER" tutorial, which is more "complicated" scene.
this scene also seems to have about 20-30 second overhead, so don't think its the USD complexity.

my guess is the time is mostly due to HUSK initiation.

what i don't understand why it has this overhead every frame? do SOLARIS shut down HUSK at end of render frame, and re-launch?

again i am very new to SOLARIS, so i am hoping i am missing something.
as i really love the concept of USD, and can see huge benefits, but for the work i do, probably not worth the overhead.

@Mark, when you render image sequence from ROP, does your render at "expected speed"?

thank you in advance!

Hi.

I have only used the render ROP with Renderman and Karma. I am using daily builds on these, amazingly renderman still works. Both render at expected speed. I have not tried it with Octane yet (which is locked to 18.0.597).

mmm you have got me thinking now about husk being shut down and restarted each frame. When I get some time I am going to look into that.

Best

Hi Mark, thank you for your reponse. if you have the chance, would be awesome if you could compare render time between just regular houdini render vs image sequence render.


also wanted to leave an updated note here. i have managed to fix the issue with toggling on "RENDER ALL FRAMES USING SINGLE PROCESS"

the problem was i had the output setup as $HIP/render/test/test.$F4.exr, as per normal houdini output setup.
however, someone on the redshift forum kindly advised me to replace $F4 to <F4>, which is USD way of doing things i am guessing.

with that change in the output path, i have managed to render out the image sequence, and it actually improved the render speed significantly (as in no overhead).

there is still the 30 second overhead at the start of the rendering sequence, but once the frames start rendering, consecutive frames were rendering at their normal speed.

i have animated geometry + camera and i both animation seems to render out just fine, so not exactly sure the CONS on toggling "RENDER ALL FRAMES USING SINGLE PROCESS".

keen to know the downside of enabling "RENDER ALL FRAMES USING SINGLE PROCESS" toggle, if anybody has any idea, would love to hear them.

Thanks!

The downsides to that toggle are:
1. You can't dish out the renders to separate machines on a render farm (all frames go to a single machine).
2. It's a little more "dangerous" in the sense that the renderer not only has to render properly, but it also has to handle incremental updates properly, and without growing its memory footprint on each frame. In an ideal world you could say "of course renderers all behave ideally", but we are not in an ideal world, so some renderers may have more difficulty with supporting this mode on a long sequence of frames.
3. Some settings may not be properly updated over time in the renderer, so for example if you turn motion blur on half way through the sequence, the renderer may not be able to respect that change. Such limitations are likely to be renderer-specific, but probably only deal with bizarre edge cases.

With those caveats, when it works properly, that mode is amazing.

On the other hand, 20-30 seconds to start up husk on a few spheres is not to be expected, and not something we see here. How long does it take for Houdini to start up and start rendering this scene in the viewport? Is the startup time of husk/houdini significantly different when you render to karma instead of redshift?

One possible culprit for this kind of slow startup is an issue with licensing (it takes a long time to grab a license for some reason, maybe a bug of maybe a network issue). If this is the problem, Houdini would probably also be slow to start up. Another would be just an issue of a slow hard drive, or having parts of your HOUDINI_PATH on a network drive which may be slow to access. Again, these would affect Houdini startup time too. If you run "husk -V9 foo.usd" from a shell you might get a better idea of how husk is spending its time.

With all this information in hand, it might be a good idea to contact support.

Hi mtucker for the information.


your explanation on "render in single process" makes good sense. i am using Deadline as my manager, so ideal workflow would be to chunk out a sequence of animation (0-100, 101-200, 201-300...) and get those rendered on each GPU with "render in single process"

i have tested this out with Deadline GPU affinity, and so far seems to work. however, i am still on my test scene, so the animations are very basic, some keyframe, some expression.

but by doing this, i am getting the expected performance, except the very first frame, where i am still seeing about 20-30 second overhead.

-- viewport render

that's the weird thing, on viewport both redshift and karma renders instantaneously, and any USD changes are reflected realtime.

-- karma

i have tested animation sequence with karma, same simple scene, but i am still getting same overhead per frame (not just the first frame, but for every frame.

all my test scene is stored in my main project NVME SSD, and i am testing locally, so don't think harddisk space / network is an issue here.

is there any way to debug the process?

i am seeing verbosity level but i am not seeing any log output displayed, assuming its being saved to a log somewhere?

-- probably not deadline issue

as this occurs even if i just click "render to disk" from houdini

--- summary

from my testing, i get the feeling its launching of HUSK? i am still learning solaris, but how is HOUDINI rendering its viewport? is it running another copy of HUSK? i don't see it in the process manager.

from my understanding it seems difference between rendering on viewport and rendering to image is in invoking HUSK to do the rendering.


RENDER INITIATE - HUSK LAUNCH - HUSK USD READ - CONVERSION TO REDSHIFT - RENDER REDSHIFT - FRAME WRITE - HUSK CLOSE? - HUSK RE-LAUNCH? - HUSK USD RE-read?

is above the kind of process HOUDINI takes to render image sequence? does it actually close and re-launch HUSK per frame?
or does HUSK runs once, and it keeps on re-preparing USD?

just trying to pinpoint where the overhead is occuring is all.

Thanks!

Are you running on Windows? It the logging sometimes gets lost on that OS because of the way it handles stdin/stdout. The best idea is probably to use a USD ROP to write the USD file out to disk, then run `husk -V9 file.usd` from the command line. I think there is also a command line option to cause husk to print out timestamps with each line it outputs. Then you can (hopefully) see what phase of the render process is taking most of the time.

Your description of the render process looks pretty accurate. Husk is restarted on each frame unless you turn on the parameter to render all frames with a single husk process.

To chime in here regarding the disparity of Viewport and Husk; Solaris (I believe) is designed for interactive rendering to be 'in-process' - it's caching what it can of the usd stage and only updating when necessary, so as soon as the render delegate is called, it's ready to go.

Husk on the other hand is a separate process that is launched outside of your houdini session, so it needs to find a licence as Mark said, initialize, locate the usd file, and fire up your render engine.

Also when using Redshift, make sure you have the Optimizations > Texture Sampling > Copy pre-converted textures to cache folder and the System > Enable automatic reprocessing of Preconverted textures turned off on your Render Settings node if you're using rstexbin textures.

Hi not sure if this should be its own thread at this point, but I wanted to ask a question about the "render all frames with a single process" option in LOPS.

Basically, since the beginning, this option has been a big point of confusion when rendering with redshift. It has never worked reliably. Seems like object transforms and camera moves are respected, but anything else like animated point attributes or uv transforms never ends up working (rs will just render the first frame over and over). This leaves any redshift user in a situation where they are extremely limited in the types of scenes that can be rendered quickly in a single process. Otherwise, you have to tell husk to reload every frame and which is super slow and not practical unless you have access to a farm etc.

Anyway, I understand this is an RS issue (this all works in karma as far as I can tell) and it has been brought to the attention of their devs in the past, yet it seems like they are still at a loss about how that option affects HUSK at the USD level or if it's something unique to Houdini itself. Wondering if you have any suggestions that could help shed some light on the subject.

Thank you!