those will only be seen in the viewport only if your geometry display is set to Show Current Operator and you have entered current node's state
- so you can hit Esc in the viewport to exit the state
- or click on empty network editor space to unselect the current node, you will still see it's paremeters
- you can also switch geometry display to Show Display Operator if you never want to see the state of the current operator
- or just move your Blast above the Noise node
Found 5503 posts.
Search results Show results as topic list.
Technical Discussion » How to hide template view ?
- tamte
- 8555 posts
- Offline
Technical Discussion » List of local variable
- tamte
- 8555 posts
- Offline
metaclay2they are Constants, which represent more human readable alternative to just typing integer numbers
Btw , i found something else like D_X / D_Y / D_Z . Since we can't use it with '$' prefix then they're not variables ,right? what species is this other than variables and attributes ?
like in centroid() hscript function [www.sidefx.com], you can use
D_X, D_Y, D_Z
0, 1, 2
however for bbox() hscript function [www.sidefx.com], it may be much clearer to use:
D_XMIN, D_YMIN, D_ZMIN, D_XMAX, D_YMAX, D_ZMAX, D_XSIZE, D_YSIZE, D_ZSIZE
0, 1, 2, 3, 4, 5, 6, 7, 8
Technical Discussion » Different result for the same 'rand(1)' expression
- tamte
- 8555 posts
- Offline
metaclay2if you really want the same result as Hscript expression in the parameter provides you can use hscript_rand() function
I added a 'Attribute wrangler' and use this code to create xx primitive attribute :f@xx = rand(1);
f@xx = hscript_rand(1);
Edited by tamte - March 15, 2024 13:26:38
Solaris and Karma » Getting curved motion blur (substeps?) in Solaris
- tamte
- 8555 posts
- Offline
robp_sidefxis this something that needs to be brought up with USD team?
USD just does component-wise linear interpolation of the matrices, which is why you get the shrinking you saw.
since it has always been an issue
xform property *.xformOp:transform:xform clearly represents transform so should be interpolated as such by usd
I've never understood why there need to be crutches like Resample Transforms LOP to seemingly get around that and create more data on stage, which still can be sampled only at timesamples to be correct no matter how much resampled they are, which on top of extra steps opens issue of keeping resampling in sync with render or other processes that just need transform value at specific time etc...
Houdini Indie and Apprentice » Save Simulation Metadata in Cache
- tamte
- 8555 posts
- Offline
storing them as Detail attributes is a common practice
you can also use Attribute From Parameters SOP to get the values in arguably easier way than wrangle with relative references, especially if most of the values come from only a few nodes
you can also use Attribute From Parameters SOP to get the values in arguably easier way than wrangle with relative references, especially if most of the values come from only a few nodes
Edited by tamte - March 15, 2024 10:42:57
Animation » Full Body IK - Bug or intended - Demo scene included
- tamte
- 8555 posts
- Offline
mrpdeanone of the ways
What would the syntax be if I wanted to exclude multiple bones?
@name!=root,ik_foot_root,ik_foot_l,ik_foot_r
@name!=root,ik_foot_root,ik_foot_[lr]
@name!=root,ik_foot_root,ik_foot_?
Edited by tamte - March 12, 2024 23:57:45
Solaris and Karma » Solaris Cryptomatte question
- tamte
- 8555 posts
- Offline
seems correct to me, it may not be what you are used to seeing in Nuke for example, but that's the layers
the first non numbered layer while shows data is actually deprecated, but can serve as a preview, the numbered ones encode the data in pairs of IDs and coverage masks
and you have 3 of them because you probably kept the default max overlap at 6, which is 3 pairs so 3 layers
but regardless of how many layers you use to encode your cryptomatte, in composition software they will all belong to one entry in Cryptomatte node called CryptoObject and one called CryptoMaterial etc..
the first non numbered layer while shows data is actually deprecated, but can serve as a preview, the numbered ones encode the data in pairs of IDs and coverage masks
and you have 3 of them because you probably kept the default max overlap at 6, which is 3 pairs so 3 layers
but regardless of how many layers you use to encode your cryptomatte, in composition software they will all belong to one entry in Cryptomatte node called CryptoObject and one called CryptoMaterial etc..
Edited by tamte - March 12, 2024 20:28:33
Animation » Full Body IK - Bug or intended - Demo scene included
- tamte
- 8555 posts
- Offline
have you tried excluding the root from the solve?
in your fbik node set Group to:
in your fbik node set Group to:
@name!=root
Edited by tamte - March 12, 2024 17:29:04
Houdini Indie and Apprentice » Animating/Activating/Masking Displacement (Mountain). How?
- tamte
- 8555 posts
- Offline
on Mountain SOP enable Blend and change dropdown from Constant to Use Attribute
then specify float attribute that contains your animated mask
then specify float attribute that contains your animated mask
Houdini Lounge » A Comprehensive Feature List Between Karma XPU + Redshift
- tamte
- 8555 posts
- Offline
tbay312as I said I'm not using Karma ROP so not sure if its doing the correct thing
If an artist is trying to get that sub-stepped motion blur, they'll need to... 1. Generate sub-frame data in sops if it's not there, 2. Cache out sub-frame USD 3. Adjust render settings accordingly so that it's picking up the data. By comparison, with RS, it would be... 1. Generate sub-frame data in sops if it's not there and then 2. Adjust render settings accordingly so that it's picking up the data. So, in that way, working with USD isn't really equivalent to the conversion that RS does at render time
but regarding MB I was talking about Karma ROP and that "hidden" USD translation layer
enabling MB turns on internal Cache LOP path automatically and infers the caching steps from the stage settings
so theoretically should be doing what RS or Mantra do, as you said at "rendertime" but technically at scene translation time
in other words, in ideal scenario artist should not notice that Karma ROP is using usd under the hood, if all scene translators were doing the ideal and optimized thing
the fact that USD and LOPs allow you to do much more stuff should be irrelevant if the translator from Object to USD is solid and handles all kinds of cases
In my mind USD workflow in LOPs is completely different topic than just using .usd as a temporary scene description like .rs or .ifd, .ass, .rib with automatic translation layer from Obj
Which doesn't change the fact that it's currently not ideal so all this feeds into your points of it currently not feeling the same, but my point is that I don't believe it's due to USD itself
EDIT: Just imagine hypothetically that Houdini doesn't have LOPs and Karma ROP needs to translate the obj scene into it's scene description file let's call it .kma (which by coincidence would be identical to .usd, but you would now be able to officially call it non-usd, but would not be any better if the scene translators do the same job as now)
So Obj to .kma translators would need to be as optimized as obj to .ifd or to .rs at least that's my point of view
that's essentially what needs to happen with Obj to USD Stage (.usd)
the fact that we have LOPs to have additional control over this translation and on top of it is just a bonus
Edited by tamte - March 12, 2024 16:04:46
Houdini Indie and Apprentice » Most grains nocolide each other even with 12 substeps.
- tamte
- 8555 posts
- Offline
actually one more thing, since I was just testing with your merge bypassed as that was not colliding either with such high timescale
but
if you are merging with shapematched pieces, they by default don't collide within piece
and merging with the pile that doesn't have i@piece attribute would initialize them to 0 so the pile also wouldn't self collide nor collide with merged piece 0
to avoid this, set i@piece = -1; on your pile particles before packing and merging with pierces
but
if you are merging with shapematched pieces, they by default don't collide within piece
and merging with the pile that doesn't have i@piece attribute would initialize them to 0 so the pile also wouldn't self collide nor collide with merged piece 0
to avoid this, set i@piece = -1; on your pile particles before packing and merging with pierces
Edited by tamte - March 12, 2024 12:35:33
Houdini Indie and Apprentice » Most grains nocolide each other even with 12 substeps.
- tamte
- 8555 posts
- Offline
your Timescale is 1000
so you'd need much more substeps than 12 if that's on purpose
otherwise just set it to 1 and go from there
so you'd need much more substeps than 12 if that's on purpose
otherwise just set it to 1 and go from there
Edited by tamte - March 12, 2024 12:14:22
Houdini Lounge » A Comprehensive Feature List Between Karma XPU + Redshift
- tamte
- 8555 posts
- Offline
tbay312you may want to word these things differently
Thanks for commenting, and I'll elaborate on those topics. When it comes to a "non usd" workflow, what that means is that Redshift has the ability to process non-usd information that's compatible with pre-solaris workflows. By comparison, with Karma, everything must be turned into usd in order to render something. Even if you go with the Karma ROP, it's using a scene import all to turn it into USD and then render. That has some major implications on certain things. For example, that has an impact on motion blur because you'll need to cache USD sub-frame data in order to get curved motion blur. Yes, you do have the accel / v / w attribute for curved motion blur, but the quality doesn't hold up to sub-frame data if the motion blur is long enough. So, that would be a situation where it matters to have the option for a non-usd workflow if you didn't want to go through the extra step of caching out subframe usd. USD has many additional quirks that introduce extra steps to workflows, and extra steps = more opportunities for failure points in the workflow. It also has an impact on any studio that doesn't want to use Disney's public version of USD. With RS, you have the option to process non-usd info which may make it easier for other studios to build their own custom "USD-like" pipeline around it. With Karma, you may be able to do that, but it's much more closely integrated with Disney's version of USD, so it may be impossible / much more difficult.
since every renderer has to translate the Houdini scene to the format they can understand first, even if it's hidden from the user and only in memory, for Mantra it's ifd, for Karma usd for Redshift rs, etc
so talking about non-usd for Karma is like talking about non-rs for Redshift
what is the issue however is that the translation from /obj to LOPs is not as optimized as it is for ifd or rs since it has bottlenecks like:
- it dirties more of the stage than seemingly necessary
- doesn't have dedicated set of Karma properties on /obj level, which it easily could have and they would be 1-1 translated to stage
- probably more, but I haven't used it much
however MB shouldn't be an issue since there can be internal Cache LOP or Motion Blur LOP which is equivalent of Mantra caching the geo substeps before frame render or I assume Resdhift has to do that as well
so rather than calling it non-usd workflow or pushing for it, I see it more like oprimizing the translators and integrating the controls on Ojbect level that directly translate to the stage and then the "hidden" USD layer could feel like the hidden RS layer for Resdhift or at least that's my understanding of the whole thing
tbay312aren't references or instanceable references equivalent of rs proxies?
When it comes to "rsProxies" that also matters for freelancers and piplelines that use multiple software packages in their pipeline. In spite of the name, "Universal Scene Description" it is one of the least universally implemented formats between software packages at the moment because each software package seems to understand and write it out differently. Having the option to simplify the render data as a proxy is quite useful because it eliminates many cross-platform complications.
but of course for Object level workflows it would be ideal if Packed Disk Primitive pointing to .usd can automatically translate to USD reference on the stage, but that again comes to the translators and nodes like SOP Import LOP
Overall I agree that XPU despite being "gold" is missing a lot of features, for me Material blending is the major one, even currently supported surface shader blending doesn't not blend AOVs as we are used to from Mantra, but overall MtlX is currently very limited for any serious material authoring even with the addition of current kma nodes
some modern features would also be nice like AOV propagation through light paths (reflections, refractions, custom LPE, ...), roughness to bump, ...
Technical Discussion » HDA Parameters: Disable if there's a Geo in Second Input?
- tamte
- 8555 posts
- Offline
that thread is a bit old, since then there is a hasinput(n) function that can be used inside of disable when conditions [www.sidefx.com] for this purpose
Technical Discussion » Velocity doesn't work after converting paritcles to vdb
- tamte
- 8555 posts
- Offline
if it's literally just spheres you are copying onto your points and if your points have f@pscale attribute you can use
Particle Fluid Surface SOP
- set Method to Spheres
- set Particle Separation to 1 and Voxel Scale to equivalent of your VDB From Polygons
- include any attributes you want to transfer in Transfer Attributes parameter
- play with Filtering tab if you want the spheres to blend together a bit
Particle Fluid Surface SOP
- set Method to Spheres
- set Particle Separation to 1 and Voxel Scale to equivalent of your VDB From Polygons
- include any attributes you want to transfer in Transfer Attributes parameter
- play with Filtering tab if you want the spheres to blend together a bit
Edited by tamte - March 11, 2024 13:52:00
Technical Discussion » Snippet VOP not working with ch() ?
- tamte
- 8555 posts
- Offline
probinerjust remember that injecting parameter values this way (using Hscript or Python below) can't evaluate animated parameters as it essentially hardcodes the value in the code before compilation
Yeah for now I'll use backticks as a fix, feels hacky but works.
probinerif you mean replacing backtick Hscript expression that evaluates the parameter with Python
Now... if I want access such evaluation path from a VOP with from python, that's not possible right?...
then the trick is to returning the whole snippet code string using Python expression and evaluate the parm values using ch() or hou.Parm.eval() and injecting that in the string before return
Edited by tamte - March 8, 2024 10:54:56
Technical Discussion » Vellum Hair collision error - Colliding with ghost mesh
- tamte
- 8555 posts
- Offline
Add f@pscale to your logo collider and adjust accordingly
Seems like your scene is small and default collision radius is simply too large
Seems like your scene is small and default collision radius is simply too large
Technical Discussion » primpoints() with ends gives vertex count?
- tamte
- 8555 posts
- Offline
Len
EDIT: Just printed the points from primpoints() and it's duplicating point 0 at the end. Still doesn't make sense to me.
primpoints() will return points that the prim vertices are attached to, it will not deduplicate point numbers, so you will essentially get point per vertex
Edited by tamte - March 5, 2024 21:51:09
Technical Discussion » Snippet VOP not working with ch() ?
- tamte
- 8555 posts
- Offline
it's relative to the node that's specified in Evaluation Node Path parameter on Attribute VOP
so while you can make it relative to your Snippet using that parm, you will not be able make it relative to 2+ snippets respectively in the same Attribute VOP at the same time
the reason is also that at the end all VOP nodes contribute to a single VEX code that gets compiled so really all controls should be on Attrib VOP or higher
as all ch() references in that VEX code will be evaluated relatively to just a single node and that's why that control is on the Attribute VOP itself
while technically VOP nodes exist and can hold parameters, historically they aren't supposed to be animated or even considered for placing your controls
nobody can stop you from placing spare parms directly on the snippet node and pointing any Attrib VOP/Wrangle to evaluate them relative to that, but I'd not advise doing that
so while you can make it relative to your Snippet using that parm, you will not be able make it relative to 2+ snippets respectively in the same Attribute VOP at the same time
the reason is also that at the end all VOP nodes contribute to a single VEX code that gets compiled so really all controls should be on Attrib VOP or higher
as all ch() references in that VEX code will be evaluated relatively to just a single node and that's why that control is on the Attribute VOP itself
while technically VOP nodes exist and can hold parameters, historically they aren't supposed to be animated or even considered for placing your controls
nobody can stop you from placing spare parms directly on the snippet node and pointing any Attrib VOP/Wrangle to evaluate them relative to that, but I'd not advise doing that
Edited by tamte - March 5, 2024 02:38:44
Houdini Indie and Apprentice » Particle emitter stops working when in RBD Bullet Solver
- tamte
- 8555 posts
- Offline
instead of clipping post sim you can delete pieces during sim
dive inside of bulletsolver1
insert POP Kill node and type this into Rule VEXpression:
dive inside of bulletsolver1
insert POP Kill node and type this into Rule VEXpression:
dead = v@P.x > 2.95;
Edited by tamte - March 4, 2024 10:40:47
-
- Quick Links