Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Eckxter

  • Rank

Personal Information

  • Name
  • Location
    Ghent, Belgium

Recent Profile Visitors

1,176 profile views
  1. Exporting Pyro Simulation as VDB problem

    It is indeed talking about the memory (RAM). When caching to disk, make sure that you've turned OFF the checkbox "Cache Simulation" on the DOP Network. Otherwise it will keep the previous frames in memory and you'll eventually run out of memory. And in that case, you would get the error you're getting. With the checkbox off, Houdini will only keep the previous frame in memory to be able to solve the next. If it was already off, then you might not have enough memory available for Houdini to solve the single frame. Solutions in that case: 1. Lower your resolution (increase voxel size) Or 2. Buy more RAM P.S.: Your SSD is 'storage', not 'memory'.
  2. I believe what you're looking for is the checkbox 'Build Hierarchy from Attribute', which you can find on the ROP Alembic Output under the Hierarchy tab. Provide a primitive path (or any string) attribute on you objects, which is unique for each object, and enable that checkbox on the ROP Alembic Output. And of course make sure the 'Path Attribute' is the attribute you need.
  3. Cannon Fire; Smoke not travelling far enough

    For starters, fast moving smoke like this is a bit tricky to control with the default solver. There are multiple ways to approach this. For the fire not going away fast enough, that is actually quite easily done post-sim. Having the fire (not) visible is not much more than a matter of visualization (or in other words, shading). A couple of ways to do this. One way would be, if you're happy with how the motion due to buoyancy is going, you can use a VolumeWrangle to reduce the heat/temperature values post-sim. Of course, using a Volume Visualization SOP to look at your sim outside of DOPs. So no matter how long your heat/temperature is lingering, you can just say "from this frame, I don't want to see any of it anymore". For the movement of the smoke, my first thought is using the GAS Repeat trick. Found here: https://vimeo.com/164664923
  4. If you've used the Voronoi Fracture SOP, it lets you create an interior group and an exterior group. Using those groups, you can assign a different material to each with a Material SOP for example.
  5. For that you'd use a SOP Solver. https://www.tokeru.com/cgwiki/index.php?title=The_solver_sop#Attributes_other_than_position
  6. Since Attribute Transfer works by distance, it might transfer the 'path' attribute to the wrong primitives. My suggestion would to do your operations in a for-each-loop that runs over the path attribute. The loop will isolate each part of your model, based on the unique 'path' value they have. Then after your process of re-meshing, still inside the for-each-loop, you can use a primitive wrangle to pick the path value from the original piece and set it on your new geo.
  7. I think you need to set the attribwrangle to run over primitives. I'm thinking that it needs to run over every primitive, so it changes the detail attribute each time. Instead of detail which runs once, giving you one value. Also, what is that attribcopy doing in the for-loop? Isn't it overwriting the attribute you want to change?
  8. Strange pyro cutoff

    I still don't get any cutoff. No matter how far/low I go. Are you sure you've given the exact same scene? Maybe it has got something to do with your hardware? Reaching memory limit or something along those lines.
  9. Strange pyro cutoff

    Opening your file, siming to frame 25 and hitting enter gives me this. In the viewport: And this in the render view: I'm not getting any cutoff.
  10. Strange pyro cutoff

    My guess is the value mapping in your shader is not the same as the one in your visualizer in DOPs/SOPs. Try to troubleshoot by checking what the min and max values are on the visualizer in DOPs and copy those values over to your shader. Making sure that it's using the same fields as well. Or, where you import the volumes in SOPs, plug them into a Volume Visualization SOP and check whe range of values you need for what you want. Once you have something you like, use those values for the corresponding fields in your shader and work forward from there. Or, you could share your scene and we could have quick look.
  11. Attempt #34057 of becoming more active on this forum.........

  12. Smoke not colliding with object

    Simple fix, on the Pyro Solver, under the Combustion tab -> Smoke tab -> Source parameter, change that to Burn instead of Heat. If you want to keep sourcing smoke from the heat field, then under the Advanced tab, go to the Collision tab. In there, add 'heat' to the list in "Fields to Correct". So that the list becomes "density fuel heat". My guess is that heat doesn't necessarily get influenced by collision objects, unless you tell the solver to do so, by adding it to that list. So as long as it's not in that list, it can move through collision fields. And since the solver uses the heat field by default as a source for smoke (aka 'density'), it was able to create density outside your tube.
  13. Exclude identical points from different arrays

    I'm not sure that'll do the trick, as there is still the possibility that the searching points will find the same goal point. Even if they're allowed to find only one. And I've tried limiting the goal points to 1 per searching point, but then the pattern in which they connect changes too much. At the moment, I've made a workaround by allowing the search points to select more than 1 goal points at random intervals. That way there will be splitting happening, that compensates for the collapsing. Which at the moment is giving me desirable results. Tho I'm still curious to find out if there's a way to compare arrays on different points.
  14. I'm making an effect very much like this one from Entagma: https://vimeo.com/194277211 I've adjusted it a little and I noticed that some of the curves that get created collapse onto each other. I think it even happens at the very first frame. You can see that by the white parts of the lines. Those are the last created points. When two white parts meet, it means the curves collapsed and continues as 1 curve. What the setup does is it has a bunch of points as the active searching points. Each of these find target points in front of them and saves those in an array. Then a random point from within the array gets chosen and used to make the polywire. Sometimes, mainly at the very beginning, the searching points are close enough together so that they might find the same target points. This is where I believe the issue lies. What I would like to achieve is that I can check between the arrays on each of the points to see if they have similar target points and if so, remove those from one of the arrays. Or that when points get targeted by one searching point, they instantly get marked so that they can't be found again before the end of the timestep/solve. At this moment, I'm still trying to figure that one out. Any tips for this are much appreciated. Eckhart ObjectMaterialize.v005_00.hip
  15. Exporting ocean geo without displacement

    You could apply the spectrum to the mesh from the simulation. Just increase the extrude divisions under the Region tab of the Particle Fluid Surface node, so you get more polygons in those corners. Be aware that you're going to have quite the heavy mesh if you're going to have a wide angle shot and you're going to match the resolution of those corners with that of the simulated part. Also, be sure to watch the Ocean Tools Masterclass to get more info about this stuff.