Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

woodenduck

Members
  • Content count

    258
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

29 Excellent

About woodenduck

  • Rank
    Illusionist

Personal Information

  • Name Joe
  • Location Vancouver
  1. Have you tried casting @ptnum and @numpt to floats before dividing? (float)@ptnum / (float)@numpt I think VEX will treat them as integers and not divide correctly otherwise.
  2. I would first check for interpenetrating geometry. MAybe try reducing the penetration threshold on the bullet solver. Are you by any chance using a drag dop in the glass simulation? I had something similar where the drag node caused my bullet sim to go haywire. You could also try whacking the substeps on the solver.
  3. I'm not entirely sure what are trying to do as the geometry is missing in your scene. The file nodes in your scene should either be locked prior to saving (depending on file size) or you could zip the hip file up with the relevant geo files. But that being said, you can't directly deform packed geometry without first unpacking it. You can transform it, but deformation would require the geometry being fully loaded in to the scene.
  4. No problem! You could also use $F which is the global frame number. $SF is the simulation frame number.
  5. Did you change "start frame" on your dopnet?
  6. Try changing your start frame to 54 and putting the path to the frame 54 sim file in the "initial state" parameter.
  7. Because a simulation evolves based on the values from the previous frame, unlike a sop network which is calculated per frame with no time dependency. In order to get to frame 54 you need to calculate frame 53 and in order to get to frame 53 you need to calculate frame 52... etc etc all the way back to the start frame. These values are not stored when you save a bgeo file, you only save the result. You can save a .sim file which would allow you to start again from frame 54, but they take up a huge amount of space as they have to save all that additional information about the simulation's state.
  8. Have you tried it with the RBD solver rather than Bullet?
  9. Set a rest attribute before you sim. Then compare this to P post sim. Delete pieces that differ.
  10. add a / before obj. so the path reads - npoints("/obj/geo1/sphere1")
  11. + rather than *
  12. Don't have Houdini open right now, but I would first suggest to investigate your collision geometry. Check 'display collsion geo' on the bowl in dops. Make sure it hasn't created a convex hull which encloses your fluid from the start. This would cause undesired results. You may need to switch it to concave. But as I said, I'm not able to open your scene right now, so this is just a guess. Cheers, WD
  13. Go to the particle fluids tab and press "whitewater". Done ;D
  14. Render it separately. Glow in comp.
  15. In an attribute vop, take a 'relative to bounding box' vop and run this through a 'compare' vop set to greater than 0.5. You can plug the result of the 'compare' in to a 'switch' vop with time and negated time as the 2nd and 3rd inputs. Plug that in to the x component of a 'float to vector' vop and plug the result in to the offset of your noise vop. You should see the noise on one half of the sphere moving in positive x and the other half in negative x.