Jump to content

rayman

Members
  • Content count

    322
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by rayman

  1. Houdini 18 is Out!

    here you go (i'm sorry for the off topic):
  2. Houdini 18 is Out!

    Such a great release! It is an honor to find out that a little piece of code I wrote a few years ago is now a part of Houdini (: I stole it from this guy and just converted it to vex, so all credit goes to him : https://forums.cgsociety.org/t/slerp-function/1406236/4
  3. Houdini 19 Wishlist

    An option to turn off weight normalization when painting capture weights using Capture Layer Paint, so we can use smooth and reduce paint modes without the need to fix the unwanted weights produced by it. Post normalization is fine. Interactive one feels like maya in 1999 when it modifies all bone weights when trying to paint only one of them - it is even worse as there is no user friendly bone weights lock.
  4. Bullet - Increasing Glue Strengths lower Impacts?

    They are not. You are comparing 2 completely different things - in one case constraints are starting to break - which means more free pieces to collide with = more impacts. Try the same experiment without breaking a single constraint - for example 20e5 vs 20e9. Do u see any difference?
  5. You can also try Extract Transform - it can convert the geometry transforms to point representation.
  6. Check this: sample_03_simple.hipnc First of all - before making a rbd sim make sure that all of your objects have proper names. I know you don't use constraints, but lets keep it consistent! No need for a sop solver, use Geometry wrangle - much faster and cleaner. Also it is a good practice to update the velocity when moving the position. Oh, and make the caps regular Static Object - you are gonna manipulate them manually inside the DOPS.
  7. You have to do it manually. Plug the constraints into attribute wrangle and simulated pieces into the second input. Then use this expression: int pt = findattribval(1,"point","name",s@name); if(pt>=0)v@P = point(1,"P",pt);
  8. Houdini 19 Wishlist

    Why would they? Sop solvers are just wrapped dops. Removing them means that they have to rewrite the whole fx context inside sops for the purpose of not having dops or just removing the access to them which equals hcore. Both approaches are very counter intuitive - every TD wants to have access to the solver and the ability to modify it.
  9. Houdini 19 Wishlist

    This one already exists - it is called Houdini CORE.
  10. For a Muscle to Bone use 'Attatch To Geometry' Vellum Constraint with predefined groups. For Muscle To Muscle - 'Glue'.
  11. Getting constraints to work

    Vellum constraints are using default points from the vellum object in order to describe themselves to the solver. Check the vellum constraint node : no matter how many constraints are created, point count is the same - there are only new primitives created. Connect Adjacent Pieces on the other hand may or may not change the point count depending of the type of connection. From the three methods only Adjacent Points could be used with Vellum.
  12. Fluid Source - strobing or stairstepping

    Make sure that geometry can be interpolated - just put a TimeBlend SOP + PointVelocitySOP before the source and turn on Velocity Blur option on VolumeRasterizeAttribute SOP, add some more Blur Samples and you are ready to go - no need to trail it or use more solving substeps. Edit : Just realized you are using the old fluid source - there should be alternative Velocity Blur option , but keep in mind that it is SLOW.
  13. Vellum and Pyro - Two way Interaction

    Yeah, thats because vdbs and houdini native volumes are using reversed sdfs. Velocities are just fine.
  14. Vellum and Pyro - Two way Interaction

    It looks like it, but it is not - if you simulate only the smoke, you will see the exact same behavior. I guess it is some kind of computational error or just the pressure solve doing its own thing. Edit : it is an error caused by the advection method.
  15. Vellum and Pyro - Two way Interaction

    You can generate collision / collisionvel fields from the vellum and copy it back to the smoke solver. DOP_Vellum_Pyro_Feedback_RnD_v002.hipnc
  16. Hard constraints stretching beyond rest length?

    This does not seem right. Most of the time forces are distributed pretty uneven based on the stress of the constraint system. I modified your scene a bit, to illustrate my point - as you can see all constrains are using the same break threshold (with the exception of both sides - I made them stronger on purpose, as they are most likely to fail), but only some of them are broken - where the forces are much stronger than the rest of the constraint network. You can expand on this and add different types of constraint breaks based on force, torque or distance between the pieces. Snap_Constraints_Example_2_MOD.hipnc
  17. Vellum hair colliding with RBD Packed Object

    I think, you have to repack the pieces before the sim using repack fragments option, but I've never found the solution to the other problem which is the huge collision padding between the packed objects and the vellum.
  18. Reverse ptnum on a prim

    attribute wrangle in details mode: int prim = 1; int pts[] = primpoints(0,prim); setprimvertex(0,prim,0,pts[1]); setprimvertex(0,prim,1,pts[0]);
  19. Hard constraints stretching beyond rest length?

    This is actually the expected behaviour. Using glue constraints will make the solver treat all connected pieces as one object (no relative movement between them) until the constraints are broken. To break a glue you need to apply collision (impact) force to the corresponding piece - forces/constraints can not force a glue to break. In this case it is like constraining a single active piece between 2 animated objects - hard constraints will stretch no matter of what. The only reason the glues are broken in your example is because of some instabilities of the collisions between the connected pieces and the initially detached pieces. If you want to force the object to break in the points with the bigger stress, then use only hard constraints and break them manually using the 'force' attribute.
  20. pyro vortex going out of bounds

    You can add single Gas Field Wrangle into the velocity update plug and try something like this: float minrad = 1; float maxrad = 1.5; float velmult = 1.0; vector center = set(0,0,0); vector dir = center-v@P; float dist = length(dir); float mult = fit(dist,minrad,maxrad,0,1)*velmult; v@vel += normalize(dir)*mult;
  21. Sop solver with multiple Bulllet object

    You can add empty data to the object you want to emit in, name that data , then add enable solver after the sop solver and type the same name to the Enable Data parameter.
  22. Happy 10th Birthday Od[force]

    WOOO HOOOO!! HAPPY B-DAY!!!
  23. Go to geometry wrangle and change Input2 Dop data from 'second' to '$OBJNAME/second'.
  24. Hi, Tim! I'm not very familiar with chops, but there is a quick vex solution to avoid flipping artefacts. All you have to do is to check the dot product between the two quaternion vectors and based on the result to invert one of the vectors before slerp-ing them. Check the attached file - it's kind of a library for proper matrix interpolation I created for my personal projects, and it uses the exact same method. Cheers! Pavel slerpmx.vfl
  25. Hi, there. I`m trying to create displacement shader with uvs offset, so when displacement is applied, the uvs are preserved and did not change in space. What I did so far is to construct prototype using vop sop and it works fine: So I converted it to the shader, but the result is not the same. As you can see there is a small error between displacement and uv offset: And The shader itself The problem is that distortion is not consistent - there is a regions with large displacement, but very small or no errors, and also places with small displacement and large distortions. I really have no idea what is the problem here, so I hope anyone can help. Thanks. disp_uv_test2.hipnc
×