I've been getting segmentation fault crashes ever since 19.5 303.
In various situations, some repeatable some not, on two different machines, with and without redshift installed.
19.5 is bloody unstable.

antc

OneBigTree
Yes, and I do not blame SideFX for the USD language. It's just that there are already several languages to learn in Houdini itself. USD just adds more hurdles for someone who didn't grow up with Houdini and doesn't even know all the "native" syntax for it, and now things are called differently again.

Each context in Houdini tends to have its own concepts and associated learning curve. Have you checked out the lops quick start [www.tokeru.com]? Using displayColor is covered on there.

The Usd Guide [www.tokeru.com] is really good as well.

I have seen it.
The point is: it shouldn't be required just to use Karma properly. A third party renderer like Redshift can be mastered in a day. Karma and the associated new additional contexts and modes require studying, practicing, learning new syntax, tutorials etc. all to get the same thing done.
I don't mind things being done differently. I always have a problem with things being done in the most tedious way possible

However I do understand that this is the result of decades of everyone cooking their own soup and believing every artist only uses one single software ever...

I remember putting up a post in the blender forums starting a discussion about industry standard viewport interaction. I got a wave of objections and flaming and it resulted in Ton writing a letter where he stated basically that blender was made for blender users and industry standards can in fact go and stick their head in a bucket of hot water.
Now look what happened eventually in 3.0: Industry standards. But it took 10 years.

I do hope MaterialX is a path to more standardization. Unfortunately SideFX put Solaris between the artist and this new shader format. A single artist doesn't need USD. Ever. But they need a fast renderer - always.
For me Houdini is just a part of my toolset. I do everything in the CG process from start to finish including compositing. So I don't and can't spend all my time in Houdini, doing tutorials and courses and learn by doing 8h a day. And I am sure there are many more like me out there.

antc

protozoan

OneBigTree
More special syntax

Technically, in this special case, it's not SideFX' fault, it's a USD-term. Pixar's to blame.

Unfortunately just the balancing act that arises from creating universal terms in the face of DCC’s that invented their own special names for things.

Yes, and I do not blame SideFX for the USD language. It's just that there are already several languages to learn in Houdini itself. USD just adds more hurdles for someone who didn't grow up with Houdini and doesn't even know all the "native" syntax for it, and now things are called differently again.

I have been waiting for the first daily build in the hope it fixes the tendency of 19.5 to exit without any warning in unexpected moments. It didn't.
I don't know what it is but 19.5xxx seems much less stable. I would post a crash message but I do not get any. Just CTD.
I am experiencing this on two different machines with different hardware. (win11, AMD CPU/Intel CPU, Nvidia RTX) 19.xxx never had this issue. It happens in completely different circumstances. Sim, rendering, modelling, pressing undo, stuff like that. Very concerning.

Am I the only one?

brians
> does karma xpu in houdini 19.5 support out-of-cores?

19.5 has something called "demand-loaded" textures.
This means only texture tiles that are needed to render the frame are loaded into GPU memory.
So this means 19.5 is much more efficient with texture memory than 19.0

> and if not , are you going to support it before houdini 20 or only in houdini 20?

We plan/hope to get texture "eviction" working for H20.
Which is what you're calling "out-of-core".

It's a tricky thing to get right + stable, so it takes time I'm afraid.
Cheers

Any chance of getting background texture (view) sequences loaded into RAM instead of VRAM (OGL Texture Cache) ?
It never made any sense and Houdini is the only 3d Application that does that. Now we need VRAM for rendering and squeezing large sequences into 12GB VRAM instead of the 128 Gig of RAM always requires extra adjustments, conversion, loss of resolution and is in general a nonsensical solution. If you have ever tried to place tiny objects with pixel accuracy into a 5k 20 sec aerial shot, then you know what I mean. I can do that in a 6 year old software that isn't even being developed anymore and render with Redshift at the same time.
I think that should help with freeing GPU memory in many cases.

What about viewport background texture loaded into GPU memory? Having large sequences in the Background can easily take up all your GPU memory. It is a feature that I never understood the reason for since I am sitting on 128gb of RAM and I have to squeeze it into the GPU mem which I need for rendering.

When will this change? I suppose this will be helpful when working with Karma XPU as well as in general. It is an absurd feature and surely easier to fix than implementing out of core rendering....

wanglifu

OneBigTree

Enivob
You can only mix colors, not shaders, so you'll have to adapt your material strategy to leverage that.

