Morning all,

I've hit a stumbling block with Solaris (H19.5 & Redshift), I'm going through some R&D using SOLARIS, as it was time I started using that environment for rendering. But what I've noticed is that using RS in SOLARIS is very slow to render, the main problem being between frames:

I can render 19 frames in 1 minute at SOP level
In SOLARIS I can only get 3 frames rendered in the same time

I've scoured some of the forum, and it is suggested to render in one process. I think that's a Karma thing and not RS!?

I'm a one man band so rendering and time taken can be quite important as I don't have a farm of machines to offload to. Any suggestions as to what may be going wrong? Is it a 19.5 thing?

I've tried Karma and H20, but I decided to go back to RS as I believe it isn't quite ready for going full on Karma I was really hoping not to renew my RS sub in March, but I don't think that's going to happen until there is a level of maturity in the XPU render engine.

Scott

without knowing what is going on in your hip file, but maybe the export to redshift takes more time in lops than sops.
I don't find the redshift delegate to be slower

There really isn't a lot going on, there are 2 characters dancing with hair applied, it scrubs fine as you are working, transformation is baked, hair is cached, and as you scrub it updates fine.

It's going to actual render that's the problem in SOLARIS. To be fair I'm running H19.5.640 and using RS 19.5.716 so maybe there is some sort of mismatch there. But it is basically when the render is complete (5 secs), the frame loading takes about 15 secs to do it's thing and then another 5 sec render.

Whilst my original method of doing it all at SOPS level, it is infinitely faster so maybe I will keep with that method until I can count on H20 and Karma XPU to do the heavy work. I have tried but found that rendering is very hit and miss with Karma XPU



Unfortunately, when recording any dialogue wouldn't record as I'm capturing the actual H window. But it is very slow when rendering to disk or Mplay.

Your graph has a time dependency which will make it very slow since it has to regenerate every frame. If you have cached animation time samples the graph will no longer be time dependent and it should be able to start rendering any frame immediately.

jsmack
Your graph has a time dependency which will make it very slow since it has to regenerate every frame. If you have cached animation time samples the graph will no longer be time dependent and it should be able to start rendering any frame immediately.

Ahhh that is the little green timer icon on a node then? I'm relatively new to Houdini so forgive my newbness.

TBH, I thought referencing objects in to SOLARIS would automatically be like a packaged element, it sounds like SOLARIS is a wrapper for SOP components. So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering, but I have to say, scrubbing the timeline is OK, no where near as laggy as rendering to MPlay or Disk. I was surprised but I need to learn these nuances and thanks for the heads up

Many thanks

Pixelised
So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering,

You want to cache them AFTER they come into solaris, there is a heavy price to pay for the sop to lop translation.

jsmack

Pixelised
So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering,

You want to cache them AFTER they come into solaris, there is a heavy price to pay for the sop to lop translation.

I'm afraid I'm currently not having any luck with this scene, I think I'll try another one, one thing I have noticed with RS as a delegate is that Motion Blur is automatically on, I can't turn it off and maybe that's why I'm getting a slow response between frames. I've cached all streams and it doesn't make any difference

Got to love learning by error

Scott

Pixelised
one thing I have noticed with RS as a delegate is that Motion Blur is automatically on, I can't turn it off

Did you try to enable "Instantaneous Shutter" for that?

jomaro

Pixelised
one thing I have noticed with RS as a delegate is that Motion Blur is automatically on, I can't turn it off

Did you try to enable "Instantaneous Shutter" for that?

I did find that in the Main settings of the redshift render node but on clicking it still keeps the motion blur enabled. I thought this might be the problem as it will need to assess a frame either side of the current render frame.

TBH, I'm just going to go back to the old way of rendering for future projects, but I will keep my eye on SOLARIS as I do like building my scene out that way.

Thanks for your help peeps

Scott

Here's a proper comparison, with simple objects, simple Vellum and there is still a huge delay between processing frames in LOPS compared to SOPS. WHYYYY!!???



After this video, I thought I'd try Karma XPU and that rendered 6 frames in SOLARIS, again there is something going on in the BG that is causing a bit of a bottleneck. Grrr.

Pixelised
Here's a proper comparison, with simple objects, simple Vellum and there is still a huge delay between processing frames in LOPS compared to SOPS. WHYYYY!!???

After this video, I thought I'd try Karma XPU and that rendered 6 frames in SOLARIS, again there is something going on in the BG that is causing a bit of a bottleneck. Grrr.

They way you've set this up will guarantee that it will be very slow. The default way to render sequences out of solaris assumes that the render will take long enough that the cost of generating the scene and starting the render process will be trivial. However, if the scene itself is trivial and the render time also, then the cost of restarting the render and loading a single frame scene will be high in comparison. For renders that are super trivial 2 second renders of micro scenes like this, it's much better to render sequence at once instead of frame by frame.

jsmack
They way you've set this up will guarantee that it will be very slow. The default way to render sequences out of solaris assumes that the render will take long enough that the cost of generating the scene and starting the render process will be trivial. However, if the scene itself is trivial and the render time also, then the cost of restarting the render and loading a single frame scene will be high in comparison. For renders that are super trivial 2 second renders of micro scenes like this, it's much better to render sequence at once instead of frame by frame.

Thanks for the explanation, I did wonder if SOLARIS was best used for huge and complex scenes. Thankfully the render single process works, but it only seems to work for the Karma render delegate. I'm now trying H20 XPU again with a scene to see how that works out, but from my initial tests I had flickering in the shadow areas, like there was a bounce light and then not. It was very odd.

But maybe trying the render single process will give a more consistent render.

Thanks for your help

Scott

Pixelised

jsmack
They way you've set this up will guarantee that it will be very slow. The default way to render sequences out of solaris assumes that the render will take long enough that the cost of generating the scene and starting the render process will be trivial. However, if the scene itself is trivial and the render time also, then the cost of restarting the render and loading a single frame scene will be high in comparison. For renders that are super trivial 2 second renders of micro scenes like this, it's much better to render sequence at once instead of frame by frame.

Thanks for the explanation, I did wonder if SOLARIS was best used for huge and complex scenes. Thankfully the render single process works, but it only seems to work for the Karma render delegate. I'm now trying H20 XPU again with a scene to see how that works out, but from my initial tests I had flickering in the shadow areas, like there was a bounce light and then not. It was very odd.

But maybe trying the render single process will give a more consistent render.

Thanks for your help

Scott

Render in a single process should work for any delegate, I would think, as it's a husk feature, not a delegate feature.

The RS log files will tell you exactly what your per-frame cost is coming from.

jsmack
Your graph has a time dependency which will make it very slow since it has to regenerate every frame. If you have cached animation time samples the graph will no longer be time dependent and it should be able to start rendering any frame immediately.

jsmack
Your graph has a time dependency which will make it very slow since it has to regenerate every frame. If you have cached animation time samples the graph will no longer be time dependent and it should be able to start rendering any frame immediately.

jsmack

Pixelised
So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering,

You want to cache them AFTER they come into solaris, there is a heavy price to pay for the sop to lop translation.

jsmack

Pixelised
So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering,

You want to cache them AFTER they come into solaris, there is a heavy price to pay for the sop to lop translation.

jsmack

Pixelised
So I will go back and check this a little later to see if I can cache all elements before coming over to SOLARIS for rendering,

You want to cache them AFTER they come into solaris, there is a heavy price to pay for the sop to lop translation.

What is the correct way to render redshift shadow passes in aov for use in comp with nuke