This change refactors the widget system to better support user made building blocks:
Uses the interface in the gui system to dynamically paint the attributes of each block
Adds the @widget decorator, so widgets can get automatically created for wisp blocks
Removes quite a few redundant widgets, and makes the who hierarchy less brittle
colors.py module now supports an unused color generator
The previous situation required implementing a specialized imgui widget for every added grid / nef / bottom level renderer which was a hassle. In the new solution, the WispModule is put into use - components can expose public properties which the gui system will automatically paint (read only).
Implementing a widget is also easier now with the @widget decorator which says which wisp building block this widget describes. When wisp's gui system paints the scene graph and encounters some component, it will know which widget to load by using the widget registered with this decorator (defaults are in place).
Supporting "editable" components is beyond the scope of this MR and still requires a specialized widget. That's not too bad though, as pretty much the only components that require "special" implementations are the RayTracedRenderer renderers (NeuralRadianceFieldPackedRenderer,NeuralSDFPackedRenderer`) and for a good reason: they maintain a copy of the tracer within, and the gui allows editing the properties of these tracers.
I've included a default RayTracedRenderer solution as well, so new bottom level renderers would still have a read-only support if they don't specialize anything (for example the SPCRenderer).
This change refactors the widget system to better support user made building blocks:
@widgetdecorator, so widgets can get automatically created for wisp blockscolors.pymodule now supports an unused color generatorThe previous situation required implementing a specialized imgui widget for every added grid / nef / bottom level renderer which was a hassle. In the new solution, the
WispModuleis put into use - components can expose public properties which the gui system will automatically paint (read only).Implementing a widget is also easier now with the
@widgetdecorator which says which wisp building block this widget describes. When wisp's gui system paints the scene graph and encounters some component, it will know which widget to load by using the widget registered with this decorator (defaults are in place).Supporting "editable" components is beyond the scope of this MR and still requires a specialized widget. That's not too bad though, as pretty much the only components that require "special" implementations are the
RayTracedRendererrenderers (NeuralRadianceFieldPackedRenderer,NeuralSDFPackedRenderer`) and for a good reason: they maintain a copy of the tracer within, and the gui allows editing the properties of these tracers.I've included a default
RayTracedRenderersolution as well, so new bottom level renderers would still have a read-only support if they don't specialize anything (for example theSPCRenderer).