Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

2 Neutral

About wakimsan

  • Rank

Personal Information

  • Name
  • Location
  1. Bouncing Pyro Flame

    Hi Furox, It will depend a bit on what you're after, but here's some things you could do; -Add a preroll - start your sim earlier so that it's fully developed on the first render frame. -Slowly increase fuel - you can animate the amount of fuel your solver takes in. Starting off with 0 and slowly increasing to the desired amount should reduce sudden pop/bounce. -Add some strong noise to your fuel source - it might help break up the uniform bounce at the begining. Cheers
  2. Issue with trail sop velocities

    Hi Josh, It could probably be several things, but I'd guess you need a consistent id attribute for your points. At the moment the velocities are probably based on your ptnums which keeps changing from frame to frame. One frame ptnum 100 might be at a point at the bottom right, next frame it's at the top. The trail sop interprets that as a very fast moving point.
  3. Orient of a point in a line

    Hi noumiere, Looks like you merged the plain scattered points with the points that has the new normals. The scattered points won't really have any normal or orientation, so it won't give you the expected result. What you're after(as far as I understand it), is to have the same normal and orientation for all of your points. Which means that when we create our copy with the offset along the normal, we need those to have the same attributes. The only things I would change with your setup is the order; after the scatter do the wrangle and pointvop. Remove the line which offsets the points: @P += @N*chf("distance_mult");. Now create another wrangle after all these and add the offset line. This wrangle will create the copy we're after. Merge the output of this second wrangle with the output of the node before it. Now both copies of the points should have the same attributes. And finally copy to points. The line and resample is not necessary. It only proves that the setup works properly and allows you to add as many boxes with the correct orientation as you'd like.
  4. How to add velocity to newborn particles

    So the particles will change their trajectory completely from one frame to the other? Like colliding with a wall? You could possibly ignore the inherit velocity and use your velocities through advection instead. But only affect a specific group of particles. In this case, if age is less than X. Then you could add another gravity force which affects the particles if age is greater than X. If you create your groups before the forces in your popnet, you should be able to simply select those for each force.
  5. How to add velocity to newborn particles

    Hi Gabor, I imagine it's "drag" or "air resistance" you're after. I think it's the popWind node where you can add a specified amount of air resistance. If you play with that value and the inherited velocity, you might get what you're after:) Though, if you need control over the exact frame the particles slows down, it might not be the best way. Maybe animate the air resistance...? With your edit, this solution is probably not precise enough. popWrangle...?
  6. Orient of a point in a line

    Hi! Vops looks correct, the problem is that the target point you're creating doesn't really inherit the orientation. You could create the orientation again and point it back to the origin point, but that seems unnecessary. What I would do is change your approach to creating that second point. Easiest way I can think of is to not create a new point at all. Instead move the origin point along the normal @P += @N*chf("distance_mult");. And merge that moved point back with the original. You can use an "add" node to create the line between the points if necessary. And if you resample all points should point the same direction.
  7. Orient of a point in a line

    Hi noumiere, What I would do is create an orientation matrix(I'd prefer vops). If you use the vector you created pointing at your target: vector p = point(1, "P", 0); v@N = normalize(p - @P); I added it to the normal in this case. Take the cross product of an up vector {0,1,0} and @N. And normalize it. That's our X vector. Now do another cross product of our normal and our newly created X vector. Normalize it. That's our Z vector. The normalized @N is our Y vector. Add these into a "vector to matrix3". Take that result into a "matrix3 to Quaternion" and that result is our orientation. If you're using vops(like me); bind export "orient" as a vector4 attribute. Your cubes or lines should be pointing at the target while having control of their local orientation. Your line node direction might have to be changed to -1, depending on what you're after. I can upload a hipfile later tonight if needed.
  8. Moving lines along grid

    I managed to find a solution to my issue. The grid animation works quite well for the intended purpose, though a bit heavy. The rotation is a bit hacky. I can't be bothered to do it better atm. It may not be elegant, but it might be a good starting point for someone in the future. rotating_grid_v001.hipnc
  9. Moving lines along grid

    So, I managed to create a hacky version of my grid. Copied some cubes to it and added some rotation. Here the grid is static and my rotation is working fine. However my animated grid is not nice. The everchanging ptnums is an issue: It yields this result: So...new technique; creating points from scratch in vex, some simple animation and make sure pointcount stays consistent. Though that leaves me with a different issue and leads me to my question(finally). Is there any way to use the pcfind function to operate on a specific axis/vector? Here I'm currently using it with the distance function to calculate the scale of the points before copying cubes to them: int nearpt = pcfind(0,"P",@P,chf("rad"),chi("maxpt"))[1]; i@nearpt = nearpt; f@dist = distance(@P,point(0,"P",nearpt)); v@scale = @dist/2*chf("scale_mult"); It only really calculates a single closest point, though I need a separate calculation for X and Z and jam that into the scale vector. I'm trying to keep a consistent gap between all sides of the cubes. Thanks.
  10. Moving lines along grid

    Thanks srletak! Lots of nice inspiration there! Closest thing I could find was this(though I'm only after a simple 2d solution): The idea was to then convert each prim to a cube with some spacing. Not a very specific question I'm asking unfortunately... I'll post an update if I make any progress. Thanks
  11. Hi guys, I'm trying to learn a bit more about geometry creation and manipulation in vex. I've been attempting to create a simple grid with lines moving along in one direction. Once the line reach the end of the grid, it moves back to the other end. Like a treadmill. I've been able to create some stuff with addvertex and addprim in a for loop, but nothing nice and procedural. Anyone have an elegant solution to this? Thanks
  12. Vellum - animated Pin to Target?

    Thank you very much splegare and Vitor! That worked great! Never would have figured out that solution by myself. And thank you for sharing the hipfile(needed that). Thanks.
  13. Vellum - animated Pin to Target?

    I'm struggling with the same issue at the moment. What's strange is that I'm perfectly able to do it the other way around; having 0 pin to target on all points, then adding pin constraints throughout the geo with an animated attribute transfer in a sop solver within the dop network. Then using the dop vellumconstraints, set to update on each frame, to create the pins throughout the simulation. Must be something I'm missing here... Any insight would be greatly appreciated. Thanks