Nebula3 rendering layer: Graphics

The graphics subsystem is the highest level of the graphics subsystem in the rendering layer. it is basically the next version of the Mangalore graphics subsystem, but it is now integrated into nebula and is more closely integrated with lower-layer rendering code. the most basic idea is to implement a completely self-governing image "world", which contains models, lights, and camera entities, and only needs to communicate with the external world for the least. the main operation in the graphic world is to add and delete entities and update their locations.
Because Mangalore's graphic sub-system and nebula2 completely split from nebula3, many ideas can be implemented with less code and interaction.
The graphics subsystem will also be multithreading for asynchronous rendering, and it and all underlying rendering subsystems will survive in their own fat-thread. this should be something more advanced in the nebula3 hierarchy, but I chose this location because it is part of the Code with the least communication between the game and rendering. it is precisely because the graphic code has more "autonomy" that the game-related code can run with a completely different frame rate from the graphics, but this must be proved by practice. but I will definitely try it, because there is no need to make the game logic code run at more than 10 frames (combat fans may disagree ).
The most important public classes in the graphics subsystem are:

• Modelentity
• Cameraentity
• Lightentity
• Stage
• View

A modelenity represents a visible graphical object, which includes location, volume, and embedded model resources. A model resource is a complete 3D model, including ry, material, animation, hierarchical transformation, etc... (As mentioned later ).
A cameraentity describes a visual object in the graphic world and provides a view and Project Matrix for rendering.
A lightentity describes a dynamic light source. nebula3's light source attributes have not yet been finalized, but my goal is a relatively flexible approximation (the last light source will not exceed several shader parameters ).
Stage and view are newly added to the nebula3 graphics subsystem. in Mangalore, graphical entities exist in a single graphic level class and can only have one level and one camera at any time. this is good for rendering the world to the frame buffer. however, many game programs require more complex rendering, such as rendering a 3D object using separate lights in the GUI, Which is isolated from other graphics worlds. there is also a reflection or something like a monitor that requires an additional view, and so on. in Mangalore, this problem is solved through the offscreenrenderer class. Although it is easy to use, it has some restrictions and requires more post-event thinking.
Nebula3 provides a more concise solution based on state and view. A stage is a container of graphical entities, indicating a world of graphics. multiple stages may exist at the same time, but they are isolated from each other. each object is connected to only one stage at a time (although cloning an existing object is a simple task ). in addition to simply organizing entities together, stage mainly aims to accelerate visibility queries based on their relationships. applications can derive stage subclasses to implement completely different visibility query schemes.
A view object uses a cameraenity to render the stage to a rendertarget. any stage can be connected to any number of view objects. view objects may be mutually dependent (or they may be connected to views of different stages ), therefore, updating a view will force the rendertarget of the other view to be updated first (this is very convenient when one view rendering needs to use the rendertarget of another view as the texture ). the view object fully implements its own rendering loop. an application can easily implement its own Rendering Strategy in the Child class of view (for example, one pass for each light, one pass for each light, and multiple light for rendering to cubemap ).
All in all, a stage completely controls the visibility Query Process, while a view completely controls the rendering process.
One of the major tasks of the graphic subsystem is to determine which entities need to be rendered based on the results of the visibility query. A visibility query establishes a two-way link between entities. It has two forms: Camera Link and light link. the camera link connects a camera with a model in its visual body. because the link is bidirectional, the camera knows all the models within the range of its visual body, and the model knows all the cameras that can see it. A light link establishes a similar relationship between a light and a model. A light has a link to all models affected by it, and a model knows all the lights that affect it.
The most important class for accelerated visibility query is the cell class. A cell is a visibility container for graphical entities and subcells. It must follow two simple rules:

1. If a cell is completely visible, all its graphical entities and child cells must be visible.
2. If a cell is completely invisible, all its graphical entities and child cells must be invisible.

Cells are affiliated with stages and form a tree-like hierarchy with a root cell. the standard cell supports simple spatial partitioning schemes, such as the quad-tree and Ock-tree. However, if other visibility schemes, such as the portal, need to derive the cell subclass for implementation. the unique functional limitations of sub-classes are the two rules marked above.
When a graph is connected to a stage, it is inserted into the cell that is "accepted" (usually only accommodating) at the lowest level. when you update the transform information of a graphic object or change the surround body, it changes the position in the cell hierarchy as needed.
Stage resides in the stagebuilder class, and the application should derive stagebuilder to create an initial stage state (by adding cells and entities ). nebula3 provides some standard stagebuilder collections, which should meet the needs of most applications.
This is just a rough overview of the graphic subsystem, because there is only one basic implementation, and many details may be changed later.