Is there a way to work with Solaris to use Karma MaterialX shader or any Karma shader support without translates asset to openUSD for FX dynamic works like RBD, water FX?
The way this Solaris do is amazing and smart.
Karma is a great improvement for FX works, love it so much.

However openUSD translate is what pulls back productivity. Double the cache process into two real from Houdini then to openUSD if do want to see things in animation. The poor performance of the viewport; Scene Graph keeps refreshing according to any changes on prim path on the node is a backward user experience.

Display multiple million fragments in Houdini viewport is quite normal, however in Solaris even use the view port loadMask, plus payload -> the process to translate USD, and refresh Scene Graph keep haunting any workflow for FX.

Scatter millions of different tree models is good, however for FX like RBD to reveal millions of unique name pieces, 10 millions of debris -> the open USD translate process keeps productivity down, even the amount of stress a person who uses Solaris has to calm.

about the hi-poly tree scatter -> for more than 15 years ago until now I did a lot in architectural animation + commercial production easily without any of `reference` concept; just with ancient V-Ray proxies, XREF scene in 3DS Max,...)

If Solaris can have another stage of the process for users to choose between migrating to openUSD or just using what Houdini usually do with FX, that would be great, improves productivity a lot with new amazing technologies and good production application.

P/s Image attach to share per click on node instance points, only 30,000 points. The time it took that not included the init time of Solaris for the process and the ending of that process

I would definitely encourage you to send under-performing scenes to us via support. It may be that we have immediate "if you reorganise things like *this* it'll be significantly faster" advice, or that we discover areas to further improve.

You mention, for example, RBD for debris. This is an area where we have invested energy to provide specific solutions to handle large quantities of data.

But again, I hope you'll send us your problematic scenes so that we can continue to learn from each other.

robp_sidefx
You mention, for example, RBD for debris. This is an area where we have invested energy to provide specific solutions to handle large quantities of data.

For large quantities of geometry, it's better to have a single prim with a positions time samples, right? At least for raytracing performance. With mantra rendering, I always unpacked packed geometry unless there was simply too much to fit in memory unpacked.

robp_sidefx
I would definitely encourage you to send under-performing scenes to us via support. It may be that we have immediate "if you reorganise things like *this* it'll be significantly faster" advice, or that we discover areas to further improve.

You mention, for example, RBD for debris. This is an area where we have invested energy to provide specific solutions to handle large quantities of data.

But again, I hope you'll send us your problematic scenes so that we can continue to learn from each other.

Thank you, I have sent email to support. I am looking forward to learn more how to render destruction scene from Houdini to Solaris in peaceful and calm.

**Just want to clarify, it is not debris. It is fragments from hero RBD solve. The Scene Graph Tree has more siblings (30K pieces) than debris as debris geo just a few then re-present instance points, similar with tree scattering. Here is Solaris in action with 1 geo tree scatter 1.69millions copy, no problem: https://media.giphy.com/media/GItcgPds1Av7SYC3C4/giphy-downsized-large.gif [media.giphy.com]
The thing is Solaris keep refresh the Scene Graph update. If I delete nodes in Stage, Solaris will process again for a while.

paranoidx
The Scene Graph Tree has more siblings (30K pieces)

Not totally sure without screen shots, but the above sounds like you might be creating a separate USD primitive in lops for each packed piece in sops. For decent performance with 30K instances you'll probably want to use a pointinstancer in lops which generates just a single primitive for all the instances. On my laptop here I can get about 15fps with 30K sop animated pigheads pulled into lops as a pointinstancer. But as individual primitives I get about 10 frames per minute, so many many times slower.

antc

paranoidx
The Scene Graph Tree has more siblings (30K pieces)

Not totally sure without screen shots, but the above sounds like you might be creating a separate USD primitive in lops for each packed piece in sops. For decent performance with 30K instances you'll probably want to use a pointinstancer in lops which generates just a single primitive for all the instances. On my laptop here I can get about 15fps with 30K sop animated pigheads pulled into lops as a pointinstancer. But as individual primitives I get about 10 frames per minute, so many many times slower.

I do appreciate your time taking to reply to my suffering with USD about RBD.

However before go to forum look for a solution, I did research with documents, cgwiki, USD survival guide, pixar USD. I have double check by apply 3 different methods (sop import direct, sublayer, instance points) for this case of RBD fragments but not talking about debris pieces which are collection of geometries re-present for later variant copies into instance points. That you can have 2 3 million even 5 8 million right on viewport. The same with the tree visualization in the link attached to my post above.

In the end, I submitted my scene to Side FX support, I hope to learn more from their correction.

paranoidx
owever before go to forum look for a solution, I did research with documents, cgwiki, USD survival guide, pixar USD. I have double check by apply 3 different methods (sop import direct, sublayer, instance points) for this case of RBD fragments but not talking about debris pieces which are collection of geometries re-present for later variant copies into instance points.

Yep I just meant that regardless of what mechanism you use to pull the data into solaris, you'll want to make sure that the usd representation is utilizing a pointinstancer, rather than individual instance prims. For example when using sop import, you'll want to select "Create Point Instancer" for packed primitives (assuming you're using packed primitives of course). The default is "Create Native Instances" which will likely not be performant for the quantity of pieces you've been mentioning.

Anyway good luck and I hope support is able to help!

antc
Yep I just meant that regardless of what mechanism you use to pull the data into solaris, you'll want to make sure that the usd representation is utilizing a pointinstancer, rather than individual instance prims. For example when using sop import, you'll want to select "Create Point Instancer" for packed primitives (assuming you're using packed primitives of course). The default is "Create Native Instances" which will likely not be performant for the quantity of pieces you've been mentioning.

I don't think there's any benefit to using a point instancer over create Xforms or Native instances when all of the pieces are unique. The most efficient way is more likely to import all the geometry as one mesh prim, (or a small number of different prims for material purposes) and use deforming geometry.

jsmack
I don't think there's any benefit to using a point instancer over create Xforms or Native instances when all of the pieces are unique. The most efficient way is more likely to import all the geometry as one mesh prim, (or a small number of different prims for material purposes) and use deforming geometry.

Ah ok - yes that's correct, if everything is unique a moderate number of deforming meshes would be the way to go.

jsmack

antc
Yep I just meant that regardless of what mechanism you use to pull the data into solaris, you'll want to make sure that the usd representation is utilizing a pointinstancer, rather than individual instance prims. For example when using sop import, you'll want to select "Create Point Instancer" for packed primitives (assuming you're using packed primitives of course). The default is "Create Native Instances" which will likely not be performant for the quantity of pieces you've been mentioning.

I don't think there's any benefit to using a point instancer over create Xforms or Native instances when all of the pieces are unique. The most efficient way is more likely to import all the geometry as one mesh prim, (or a small number of different prims for material purposes) and use deforming geometry.

Yeah I did, "import sop" that what I do when working with Solaris ( 1 branch for rest to do material assign, then apply sub-layer to add next "import sop" which has animated transform rbd), other methods is what I digging into Solaris document and others while the scene is really slow (compare to SOP regular working)

So for quite a time with support and still wait for their reply.

I recently discovered that my version of Houdini initiates a recook every time, even when clicking into a non-cook node like file cache. This appears to be the root of the problem. Currently, I've had to disable simulations when not actively using them by clicking on the "brain icon." This behavior was not present in the previous version of Houdini that I had installed. It's possible that something went awry with the user configuration when transitioning from the previous version to the current one. Your assistance in resolving this matter is highly valued.

My Houdini is 20.0.547