You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently setting up a lot of SpatialMaterials and Spatial scenes using GridMap and MultiMesh, by hand for a new 3D game project's resources.
Describe the problem or limitation you are having in your project
Many editor float controls don't have a default float step, and so fall back to the editor setting's interface/inspector/default_float_step. Though this is configurable, it's painful to have to open the editor settings repeatedly to do so, to get different "scales" of control for values that use different magnitudes of float values.
Values are also usually rounded to this float step value, even if the parameter can take many decimal places, if I set default float step to 0.01 then entering 0.005 with the keyboard will be rounded to 0.01.
Also, being able to run the game and, for example, adjust shader params and material values by clicking and dragging on the slider, or by clicking and dragging on the LineEdit for the value lets you adjust the number by the default_float_scale. Different params and values use different numbers of decimal places, meaning "fine control" on one value becomes "unwieldy super fast" on another.
2021-07-15.23-32-53.mp4
Quick but not fully demonstrative example, (I am holding shift in these examples while dragging the mouse to get the more fine-grained control), the editor has a default float step of 0.001.
First value moves by 0.001, and the output of that (the UV offset) moves by a reasonable, controllable amount with the mouse.
The second value (metallic) has a default float step set on the control itself with 2 decimal places, and I can move this at an appropriate speed visually by moving at that step (0.01).
The third value (Lightmap Size Hint) moves at 0.001, and while this isn't the best example because there's not much visible output from adjusting this, it's a demonstration of how the usability is reduced by these varying steps not always being suited to the control,
If that were fixed, and all default editor controls had an appropriate float step set, (or made redundant with Godot 4 changes?), it still would be a boost to be able to scroll quickly through a large number this way, but retain much more fine grained control over a more specific range of values. For example, I might want to click and drag to see which numbers out of values 10.1-20.9 look good, and then when I find a value that works, fine tune that value at a lot higher resolution, say, 19.001-19.999 maybe even down to that 0.001 step. Currently I would have to open the editor settings, find the default_float_step value, change it there, and back out to the 3d editor for every calibration like this.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a set of modifier keys or keyboard shortcuts to adjust the default float step between a predefined set of step value levels, or programmatically shift the default step in orders of magnitude.
This retains the excellent visual feedback of running and adjusting editor values like this, doesn't break the workflow by having to open the editor settings between adjustments.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
These modifiers would override the specific float step, if set, in the editor settings, and on individual editor controls
This might not be desired in some editor controls where the resolution really is e.g. 2 decimal places for a technical reason limitation, or optimisation, and so maybe some controls would have to use a flag to say "don't override this step value".
I have a couple of implementation ideas around keyboard shortcuts or modifiers:
holding "shift" could adjust the value by 0.001, holding "ctrl" by 0.1, holding "alt" by 1, and by default, 0.01
these 3 levels could be defined in the editor settings for each modifier key
or, pressing and releasing "ctrl" while adjusting a control by dragging could move a "step" down in resolution by changing the default_float_stepof 0.001 to 0.01, and pressing/releasing "alt" could go up in resolution from 0.001 to 0.0001. Pressing these keys repeatedly would move into further levels of resolution.
this adjusted value could either overwrite the editor settings default, or maintain its own overriding resolution in its own state, and a keyboard shortcut to reset the step value back to the default could be added.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I haven't been successful in creating an editor plugin that could do this, I suppose it might be possible by some wizardry that I don't yet understand, but to me it seems to require alterations to the editor's C++ code to be able to add the interactivity (though I suppose there may be other fixes and workarounds I haven't considered).
Is there a reason why this should be core and not an add-on in the asset library?
I've repeatedly found myself wanting this feature during long editing sessions. I'm unsure if it would be possible to implement without direct engine modification, my instinct is no, but I would love to be corrected. For me it's a definite quality of life feature for the editor itself. I do a lot of things in a code-first way with Godot, meaning the values are dynamic or not easily adjustable, but adjusting certain things like materials and spatials in the Editor like this is still often very useful.
The text was updated successfully, but these errors were encountered:
@Calinou that looks similar, I haven't tried it yet, but glancing at the code that seems to be changing the value via the keyboard, which is useful, but not quite what I'm looking for - I want to use the mouse to click+drag and adjust the value that way, but have the keyboard be able to adjust how much the mouse is stepping by.
I'd like to see if I can build off that PR to the kind of thing I had imagined, though I've only made quite minor changes to the engine code before so it might be out of my league.
Describe the project you are working on
Godot 3.3.2, Linux
I'm currently setting up a lot of SpatialMaterials and Spatial scenes using GridMap and MultiMesh, by hand for a new 3D game project's resources.
Describe the problem or limitation you are having in your project
Many editor float controls don't have a default float step, and so fall back to the editor setting's
interface/inspector/default_float_step
. Though this is configurable, it's painful to have to open the editor settings repeatedly to do so, to get different "scales" of control for values that use different magnitudes of float values.Values are also usually rounded to this float step value, even if the parameter can take many decimal places, if I set default float step to
0.01
then entering0.005
with the keyboard will be rounded to0.01
.Also, being able to run the game and, for example, adjust shader params and material values by clicking and dragging on the slider, or by clicking and dragging on the LineEdit for the value lets you adjust the number by the
default_float_scale
. Different params and values use different numbers of decimal places, meaning "fine control" on one value becomes "unwieldy super fast" on another.2021-07-15.23-32-53.mp4
Quick but not fully demonstrative example, (I am holding shift in these examples while dragging the mouse to get the more fine-grained control), the editor has a default float step of 0.001.
metallic
) has a default float step set on the control itself with 2 decimal places, and I can move this at an appropriate speed visually by moving at that step (0.01).If that were fixed, and all default editor controls had an appropriate float step set, (or made redundant with Godot 4 changes?), it still would be a boost to be able to scroll quickly through a large number this way, but retain much more fine grained control over a more specific range of values. For example, I might want to click and drag to see which numbers out of values 10.1-20.9 look good, and then when I find a value that works, fine tune that value at a lot higher resolution, say, 19.001-19.999 maybe even down to that 0.001 step. Currently I would have to open the editor settings, find the
default_float_step
value, change it there, and back out to the 3d editor for every calibration like this.Describe the feature / enhancement and how it helps to overcome the problem or limitation
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
These modifiers would override the specific float step, if set, in the editor settings, and on individual editor controls
This might not be desired in some editor controls where the resolution really is e.g. 2 decimal places for a technical reason limitation, or optimisation, and so maybe some controls would have to use a flag to say "don't override this step value".
I have a couple of implementation ideas around keyboard shortcuts or modifiers:
default_float_step
of 0.001 to 0.01, and pressing/releasing "alt" could go up in resolution from 0.001 to 0.0001. Pressing these keys repeatedly would move into further levels of resolution.If this enhancement will not be used often, can it be worked around with a few lines of script?
I haven't been successful in creating an editor plugin that could do this, I suppose it might be possible by some wizardry that I don't yet understand, but to me it seems to require alterations to the editor's C++ code to be able to add the interactivity (though I suppose there may be other fixes and workarounds I haven't considered).
Is there a reason why this should be core and not an add-on in the asset library?
I've repeatedly found myself wanting this feature during long editing sessions. I'm unsure if it would be possible to implement without direct engine modification, my instinct is no, but I would love to be corrected. For me it's a definite quality of life feature for the editor itself. I do a lot of things in a code-first way with Godot, meaning the values are dynamic or not easily adjustable, but adjusting certain things like materials and spatials in the Editor like this is still often very useful.
The text was updated successfully, but these errors were encountered: