On the Karma Render Settings LOP node, if you turn off Rendering > Camera Effects > Disable Image Blur do you get the expected motion blur?
Are you rendering with XPU or CPU? Only CPU has motion vectors supported at the moment.
Here's a hipfile that shows it working.
Found 181 posts.
Search results Show results as topic list.
Solaris and Karma » Motion vector AOV in Karma
- npetit
- 360 posts
- Offline
Technical Discussion » Deleting chips in RBD material fracture.
- npetit
- 360 posts
- Offline
Use the RBD Connected Faces SOP before deleting geometry, and make sure you enable the Face Name Attribute.
Delete your pieces and chips, then use the RBD Disconnected Faces SOP to remove connected faces. Make sure you enable the Face Name Attribute on that node too.
When using the primitive attribute to store the connected faces, it may not cover ALL connected pieces - with more complex fractures a face could be connected to multiple pieces. Using the Vertex mode instead of Prim mode will store all the connected faces at each vertex instead of 1 per prim. It's normally is enough to avoid unwanted holes around the corners of pieces at the intersection of multiple cutters.
Here's an example hip file.
Delete your pieces and chips, then use the RBD Disconnected Faces SOP to remove connected faces. Make sure you enable the Face Name Attribute on that node too.
When using the primitive attribute to store the connected faces, it may not cover ALL connected pieces - with more complex fractures a face could be connected to multiple pieces. Using the Vertex mode instead of Prim mode will store all the connected faces at each vertex instead of 1 per prim. It's normally is enough to avoid unwanted holes around the corners of pieces at the intersection of multiple cutters.
Here's an example hip file.
Solaris and Karma » Is it possible to import background image in Solaris?
- npetit
- 360 posts
- Offline
If you are using the Background Plate LOP, make sure you have geometry to project the plate onto, and then make sure your object is refractive. In Karma CPU this should just work.
Technical Discussion » RBD attribute for number of constraints connected?
- npetit
- 360 posts
- Offline
in a point wrangle with the rbds in the first input and the constraints in the second, this will give you the number of constraints connected to each piece.
int pts[] = findattribval(1, "point", "name", s@name); int numconstraints = len(pts); if (numconstraints < 1) { // do your magic }
Technical Discussion » Copy to points after rbd sim
- npetit
- 360 posts
- Offline
The DOP points have a restxform matrix attribute which will allow you to do what you want.
First, add the "restxform" attribute to the DOP Import SOP's "Transfer Attributes" parm so the points get the restxform attrib.
Create a point wrangle SOP and use this code:
Add an attrib delete SOP and set it to delete all attributes except "transform".
Plug the output of the attrib delete SOP into the copytopoints SOP.
You now have all of the copied pig heads at their rest position and orientation. Now use a transform pieces SOP on them and use the points from the dopimport SOP to transform them.
Here's the updated hipfile.
First, add the "restxform" attribute to the DOP Import SOP's "Transfer Attributes" parm so the points get the restxform attrib.
Create a point wrangle SOP and use this code:
4@transform = 4@restxform; @P = 0;
Plug the output of the attrib delete SOP into the copytopoints SOP.
You now have all of the copied pig heads at their rest position and orientation. Now use a transform pieces SOP on them and use the points from the dopimport SOP to transform them.
Here's the updated hipfile.
Solaris and Karma » Karma XPU background plate
- npetit
- 360 posts
- Offline
tamte
When you dive into the Background Plate dive target there is an editable VEX based material called background, however it doesn't seem to have any effect even on CPU, the background plate still works even if I completely bypass the materiallibrary that's adding the material to the stage, is it just a red herring at this point and can potentially be removed to avoid confusion? H20.0.625
That isn't quite right. The background shader is applied to the background geometry and is visible in secondary rays for the other geo in the scene. With no shader applied, you will still catch shadows, but you won't get any of the background geometry reflected in other objects, etc... It only looks like it doesn't change anything as the plate is still projected through the camera and composited into the viewport. If you drop a chrome ball into your scene it should be obvious.
Here's a with background shader and a without background shader viewport screengrab that shows the difference.
We intentionally left the background shader editable so users could customize it if need be, with all the plate projection, offsets and scaling handled for you.
We're still looking to update it to MtlX however, as soon as we have the required math nodes to do so - which is why with or without won't make any difference in XPU renders currently.
Houdini Indie and Apprentice » RBD Guided simulation removal
- npetit
- 360 posts
- Offline
The "Evaluation Node Path" parameter defines the node from which to evaluate VEX commands on (the parm search path). The default, set to "." means it'll evaluate parms on the RBD Bullet Solver SOP node directly, so adding a "detachframe" attribute on the RBD Bullet Solver node directly can be referenced with for example.
Most VEX functions take a geometry as first argument, so, in your case, you can specify it as "op:<path to node>", i.e:
ch(), chs(), etc
float detachframe = ch("detachframe");
Most VEX functions take a geometry as first argument, so, in your case, you can specify it as "op:<path to node>", i.e:
int npts = npoints("op:/obj/geo1/refgeo");
Technical Discussion » Collision shape in RBD Bullet Solver only shows Convex Hull?
- npetit
- 360 posts
- Offline
On the RBD Bullet Solver, "RBDs" or "Geometry" refers to the geometry plugged into the 1st or 3rd inputs. "Collision" refers to the geometry plugged into the 4th input.
That is correct, the Geometry Representation menu in the Collisions tab refers to the collision geo plugged into input 4.
The visualization tab has options for both the Geometry/RBDs (plugged in 1st or 3rd inputs) and the Collision (plugged in 4th input)
Displaying the Visualization > Geometry > Collision Shape shows the collision shape for the RBD geo.
Displaying the Visualization > Collision Geometry > Collision Shape shows the collision shape for the Collision geo.
This visualization geo is extracted directly from DOPs. If you aren't seeing what you expect, it'll be because you aren't setting the geo representation as you think.
The settings on the RBD Bullet Solver SOP are all overridden by attributes set on the input geo, either set manually or via a RBD Config SOP.
You cannot change the Geometry/RBD collision shape (geometry representation) on the RBD Bullet Solver node itself, you need to change it by setting the "bullet_georep" string point attribute on the packed fragments. The RBD Config SOP has options for setting this.
Here's an example file with 3 different setups. The default (everything comes in as convex hulls), the RBD Bullet Solver's Collision Geometry Representation changed to Sphere, and finally overrides using the RBD Config SOP.
Although the RBD Bullet Solver's UI has changed significantly since 18.5, the parms and the way this works hasn't changed, so you should see the same results (despite some warnings when you open the file).
That is correct, the Geometry Representation menu in the Collisions tab refers to the collision geo plugged into input 4.
The visualization tab has options for both the Geometry/RBDs (plugged in 1st or 3rd inputs) and the Collision (plugged in 4th input)
Displaying the Visualization > Geometry > Collision Shape shows the collision shape for the RBD geo.
Displaying the Visualization > Collision Geometry > Collision Shape shows the collision shape for the Collision geo.
This visualization geo is extracted directly from DOPs. If you aren't seeing what you expect, it'll be because you aren't setting the geo representation as you think.
The settings on the RBD Bullet Solver SOP are all overridden by attributes set on the input geo, either set manually or via a RBD Config SOP.
You cannot change the Geometry/RBD collision shape (geometry representation) on the RBD Bullet Solver node itself, you need to change it by setting the "bullet_georep" string point attribute on the packed fragments. The RBD Config SOP has options for setting this.
Here's an example file with 3 different setups. The default (everything comes in as convex hulls), the RBD Bullet Solver's Collision Geometry Representation changed to Sphere, and finally overrides using the RBD Config SOP.
Although the RBD Bullet Solver's UI has changed significantly since 18.5, the parms and the way this works hasn't changed, so you should see the same results (despite some warnings when you open the file).
Technical Discussion » Collision shape in RBD Bullet Solver only shows Convex Hull?
- npetit
- 360 posts
- Offline
The RBD Bullet Solver's Collision tab is to control the collision geo plugged into the 4th input.
The RBDs (plugged into the 1st and/or 3rd input) come in as Convex Hulls by default. To change that, use a RBD Configure SOP to change the bullet_georep.
The RBDs (plugged into the 1st and/or 3rd input) come in as Convex Hulls by default. To change that, use a RBD Configure SOP to change the bullet_georep.
Technical Discussion » Bulletsolver | Delete Collision Geometry
- npetit
- 360 posts
- Offline
This can be accomplished a number of ways.
Using a Collision Ignore attribute:
This method will give you the greatest flexibility as it will allow some RBD pieces to continue colliding with the collision geo while allowing others to simply ignore the colliders you want.
The rbd geometry feeding into RBD Bullet Solver either through its first or third (proxy) input is named "rbd_object", while the collision geometry feeding into the fourth input is named "collision_object", and the groundplane or heightfield collider is called "groundplane". These are the object names you can use in the collision ignore field. You can add collision groups if you want to target subsets of these if need be.
The collision ignore field must be bilateral - meaning the various objects need to be ignoring one another. So rbd pieces ignoring "collision_object" will need the collision geo to be ignoring "rbd_object".
If you need to update the collisionignore attribute dynamically from SOPs, you can add it to the list of attributes in
Properties > Pieces > Override Attributes > Attributes for RBD objects
or
Collision > Collision Geometry > Override Attributes > Attributes for Collision geometry.
Emitted RBD geometry will not be updated from SOPs - you will need to handle updating the attributes yourself. Dive inside the RBD Bullet Solver SOP and use a geometry wrangle, or a SOP solver, or any other way of modifying the RBD pieces' attributes as needed.
Updating the Collision Geometry's geometry representation:
Set the bullet_georep attribute on the pieces you want to no longer collide with anything to "none" and add that attribute name to the Collision > Collision Geometry > Override Attributes > Attributes list to update it dynamically from SOPs.
Delete the Collision Geometry dynamically:
By feeding the collision geometry into the same input as your other rbd pieces (make sure there are no name clashes) they will be treated as regular rbd pieces you can now access by diving inside the RBD Bullet Solver.
In order for it not to become active by default, make sure you configure it properly by setting its active, animated and/or deforming attributes as needed.
Dive inside the RBD Bullet Solver and add a SOP Solver. From there you can simply delete the pieces you no longer want to be participating in the simulation.
Make sure to delete the remaining collision geometry from the various outputs (1 and/or 3) of the RBD Bullet Solver SOP if you do not want it to be cached out with the rbd pieces.
More advanced colliders:
Having said all that, if you need to update the collision geometry's attributes dynamically based on what is happening in the sim, as opposed to doing it in SOPs blindly, you will want to treat the collision geometry as regular rbd geo in order to have access to it when diving inside the RBD Bullet Solver.
The reason there is a fourth input to the RBD Bullet Solver node for collision geometry is to make it easier and faster to setup collisions with geometry globally, which you don't care to output or do anything too fancy with during the sim. For example, using the set environment for collisions, or an animated character to smash whatever it is you need breaking etc...
If you need to do more than simple collisions that can be static/animated/deforming etc, you may need to treat them as regular RBDs and feed everything into the first input of the node, making sure you configure all the various pieces and colliders appropriately using the attributes the bullet solver recognizes.
The RBD Configure SOP exposes all these attributes in a convenient way.
Using a Collision Ignore attribute:
This method will give you the greatest flexibility as it will allow some RBD pieces to continue colliding with the collision geo while allowing others to simply ignore the colliders you want.
The rbd geometry feeding into RBD Bullet Solver either through its first or third (proxy) input is named "rbd_object", while the collision geometry feeding into the fourth input is named "collision_object", and the groundplane or heightfield collider is called "groundplane". These are the object names you can use in the collision ignore field. You can add collision groups if you want to target subsets of these if need be.
The collision ignore field must be bilateral - meaning the various objects need to be ignoring one another. So rbd pieces ignoring "collision_object" will need the collision geo to be ignoring "rbd_object".
If you need to update the collisionignore attribute dynamically from SOPs, you can add it to the list of attributes in
Properties > Pieces > Override Attributes > Attributes for RBD objects
or
Collision > Collision Geometry > Override Attributes > Attributes for Collision geometry.
Emitted RBD geometry will not be updated from SOPs - you will need to handle updating the attributes yourself. Dive inside the RBD Bullet Solver SOP and use a geometry wrangle, or a SOP solver, or any other way of modifying the RBD pieces' attributes as needed.
Updating the Collision Geometry's geometry representation:
Set the bullet_georep attribute on the pieces you want to no longer collide with anything to "none" and add that attribute name to the Collision > Collision Geometry > Override Attributes > Attributes list to update it dynamically from SOPs.
Delete the Collision Geometry dynamically:
By feeding the collision geometry into the same input as your other rbd pieces (make sure there are no name clashes) they will be treated as regular rbd pieces you can now access by diving inside the RBD Bullet Solver.
In order for it not to become active by default, make sure you configure it properly by setting its active, animated and/or deforming attributes as needed.
Dive inside the RBD Bullet Solver and add a SOP Solver. From there you can simply delete the pieces you no longer want to be participating in the simulation.
Make sure to delete the remaining collision geometry from the various outputs (1 and/or 3) of the RBD Bullet Solver SOP if you do not want it to be cached out with the rbd pieces.
More advanced colliders:
Having said all that, if you need to update the collision geometry's attributes dynamically based on what is happening in the sim, as opposed to doing it in SOPs blindly, you will want to treat the collision geometry as regular rbd geo in order to have access to it when diving inside the RBD Bullet Solver.
The reason there is a fourth input to the RBD Bullet Solver node for collision geometry is to make it easier and faster to setup collisions with geometry globally, which you don't care to output or do anything too fancy with during the sim. For example, using the set environment for collisions, or an animated character to smash whatever it is you need breaking etc...
If you need to do more than simple collisions that can be static/animated/deforming etc, you may need to treat them as regular RBDs and feed everything into the first input of the node, making sure you configure all the various pieces and colliders appropriately using the attributes the bullet solver recognizes.
The RBD Configure SOP exposes all these attributes in a convenient way.
Solaris and Karma » background plate lop + xpu
- npetit
- 360 posts
- Offline
The material is inside an editable subnet, to allow users to modify it if need be. This means a Background Plate LOP created in a 19.5 scene will retain its VEX based material when the hip file is opened in 20.0
You'll want to recreate a fresh Background Plate LOP to get the XPU compatible material.
You'll want to recreate a fresh Background Plate LOP to get the XPU compatible material.
Solaris and Karma » Split SSS per LPE
- npetit
- 360 posts
- Offline
Technical Discussion » Assemble vs Pack per connectivity: super slow!
- npetit
- 360 posts
- Offline
Tomorrow's build has packing options for the prototypes (create packed fragments and pivot location) as well as supporting user supplied prototypes as packed geo.
The comparisons still happen using the unpacked prototypes, however attributes that are not used for the comparisons are sanitized beforehand to avoid attrib pollution.
The comparisons still happen using the unpacked prototypes, however attributes that are not used for the comparisons are sanitized beforehand to avoid attrib pollution.
Technical Discussion » Assemble vs Pack per connectivity: super slow!
- npetit
- 360 posts
- Offline
Thanks Tomas, that's a good point.
I've got it working with packed prototypes. As soon as I get the go ahead from our UX Czar I'll backport the changes.
I've got it working with packed prototypes. As soon as I get the go ahead from our UX Czar I'll backport the changes.
Technical Discussion » Assemble vs Pack per connectivity: super slow!
- npetit
- 360 posts
- Offline
At the moment when packing the prototypes which get instanced onto the extracted points, the pivot location isn't promoted and is set to "Centroid" by default. I'll add that as an option.
Replacing a prototype however should be pretty simple. You can either replace the prototype entirely or unpack the prototype, offset it to place the desired pivot at the world origin, repack it and set the pivot location to "Origin" and reset the transform (apply the inverse transform of whatever transform you did to set the desired pivot before packing).
Here's an example.
Replacing a prototype however should be pretty simple. You can either replace the prototype entirely or unpack the prototype, offset it to place the desired pivot at the world origin, repack it and set the pivot location to "Origin" and reset the transform (apply the inverse transform of whatever transform you did to set the desired pivot before packing).
Here's an example.
Technical Discussion » Assemble vs Pack per connectivity: super slow!
- npetit
- 360 posts
- Offline
If your leaves are all a single piece of geo to start with, you may want to try the Find Instances SOP in H20.0
Solaris and Karma » How to convert extracted instances back to point instances
- npetit
- 360 posts
- Offline
As Mark said, there is no easy way to turn extracted point instances back into point instances. If you are using physics to only move them around however, you could use the Modify Point Instances LOP in a couple of different ways to get those edits back onto the original point instancer.
In this example hipfile, the first modify point instances LOP ("modifypointinstances_physics_inside") is used to run physics on the instances directly - dive inside the node and there's an example of turning them into RBDs to move the point instances around.
The second modify point instances LOP ("modifypointinstances_match_edits") is used to bring back changes done to extracted point instances by copying their packed full transform in SOPs onto the instance representations inside the modify point instances LOP.
In this example hipfile, the first modify point instances LOP ("modifypointinstances_physics_inside") is used to run physics on the instances directly - dive inside the node and there's an example of turning them into RBDs to move the point instances around.
The second modify point instances LOP ("modifypointinstances_match_edits") is used to bring back changes done to extracted point instances by copying their packed full transform in SOPs onto the instance representations inside the modify point instances LOP.
Houdini Indie and Apprentice » Animating an object through a pre-decided rail with physics
- npetit
- 360 posts
- Offline
It'll be because I saved this file in H20 and you must still be on 19.5 or lower. The RBD Bullet Solver has some new parameters as the Cone Twist Constraint DOP has been significantly improved for H20.
You can happily ignore that message, save the hip file, and it will no longer appear when you re-open the file.
You can happily ignore that message, save the hip file, and it will no longer appear when you re-open the file.
Houdini Indie and Apprentice » Animating an object through a pre-decided rail with physics
- npetit
- 360 posts
- Offline
That VEX snippet was a clunky way of adding some random velocity per frame (with a minimum amplitude) constrained in the X axis.
I was just playing around to get some emission velocity that might work with what you were describing. The attribute randomize SOP has more elegant ways of doing the exact same thing. In this updated hip file I've replaced it.
The way the emission works with the RBD Bullet Solver is anything that is currently plugged into the RBD Bullet Solver SOP will be emitted at every solver substep.
So in order to only emit on every second frame, only have geometry coming through on every second frame.
To emit on every 3rd frame, only have geo coming through on every 3rd frame, etc...
Here's an update to the file where emission only happens every 5 frames.
v@v = (rand(@ptnum + @Frame) * 5 + {3,3,3}) * {0,1,1};
I was just playing around to get some emission velocity that might work with what you were describing. The attribute randomize SOP has more elegant ways of doing the exact same thing. In this updated hip file I've replaced it.
The way the emission works with the RBD Bullet Solver is anything that is currently plugged into the RBD Bullet Solver SOP will be emitted at every solver substep.
So in order to only emit on every second frame, only have geometry coming through on every second frame.
To emit on every 3rd frame, only have geo coming through on every 3rd frame, etc...
Here's an update to the file where emission only happens every 5 frames.
Houdini Lounge » can't get background plate to render (Houdini 20)
- npetit
- 360 posts
- Offline
You need the geometry to project the background plate onto. Add a grid below your cube and set the background plate LOP's "primitives" parameter to point to the grid.
-
- Quick Links