Found 45 posts.
Search results Show results as topic list.
Technical Discussion » Creating Muscles in new Muscles System
- geordiemartinez
- 45 posts
- Offline
Technical Discussion » Creating Muscles in new Muscles System
- geordiemartinez
- 45 posts
- Offline
Does the forgiveness have a radius or scale or attribute that can be modded? I have some finger tendons that are not intersecting the finger bones. On frame 1 they look like this:
And on the next frame they sproing away from the bones by some radius.
Q: Is there a way to visualize the collision radius?
Q: is there a procedural way to detangle penetrating geom before solidifying it? Or deactivate those points like with a nocollide attribute or something like in the vellum cloth solver?
And on the next frame they sproing away from the bones by some radius.
Q: Is there a way to visualize the collision radius?
Q: is there a procedural way to detangle penetrating geom before solidifying it? Or deactivate those points like with a nocollide attribute or something like in the vellum cloth solver?
Technical Discussion » Vex equivalent of Group Expand node?
- geordiemartinez
- 45 posts
- Offline
Animatrix, this is great! thank you. I was able to adapt that.
Here are the two functions I came up with with help from Animatrix_ to contract a group:
Here are the two functions I came up with with help from Animatrix_ to contract a group:
function int [ ] groupexpand ( int geo; int pts []; int depth ){ //int pts [ ] = expandpointgroup(0,groupname); int lastpts [ ] = pts ; for ( int i = 0; i < depth; ++i ){ int newpts [ ] = { }; foreach ( int pt; lastpts ){ int connected [ ] = neighbours ( geo, pt ); foreach ( int c; connected ){ if ( find ( pts, c ) < 0 ){ append ( pts, c ); append ( newpts, c ); } } } lastpts = newpts; } return pts; } function int [ ] groupcontract (int geo; int pts []; int depth ){ //int pts [ ] = expandpointgroup(0,groupname); int lastpts [ ] = pts ; for ( int i = 0; i < depth; ++i ){ //printf("lastpts loop %d len: %d \n",i,len(lastpts)); int rempts [ ] = { }; int keeppts [ ] = { }; foreach ( int pt; lastpts ){ int connected [ ] = neighbours ( geo, pt ); foreach ( int c; connected ){ if ( find ( lastpts, c ) < 0 ){ if (find ( rempts, pt ) < 0 ){ append ( rempts, pt ); } } } } foreach (int kpt; lastpts){ if (find(rempts,kpt)<0){ append ( keeppts, kpt ); } } lastpts = keeppts; } return lastpts; }
Edited by geordiemartinez - Feb. 12, 2021 18:12:53
Technical Discussion » Vex equivalent of Group Expand node?
- geordiemartinez
- 45 posts
- Offline
Hey all,
Does anyone have the vex equivalent of the group expand node?
why:
I want to contract a group by n levels and then expand it again by n levels to get clear out of singleton points that are not connected to the main body of points.
this is to clean up the results of an Attribute Transfer node that has pieces that are overlapping and the values need to be part of a single island so I can use it in a point deform node as the piece attribute.
Does anyone have the vex equivalent of the group expand node?
why:
I want to contract a group by n levels and then expand it again by n levels to get clear out of singleton points that are not connected to the main body of points.
this is to clean up the results of an Attribute Transfer node that has pieces that are overlapping and the values need to be part of a single island so I can use it in a point deform node as the piece attribute.
Technical Discussion » Vellum pdg sims not colliding properly
- geordiemartinez
- 45 posts
- Offline
UPDATE:
user error.
I had wedge values driving density of the tetmesh and they were coming up zero instead of the value I submitted in the wedge. this made it floaty and no collisions because of no mass.
Also, I was calling my density attribute “mass” which was clobbering the mass in the vellum solve. so I changed the attrib name to densityx and testing now.
user error.
I had wedge values driving density of the tetmesh and they were coming up zero instead of the value I submitted in the wedge. this made it floaty and no collisions because of no mass.
Also, I was calling my density attribute “mass” which was clobbering the mass in the vellum solve. so I changed the attrib name to densityx and testing now.
Edited by geordiemartinez - Dec. 6, 2020 14:44:45
Technical Discussion » Vellum pdg sims not colliding properly
- geordiemartinez
- 45 posts
- Offline
Hey all,
I'm testing some pdg wedging and for some reason my sims are not colliding properly when using PDG vs a standard vellum I/O node.
the pin-to-target constraint is working as expected and using the exact same solver. Then only difference is pdg using a ROP Geometry node (pdg) vs. a standard vellum I/O.
I'm guessing it's a setting I have here on the ROP Geometry node. Any ideas?
I'm testing some pdg wedging and for some reason my sims are not colliding properly when using PDG vs a standard vellum I/O node.
the pin-to-target constraint is working as expected and using the exact same solver. Then only difference is pdg using a ROP Geometry node (pdg) vs. a standard vellum I/O.
I'm guessing it's a setting I have here on the ROP Geometry node. Any ideas?
Technical Discussion » sharpening attribute values (opposite of AttrBlur)
- geordiemartinez
- 45 posts
- Offline
@Michael_Hu.
Yes! This is what I was looking for.
I was trying to use an AttributeCopy and and it wasn't giving me desired results.
Thank you.
Yes! This is what I was looking for.
I was trying to use an AttributeCopy and and it wasn't giving me desired results.
Thank you.
Technical Discussion » sharpening attribute values (opposite of AttrBlur)
- geordiemartinez
- 45 posts
- Offline
That's not what I'm trying to do.
what I want is for the float value that is on the original mesh to not be interpolated when transferred to the remeshed mesh. I think I may want to convert the attribute to a string for the remesh then convert back to a float so it doesn't interpolate.
what I want is for the float value that is on the original mesh to not be interpolated when transferred to the remeshed mesh. I think I may want to convert the attribute to a string for the remesh then convert back to a float so it doesn't interpolate.
Technical Discussion » sharpening attribute values (opposite of AttrBlur)
- geordiemartinez
- 45 posts
- Offline
I remeshed a piece of geometry and a float attribute, we will call @island, interpolated (blurred) so the values are soft between the pieces.
I would like the values to have a hard values matching the bulk of the nearby island. I've looked for a node to do this but ended up doing it in a for loop. I can't help but think there is a better way to do this.
Before:
After:
the for-loop just uses a GroupExpand to match @island with the iteration value to expand and then set the float value of that expanded group. but to get it to accumulate you have to set the for-loop to Merge Each Iteration so the point count goes up by the number of islands. so in this case it is 10x point count. then you have to use an attr transfer to get the proper values.
I know there is an elegant way of doing this. Any help would be appreciated.
I would like the values to have a hard values matching the bulk of the nearby island. I've looked for a node to do this but ended up doing it in a for loop. I can't help but think there is a better way to do this.
Before:
After:
the for-loop just uses a GroupExpand to match @island with the iteration value to expand and then set the float value of that expanded group. but to get it to accumulate you have to set the for-loop to Merge Each Iteration so the point count goes up by the number of islands. so in this case it is 10x point count. then you have to use an attr transfer to get the proper values.
I know there is an elegant way of doing this. Any help would be appreciated.
Solaris and Karma » Indie Karma switch to non commercial
- geordiemartinez
- 45 posts
- Offline
Solaris and Karma » Indie Karma switch to non commercial
- geordiemartinez
- 45 posts
- Offline
Yep. Same thing happened here. right after I assigned a geometry path to a piece of geometry it switched.
Edited by geordiemartinez - Oct. 21, 2020 17:29:57
Technical Discussion » Visualizer doesn't display attr as expected or Remesh broken
- geordiemartinez
- 45 posts
- Offline
Keeping the attribute a float value and using the in a point wrangle right after remesh wdorked to achieve the desired results.
I'm glad I could have this conversation with myself.
@island = rint(@island)
I'm glad I could have this conversation with myself.
Edited by geordiemartinez - Oct. 4, 2020 18:42:58
Technical Discussion » Visualizer doesn't display attr as expected or Remesh broken
- geordiemartinez
- 45 posts
- Offline
I just found there is a rint function that returns the proper integer value.
I guess the geom spreadsheet is rounding some 1.9#### values to 2 for space. and when int() is used it just chops off the tail float and keeps the first digit where rint() rounds first then returns the int.
This still doesn't explain remesh node is transferring interior integers as zeros.
I guess the geom spreadsheet is rounding some 1.9#### values to 2 for space. and when int() is used it just chops off the tail float and keeps the first digit where rint() rounds first then returns the int.
This still doesn't explain remesh node is transferring interior integers as zeros.
Technical Discussion » Visualizer doesn't display attr as expected or Remesh broken
- geordiemartinez
- 45 posts
- Offline
I have a simple example file attached.
there is an int attribute called patch
and it has a value of either 1, 2, 3, 4, 5 in columns along the patch.
The remesh will transfer the values as expected on the borders of the mesh, but the interior will entirely be zero.
both in the geometry spreadsheet and the visualizer. This is not expected
I have noticed similar results with float values. interpolating completely wrong values far away from their original point in space values.
Here is a float attr called remesh_bug before remesh
and after:
BUT here is the truly odd thing, the correct expected value is in the geometry spreadsheet for the float value remesh_bug but not the integer value casted by the int function.
I am either missing something fundamental or some function I don't know to cast this float to a proper integer.
Please help
there is an int attribute called patch
and it has a value of either 1, 2, 3, 4, 5 in columns along the patch.
The remesh will transfer the values as expected on the borders of the mesh, but the interior will entirely be zero.
both in the geometry spreadsheet and the visualizer. This is not expected
I have noticed similar results with float values. interpolating completely wrong values far away from their original point in space values.
Here is a float attr called remesh_bug before remesh
and after:
BUT here is the truly odd thing, the correct expected value is in the geometry spreadsheet for the float value remesh_bug but not the integer value casted by the int function.
I am either missing something fundamental or some function I don't know to cast this float to a proper integer.
Please help
Edited by geordiemartinez - Oct. 4, 2020 02:57:53
Technical Discussion » Quad Remesher
- geordiemartinez
- 45 posts
- Offline
I purchased a license a while back.
just tested in houdini 18.0.592 and it works on windows 10.
just tested in houdini 18.0.592 and it works on windows 10.
Technical Discussion » Running a Vellum Cloth Simulation in a For Each Loop?
- geordiemartinez
- 45 posts
- Offline
Here is a great video that just came out.
https://www.sidefx.com/tutorials/pdg-wedging-a-compile-sop-network/ [www.sidefx.com]
https://www.sidefx.com/tutorials/pdg-wedging-a-compile-sop-network/ [www.sidefx.com]
Technical Discussion » Vellum RefFrame Node takes 25% more time to simulate
- geordiemartinez
- 45 posts
- Offline
Hey all,
Running a vellum cloth sim that takes about 15 hours to simulate (long frame range). Sorry can't share the hip.
I ran a test with the exact same shot with/without the RefFrame node as the only difference.
With the RefFrame node added 5 hours to the sim time! total 20 hours.
5 hours more seems a bit excessive to me.
I have a pretty decent system (64gig RAM, 2080ti RTX, AMD Threadripper 1900) so I'm wondering if there is some kind of recursive looping going on in that node. I've looked inside and I don't see anything that jumps out.
Has anyone else had 25% time increases in sim times with a Ref Node?
Any help will be appreciated. Thanks.
Running a vellum cloth sim that takes about 15 hours to simulate (long frame range). Sorry can't share the hip.
I ran a test with the exact same shot with/without the RefFrame node as the only difference.
With the RefFrame node added 5 hours to the sim time! total 20 hours.
5 hours more seems a bit excessive to me.
I have a pretty decent system (64gig RAM, 2080ti RTX, AMD Threadripper 1900) so I'm wondering if there is some kind of recursive looping going on in that node. I've looked inside and I don't see anything that jumps out.
Has anyone else had 25% time increases in sim times with a Ref Node?
Any help will be appreciated. Thanks.
Technical Discussion » Difficulty attaching buttons to cached vellum cloth sim
- geordiemartinez
- 45 posts
- Offline
I see what you're saying.
There are basically two ways to do this:
if you don't want to simulate with the buttons for some reason (I've had a few get stuck in parts of other meshes) you can use the PointDeform single triangle approach.
I like the weight of the buttons on the cloth. But I will probably turn off collisions using collisionignore and collisiongroups so they don't get tangled up.
There are basically two ways to do this:
- Sim with the button geometry (or a proxy) using the Stitch Vellum Constraint
- Post sim using the PointDeform node to transform the button geom with a single triangle-per-button.
if you don't want to simulate with the buttons for some reason (I've had a few get stuck in parts of other meshes) you can use the PointDeform single triangle approach.
I like the weight of the buttons on the cloth. But I will probably turn off collisions using collisionignore and collisiongroups so they don't get tangled up.
Technical Discussion » Difficulty attaching buttons to cached vellum cloth sim
- geordiemartinez
- 45 posts
- Offline
The point deform method is a decent cheat. I will go with that.
I blew away all but a single triangle near each button and tweaked the settings and it looks great.
I think I'll make this an OTL that finds the nearest prim at rest and puts it in a group then blast the rest for button deformation during point deform time.
At least until I find a rivet method. But if that is just doing the same thing mathematically I think this will work.
I blew away all but a single triangle near each button and tweaked the settings and it looks great.
I think I'll make this an OTL that finds the nearest prim at rest and puts it in a group then blast the rest for button deformation during point deform time.
At least until I find a rivet method. But if that is just doing the same thing mathematically I think this will work.
Edited by geordiemartinez - Sept. 20, 2020 20:10:29
Technical Discussion » Difficulty attaching buttons to cached vellum cloth sim
- geordiemartinez
- 45 posts
- Offline
Thanks vusta!
I already have a stitch version working, but yours is a bit better. I have my bend stiffness way too high. Yours behaves better.
I am think I may just use a point deform method with just one prim per button and see what that looks like.
I already have a stitch version working, but yours is a bit better. I have my bend stiffness way too high. Yours behaves better.
I am think I may just use a point deform method with just one prim per button and see what that looks like.
-
- Quick Links