Control Particle and Curve Size in Karma | Houdini 19.5
ฝัง
- เผยแพร่เมื่อ 15 ต.ค. 2024
- When rendering particles or curves inside of Solaris and Karma you are going to want to be able to control the overall size. There are a few ways to achieve this but some that you would think would work do not. This video will go over how to control the particle and curve size in Solaris and Karma using Houdini 19.5.
Join this channel to get access to perks:
/ @insidethemindspace
Join my Discord here:
/ discord
Leave a like and a favorite if you enjoyed. Subscribe if you want to.
Please let me know what you thought of the video.
Follow me-
insidethemind....
/ stormz3d
/ mindofstormz
www.artstation...
#houdini #houdinikarma #houdinisolaris
A little bit tricky and kinda weird is the understatement of the year when it comes to Houdini :D Thank you for a superb tutorial!
I finally understood how to do pscale in Karma, thanks, it's very important, this was something I didn't understand.
Glad you found it useful!
Awesome tutorial, really looking forward for more.
Oh, you saved me!!! I'm already was ready to get rid of curves in project... Thank you a lot!!!
Glad you got it figured out
Another gotcha, to import @Alpha into MaterialX, you need to use displayOpacity as the name instead of Alpha. Even if you have Alpha attribute in geo context.
For curves i /geo, I found using @widths directly instead of @pscale worked.
do you know how to render the Alpha attribute for the particles? I've set up @Alpha base on the position, but I cant get that to render in Houdini
I know how to do this but am blanking. How would you tie the width the age of the particle? So you create a tapered affect?
You could set up a wrangle and set the pscale equal to the age. You may need to fit the range though to whatever size you want or clamp it depending on what you are looking for.
@@InsideTheMindSpace Thanks!
Great
This is expected behavior. This has to do with parameters setting the radius, and not the diameter.
Radius is always half the length of diameter. If you create a Sphere in SOPs you will encounter the same math.
I didn't even think about it being the radius. To me "width" refers to the entire width not just the radius. I don't think labeling it as the width is clear that it actually is referring to the radius but oh well
@@InsideTheMindSpace Admittedly it can be confusing sounding at first. When you think about how diameter is visualized however, as a cross section line from one outer edge to the other, then you can see that radius could also be considered “width” as it too is a cross section line, just from the center to the outer edge.
USD definitions are driving this choice to use “widths” as the attribute name too. In the docs they mention all of the common Houdini attributes that will be converted into the USD spec. Here’s the width/pscale one.
“width, widths, pscale
All of these may be converted into the USD widths attribute.”
If you were to check the Draw Curve node as another example, you will see a mention of the “width” attribute it creates as being the radius of the curve. This mention is definitely tucked away though and only found if you use that node.
Yeah I understand that USD is driving the naming conventions. The choices that were made for a lot of what goes on in USD do not necessarily make sense at first glance which is a big reason for it not being widely adopted at this point in my opinion. It will never happen but I would like to see them rethink some of the naming conventions and the way things are setup so that new users wouldn't feel so overwhelmed when trying to learn the process.
@@InsideTheMindSpace USD is absolutely widely adopted currently and only growing. Every major studio in feature work is using USD, many design shops are hoping on board, and it’s only gaining more traction. Side Fx road map is to fully integrate USD more and more. It’s definitely not going away. Evolving over time? For sure.
Being the holy grail solution to finally having universal project builds that can be exchanged between DCCs without issue any of the BS conversion headaches and incompatibilities of going between world scales, and coordinate differences each DCC chose to default to is huge.
Add in a render material format that’s also universal (MaterialX), and it’s a no brainer. 😁
The workflow is very different that what most DCC users (Cinema4D primarily) are use to, but C4D was always behind the ball when it came to industry standards. Even they are coming around to the reality that the future is USD and the if they want to stay relevant they will need to at least support such standards.
USD is definitely the future. I will agree with that but widely adopted is not the term I would use. It is starting to get there but things like obj or alembic are or were widely adopted and used by everyone. USD is becoming the industry standard yes. There are tons of advantages to USD but it's also not the easiest to understand if you are new to it which I think is something that needs to change.
As far as Cinema 4D being behind the ball on USD that is an understatement. They were asked about it awhile back and they hadn't even heard of it. That is kind of ridiculous coming from one of the major DCC's.
Mtlx also has a lot of growth to go before it reaches its full potential but without a doubt it will get there.