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.


  • Content count

  • Joined

  • Last visited

Community Reputation

66 Excellent


About bunker

  • Rank

Personal Information

  • Name Julien
  • Location Dreamworks, Shanghai
  • Interests bespoke solvers, volumes, fire, smoke, FLIP, RBDs/Bullet, particles, VEX, Python, lighting, rendering...

Recent Profile Visitors

6,559 profile views
  1. I didn't find any global switch for openCL but you can use python for that: for example, to turn off all Pyrosolver's openCL pyro = hou.nodeTypeCategories()["Dop"].nodeTypes()['pyrosolver::2.0'].instances() for i in pyro: i.parm("opencl").set(0) print i.path()
  2. Try the grain solver with clumping ("Wet Sand" in the shelf) The result of the simulation will give you a "model"
  3. You can use hrender from Python. Have a look at the attached HIP file. bunker_localrender_001.hip
  4. Yes I meant the Bounding box. To join the slices, add some padding on each slice, remove the Adaptivity on the VDB to polygon conversion, then you can use a few clip SOPs, and a fuse SOP to join the slices. You can also try a different approach using VDBs only, if you export each slice as VDB, you can merge them all with a VDB combine, then mesh it with the "convert VDB" SOP .
  5. the particlefluidsurface SOP has a "Regions" tab so you can mesh your FLIP sim in several chunks and merge them afterwards
  6. I don't think you need any SDF volumes. You can use the pointcloud directly and find the closest points from the previous frame to compute velocity. KinectEmulation_ProcessingTest2.hipnc
  7. deleteAllKeyframes()
  8. or simply click on the merge node, the default is set to: Affector Relationship: Left Inputs Affects Right Inputs
  9. the inputs of your "merge1" node are in the wrong order.
  10. did you try using the Performance Monitor? (Alt+y)
  11. Use a blast SOP on primitive group, there is a " popobject1" group, set to "Delete Non Selected"
  12. no problem, should be the same in H13, wrangle nodes have been introduced in H12.5 would be cool to see what you do with it, if you can post it...
  13. Very cool @petz! just for fun, I tried a SOP solver approach, very brute force but good for packaging squares just a "fill" method on one square at a time, if it's not square of filled enough, move to another area ... converting the points to a shape needs a lot of work... I using the osm map with a bit of cleanup of the edges and some random extrusion... bunker_city.zip
  14. very cool topic! Looks like some kind of "convex decomposition". Might be possible to approximate that with recursive levels of voronoi fracture SOPs (in a for each). Can you upload a bgeo with your imported osm data?
  15. It's definitely nothing to do with the lack of "gas released" in the upres solver. "gas released" is controlling divergence on the lowers sim only - which affects the velocity at the projection stage The Upres solver copies the lowres vel field (and add some noise), there isn't any velocity projection. You shouldn't expect exactly the same amount of fire or smoke at the upres stage. For example, simply copying a lowres field into a hires grid isn't perfect (interpolation) during combustion any small error is carried across multiple fields over time, which make things worse. to simplify, combustion is: fuel∩temp>burn>heat>density you can see that any small error in the "fuel" field for example will affect the final products: heat/density some options to solve this issue: 1) adjust the heat/density values post sim (not the best result) 2) adjust some values in the upres combustion (very time consuming) 3) tweak the upres solver to bypass most of the combustion model: if you copy the burn field directly from the lowres sim, you don't need fuel and temperature, the result should be closer to your lowres. it's not perfect, but removes 2 fields and the error they introduce. You'll still need to tweak the combustion values a bit. ideally you would combine options 2 and 3, so you spend less time tweaking the combustion settings. hope that helps.