Change Particle Properties in the editor back to Base-Randomness from Min-Max

[peter-rocchio]

Describe the project you are working on

A 2D Metroidvania platformer

Describe the problem or limitation you are having in your project

In Godot 4.0 when adjusting particle properties you set a minimum and maximum value. While initially this may be more intuitive, it is much less compatible with the workflow of using particles. Generally speaking, while working with particles, you want to adjust the general size of a particle or how variable it is independently.

Under the current property behavior, if you want to adjust (for example) either base size, or how random the size is, you must always change 2 properties. Even when tweaking only randomness or general size you usually have to adjust 2 properties. About the only time setting the min and max directly reduces the number of steps is when you want to adjust both the median size, and the overall size and the median size you want happens to line up with the overall size you want. For me this is almost never, and I am always adjusting both fields while tweaking particles. This is a significant downgrade in usability

Describe the feature / enhancement and how it helps to overcome the problem or limitation

We can simply use the old method from 3.x of adjusting base size, and a variability range instead of having to specify a minimum and maximum value.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Essentially just revert the property behavior to how it was in 3.x, you adjust a particle's base size and its randomness independently as opposed to the min and max values.

From:

Back to:

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is basic editor behavior

Is there a reason why this should be core and not an add-on in the asset library?

It is basic editor behavior

[Calinou]

The new setup was highly welcomed by VFX artists, as it provides far more flexibility. I don't think we should go back to the old way of doing things, especially when it breaks compatibility.

Instead, we should add a way to link min/max properties together in the inspector. We could also provide an additional way to adjust min/max properties to be closer or further away from each other, so that you can effectively adjust randomness in one go.

Under the current property behavior, if you want to adjust (for example) either base size, or how random the size is, you must always change 2 properties.

Actually, you can get away with changing only one property. Which one you need to change depends on whether you're increasing or decreasing the value:

• If you increase the value, change Min and Max will automatically change if it's lower than Min.
• If you decrease the value, change Max and Min will automatically change if it's greater than Max.

[Mickeon]

I don't think it's an issue of the properties. Rather, it's whole way in which editing particles is set up. Changing so many unrelated properties in a tall, narrow panel is quite uncomfortable, and these min-max values add to the annoyances.

I feel like that is the main issue that absolutely needs to be tackled on, instead.

[peter-rocchio]

The new setup was highly welcomed by VFX artists, as it provides far more flexibility. I don't think we should go back to the old way of doing things, especially when it breaks compatibility.

I work with VFX artists, and in the past have helped to design a custom particle tool, I have a hard time thinking min/max is the preferred method in general. The way they (and I) work is to dial in the average of the property so that fits about what you want and then adjust the variability to add variety. I've not worked with a VFX artist that approached making particles differently.

I also don't understand how min/max is more flexible than base/variation. They are both ways of specifying a range and both methods can specify the same range. In the aforementioned particle tool the under-the-hood code actually used min/max variables, it was just the editor that used average + range.

In the linked example you would specify the base scale as 1.1 and the randomness by +/- 0.2. That would generate a range from 0.9 to 1.3.

Instead, we should add a way to link min/max properties together in the inspector. We could also provide an additional way to adjust min/max properties to be closer or further away from each other, so that you can effectively adjust randomness in one go.

That might help in the use case where you want no randomness, but it doesn't solve the main issue that when working with lots of something (this goes for things other than particles) that may or may not vary it is much more helpful to tweak the average value and the variability directly since those are the concepts you are actually playing with even when using min/max.

I encourage you to make some particles, or follow some particle tutorials to get a better feel of the flow of approaching what you are tweaking and when.

Under the current property behavior, if you want to adjust (for example) either base size, or how random the size is, you must always change 2 properties.

Actually, you can get away with changing only one property. Which one you need to change depends on whether you're increasing or decreasing the value:

• If you increase the value, change Min and Max will automatically change if it's lower than Min.
• If you decrease the value, change Max and Min will automatically change if it's greater than Max.

Only in the specific use case that the new max value is below the current min-value and you want to remove all the variability. If you want to keep the same range of values you will have to edit the numbers again anyway making the process 3 steps instead of just two.

Again, the 2 primary concepts your are tweaking when making particles are about how much of something and about how much that thing can vary. This makes the 2 sliders being base and variation much more natural and usable than min max.

