Particle Ageing (via Math Node) does not map correctly to ColorRamp Fac #39474

New Issue

Willi · 2014-03-28T01:21:36+01:00

Jarron commented

2014-03-28 01:21:36 +01:00

(Migrated from localhost:3001)

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 Agedivided 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

Jarron-ParticleInfoNodeMathColorRampMismatch.blend

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...!//

**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 [Jarron-ParticleInfoNodeMathColorRampMismatch.blend](https://archive.blender.org/developer/F83072/Jarron-ParticleInfoNodeMathColorRampMismatch.blend) *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...!//

Jarron commented

2014-03-28 01:21:36 +01:00

(Migrated from localhost:3001)

Changed status to: 'Open'

Jarron commented

2014-03-28 01:21:36 +01:00

(Migrated from localhost:3001)

Added subscriber: @Jarron

Jarron commented

2014-03-28 01:37:05 +01:00

(Migrated from localhost:3001)

Oh: I forgot to mention that I have tested this on multiple computers, the Math Node's Clamp option appears to have no effect, and that it does also manifest when Physics are enabled.

Oh: I forgot to mention that I *have* tested this on multiple computers, the Math Node's **Clamp** option appears to have no effect, and that it does also manifest when Physics are enabled.

Willi commented

2014-03-28 03:14:10 +01:00

Added subscriber: @willi-2

Willi commented

2014-03-28 03:14:10 +01:00

I can repro it, and I agree. As connecting the output of the Divide node directly to the emission shader gives RGB values 0.10197, the input to the ramp node is correct. In addition, the Pos value within the ramp node is exactly 0.1 without truncated decimal places, so I'd see the problem in the ramp node, too.

Willi commented

2014-03-28 04:25:11 +01:00

After looking at the source code, I think the reason is that the color ramp has a limit of 256 entries (in the range 0 to 255). At frame 10197, the age is 10196 because the start frame is one. Age divided by LifeTime results in 0.10196. Multiplied by 255 it's 25,9998. This value rounded is 25. That means: At frame 10197, the entry at position 25 in the ramp table is used.

At frame 10198, the computation is ((10198 - 1) / 100000) * 255 = 26,00235. Consequently, the entry at position 26 is used.

In other words, the fac of the ramp node has a resolution of 0.00390625.

So the experienced behavior is by design.

After looking at the source code, I *think* the reason is that the color ramp has a limit of 256 entries (in the range 0 to 255). At frame 10197, the age is 10196 because the start frame is one. Age divided by LifeTime results in 0.10196. Multiplied by 255 it's 25,9998. This value rounded is 25. That means: At frame 10197, the entry at position 25 in the ramp table is used. At frame 10198, the computation is ((10198 - 1) / 100000) * 255 = 26,00235. Consequently, the entry at position 26 is used. In other words, the fac of the ramp node has a resolution of 0.00390625. So the experienced behavior is by design.

Willi commented

2014-03-28 13:43:55 +01:00

I should have added that I was referring to constant interpolation mode (i.e. no interpolation) as in your blend file. Otherwise, I wonder what's the actual problem if you set interpolation to linear, which is, what you probably need in your actual project.

I should have added that I was referring to *constant* interpolation mode (i.e. no interpolation) as in your blend file. Otherwise, I wonder what's the actual problem if you set interpolation to linear, which is, what you probably need in your actual project.

gandalf3 commented

2014-03-29 21:57:09 +01:00

Added subscriber: @gandalf3

Brecht Van Lommel commented

2014-03-31 13:45:19 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2014-03-31 13:45:19 +02:00

Brecht Van Lommel self-assigned this 2014-03-31 13:45:19 +02:00

Brecht Van Lommel commented

2014-03-31 13:45:19 +02:00

The color ramp indeed has only limited precision, it's converted to a table with 256 entries for fast lookup at render time. I wouldn't consider this a bug, we could add more precision but that also means more memory usage or longer render time. If you need to do such precision operation it would be better to use math nodes.

Jarron commented

2014-04-01 05:04:52 +02:00

(Migrated from localhost:3001)

It's a valid question, I suppose, wondering just what practical impact this has – especially considering all the other hoops I have to jump through to get the particle system working as I want, but shrug I found a bug, so I reported it.
If y'all wanna ignore it, no worries. At least my conscience is clear (this was my very first instance of "contributing something back" to one of my fav apps - I appreciate you taking the time to make it a very professional experience)

It's a valid question, I suppose, wondering just what practical impact this has – especially considering all the other hoops I have to jump through to get the particle system working as I want, but *shrug* I found a bug, so I reported it. If y'all wanna ignore it, no worries. At least my conscience is clear (this was my very first instance of "contributing something back" to one of my fav apps - I appreciate you taking the time to make it a very professional experience)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Particle Ageing (via Math Node) does not map correctly to ColorRamp Fac #39474