robertlong
commented
2 years ago Hierarchy Panel and Properties Panel Design:
Editor state is shared from GameWorker to MainThread in two SABs
- First is the same TripleBuffer as the render thread (hopefully at least, need to figure out sync mechanics since we swap buffers there, may need to be another triple buffer with just hierarchy data)
- This would contain: parent, firstChild, prevSibling, nextSibling and a new hierarchyChanged flag used in the UI to perform efficient updates to the tree view component
- Second is the active entity buffer
- This SAB is included in the selection changed postMessage any time the active entity changes
- That post message already contains the selected entity ids and their initial values. We'd remove the initial values though and replace with this SAB
- This SAB would contain:
- The values for every editor exposed component on the active entity
- Including a flag for any property that changed which forces the component to rerender. This flag is set by checking each property against the prev SAB value and the current value
The first SAB is used to render the hierarchy panel and the second is for the properties panel.
Strings and other non-serializable fields are sent via post message as property changed events.
Every game tick we iterate over all the editor exposed properties of the active component and check for changed properties and copy to the SAB. If the field is a complex value (string, etc) we check for equality and then send a property updated post message. Dirty flags are reset at the beginning of each tick. If the active entity changes we create a new SAB and post message to the main thread. Getters for component properties are defined in component schemas. Complex equality operations should be defined here as well.
For the hierarchy data we set that dirty flag inside our transform component methods on the game thread. All of this data is stored in a SAB and syncs like any other triple buffer. No post message required.
For node names we'll want to create a component for storing names of nodes that will also store a dirty flag. We'll post message any changes to names from the game thread to main thread.
The main thread hierarchy view iterates over all the hierarchy info every animation frame and mutates its representation of the scene graph. It can be efficient about this by only updating the parts that actually changed.
The main thread property panel uses the component schemas it gets from another post message based API and the active entity buffer to render the component properties. Because it reads from a SAB, the inputs will be super responsive for any component property changes. Even if we're in play mode and observing an entity while it's in motion or animating, etc.
Big design points here are:
- Less postMessage use == less GC pressure
- Animation frame synchronized SABs == highly responsive UI even when lots of things are changing
All mutations from the Editor UI are made via postMessage to the GameThread. Setters for these properties are defined in component schemas. Creating entities will use prefabs. Prefabs are just functions that create entities with pre-assigned components. We'll display a list of prefabs to create when clicking on create new entity. Creating a new entity is accomplished via a postMessage with the prefab id and any initial properties sent from the main thread to game thread.
hazre
The Manifold Editor is our game engine environment / asset editor built around the glTF standard. Both the interchange and authoring format will utilize glTF and should be capable of producing content for Third Room as well as exporting glTF content for use elsewhere.
The todo list below represents the tasks needed for a feature-complete 1.0 release. We plan on tackling this list in chunks, focusing on iteratively improving our demo environments.
canDropimplementation