wakimsan

The pyro post process node applies its own material to the object at SOP level. If you look at the primitive attribute "shop_materialpath" you can see which material overrides the one you applied at OBJ level. It's actually a material within a matnet in this node. If you uncheck "assign render material", the node will not apply a material. However, if you want the post process node to work properly with a similar shader setup - you can go to the "Bindings" tab of the post process node. And, just like we did with the shader, type in "flame" in the temperature field. Make sure "Assign Render Material" is checked ON. This method will allow the post process node to apply the intended material and allows you to control the (shader)attributes in sop context. cheers

Hi, I recently finished this little teleportation effect. Some of it's based off of "applied houdini particles VI", but converted into 3d behavior. CC is always welcome:)

Hi Doanh, I haven't really looked through the tutorial, but I can tell you're having some issues with your fields. At the moment you only have a vdb converted into a volume called "flame". The pyroshader you applied to this volume tries to read the fields; "heat" for intensity and "temperature" at the "fire temperature field" tab. That's usually the default setting because a pyro sim will usually produce those fields for you automatically. You probably only want the intensity to be controlled by your flame field. If you type in "flame" in each of these fields(intensity & temperature) in the shader, you should get some visible muzzle flash in your render. cheers

It's render view. I always thought mantra did normal buckets when batch rendering anyways...? Yeah, it always seems slower to me as well, but not at this level, where all cores are barely showing any activity. I'll try to play around with some settings when I get to my workstation again:)

Sweet, thank you! I started listening, but need a bit more time to get through all of it. It seems like a really interesting lecture! Thank you!

Hello! I just got myself a threadripper 3960x for freelance simulation purposes etc. My workstation is now up and I'm doing some performance tests. I'm getting some very unexpected results when rendering in mantra. And I'm very curious if someone can help me understand what's going on under the hood? A simple scene I created(with some geo, lights and reflective materials) takes about 2 minutes to render in mantra in bucket mode. All good and as expected! The same scene takes about x3 times as long in progressive mode. If I monitor the core activity, they're almost idling while rendering, then suddenly, about halfway through, they all accelerate up to max speeds and finish the render in seconds... Anyone wanna take me to school? Thanks, Joachim

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

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.

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.

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.

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...?

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.

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.

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

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.