Jump to content

Leaderboard


Popular Content

Showing most liked content on 12/17/2020 in all areas

  1. 1 point
    Hey, seems like maybe you forgot to toggle some important thing. Post the file, it ll be easier to debug!
  2. 1 point
    You're right, it works very well Thanks for your help
  3. 1 point
    @mohammadmolanejad Just Play a Little bit with 4 variant of Shaders and Shadows have Fun LineDisplacement.hiplc
  4. 1 point
    1. the 1f offset may have something to do with evaluation of the constraints if they are nor attached to an object, which is once per dopnet substep if you want it more precisely (during Bullet substeps) you will need to check Attach Internal Constraint to object and connect it just after object, but then you will have to have your active and passive rbds part of a single object, so a bit of rearranging the setup, but regardles at least it sort of works 2. seems like intrinsic transform is not reliable way to assume the initial pose, so I'd go back to using p@orient and v@pivot attributes as described at the beginning of this thread something like this: int found_pt = findattribval(1, "point", "name", s@name); if(found_pt != -1){ vector pivot = point(1, "pivot", found_pt); vector P = point(1, "P", found_pt); vector4 orient = point(1, "orient", found_pt); orient = qinvert(orient); v@P = qrotate(orient, v@P - P) + pivot; p@orient = orient; } also I made sure @restlength is initialized and computed in your file as it's necessary for spring constraint and switched f@strength attrib to prim as it's per constraint and also added switch to Soft constraint if you want to use that instead and tweak strength maybe as its much more stable than spring and has greater range of stiffness (I included f@stiffness prim attrib that controls it instead of f@strength which controls spring one) I may have changed something else while playing (I temprarily replaced your primcenter HDA as it was not embedded) dynamic_constraint_problem_fix.hip - alternatively you can also have the fragments glued together from the beginning and have the spring or soft constraints set as secondary constraints (s@next_constraint_name and s@next_constraint_type), then just break the glue when you need or with impacts and it should switch to secondary ones even during substeps
  5. 1 point
    With help of some fellow students I found a workaround to get a paint explosion, using popattract and setting it to a minus value. However, I'm still wondering how to use velocity information from a sop for a fluid.
  6. 1 point
    Hey all, I'm trying to figure out ways to do this but I'm stumped. I've searched the forum and the web. everything was just a little off from what i'm trying to do. GOAL: 2+ different pieces of vellum cloth point deforming a single piece of geometry. and/or how to have a single piece of cloth (like pants with both legs) deform ONLY each leg's hires geom. I want there to be zero influence from the left leg pant on the right pant leg etc. ideally I'd like to have 2+ painted areas that define what cloth mesh deforms which area. then be able to plug the painted attributes into group expressions to get point groups. e.g., groupL would include the left leg hires and the left leg cloth mesh. and groupR would be the opposite. And somehow have that be respected in the PointDeform node Any help is appreciated.
  7. 1 point
    Thanks for the tip ParticleSkull, here is a basic setup working using those two attributes you mentioned above. // Setup attributes based upon color paint value. i@stopped = 0; i@gluetoanimation = 0; if (@Cd.r==0) { i@stopped = 1; i@gluetoanimation = 1; } I am wondering if some kind of strut constraint might help the trunk keep it's volume better?
  8. 1 point
    If you need to invert your animation use this expression in the timeshift : $FEND + 1 - $F
  9. 1 point
    The Import Attribute VOP and Add Attribute VOP are slightly less efficient than using Bind VOPs to fetch and write attributes. The Import Attribute VOPs need to account for all four inputs and from what I understand this is where the slight overhead may come from. Bind VOPs are intended to pick up the first input attribute data only. The Bind VOP was introduced in H12.5 to support the pre-compliation of VOP HDA's (with the Save Cached Code option on in the Type Properties). You can't have Parameter VOPs in HDA's with this pre-compliation toggle enabled for inheriting attributes inside your VOP HDA so you use the Bind VOPs instead as they do support this option. It is preferred that for directness and future-safing files that if you are strictly inheriting attributes from the first input, use the Bind VOP in place of the Parameter VOP. As for Import Attribute VOP, use it if you are picking up attributes from the other inputs. Or do what you want.
×