Glad to provide feedback, a delight to use. Great tool.
I’ll let you marinate on the numeric text input problem. In general, you probably want to start by avoid modifying the input value while it’s focused. (If you’re using React, this means switching to an “uncontrolled” input paradigm). This will probably mean you will keep a separate (“last good”) value for each field to allow the user to faff around with possibly-invalid inputs until blur, when you can sync the field string to the internal value.
Regarding post graph, I was just unlucky.
On my first exploration I immediately ran into a bug that disables the whole post process until you reload. If you add two gaussian blurs in series, it triggers this condition. (Whether that’s a reasonable thing to do, is up for grabs… haha)
But now that I know to avoid this I see that the post graph is really wonderful. Already super useful and very promising.
A few things I miss (or wonder) in post graph:
- Can we access viewport width/height (especially useful for calculating aspect ratio, for adjusting noise UV to stay “square”)
- Is there a way to invoke ThreeJS’s tonemapping code?
- What about sRGB encode/decode? (Maybe should we just use exponent.)
- Screen UV → Texture → Output seems to disable output (goes black while connected).
- What is the difference between depth and depth texture? If “color” and “depth” are convenience samplers, why is there “normal texture” but no “normal”. It’s good to be “batteries included” (sensible defaults) but maybe you could make the advanced/optional outputs opt-in via a properties checkbox (like how the texture node exposes colorspace, etc).
- Is it possible to mix data from more than one render (e.g. via a rendertarget texture)?
- Wondering if you would implement a way to detect specific objects from the scene, either via a stencil read node, or a “cryptomatte” texture. Maybe there are other ways, too. This would allow implementing effects like “selected object” highlights and outlines, as well as object-specific post processing.
Type feedback (inference) would be very welcome. I don’t think it’s urgent or high priority, but it’s super useful “system feedback”. Would provide small, but constant “course-corrections”.
Debug view is a great feature, but doesn’t seem to be working consistently for me. With the Noise Gradient template, just pulling the color property into a vec4 and selecting that shows a bright pink sphere. I wondered if this was because the render is HDR, but multiplying but 0.1 has no effect. Any ideas?
Separately, while “select to inspect” is perfectly reasonable and useful, I’d personally love to be able to see a preview of the “texture value” at each node. This is relatively uncommon in node editors, but Godot seems to have this feature (see screenshot below). This might be a little tricky to implement, but seems plausible: either with multiple render outputs, or by compiling an “early exit” shader for each node preview.
Re: multi-select, glad this works, thanks!
I think cmd-click is unlikely to be discovered by most users (even though it is conventional for toggling selection of single items). In this context, shift click is probably the expected action for multi-select.
I noticed box select is bound to shift-drag, which is also a delightful discovery! But similarly, I think this feature will probably not be easily discovered with this binding.
So, I guess this is why you chose to use cmd-click for multi-select picking. Perhaps both actions can use shift? (Seems like it should be able to work.)
I think you probably just need time and space to continue to work your magic, so I’ll back off now. Sing out when you next want me to take it for a spin. Have a think about where you’d like to collaborate in the future.