**System Information**
Operating system and graphics card
Mac OS, Macbook Air
**Blender Version**
2.70 2525f9c (latest)
(Has never worked in past versions as far as I have experienced)
**Short description of error**
Attempting to use **Particle Info** node in Material to cause particles to change RGB during lifetime - //for example to simulate sparks which start yellow-white hot then cool to red before dying.//
Straightforward/conceptual math would reason that **Particle Age **divided by total **Lifetime** would result in a 0.0-1.0 range, perfect for plugging into a **ColorRamp's Fac**.
However, this is not consistently the case.
I have in the included Blend file shown my reasoning and steps to arrive at this conclusion.
**Exact steps for others to reproduce the error**
Based on a (as simple as possible) attached .blend file with minimum amount of steps
{F83072}
//Note that I have intentionally maximized the variables involved to more clearly show the error.//
- **Particle Lifetime** has been set to **100,000** (not too far short, as a factor, of what appears to be the current maximum of 300,000)
- **Scene Duration** has also, therefore, been set to **100,000**
- All particles are emitted at the same time, **Frame 1**
- **Physics** are irrelevant and so are **disabled**
The Particle's Instanced Object Material nodes are set up as shown in the file.
- A key point is that the **ColorRamp's interpolation** is set to **Constant**, which makes it as easy as possible to spot the "switch-over" as compared to the smoother modes.
One should now expect that the **Pos** of the **Ramp Handle** will map consistently to the scene playhead.
- //For example//, setting **Pos** to **0.500** should cause the particles to change to that hue **exactly halfway** through the animation.
What actually happens, however, is that **results are mixed** depending on the set **Pos**
- If the Pos happens to be a nice even value it works correctly. So far I have personally verified **0.2**, **0.4**, **0.6**, and **0.8**
- But for many **odd values** - so far I have seen **0.1**, **0.3**, **0.5**, **0.7**, and **0.9**, the actual changeover happens exactly 197 frames late - over the lifetime of the scene this is an error of **0.197%**
Such a percentage may sound like nitpicking, but the error is manifested in quite reasonable ranges, too.
It's how I first became confused by the problem, after all.
- Even over a mere **1000 frames** it will pop in two frames late - the same percentage of error, adjusting for rounding.
Further, the fact that it happens at **some values** and **not others** makes me regard this as a bug worthy of chasing up since it involves some **pretty foundational** nodes, such as the Math node.
If it was a consistent offset I would just add another math node to compensate.
//Yes yes, I know this isn't the place to request features, and I will file a separate request, but seriously: Why isn't there a way to directly find out the evaluated result of a Math node?
Either by plugging in a "Show Value" node, conceptually equivalent to the Viewer Node for image results - or even better simply displaying the value in the node's upper right corner, just like the warning on the new Volumetrics nodes.
It would eliminate **so much** guesswork...!//