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

6 Neutral

About merlino

  • Rank
  • Birthday 07/30/1978

Contact Methods

  • Skype marco.merletti

Personal Information

  • Name Marco
  • Location AR

Recent Profile Visitors

2,493 profile views
  1. Hi @lukeiamyourfather! Just check here, there's some interesting info: https://www.sidefx.com/forum/topic/48975/?page=1#post-222234 It seems the Ryzen has a good performance on OpenCL, like a GTX 1070, but there you have all the system memory. It sounds interesting
  2. Shouldn't be the internal OpenCL from the CPU? I used the i7 OpenCL capabilities in some test and worked well But now that you say that I go to check if the last CPU have OpenCL capabilities (Y)
  3. A friend of mines just bought one but is waiting for the RAM right now ... I think I'll wait a week or so to see what happens
  4. Not in Houdini, but there's some data (see Rendering: Luxmark CPU OpenCL): http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/18 It's strange that 1700x and 1800x have the exact same performance in this case, isn't it?
  5. Why not a Ryzen? With that price difference (and same performance) you can buy a top GPU. The downside is that you have a limit of "only" 64GB of RAM and the CPU and system are fresh, so I can't talk about stability... Anyone has experience with them?
  6. It's really better if you cache out the sim using the "compressed_cache" node. It will use only the ram needed for the sim, and then only the ram needed for the surfacing. Maybe just with that it will works. 1 - "Save to disk in background" on "compressed_cache" it will start hbatch so you can close your current Houdini session 2 - Save to disk in background on "particles fluid surface" ... same as point 1 this way is more efficient.
  7. Can you upload the frame 137 cache? maybe the compressed_cache one 7zipped... so I can play with that directly
  8. Hi Atom, The distibuted sim works only if you have 2+ pc and halp exactly in this situation. So you have a rough total of ram that is the sum of your pcs ram. In this case you can't use distributed sim as you have just one pc. I think that depending on the flip sim it can be possible to split it. If the fluid is fast moving it will be very hard to set up, but for slow moving FLIPs I think it will be possible. Anyway I should try to be sure. Can you share the HIP to see if is there any optimization that can help? I'm thinking for example that the convert vdb node has and automatic partition in it, maybe you can set the partitions to higer values. Also the "VDB from particle fluid" has an option "Tile size" you can try setting the size to smaller values as that way should use less ram. I hope this can help. Cheers! Marco
  9. You almost did it! Just few more steps: Do the "attribute promote" of "Cd" from vertex attribute to point attribute before the "fluid source" node. To clear the linked value (green) do CTRL+Shift+LMB on that greened "density" and put Cd there. It should works
  10. Marcos, I think the easiest way is to export the alembic with the weight map as vertex colors. Then when you create the fuel source (your "fluid source" node after the emitting geometry) you should set "Scale by Source Attribute" ON and set "Cd" as source attribute. It should works this way. Maybe you should promote the Cd attribute from vertex to point, but I'm not sure it's necessary. Let me know if it works! Cheers, Marco
  11. Consider that if you set a "v" you are forcing a velocity for a point, exactly that velocity. "targetv" works like a goal, you're not setting a hard value for the velocity, just a goal and the solver try to reach that velocity. Something like this can help with the "deflating"? inflate_01_a_012_fix2_mem.hiplc
  12. Another option, but really I don't know if it's necessary (I think is not), is to use the wave layer tank. That way you have a layer of particles and you can adjust how deep is it, but I think it's useful when you actually have waves, in your case (calm water) you can simply resize the tank in -Y, that way you are controlling the deepness.
  13. You can resize the tank itself in the Flip solver settings, "Volume limits". Depending on how you created the sim it can be referenced to another node or not. In any case you can cut the reference, if you want, and modify it there.
  14. Also, I feel like the res of the flip it's kind of low. How many particles do you have? I see the parts separation is 0.015 but we don't know how big is that geo. I think in that particular shot you can use a relative small flip tank, surely not so deep as there's almost no action, and go with smaller parts separation. It's well optimized the size of the tank? A thin layer of water should do the job I suppose. Cheers! Marco
  15. Hi Andrew, yep, it's kind of strange behavior. Without the hip file I feel like the problem is the collider, but it's hard to tell.... Have you "polycapped" the geo?