Akabane

I guess more than a problem with wrangling points into a pop network (which you are doing, and checking wheter a pt is in a group is a bool so is only 1/0 - Yes/No), the problem with the smooth transition would be in my opinion that your points are going from a state of stop to one of full pop control. So they might look like they "snap" where they have to be (as you said, 1 frame transition). two ways I can think to build a workaround: 1-Use the good old blendshapes. If you're merging a fixed number of points into the pop stream, you can match them by $ID and blend between them with your desired transition length via keyframes or expression/vops (ie: fit($FF, 15,30 , 0, 1) on the blend node for example which will remap the frames 15->30 to be value from 0->1) - The problem I can see with this is that the particles will move linearly towards their desired output position, but then again, being the blended points animated via pop, the effect might work just fine, and it's by far the easiest solution. 2-Do a pcCloud lookup in a popvop and start averaging the velocity of newly added points into the sim during the amount of frame you want. Just be aware of the fact that sometimes pop forces add speed and not velocity so yeah just be careful if you have unwanted results Of course those are my 2 cents and with a scene included it would be easier to help

Hello there! I have been wondering what could be the cleanest way to have only some specific points on a mesh (say, grouped by attr or something else) to be fed into a particle system, removing the points the particles generated from (basically switching from a point to a moving particle). Of course I know all the standard sourcing pops practices, but my problem lies in the fact that I want to do this in a gradual way over time. For example, frame 1 = all my mesh points are still points, frame 10 = a group is created of 10 points, those 10 pts get deleted and fed into a popsystem, frame 20 = my mesh still is going forward with all its points except the 10 I used to spawn particles, and another group gets created, those points need to be deleted and fed into the same particle system and so on and so forth. In the past I approached this in different ways (manually creating hdd saved geometry for the spawn frames and use those as source, get all my mesh to be a particle system and only affect some based on pop grouping etc) but I haven't still found a more elegant and streamlined way to do it. I have thought about doing a growing group in sopsolver, but the particles that are there would stay in that group, meaning that if that group is my spawner, it will always emit all the points in that group at every frame. Also thought about stepping forward in time by 1 frame, regroup and subtract from the previous group (so I would get only the "newest" particles each frame), but this would mean cache my points to disk before doign this operation which might be too convoluted. Any thoughts/best practices/ suggestions about this? Thanks!

Hi guys! I was wondering how could I implement an "age" field to shade and tweak my fluid. I would start doing it by advecting a bunch of particles and transfer their age attribute to field via the particle to field dop node, but I don't know if that would be the preferred way or if there's a gas microsolver I'm not aware of that might help calculating all of that inside the gas calculation (even if I might end up chewing more data than needed). Has anyone here already done that? Any pointers? Thanks!

Ice cold. Love it. XD

Well, to use a shelf tool you'd need to click on it, thus making it useless, right? You'd do 1 click anyway to activate or deactivate the display of background image from the viewport...

Alembic all the way. If you feel old fashioned (or can't use alembic for a reason or another), good old obj/fbx+pointcache

You guys, you DON'T have to change the field inside the shader. That DOES NOT WORK. As explained, Mantra expects a density field to make the pyro shader work. If your sim doesn't have that, no render - simple. You have 2 options for now: 1- What Mawi has suggested. Dive inside the shader and change the parameter that the renderer expects to calculate quality (<-cleaner technique, thanks!) or 2- My solution which is just rename the temperature field to be the density field. If you go with (2), you don't do this change in the shader. What you've basically done was trying to tell the shader to evaluate the fire/density using different fields. That's just how it will look.You'll need to go in your SOP object with the sim, drop a "name" node, and rename "temperature" (or heat or whatever) to "density". Now use "density" in your shader for the fire field.

Add velocities to the pieces in SOP before feeding them into the cloth solver? Should work O.o Either you add velocities to the points and them copy them to the copied cash objects (and you'll have 1 vel vector which is uniform for each cash piece), or after copying them, create vel vectors for each cash object (in this case you'll have every cash piece having varying velocities per-point, and per-object). Edit, whops, just realized you asked for ANGULAR vel... Well you can recreate it giving each piece of cloth opposite velocities at both ends, as you'd do in real life: v(1,0,0)------v(-1,0,0) (where "-------" is the cash bill from the side) This should create a spin force on each object.

Isn't it easier to just play around with the Spatial Scale parameter in the solver? To go your route, you'll probably have to plug that multiplicator in a LOT of parameter/nodes inside the solver, and I'm not sure we have access to which one is working in world units or "percentages", and how they all tie up together to come up with a formula that allows scaling by number.

Haven't had a look at your file yet, but it probably it's because when you create a smokeless flame, there's no Density volume. I've been going aroudn this problem just by renaming the temperature field to density, and that's it. Of course modify your shader accordingly to pick up "density" instead of "temperature" in your fire shading tab

...but you could also opt for a half procedural way For example, without having to automatically find out where to place windows, or creating the windows procedurally with correct spacing etc..., you could create the walls, then place points manually where you'd want the main features of the house to be, rename the points (like 'pt_window_01') and then just instance the models you made by hand (in houdini even, you have to be more patient than doing it in maya/max/xsi though but you have more flexibility) on top of those points, and just use procedures to put holes in the walls where you put the windows in etc...

Hah, maybe a display bug (go read the "Houdini OGL viewport" poll ) See if closing and reopening houdini helps.

If there's no dust but it's only dirt and grass, I'd go super easy with pops and wires for the leafblades if you want to be super cool, otherwise just a particle with a bent line (maybe counteracting the particle's own vel so it bends 'correctly') would easily do, if the car is far. For the dirt, just throw a bunch of particles around that move in a decent way, add rotation to them, and instance small pieces of geo to it (or even other bunch of particles)

Just from the top of my head... What about attribTransferring the surface N as Velocity for the particles each frame? Delete it each frame and replace it directly with the nearest surface point velocity?

It depends on what you need to achieve. PBR actually gives sharper results out of the box, but of course you'll have to ramp up the pixel samples. On the other hand, you can go pretty high with the Volume Quality without detail loss. PBR works GREAT with raytrace shadows, super fast. Good thing about the PBR is you can fake fire scattering in the smoke (using a geometry light generated from the heat field) and it's pretty fast at that (opposed to the pyro shader default scattering) On the other hand, Micropoly gives softer results, so you'll have to tweak the shader more to get sharp details, you'll have to lower the volume quality to get nice details. Working with Micropoly takes the raytrace shadows out of the question so off you go with DepthMaps. The pros of using micropoly is that you can actually use pyro displacement, which gives A LOT of NaN artifacts in PBR. EDIT: Everything here using 12.1 - Haven't checked if the PBR + pyro displacement still gives NaNs in 12.5 or if it has been solved, AND I still need to understand how to succesfully render out the changes created by the 12.5 Cloud Light node, which should help a lot in faking scattering. It does in the viewport at least. If you want to play with it remember to isolate the density field for the cloudLight, otherwise it'll calculate it for EVERY field you have. But as of now (been playing with it 10 mins) I still am not able to render it correctly (whenever I use the Ce Vector field as emission in the pyro shader, render goes crazy)