Expose preview enums as configurable properties. #84
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Exposes realtime lightfield preview options as overlappable and configurable properties for improved realtime rendering performance options.
I keep my LKG Portrait angled on my desk, so when working I am looking at the right-most perspectives. This made the default restricted viewcone preview (which was centred) inconvenient for my setup, so I figured I'd expose the settings to customize it in the UI! This lets users configure the parameters for skipped-view and restricted viewcone previews, and select multiple different lightfield preview optimisations at once.
Exploring various combinations of these properties, it would appear that the low-res preview is almost required for snappy realtime performance on my system, and then adding either or both skipped-view or restricted viewcone rendering gives greater overhead. It's worth mentioning that I was unable to get the starting cube to render performantly (1 FPS at best) using only skipped-view and/or restricted viewcone rendering (GTX 970, Ryzen 5 3600, LKG Portrait) - even with the viewcone coverage set to 0%, which yielded blank for all perspectives and good recorded debug timings (5ms), but still poor responsiveness and multiple-second delays. This behaviour is at parity with the previous implementation. Adding low-res rendering to the mix made it instantly responsive (>30 FPS). So food for thought that even with fully blanked frames there's something outside of graphics rendering that's bogging down the pipeline, if this isn't known already.
As this is my first pull request, please let me know if you need any additional information :)