Thanks for giving that info, I wouldn't have thought about a separate pane.

Do you know of a better way of doing this then? I guess I'm used to working in SOP mode due to using OR / RS in the past, however, I really want to drive down subscriptions hence going for Karma as my choice of render engine.

I would love to avoid the lag of writing to disk via this route, maybe for the next part of the project I can implement that, but is there definitely a way of doing so, I do get frustrated with the lag. At the moment, I can easily animate in the SOPS environment for this phase of development, do you know of any good tutorials or even have suggestions yourself?

Cheers

Scott

Hi all,

It's not often I visit these forums but I'd love to know if this is possible, basically I've been creating some illustrations of dancing ribbons, it's not dynamic, but I control various elements within the SOP build.

This is all fine when using OR to render as I can remain in the SOP context. However, I have shifted the project over to Karma / Solaris. With that, when in the Stage context I cannot access the SOP CTRLS anymore, is there a way of importing those pre-made CTRLS into the Solaris environment? I hope this makes sense!!!

My CTRLS are exposed:



When in Solaris I would love to tweak in the Stage context?

I'm also trying to transition away from the Maxon licensing system, used to use C4D, moved to Houdini. Use Redshift but can't quite move away just yet. I think for the freelancer it is a hard transition as Karma / USD would appear to be for the large scenes and not the archetypal motion piece.

I am persisting as my license of RS runs out in March and I really hope to go over to XPU, but it isn't as full featured or efficient as RS. After all RS has been going some years and has a dedicated team to just rendering. Fair play to the H guys and Karma team.

Along with another thread, just remember to tick "Render all as one process" if you are rendering multiple frames. I think the fact RS isn't available to H20 just yet means more and more people are trying Karma.

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

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.

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

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

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

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.

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

Thank you Tamte,

Much appreciated and nice to see an alternative to YT

Scott

Hi all,

I've been scouring the internet for examples of how to convert geo to the new cloud (Skybox) format, but having no luck in finding anything out there. I'm relatively new to Houdini, so never used the deprecated system, and I assume this new skybox method is the way forward in H20.



I'm using cloudshapefrompoly - but I have no concept on how to mesh / vdb it to the new skybox format. I noticed in the original keynote that they had used a biplane with spinning prop, and I would like to achieve that kind of look down the line.

Anyone had success in doing something along the lines of that keynote example? Any documentation would be great.

cheers

Scott

Imagine if developers said why should I develop for Intel chips back in the day. I'm sticking with the 68000, that's good enough.

Chips are getting smaller, getting faster and it is a progression. I don't think it's realistic that a laptop can outperform a dedicated workstation just yet. They will always be behind, but it's quite phenomenal that they are becoming so powerful after 2 generations IMO.

The M2 is as powerful as my 1950x that I type on. I can afford to run a sim for 20 mins or so on the 1950x, so I could afford a couple of mins extra on a laptop that can be taken anywhere. That's phenomenal IMO.

Rule of thumb, don't need it, don't buy it. But it may just enable more options if you need it.

Benchmark I was referring to:

https://www.cpubenchmark.net/singleCompare.php [www.cpubenchmark.net]
https://www.cpubenchmark.net/compare/5719vs5060vs5031/Intel-i7-14700K-vs-Intel-i7-13700K-vs-AMD-Ryzen-9-7950X [www.cpubenchmark.net]

@Syngum - I'm quite impressed given this is the 2nd gen apple chip, and it has the power of a 32 threaded workstation in a small form factor. I think that is quite something. But, yes, is it suited to simulation work, probably not, depends on how much time and patience you have, but it might get you through with regular modelling / texture and rendering work.

Definitely going to follow this thread, as I'm thinking about an upgrade and I'm running a 1950X from 6 years ago, it's not bad but as we always "need" faster machines I'm interested to see how the M3 Pro will stack up.

I did a CPU benchmark and an M2 Pro was slightly slower that a 1950X, albeit impressive in itself given it's a laptop. I've also heard that you never hear the fans kick in. So it will be interesting to see where the M3 Pro sits, I'd anticipate a 15% increase judging by the M3 presentation the other day.

With all this in mind, what would it be like on day to day usage, and over a year! The 7950X is about 2.5x faster and probably makes more sense to upgrade as a workstation scenario. But I like the small form factor it has to be said.

Will be interesting to see how and what comes out soon I hope I haven't derailed this thread...

After looking a little more into this, one optimisation I did make was the colliding mesh was better to be converted into a VDB model, it's a sweet with lots of choc chips added. Major improvement in SIM speed as a result, just checked my graph and it has also helped.

A very heavy mesh might have got converted when using DOPs level, but not automatically done during the SOP method.

I'm clutching at straws with my explanation, but I'm happier I can see results at almost a 200% speed increase

Hi all,

I decided to load up an older project which used DOPS to carry out a FLIP sim. I decided it was time to embrace the SOP way of using FLIPs. But on doing so, I've since discovered that there is a serious bottleneck, I wondered if anyone else had encountered this problem? If so, what can be done to speed up the sim?

Here's 2 screenshots, the DOP showing better simming speeds.

Cheers

Scott

From what I saw in that keynote re: the football being volleyed etc... It would seem you could create 4 key points in a walk cycle and have the "Dynamic Motion" do the in between stuff. It may get to 85%-90% of what you are after.

I have to say, not being a character animator I am excited to see this part of Houdini being pushed, and actually innovating compared to the regular character DCC tools out there

Just found there was an issue with the same thing in another thread (4090), so it was a driver issue, and using a non-production build of Houdini gets round this particular issue

Hmmm this is strange, first time in a while I open up Houdini to do some Vellum work and then BAM, as above I'm getting the same problems. Anyone else?

I'm running a 3090RTX and I do have the latest NVidia studio drivers, I wonder if they broke something?

Scott