-
Notifications
You must be signed in to change notification settings - Fork 192
dev.IdeasForOperators
Operators that would be great to have:
[LightVisibilities]
- Returns a list of floats that indicate the visibility ratio of all lights defined for the current evaluation context. For this, it would have a reference to the last depth buffer, use the current ObjectToClipSpace matrix to convert the light position into screen position, and somehow fetch the relevant depth information for those positions.
The implementation could be done in several ways: A first naive approach could reuse the implementation of the [PickImageColor] operator. This should be good enough for testing but has some drawbacks:
- The complete image needs downloading (which might be slow).
- There might be a significant delay (several frames) between the information and the current render content.
For the current use case, this should be okay, because the lense-flare intensity does not need perfect syncing and could even be smoothed to suggest an after-image effect.
Another possible implementation could be to convert PointLight positions into a set of GpuPoints and then use a compute shader implementation to generate a result buffer with some information like a signed float value for each light (indicating the difference of the light depth to the current z-buffer depth). This approach would be great because we could use the compute shader to sample a larger radius to avoid flickering or allow partial occlusion.
The result of both implementations should be a list of floats that can directly be connected to either DefineLensFlares or [DrawLensFlares].
When this operator is selected, the parameter window should present an interactive list view (similar to that of StructuredList) that allows the simple manipulation of a value list:
- add, insert, delete, rearrange. As far as I can see, the
List<float>
type is already correctly serialized inModel.TypeRegistration.cs
. This means that as soon as we have the UI, we can already use this feature in production. Some use case for which this feature would be great: A workaround for a simple sequencer animation. - A definition of the number of values of random seeds: There could be an operator GenerateLenseFlareAtlas that only has a float list of random seeds as a parameter. Depending on the number of floats it would define and render an image atlas. Dragging the float sliders would then allow us to quickly assemble a selection of random lens flare sprites.
Side note: An interesting UI gimmick could be to add the option to switch between different view modes: a list mode being the default, but also a swatches mode, that would look like a color swatch list and would provide a means to adjust the values but dragging or clicking (toggling between 0 and 1). This would almost work like a sequencer and be a very playful edit method.
Similar to the value list, this would provide a custom UI for defining and manipulating a list of colors. It would be a powerful alternative to using gradients because it would be more controlled.
Additional Ideas: may we could provide a list view that allows to additionally define labels for these colors. However, this would require some way of storing those labels.
Reference
Getting started
- Basic Concepts
- How Tooll Works
- Keyboard shortcuts
- Video tutorials
- Rendering Videos
- Exporting to Executable
- Creating new Operators
- Tooll for live performances
- Presets and Snapshots
- Optimizing Rendering Performance
- Using backups
- Realtime Rendering for Artists
Advanced features