[KoBeWi]

Note that reverting the behavior to exactly how it was in 3.x would be a downgrade. The old system wasn't a flat "value += range", it was a "value - value * some_coefficient". It was confusing to use, because it's hard to tell what the 0-1 "randomness value" actually means and it made some ranges difficult or impossible to express.

Oh, and the randomness wasn't even consistent - there were 3 different formulas for it. When I was making my project converter, I was only able to figure it out by checking the shader source code + lots of trial and error. This is how it translated to the new min/max range:
https://github.com/KoBeWi/Another-Godot-4-Converter/blob/1b55dd6661ad264bce122a12ef4a055fa1dd9e5d/conversion.rb#L246-L252
As you can see, max is always equal to the parameter value and min depends on the parameter type and some made up formula.

My downvote here comes mostly from how bad the old system was. Maaybe a real value +- range would be usable.

[QbieShay]

@Mickeon I've been annoyed as well at how clunky a long pillar of properties is. It should be better after godotengine/godot#79527 , but I still struggle when I need to edit both the material and the particle process at the same time. lots of scrolling.

I'm happy to gather ideas how to improve that. It seems to me that this proposal is not as much about the functionality itself, but rather how it scales in a production pipeline, with people that are proficient enough to just eyeball the result they need first try.

Reverting to previous behaviour in a stable version is not possible. But we can talk about how to expose a similar functionality. I've been hoping to improve in general the editing of particles. I feel like VFX need their own editor, and ways to show/hide things that are not relevant.

To me this issue is the convergence of

1. We don't have a custom editor
2. We have a lot of properties and they require reorganization (hopefully solved with #79527)
3. The value ranges, because they need to be compatible with 2D and 3D, are very hard to work with. I find the fast sliders (the one with the ball that appears to drag) entirely unusable for most particle properties in 3D

[Calinou]

The value ranges, because they need to be compatible with 2D and 3D, are very hard to work with. I find the fast sliders (the one with the ball that appears to drag) entirely unusable for most particle properties in 3D

Remember that the behavior differs if you drag the slider's grabber compared to dragging the number. Holding Shift slows down the value adjustment when dragging the number, but not when dragging the grabber (likewise for Ctrl snapping). Maybe we should change this so that modifiers are effective for both.

[QbieShay]

I normally just drag the number instead of the bar (which i imagine is the saeme as shift?) but the thing is that, the slider has inconsistent behaviour that way. It's the same widget but you need to use it in a different way, within the same object. I find myself often trying to drag the bar and be like "ah right" then drag the number.

[peter-rocchio]

Note that reverting the behavior to exactly how it was in 3.x would be a downgrade. The old system wasn't a flat "value += range", it was a "value - value * some_coefficient". It was confusing to use, because it's hard to tell what the 0-1 "randomness value" actually means and it made some ranges difficult or impossible to express.

Oh, and the randomness wasn't even consistent - there were 3 different formulas for it. When I was making my project converter, I was only able to figure it out by checking the shader source code + lots of trial and error. This is how it translated to the new min/max range: https://github.com/KoBeWi/Another-Godot-4-Converter/blob/1b55dd6661ad264bce122a12ef4a055fa1dd9e5d/conversion.rb#L246-L252 As you can see, max is always equal to the parameter value and min depends on the parameter type and some made up formula.

My downvote here comes mostly from how bad the old system was. Maaybe a real value +- range would be usable.

I admit I was a ignorant of how the under the hood values worked in the old system. I had assumed it was much more similar to how I described it (base value ± randomness) and explains why I couldn't dial in numbers exactly and had to just kind of play with them previously. I agree that going back to that system in totality would be a major downgrade.

My only real concern is the editor values and how they interact with a typical particle workflow. Like I said previously, any tool I've worked on in the past that used base + variation in the editor converted those values to min-max under the hood in order to roll on them anyway since that is how rand() functions work.

I am quite flexible as to how "randomness" is calculated ("variation" or "variance" may be a better word), whether it is base ± randomness, base ± ½*randomness, or some other formula. For me it is just important that the sliders align more directly with the actual design concepts I am working with. It is entirely possible that I am unusual in my approach, but I feel like this isn't the case.

Edited to add: The UI solution you've presented in the linked issue would solve my issue, and be a general improvement to the editor as a whole. Thank you