Found 379 posts.
Search results Show results as topic list.
Technical Discussion » Lock RBD constraints angle
- cwhite
- 733 posts
- Offline
Hard constraints (with constraint type set to all) should keep the relative rotation between the constraint anchors the same. However, if they aren't being completely enforced, that's a sign you might need more constraint iterations on the solver
Technical Discussion » Swap rbd during simulation
- cwhite
- 733 posts
- Offline
I think you can do this by first replacing the packed prims' contents with the new shape(e.g. with the Pack Inject SOP, or by copying the point attribs over to new packed prims) and then resetting the 'id' point attrib to -1 which will cause the solver to re-import the shape. You might also set 'computecom' and/or 'computemass' to 1 if you want those properties to be recomputed for the new geometry.
Solaris and Karma » sop crowd import to usd rop
- cwhite
- 733 posts
- Offline
I'm not sure offhand what causes the animation layer to be flattened as an implicit layer, but depending on the Save Style on the USD ROP it would be saved out to its save path
Having each agent as a payload probably wouldn't help much, I think, since they're individually pretty lightweight (just a SkelAnimation prim and then a reference to some shared prims). Deactivating or using population masks sounds like the best approach for pruning
The difference in playback speed is to be expected currently, as the SOP viewport is doing instanced GPU skinning, which isn't supported in Hydra / Houdini GL currently in the solaris viewport.
Having each agent as a payload probably wouldn't help much, I think, since they're individually pretty lightweight (just a SkelAnimation prim and then a reference to some shared prims). Deactivating or using population masks sounds like the best approach for pruning
The difference in playback speed is to be expected currently, as the SOP viewport is doing instanced GPU skinning, which isn't supported in Hydra / Houdini GL currently in the solaris viewport.
Technical Discussion » Clustering, Glue and Strength rbdbulletsolver issue
- cwhite
- 733 posts
- Offline
Yeah, I think the issues probably are from mismatched names.
On your constraint geometry, there should be a 'name' point attribute which specifies the object the constraint anchor is attached to. This is matched against the 'name' point attribute on the proxy geometry prims (your geometry doesn't have that, so the solver is setting up default names - it's better to set this up yourself if you're creating constraints)
The constraint setup seems to be renaming the points in its loop, so you probably need to go through and make sure that the constraint points have the same name as the piece they're supposed to be attached to
On your constraint geometry, there should be a 'name' point attribute which specifies the object the constraint anchor is attached to. This is matched against the 'name' point attribute on the proxy geometry prims (your geometry doesn't have that, so the solver is setting up default names - it's better to set this up yourself if you're creating constraints)
The constraint setup seems to be renaming the points in its loop, so you probably need to go through and make sure that the constraint points have the same name as the piece they're supposed to be attached to
Solaris and Karma » SOP Import for Volumes with specified path attrib
- cwhite
- 733 posts
- Offline
I'd guess that the absolute paths are lost because Load As Reference is enabled and they're not under the default prim?
Since you want to split the fields into multiple Volume prims, I would try setting 'usdvolumepath' (https://www.sidefx.com/docs/houdini18.5/solaris/sop_import.html#vols) to e.g. 'clouds/cloud_2' and then have 'name' set to 'density' for all of the prims
Since you want to split the fields into multiple Volume prims, I would try setting 'usdvolumepath' (https://www.sidefx.com/docs/houdini18.5/solaris/sop_import.html#vols) to e.g. 'clouds/cloud_2' and then have 'name' set to 'density' for all of the prims
Houdini Indie and Apprentice » Kinefx to agent Crowd : Wrong Scaling
- cwhite
- 733 posts
- Offline
You should wire third output (animation skeleton) into the Agent from Rig SOP, not the second output (bind pose). The bind skeleton doesn't necessarily have all of the joints
Because of this, when the animation clip is applied some of the local transforms are lost since they aren't joints in the agent's skeleton. If you turned on Set Current Clip on the Agent Clip SOP you'd see the same issue as when the agent definition is loaded onto a new agent instance.
Because of this, when the animation clip is applied some of the local transforms are lost since they aren't joints in the agent's skeleton. If you turned on Set Current Clip on the Agent Clip SOP you'd see the same issue as when the agent definition is loaded onto a new agent instance.
Solaris and Karma » LOP Import SOP no longer import primvars?
- cwhite
- 733 posts
- Offline
Also, if you do need to access primvars before unpacking, the usd_* vex functions can now be used from SOPs to read data from the LOP stage.
Solaris and Karma » LOP Import SOP no longer import primvars?
- cwhite
- 733 posts
- Offline
The LOP Import SOP doesn't import primvars - that happens when unpacking the packed USD prims.
I think in 18.5 there was an odd behaviour where when a packed USD prim was created, if it had a non-boundable type (like Xform) then its primvars were imported as attributes on the packed USD prim. This was a leftover from the original Pixar integration, and didn't support all attribute types and ignored the usual import options like the primvar filter. And, of course, this only happened for certain prim types and made unpacking / transferring those attributes complicated.
This was replaced in 19.0 by an option on Unpack USD to transfer inherited primvars when unpacking.
I think in 18.5 there was an odd behaviour where when a packed USD prim was created, if it had a non-boundable type (like Xform) then its primvars were imported as attributes on the packed USD prim. This was a leftover from the original Pixar integration, and didn't support all attribute types and ignored the usual import options like the primvar filter. And, of course, this only happened for certain prim types and made unpacking / transferring those attributes complicated.
This was replaced in 19.0 by an option on Unpack USD to transfer inherited primvars when unpacking.
Technical Discussion » RBD grain & Collision
- cwhite
- 733 posts
- Offline
I'd suggest checking the Bullet collision shape settings for the collider object - the default is convex hull, which may not be what you want for a concave object.
Solaris and Karma » Native USD Instancing of source crowd geometry
- cwhite
- 733 posts
- Offline
SOP Import is indeed creating a similar setup to instance the bind state prims. However, when rendering through Hydra this is ignored (https://github.com/PixarAnimationStudios/USD/commit/08ceaf53d653becf469aeb02f8e1e7f9345243b2) so the benefit is just on the scene graph side of things currently.
Note that this is very different from Mantra's crowd procedural, which attempts to detect agents that have similar enough poses that their final deformed geometry can be directly instanced.
Note that this is very different from Mantra's crowd procedural, which attempts to detect agents that have similar enough poses that their final deformed geometry can be directly instanced.
Technical Discussion » Creating A Unique Number Based on Unique Path Names
- cwhite
- 733 posts
- Offline
You could use the Enumerate SOP in the Piece Attribute mode (Mode = "Enumerate Pieces")
Technical Discussion » HDK: PRM generated choice list - persistence question
- cwhite
- 733 posts
- Offline
I'd probably suggest using a PRM_STRING parameter rather than PRM_ORD - since your menu values are generated while cooking your SOP, there's no guarantee that the existing parameter value is still a valid menu token. For example, the menu may be requested while loading the .hip file but before your SOP has cooked, but there are also other cases like having cooking disabled, or if the input geometry has changed.
Technical Discussion » Hard constraint between animated and active object? Bug?
- cwhite
- 733 posts
- Offline
I think this has to do with the location of the constraint anchor points (the 'AnchorPins' helpcard example is a good visualization of how the anchor locations affect the behaviour). The hard (pin) constraint works by enforcing that the two anchors have the same position and/or orientation.
In the scenario where 'restlength' is being used, internally this just shifts the first anchor point towards the second anchor by that distance. In your setup, this means that both anchors are initially positioned in the middle of the active object. Since the inactive object can't move, the two anchor points essentially stay at the same position and prevent the active object from moving.
I think you want to flip this around so that the anchors are positioned on the static object, letting the active object rotate around that pivot. You can use a Reverse SOP to flip the vertex order on your constraint primitives.
In the scenario where 'restlength' is being used, internally this just shifts the first anchor point towards the second anchor by that distance. In your setup, this means that both anchors are initially positioned in the middle of the active object. Since the inactive object can't move, the two anchor points essentially stay at the same position and prevent the active object from moving.
I think you want to flip this around so that the anchors are positioned on the static object, letting the active object rotate around that pivot. You can use a Reverse SOP to flip the vertex order on your constraint primitives.
Technical Discussion » Houdini 18+ RBD Tools - Localized Fractures
- cwhite
- 733 posts
- Offline
The concrete fracturing method is doing a voronoi fracture at its core, so the placement of the cell points determines the pieces that are produced. In particular, if you want a section of the model to not be fractured, then that section needs to be in a single voronoi cell. The attached example demonstrates that, and is probably why the scattering by density didn't quite achieve what you were after.
Doing a prior boolean fracture is also a very reasonable approach. You can append an RBD Material Fracture and use the Group field to fracture certain parts of the geometry, and turning on Fracture per Piece would make it behave more like a recursive fracture.
Doing a prior boolean fracture is also a very reasonable approach. You can append an RBD Material Fracture and use the Group field to fracture certain parts of the geometry, and turning on Fracture per Piece would make it behave more like a recursive fracture.
Houdini Indie and Apprentice » Packed RBD Collision Attribute?
- cwhite
- 733 posts
- Offline
In the geometry spreadsheet you can see the unique id for each DOP object (attached screenshot), but in the SOP solver I was using https://www.sidefx.com/docs/houdini18.5/expressions/dopobjectlist.html [www.sidefx.com] to determine the ID from the object name, since the ids can vary depending on how your DOP network is wired (in this case, the expression on the ground id parameter was
atof(dopobjectlist("../..", "groundplane1", 0))
Edited by cwhite - Aug. 27, 2021 13:57:29
Houdini Indie and Apprentice » Packed RBD Collision Attribute?
- cwhite
- 733 posts
- Offline
I think you were pretty close - you just need to look up the primitive number in the geometry that contains the impact data, and then interpret the other attributes (like DOP object id) when you find an impact record (see attached)
Solaris and Karma » Unpacking alembic in Solaris?
- cwhite
- 733 posts
- Offline
In this case it looks like you're relying on SOP Import's ability to partition the geometry into different USD prims based on the SOP `name` attribute.
So in the second image that's directly loading the alembic file, I'd expect there to be a primvar on the mesh with the various 'name' values, since the .abc file format plugin would just be loading the alembic file as-is. If you're creating the alembic file with the Alembic ROP, you could set the "Partition Mode" parameter to "Use Attribute Value" (and set Partition Attribute to "name") - this should partition the mesh based on the name attribute
So in the second image that's directly loading the alembic file, I'd expect there to be a primvar on the mesh with the various 'name' values, since the .abc file format plugin would just be loading the alembic file as-is. If you're creating the alembic file with the Alembic ROP, you could set the "Partition Mode" parameter to "Use Attribute Value" (and set Partition Attribute to "name") - this should partition the mesh based on the name attribute
Solaris and Karma » Unpacking alembic in Solaris?
- cwhite
- 733 posts
- Offline
SOP Import doesn't have much support for packed Alembic prims - since USD has a .abc file format plugin, you can directly load alembic files through the File LOP etc
Technical Discussion » How to assign dop sop solver to each objects?
- cwhite
- 733 posts
- Offline
You can use an Enable Solver with the Enable Objects parameter set to the name of the object you want to enable its input solvers for (in this case, you'd wire your SOP solver into the Enable Solver)
Technical Discussion » motion clips, agent and crowds
- cwhite
- 733 posts
- Offline
Without a .hip file I'm just guessing, but the 'agentclip1' SOP in the last picture has a warning - what does that say?
From that picture it looks like you might be trying to wire a different agent prim into the second input of Agent Clip, which doesn't work. That input expects kinefx motion clips, not agent primitives
From that picture it looks like you might be trying to wire a different agent prim into the second input of Agent Clip, which doesn't work. That input expects kinefx motion clips, not agent primitives
-
- Quick Links