Application & Graphics Discussion

[AlexvZyl]

Currently the Graphics engine works by having a different engine and instantiation for each OpenGL scene, essentially combining a renderer and scene into one entity. We need to discuss if this is the best way to do it. I think how The Cherno does it is by having a renderer and passing it a scene that it wants to render to.

In addition to this, the GUIHandler and GraphicsHandler are separate entities that are rendered separately. I do not think this is the best approach, these two should probably be combined in some way.

[AlexvZyl]

If we use a system where the Renderer is separate from the Scene we will only have to compile the shaders once, instead of compiling it for each instance.

[AlexvZyl]

This issue will also help resolve #92.

[Cullen-Enerdyne]

This definitely seems to be the way to go. How much effort will these changes be?

[AlexvZyl]

Definitely something for 2022, but I do not think it will take too long.

[AlexvZyl]

I think it should be approached someting like this:

• Have one Renderer.
• The renderer owns all of the Shaders so they only have to be compiled once.
• We should have different types of Scenes.
• The Scenes own all of the VAO's and the FBO.
• Scenes get passed to the Renderer if we want to render it.
• Rendering should be different based on the type of Scene.
• A Scene should also own a Camera that is set based on 2D or 3D.

We should think about whose responsibility it is to add Entities to the Scene. I am thinking we pass a Scene to the Renderer and have different functions that add Entities to the Scene?

@Cullen-Enerdyne

[Cullen-Enerdyne]

Where do the engines fit in this?

[Cullen-Enerdyne]

Surely the engine is adding the entities?

[AlexvZyl]

What do you mean with the engine? There is only Scene and Renderer in my suggestion.

[Cullen-Enerdyne]

So the design2D engine and base2D engine and core engine all become scenes?

[AlexvZyl]

So the design2D engine and base2D engine and core engine all become scenes?

Atm each engine is basically a scene and renderer combined.

[AlexvZyl]

Window activity should be stored on a stack, rather than having one pointer that points to the active window and NULL when none is active. So the most recently activated window should be on top, and the last one on the bottom.

[AlexvZyl]

I had an idea for how the renderer can work, what do you think? The Renderer will be a static class. @Cullen-Enerdyne

// Draw a polygon to the scene.
Renderer::bindScene(myScene);       // Allows the Renderer to have access to the VAO's.
Renderer::addPolygon2D(params);     // Draws a polygon to the bound scene.
Renderer::render(params);
// Not crucial, but can help with debugging.
Renderer::unbindScene();  

So when we use it inside an entity we can use it something like this:

Renderer::bindScene(m_scene);
// We want to manipulate the primitive, so we keep a pointer to it.
Polygon2D* m_polygon = Renderer::addPolygon2D(params); 

This way we dont have to pass the Scene and the VAO's every time we want to render something. Scenes own the VAO's and FBO, the Renderer owns the Shaders. VAO's own the Primitives and Scenes own the Entities. If we make the VAO's responsible for the Primitives we can implement #77.

In addition to this, a difference between a 2D and a 3D Scene will be how Camera is set up.

The application will have Windows that can be of different types (CircuitDesigner, ComponentDesigner) that determines the input handler.

[AlexvZyl]

In addition to the previous comment, I want to be more rigid with our use of shared_ptr and unique_ptr and raw pointers.

For example, Scenes will own VAO's and there is no reason for any other class to own it, so we should use unique_ptr. If something wants access to it it should be via a raw pointer.

[AlexvZyl]

For textures (#88) we can have something like:

Renderer::bindScene(myScene);
Texture* texture = Renderer::generateTexture(RESOURCE_ID);  // Keep a pointer so that we can manipulate it.
Polygon2DTextured* texturedPolygon = Renderer::addPolygon2DTextured(params, texture);

The resource ID will then be stored in the scene, so when you call Renderer::generateTexture(RESOURCE_ID) again and the texture already exists it will not generate a new texture but rather just return the already created one.

If we want to generate two textures from the same png:

Renderer::bindScene(myScene);
Texture* texture0 = Renderer::generateTexture(RESOURCE_ID);  
Texture* texture1 = Renderer::generateTexture(RESOURCE_ID, new=true);  
texture0->setMipmapLevel(-0.2f);
texture1->setMipmapLevel(-0.5f);
Polygon2DTextured* texturedPolygon0 = Renderer::addPolygon2DTextured(params, texture0);
Polygon2DTextured* texturedPolygon1 = Renderer::addPolygon2DTextured(params, texture1);

The resource ID is something that we will have to manually add to the resource handler, unless we allow Lumen to add textures via the GUI.

[AlexvZyl]

Along with this we have to think of a system to handle events.

[AlexvZyl]

The thing we need to keep in mind is that ImGui states only change once the renderer reaches that specific widget in the loop.

Atm that is a problem since the graphics renders and then the GUI renders. But in our redesign we should not separate is this much. The graphics rendering should be called at the end of the ImGui graphics window rendering so that all of the states can be updated. This will also prevent windows that are not seen from rendering, which will be great.