Thanks for posting this. I was about to ask the same question.
Time to dive into MtlX I guess.

Are you accessing the CD attribute by any chance in your network?

Just use Mtlx Geometry Property Value node to bind any attribute,but Cd is a special one,you should call it displayColor in solaris.

I see. I had no luck accessing Cd with the geo property. Now I know why. More special syntax... However there is a node specifically for accessing color which works without any additional conversion.
Thanks for the response.

I would love to know that too.

Enivob
You can only mix colors, not shaders, so you'll have to adapt your material strategy to leverage that.

Thanks for posting this. I was about to ask the same question.
Time to dive into MtlX I guess.

Are you accessing the CD attribute by any chance in your network?

Any news on this? I am having the exact same issue with the .622 build.
Billowing smoke shelf tool renders every few frames black.
In the Karma viewport, rendering to Mplay and to disk, all the same.

Edit:

I think I found what this issue is related to. When I run a simulation with mem cache on and the render with Karma I get a black frame every now and then. However, if I turn off mem cache and render the sim directly (simming every frame at render time) then all is fine.
Tested in .589, .622 and .655.

Just want to add this:
If you have a calculated rotation (like an expression based on $F) the Karma ROP viewport will not render motionblur for that rotation. If it is keyframed, it will.

shouldn't that be a light option, not a global view option?

Aizatulin
divide (avoid small angles)

Thanks
I've used remesh with only the large polygons selected. It triangulates the rest of the object.

soulcage_dpt
hi,

i have 1x houdini indie.
i wrote a little python script that can submit a houdini file to backburner with hpython2.7.exe, hrender.py and redshift as the renderer for network rendering...
for testing i installed houdini indie on 2 PCs.
but only the one PC that has the license server installed can render.

is houdini indie capable of network rendering (like mayabatch) with only one license?

Nope, not Indie. But what you can do is to get 3 free engine licenses and use them for network rendering.

No answer to that in 5 years?

SIgor420
Hi folks, me again. This time with trying out DM modeling with vanilla Houdini stuff. At this point, I am not really sure why people are saying that DM modeling sucks, or it's not possible or I should not do it in Houdini. From what I have learned in the past two weeks is that things are quite the opposite. I have found a lot of nice solutions for different modeling tasks. I have to spend a lot of time trying out things and I am quite happy with what I can do with Houdini DM. It needs a bit more functionality to really make it awesome, like for example, Proportional Beveling. Now, I can see how people might have an impression that DM sucks in H. I have watched a gazillion of tutorials and none did show DM modeling in a way I managed to model this. So it's not about that H sucks in this regard, it's more about others simply not demonstrating what's possible and how.

This is still a work in progress. I plan to push this as far as possible.

It's not that it sucks (with the additions in the past two years that is) or that it is not possible. It is just that modelling is still faster and more direct in other tools. Like XSI....
But as I said a lot has been done and I find myself using it more often for the entire workflow.
The biggest issue for me is still the lack of multi object editing. Having a model consistent of many parts, all in one tree with only tedious methods to directly select and transform a part in the viewport is slowing the flow down a lot. Being able to just grab all upper points of windows, doors and walls and adjust the y position - while having them being separate geo - is something you don't want to miss...

In the end what makes you the money is never what you can do but how fast you can do it and how many people you need.

Hans Palacios
That parameter Preserve Bubbles is set up to hide when the Method parameter is set to its default option, Average Position. When the Method is changed to Spherical, then the Preserve Bubbles parameter is made visible. The conditional for the Preserve Bubbles visibility is noted in the Hide When field of the Edit Parameter Interface screenshot.

Oh, thank you. I wish the manual was as clear as you, and I wasn't as blind as a mole

toadstorm
You can introduce divergence into the simulation, either through a point attribute on the FLIP points or by sourcing a divergence field from SOPs with a positive value. Positive values will force the volume to expand around the affected areas.

Thank you that helps a lot. Never thought of divergence in that context.

Have you tried unpacking the abc file after load before instancing or recaching?

Can someone explain why "preserve bubbles" is missing from the UI in the particlefluidsurface node in H 18.5 (563)?
It was there in 2020 still according to the screenies in this thread:
https://www.sidefx.com/forum/topic/74336/ [www.sidefx.com]

This is a screenie from yesterday:



The parameter is there in the UI editor and is not hidden.
Is it in any way conditional? The docs don't say anything. Mysteriouslier...