I'm confused about pop attributes. The docs show @nage as an attribute however it does not show up in the Geometry section of the popobject in the geometry spreadsheet. Apparently in pops @attrib calls effect node properties that effect the sim and not geometry attribs. however may attribs are shown in the geometry spreadsheet. But not @nage. is there are reason for this? or is there another way to see the values of @nage.

Thanks

Well @nage is just the normalized age. To acquire it just use a fit.

Apparently @nage is a virtual attribute. I don't know what a virtual attribute is. But i guess that means its an attribute that isn't shown in the spreadsheet.

This confuses all the new users alot and normalized age is whats gets used all time for effects. I think its should always be propagated to sops. I hope sesi will change this behaviour in future.

Thank You Enivob!
@nage gets unfortunately bugged from v19.5.805 all the way to v20.5.410. Gives the exact bugged anomalous-spontaneous large lit spheres to appear generated completely at random that Ivan L reported [www.sidefx.com]. All the other properly working-generated small spheres animate beautifully, then randomly large-spheres appear occluding the entire beautiful animation with diameters @pscale "10 or 55", when they should all have diameters between @pscale 0....1! This on GL Viewport (lit spheres display) or on Karma same.

Visible also on Geometry spreadsheet where you can observe bugged negative values appearing randomly and larger than 0...1 numbers, like a negative @pscale diameter -0.005 or 7.01 @pscale size lit sphere, which should not be happening. Took me days to investigate and track this down, when attempting to follow
Houdini is HIP - Part 6: Particle Simulations [youtu.be] I was thinking my RAM is broken, my HDD is broken and Houdini reading back generated particle cache from bad sectors on my disk. Turns out its a bug. Keep in mind I'm a beginner C# coder and a blundering math trainwreck. So I cannot spontaneously summon a brilliant equation (or two) fantastically relieving @nage and solve this problem. Many on this forum here are genius mathematicians.
WORKING ALTERNATIVES
The following particle-diameter thinning / gradually reducing methods work that I found:

1. Enivob saved the day with:
fit(@age,0,@life,0,1);
Example:
@pscale = @pscale * fit(@age,0,@life,0,1);
so to make particles get smaller and disappear with age:
@pscale = @pscale * (1 - fit(@age,0,@life,0,1));
This looks really nice!
Weird, as its the same, but it works! Probably the @nage attribute is hardcoded and that specific code is bugged.


2. I found it works similarly, if I just leave out the N from @nage, netting @age!
@pscale = @pscale * (1-@age);

Instructor is using v19.5.493 and he uses just @nage and it runs perfectly on his machine!

In later versions @nage becomes is bugged! OpenGL viewport AND karma shows anomalous LARGE SPHERES spontaneously popping up at random timeframes if you move the time slider.

Visually and artistically the two solutions above look different, but both are nice. #2 gives fatter lit spheres and #1 is very comparable (same visually) to what instructor Moeen Sayed is demonstrating in his amazing tutorial.

If you have a particle die on impact does Houdini only know the life of the particle after caching?

thanks

jamination
If you have a particle die on impact does Houdini only know the life of the particle after caching?
thanks

it doesn't, the @life is set during emission and it's the particle's lifespan
if the particle gets killed earlier for whatever reason, the @life is not updated and therefore @nage will still be normalized age across the original lifespan

if you want to update @life to that @nage is normalized age until the particle gets killed you will have to do it yourself post sim