Custom objects, step #2: custom commands #293
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nd buffer and assignment logic Next up, prepare details from graphics.defineEffect()
…from Program Slight redesign of TimeTransform with caching (to synchronize multiple invocations with a frame) and slightly less heavyweight call site
Err, was calling Modulo for sine method, heh That said, time transform seems to work in basic test
Fixed error detection for positive number time transform inputs Relaxed amplitude positivity requirement
Maintenance Revert Test
My mistake adding back changes made
Do-after-batch operation Some things to make that last one work properly (maintaining current geometry, etc.) Pulled some GL renderer bits out into subroutines to better accommodate commands (did same for Vulkan, so probably will want to generalize later) Apple and Windows simulator lists
|
In working on the PR 5 stuff (WIP here), I realized the "Do" approach, and the discontinuities it introduced into the renderer batch, just didn't cut it. You can now reserve a blob of dirtyable state that is examined, and reacted to, in The clear handler was also done away with, albeit in a different way: basically, the "important" cases were added to I figure this PR won't suddenly be pulled, so just pushed the updated plugins that rely on some of that PR 5 machinery. |
Shchvova
approved these changes
Jan 24, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is PR 2 as first described here.
There is slight overlap with PR 1 with the
Rtt_ApplePlatform.mmandMain.cppfiles, since more library functions have been added. The remaining files are all distinct from PR 1; no new ones this time.That said, this can't just be built on its own, since it depends on the public types and object box list stuff from PR 1. It's just an attempt to keep the overall process digestible. 😄
The details:
Solar's display hierarchy is not responsible for the actual rendering, but instead structures display objects into consecutive geometry batches of related state, then issues a series of commands, including
Draws. The "command buffer" is where rendering finally happens.To do custom, display hierarchy-based rendering, we need to issue such commands. The custom objects from PR 1 ensure that we are ready and waiting at the appropriate moment, while the new features here give us the command capability.
Again, the comments should give a reasonable approximation of the eventual docs.
I tested with this plugin. Using the machinery from PR 1, we create a color mask object and put it in the group before any children we want to affect. The object's
Draw()method issues a custom Solar command that callsglColorMask()at the appropriate time.A special "Do" routine is used to perform the aforesaid logic. This ensures that Solar first commits any pending non-masked display objects.
Since it's in a "scope group" (also used in the PR 1 plugin), the mask object will receive a "didDraw" message when the last member of the group is drawn, i.e. when the "scope" ends. This will rewind to the mask state to what it was before. (If I wrote this properly you can stack masks + scope groups, although this might not be a very important use case. 😄)
When a mask command is issued, an "end of frame" handler is temporarily installed. This is a failsafe in case some mask object wasn't in a scope group: we explicitly restore a non-masked state so the next frame begins as expected.
Although not used in this plugin, similar support is available for "clear" handlers, for resources—stencil or depth buffers, say—that should be wiped before any rendering.