Jump to content


Popular Content

Showing most liked content on 10/24/2019 in all areas

  1. 2 points
    OBJ Wrangle https://vimeo.com/286025778 CPP Wrangle https://vimeo.com/171189268
  2. 1 point
    That is from an insufficiently high enough resolution. Crank that sucker, maybe even to 0.01 or lower. You'll want to use friction and bounce (on the solver) too. I'm a fan of a little bit of viscosity too, like just 1. Also in your solver, the volume motion > surface tension would be good to turn on too. Turn on and play with filtering in the surfacer.
  3. 1 point
    Hi, did you meant those "flickering holes" showing up when water is flattened and sliding against the table? I hope there's better solution, otherwise you'll have to go much higher resolution. The meshing method is based on mainly pscale and distance among reseeded particles.. when two particles' distance is on the threshold, it's easy for the meshing between them disconnect and connect again, hence the flickering. You'll need to lower the particle separation in your sim.
  4. 1 point
    Hey @ikoon I will check out the first thing you mentioned. For number 3: I'm aware of the python panel and often use it when I need to print python help data, as it has no limit to the amount of data shown. The downside it that it has as far as I know no options to clear or mark data. Both of which I also use allot. I use the console / prints allot for making and debug complex vex script, as houdini does not really have anything like breakpoints or step through whit variable inspect.
  5. 1 point
    Hey Luca Thanks for your hints! Can't post the Hip-File unfortunaety since it's project based, and wasn't able to recreate it at home yet. But I got a somehow stable result now by lowering the constraint iterations to 1000, and lowering attraction to around 25. Repulsion is also critical as it seems and the default value of 10000 looks to be too high for some cases. Those settings will cause the clumps to break up on impact, but on second thought, when you drop wet sand from 1m onto a collider in the real world, it will inevitable break up on impact so it should be ok for now.
  6. 1 point
    In case anyone ever stumbles upon this thread and wonders what caused these problems, I think I solved it. Inside the gas guiding volume dop, there are 2 gas linear combination nodes for guidingsurface and guidingcollision fields. These nodes should make sure that collision fields are properly accounted for in the guiding surface field, however if your collision field is set up in static object as a "Volume Sample", it produces very stepped guiding surface in the domain of the collisions. The solution to this is to either use "Ray Intersect" on the static object and so calculate the collision field every frame, or disable the 2 gas linear combination nodes, and do the same operation in sops - using vdb combine->sdf difference, and then bring it over with a sop solver. This produces a nice smooth guiding surface and so no weird artifacts happen.
  7. 1 point
    I don’t believe this will ever happen... VEX is used inside nodes and is designed to be run fast : it takes an input, process the code, and generate the output of a Wrangle or other snippet. Python is mainly used for scripting in Houdini, and depending on where you run it (from the terminal or from inside a Python node), you don’t have the same freedom of doing things. But basically, at first it was used to « automatize » what a user could do manually, like creating nodes and setting up some parameters (... scripting !). Now, if VEX could change parameters, in other nodes, that would break the « dependency graph » : nodes are connected and are cooked sequentially. So if you start allowing VEX to change parameters upstream for example, that will really breaks how Houdini works. You could potentially generate unstable situation with infinite loops / circular references and so on. And it wouldn’t be easy to know when to recook part of the network and when to stop... I believe that’s why VEX is run « inside » a node (a closed system in a way), while Python is more open on that, but therefore probably slower to execute because it may recook everything everytime it is run. Maybe you would love to write VEX inside a terminal (like the Python terminal), with functions that allows to create nodes and change parameters everywhere, a kind of new API in VEX, but that would be a huge change because VEX is not Object Oriented (while Python is, which is great because nodes are ... objects). It would become a VEX++ ! Of course, insight from SideFX on that could be better than these guesses :-)
  8. 1 point
    Well, a parameter on a node is not an attribute or a field of data. Attributes are linked to the geometry. vel and density are fields of vectors or scalar. They are attributes linked to a fictitious primitive that store volumetric data (voxels). If you want to read a parameter in VEX, use the vex expression chf() for a float, chi() for an integer etc. example chf(‘’path to the node with the wanted parameter / parameter ‘’) And seeing another question on the forum, ch() is only to read, not change a parameter. Hope the difference is clear.
  9. 1 point
    Guys, why are you adding wishes without an actual release? This is not ethical
  10. 1 point
    Only ink left in our printer was orange.
  11. 1 point
    @Jesper Rahlff Here you go. Sops and Shader versions inside. volume_pc_colour_01.hip
  12. 1 point
    Also, If you are trying to learn this stuff in general, I've got a thread about it over here.
  13. 1 point
    inside your $HOME/houdini15.5/ there is a file called jump.pref (if there isn't you can make one) in this file you can list paths (with env vars) like this: $PROJECT/$ASSET/geo/ /mnt/someDir/someOtherDir now these paths will show up on the left hand side of the file browser as 'favorites'