Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Eckxter

  • Rank

Personal Information

  • Name
  • Location
    Antwerp, Belgium

Recent Profile Visitors

974 profile views
  1. 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.
  2. 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
  3. 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.
  4. Collision causing issues in pyro cluster

    I actually think I need Track Object on, because that's the whole point of my setup. The source grows per cluster, as the geo from which gets sourced changes in size and position or even just isn't there yet/anymore. And since the smoke will rise beyond the bounds of the source geo, it needs to be able to expand. For that reason, I don't think I can have max bounds on, since I need it to be able to grow beyond them. That being said, yesterday I was able to get it to work, although not as procedural as I'd like it. I just had to correct the expression that took care of the cluster groups by the amount of collision objects I added. (currently just 1) So the expression became: cluster_`stamp("../..", "OBJID", 0)-1` That only gave me a warning that it couldn't find 'cluster_-1', which it got when looking at the collision object which has an OBJID of 0. So for that I'd have to learn how I can add an id value that doesn't change regardless of the OBJID. Basically what the @id value is for particles. But for now I guess I'm good to go.
  5. Collision causing issues in pyro cluster

    After some more troubleshooting I think I found what is messing with the sourcing/collision. Since I changed the Gas Resize Fluid Dynamic node to resize each container based on OBJID, the number of objects changes the moment I add a collision object. So I guess because of that, the order gets messed up and it's doing its job one too many times or on the wrong ID number. I'm going to try and exclude the collision geometry from it. If anybody can come up with some advice, it would be much appreciated! Eckhart
  6. Grains point deform speed

    Not sure if it's even possible to speed this up. But I did make a cleaner setup so that you don't have to go copying those nodes for each piece you have. Now it'll do it by itself, regardless of amount of pieces you create. GrainPointDeform.v001.hip
  7. I'm having some trouble making my clustered pyro sim have collisions. It's a custom setup where I make a couple of containers with instancing at start frame and I've made a small change in the Gas Resize Fluid Dynamic DOP to resize each container separately based on $OBJID. The problem is that when I add collision objects, my density just doesn't show up or source anymore. When I use the shelf tool to make a static or deforming collision object, I don't get any smoke. Or I get it in weird places where the containers overlap. And when I use a Source Volume node set to Collision, all I get is what appears to be the Source field, but there is no density coming from it. When I disable the Source Volume node, density is sourcing and moving normally again. I've tested it in small scenes with basic geometry where I use shelf tools to setup the clustering and collision and then it seems to work. With the Source Volume node gives me the same issue, except when there's just 1 container (so no clusters). Then it works just fine. Since the shelf tool works, my guess is that I have to set some setting somewhere so that it works with instancing. I've been comparing the working test scene with my scene, but I haven't found anything yet. I'm afraid I won't see what I need to change even if it's under my nose. I've added the .hip file, but beware as it makes quite a bit of geo. So expect some loading time when you go in the SURFACE node. Thanks for any help! Eckhart TerrainDemat.v013.hip
  8. Rising wax from candle

    Hi Huds Thanks a lot for the response! Much appreciated. Yeah I started to get the feeling that POPs wasn't really the way to go. For the grouping, I'm not sure if I explained it properly. The thing I would like to get is calculate the amount of particles in a separated bunch of particles. Imagine a large body of fluid particles and now and then a bunch of particles rise up and detach from it, creating smaller bodies of fluid. What I'd like to put together is something that would detect each of these bunch of particles and tell me the amount of particles that each body of fluid has. So I suppose basically the mass of each of them. Then each particle of its fluid body would get the mass assigned to it, which I would use to control its velocity. With that same attribute I could drive a color value so that each fluid body has a different color. I hope that's a bit clear. I tried something with density field, but that got me nowhere. I'm kind of in the dark on the area of fields and gas solvers, for that matter... More and more I feel the need to understand how to work with GAS solvers and fields. Also, I have changed some things and managed to get rid of the need for killing the particles. But thanks anyway for the help there! ^^ I've put my most recent file in attachment. The candle is still the one form my first post. Eckhart CandleBorsato_Candle01_23.zip
  9. Rising wax from candle

    Is there a way to calculate the amount of particles in sperated group of particles? I'd like to make it so that drops of fluid with less particles travel faster than drops with more particles.
  10. Rising wax from candle

    Hi guys, I have a couple of issues with my project. What I want to accomplish is wax rising from a candle in interrupted streams and it has to be able to loop every 10 seconds. The first issue that I'm having is that the particles that I don't want anymore, are not being killed by the POP Kill. I want to kill particles that are older than 3 seconds and barely move anymore. As you will see in the .hiplc, I am first grouping particles that are older than 3 seconds. Then from that group, I group the particles that have a velocity length of lower than 0.5. This is to prevent getting these very long and thin streams of wax. I would like to have shorter streams as those that I get at the start of each stream and that they then just cut loose from the candle instead of these constant streams. I had found this thread in which they mention to put an * in one of the group nodes. I did that on my initial group node, as I source from other groups down the line, but that didn't help. My second issue is that I would like to get different velocities for the different streams of wax. I'm not quite sure how I could assign multiple velocities to groups of particles within the same simulation. I currently set the gravity in the positive direction, but I'm guessing I'm going to need something else eventually. Or should I just create particle simulation for each stream of wax? Thanks in advance! Eckxter Candle.zip