# Why does each point have the same life time?

Why does each point have the same life time? I would expect like, 0, 1, 2, 3, 4 etc. (one new point each frame, and life time increments by one...)

Take a close look at the sockets of Life Time. It's always a green diamond with a dot in the middle. From the docs:

Diamond with Dot: The socket can be a field, but it is currently a single value. This is helpful because it allows tracking where single values are calculated, instead of a field with many different results.

This means that you assign the same life time value to every new point you join to the simulation. You need to make that property a field. From your description i assume you want to increment Life Time of every existing point by $$1$$ per frame and let every new point start with Life Time = 0. Try this setup:

As you can see, the simulation is at frame 21 and the first point (index 0) has a Life Time value of $$21$$. Also observe that the sockets of Life Time have changed to a filled diamond, indicating a real field.

(Side note: i am not sure why you plugged the point Geometry output node into the simulation Geometry input node. Makes not much of a difference except for a duplicated first point if i am not mistaken.)

• For your side note, I copied that behaviour from a tutorial, thanks for pointing that out. Commented Aug 23, 2023 at 9:04
• I think it's a bug. Blender assumes it's a single value, because it uses a default value on the input, disregarding the fact it's true only on the 1st frame, and could be different (is) on consecutive frames. It's very similar to this question of mine, which has been confirmed to be a bug. Commented Aug 23, 2023 at 9:55
• @MarkusvonBroady Interesting, didn't come to my mind it may be a bug. I thought without any actual dependency to geometry (Sample Index) Life Time is just a standalone simulation zone property getting incremented. Commented Aug 23, 2023 at 10:06
• @taiyo if only Blender docs were more elaborate, specifying not as much the actual behavior, but the designed behavior, the contract, as in, this is how it's supposed to work, if it doesn't, it's a bug and will be fixed, if it does, it won't be changed (maybe in a major=breaking version)… But we are left guessing and making sense out of things… Moreover, I'm not so sure it was the right call to consider it a bug and "fix" it. Your interpretation makes sense! It is a single-value (I call it constants, though makes less sense in simulations), and interpreted as such, produces another Commented Aug 23, 2023 at 10:45
• single-value on the output, so it is a single-value in the input on the next frame and so on. If you wanted to convert it to a field, you could do it like so: i.imgur.com/gqkuQQ4.png [maybe even before the group input, would be faster too] maybe it would be better if you had nodes to explicitly convert a single value to a field (other way around you do with an attribute stat or sample index with a constant index) Commented Aug 23, 2023 at 10:46