Particle Size Weirdness #53513

New Issue

Steffen Dünner · 2017-12-08T14:57:58+01:00

Steffen Dünner commented

2017-12-08 14:57:58 +01:00

System Information
Win10 x64, nVidia GTX1080Ti

Blender Version
Broken: All so far
Worked: (optional)

Short description of error
One might not consider this a real bug, but IMHO this can easily destroy (as in "change") your particle simulations during a project so I consider it a showstopper bug.

The value "ParticleSettings.particle_size" can be changed in two different places in the particle settings tab.

Under "Physics":

And under "Render":

This makes perfect sense if you want to e.g. simulate particles with a certain size but render them as larger or smaller instances (Groups, Objects, ...).
The problem is that both sizes point to the same data path and change each other. So if you use "Fluid" particles and bake your simulation, most of the particle settings UI turns grey and can't be changed (because now the bake is in control). You're still allowed to change how particles get displayed and rendered. And you can also change the render size of the particles BUT as it uses the same data path you don't only change how they're rendered but you now change a setting of the simulation / physics. You can successfully render the baked sim with larger particles if you want BUT as soon as you have to rebake your whole simulation will totally change which is a true production nightmare.
The render/display size could be made totally independent or a factor of the physical size but the display size should NEVER influence the physical size.

This "feature" is currently making an otherwise super smooth project a lot more tedious to handle and I hope it can be "fixed" with some band-aid until the new particle system in 2.8+ comes.

Exact steps for others to reproduce the error
Read above.

**System Information** Win10 x64, nVidia GTX1080Ti **Blender Version** Broken: All so far Worked: (optional) **Short description of error** One might not consider this a real bug, but IMHO this can easily destroy (as in "change") your particle simulations during a project so I consider it a showstopper bug. The value "ParticleSettings.particle_size" can be changed in two different places in the particle settings tab. Under "Physics": ![Particles_Force.png](https://archive.blender.org/developer/F1344709/Particles_Force.png) And under "Render": ![Particles_Render.png](https://archive.blender.org/developer/F1344731/Particles_Render.png) This makes perfect sense if you want to e.g. simulate particles with a certain size but render them as larger or smaller instances (Groups, Objects, ...). The problem is that both sizes point to the same data path and change each other. So if you use "Fluid" particles and bake your simulation, most of the particle settings UI turns grey and can't be changed (because now the bake is in control). You're still allowed to change how particles get displayed and rendered. And you can also change the render size of the particles BUT as it uses the same data path you don't only change how they're rendered but you now change a setting of the simulation / physics. You can successfully render the baked sim with larger particles if you want BUT as soon as you have to rebake your whole simulation will totally change which is a true production nightmare. The render/display size could be made totally independent or a factor of the physical size but the display size should NEVER influence the physical size. This "feature" is currently making an otherwise super smooth project a lot more tedious to handle and I hope it can be "fixed" with some band-aid until the new particle system in 2.8+ comes. **Exact steps for others to reproduce the error** Read above.

Steffen Dünner commented

2017-12-08 14:57:58 +01:00

Added subscriber: @SteffenD

Philipp Oeser commented

2017-12-28 15:54:25 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2017-12-28 15:54:25 +01:00

Just to give this a second voice: I can confirm above analysis and would also consider this kindof weak...
However, splitting this into two separate props would have to be done carefully as it touches various places (cycles, smoke, ...) and I'm not sure how high this is on the list?
Until someone else votes this as 'not a bug' I'll change this to normal prio...

Just to give this a second voice: I can confirm above analysis and would also consider this kindof weak... However, splitting this into two separate props would have to be done carefully as it touches various places (cycles, smoke, ...) and I'm not sure how high this is on the list? Until someone else votes this as 'not a bug' I'll change this to normal prio...

blender-admin commented

2017-12-29 16:03:26 +01:00

This issue was referenced by a6c69ca57f

This issue was referenced by a6c69ca57f661a8538d70cde9471a2554cecc65b

Dalai Felinto commented

2017-12-29 16:21:51 +01:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2017-12-29 16:21:51 +01:00

ronan ducluzeau commented

2018-02-05 18:53:06 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2018-02-05 18:53:06 +01:00

I think that this should be re-opened.
Removing size in Physics panel does not solve anything.

User can still precise one size for simulation, modify it for rendering purpose (for example, to use metaballs).
When he will try to re-use same simulation settings to make a derivative one, value of Size used for initial simulation is lost.

I think that this should be re-opened. Removing size in Physics panel does not solve anything. User can still precise one size for simulation, modify it for rendering purpose (for example, to use metaballs). When he will try to re-use same simulation settings to make a derivative one, value of Size used for initial simulation is lost.

Steffen Dünner commented

2018-02-05 18:58:38 +01:00

After finishing the job that caused me to post this "bug report", I somehow lost sight of this ticket. But on second thought it might actually be worth to re-open it again for the exact reason that ronan mentioned.
Render size and simulation size should both be available but the render size should never affect the simulation. Quite the same as changing the instanced object or group doesn't affect the simulation. You should still be allowed to change render settings after caching a simulation.

After finishing the job that caused me to post this "bug report", I somehow lost sight of this ticket. But on second thought it might actually be worth to re-open it again for the exact reason that ronan mentioned. Render size and simulation size should both be available but the render size should never affect the simulation. Quite the same as changing the instanced object or group doesn't affect the simulation. You should still be allowed to change render settings after caching a simulation.

ronan ducluzeau commented

2018-02-05 19:39:40 +01:00

In #53513#483348, @SteffenD wrote:
Render size and simulation size should both be available but the render size should never affect the simulation.

My point is just that fix did not fix the issue. There is still one size in the UI affecting both render and simulation.

If you consider that you can always scale a metaball in edit mode or an object or a group that will be used by duplis ; in that case, it is render size that should be removed and physical size should be kept and greyed out after baking particles.

> In #53513#483348, @SteffenD wrote: > Render size and simulation size should both be available but the render size should never affect the simulation. My point is just that fix did not fix the issue. There is still one size in the UI affecting both render and simulation. If you consider that you can always scale a metaball in edit mode or an object or a group that will be used by duplis ; in that case, it is render size that should be removed and physical size should be kept and greyed out after baking particles.

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 Size Weirdness #53513