Jump to content

FlorianEggers

Members
  • Content count

    21
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by FlorianEggers

  1. You can also use the Transform Pieces SOP to do that. Just make sure you have matching name attributes on both the sim and hi-res pieces.
  2. Import Caches into Dopnetwork to sim

    Just to make sure I understand correctly: You import Frame 1 from your cache as your initial geo You sim this wire in DOPs At a certain point, you want to override the simulated motion with the animation from cache One approach I can think of would be to change the geo with a wrangle inside DOPs. Ofc there's a ton of things to think about, maybe if you could post your scene (or a simple example of the setup) I could try what I have in mind
  3. AFAIK there's no way to make this work without scripting. (If there is, I'd be curious to know aswell). As a sloppy workaround, you could expose the "reset Simulation" button of the SOP Solver to your HDA. Using for-loops would solve this issue, I think. You said it's easier to work on the system using a solver, but maybe you could port the logic to for-loops for the final HDA? That would be my approach.
  4. Not sure I understand correctly: You want the Solvers to automatically re-cook to the desired frame (specified in the Timeshift SOP)?
  5. rbd forces question

    In DOPs in your glue constraint relationship, make sure the Data name matches the constraint_name attribute exactly (case sensitive!). In your scene, the glue cluster sets the name to uppercase "Glue", the glue constraint relationship has it's data name set to lowercase "glue". Make sure they both match exactly
  6. stop combine

    Not sure I understand correctly, you want to keep the deformation after the sphere left for the next box? For that to work (e.g. for the boxes to "remember" the deformation), you need to use a SOP solver. More specifically, the vdbcombine needs to happen inside a SOP solver. Alternatively, you could just copy the sphere onto every box. Depends on what you are trying to achieve in the end... Hope that helps, I might have the time to put up a quick sample scene later today.
  7. pyro cache issue

    I never used the "DOP Node" field, but from the help: So my guess is, if you point to your smokeobject in DOPs, it'll work aswell. Sounds usefull if you want to import multiple objects, but I've always used something like "smokeobject*" as the default object. Maybe someone else can elaborate on usecases for the DOP Node?
  8. Split curve input to seperate meshes

    can't test right now, but using the Convert Line SOP might help?
  9. The reason I can think of is consistency. @ptnum of a given point might change if you delete or modify your geometry. If you define something like i@myID = @ptnum; before you do any modification of the geo, and use @myID to generate random numbers, the result will stay the same, no matter if you delete points or change the point order.
  10. rbd forces question

    Set the second wrangle to run over primitives instead of points, then it'll work. Also, in your glue in DOPs, set the strength to 1. It acts as a multiplier to your prim attribute.
  11. pyro cache issue

    in your dop i/o, try to leave "DOP node" empty, but set default object to "smokeobject1" (or whatever the name of your smokeobject inside DOPs is. If this doesn't help, could you post your hip file?
  12. point deforming problem

    Have you played around with the radius of the point deform? Also could you post a scenefile? Would make it easier to debug.
  13. getbbox_size - what input does it expect?

    vector size; size = getpointbbox_size(0); It expects an input Geometry and outputs the size of the entire thing. So it doesn't need any other argument. note, that "getpointbbox_size" only looks at the points. you can use "getbbox_size" to check for everything in your input geo. From the help: "getpointbbox_size is the same as getbbox_size except it only computes the bounding box of the points. So if a primitive has extents that don’t have points (for example, the boundary of a primitive sphere), they will not be included in the box."
  14. Difficulty breaking hard constraint

    Could you post your scenefile? Maybe it's just something silly. Like, in your SOP solver, hooking up your code to the Geo input instead of relationships (?)
  15. Slow down bullet bjects

    yes, exactly!
  16. Slow down bullet bjects

    You need to reduce torque aswell. I increased the drag and added drag to torque, check the file. v@v *= 0.88; // Increased drag from .99 to .88 @w *= 0.88; // Added drag to torque slowBullet_001_TorqueDrag.hipnc
  17. Slow down bullet bjects

    AFAIK, Set always and Set initial refers to changes of the values. E.g. "Set Initial" sets the value once, while "Set always" allows the value to change over time. Both modes are active constantly. Same goes if you import data. "Set initial" imports it once, "Set Always" imports it every frame. (E.g. getting constraint network geo from SOPs)
  18. One slight workaround would be to use texturespace to scatter the points (see file attached) scatterDensity_001_UVs.hipnc
  19. Ghost in the Shell liquid FX

    Not an expert in fluids by any means, but here's what I think is worth looking into: Particle reseeding to keep the liquid surface intact Post process the surface with some VDB trickery to get a smooth thin layer on top and keep a shell of liquid after it rises above the pool
  20. Slow down bullet bjects

    I sometimes make my own poor-mans drag with a popwrangle. Something simple like @v *= 0.99; or you can also modulate it with a ramp float normalizedVel = fit(length(@v), your vel min, your vel max, 0, 1); @v *= chramp("DragCurve", normalizedVel); Basically what you want for water is to drastically slow down fast velocities while keeping slow ones (e.g. for sinking behaviour).
  21. Yea, I'm with David on this one. As long as you're not being deceiving about your contribution it's fine and fair to have it in your reel.
×