Following up from the previous blog post about the Java engine or “Zengine” that I'm developing with my friend. I was contemplating how to go about implementing an editor build or rather multiple build types for editing and for a game. After doing some brainstorming I've figured out how to implement such a method and furthermore figured out how to go about refining the engine renderer as implmenting an editor driven development side for the engine means removing any implementation details within the engine and instead going solely through the editor.
What I had in the first place was a system set whereby I had implementation details in different render entity types about the components held, and the structure for initialisation, rendering e.t.c. Although this may have been good if the engine were directly implementing the game/engine features, it's not usable if an editor is involved. Firstly though I thought about how to include an editor build which was extremely easy, it was just to create a separate main funciton in a different file which works in a different directory including everything the editor requires. So in my situation I have a Zengine.java class with a main function which I'm going to strip away. I've now got a Z_Editor.java class which will import the zengine.core package which just has all of the engine code required. This file is currently in the context of the zengine.core package, but instead I'll be moving it to a zeditor.core package directory. This might seem like a small change but it's actually very powerful. This way all of the editor related code can separate within a different directory containing all the editor related code relating to IMGUI which will no doubt have GUI for creation of entities, GUI for adding components to entities, saving the current editor state, and somehow in the future saving state created for the game.
So that's been the first main change, an it just requires changes to the rendering process. Currently I've got implementation details for the engine for each render entity type and the components which isn't good for an editor, the editor needs to be able to create render entities, and add components. The reason there were implementation details in the first place in the engine was due to having the circumstance of a render component relying on another render component rendering first or a render entity relying on a component which relies on another render entity. Such a situation would present itself say if for example we first need to render to a texture and then use this texture as a texture for a render component. This was quite a difficult issue to get around since the engines abstraction to an editor using the engine wouldn't work with implementation details. Basically you'd need to leave the engine as simple as having a render/update call which would loop through the components and call the respective render/update calls, but with that in mind, how would you ensure that render components and entities are all rendered in order? That's where a “Render-Scene Graph” comes in handy.
The idea of the Render-Scene Graph or 'RSG' to make it simpler is to render components/entities in order of hierarchy. The idea is that when entities/components are created/added to the list of components/entities within the entity/component, the RSG gets updated accordingly, and then when rendering comes around, we start from the bottom and render until we reach the top of the RSG. Thinking of a scene-graph, each node represents an object, in this case, each node is either an entity or component. We render from the bottom to the top so each bottom child node in a given row of nodes, and then move up and render all subsequent nodes. This then tackles that issue of not having a rendering order when one component requires another to be rendered, the required component will always render first.
Anyways, those are two proposed ideas which will be implemented in the Zengine. I've ALREADY thought about batched rendering as it's imperative the entities/components are batched together to save on draw calls, this also coupled with a proper scene graph in the future for objects in the gameworld will potentially improve performance and FPS ten-fold. The next stages with the Zengine then are to finsh refactoring the Zengine.core package so that it works given an editor context, so create the RSG, think about updating the given implementation for how UBO's work and in general patcing up. Then starting work on creating the Z_Editor package which will have a solution for creation using IMGUI of the engine related things.
If you made it this far, thanks! That means a lot ? I'll probably be providing screenshots in the future but for the moment the idea is to get something actually running and looking good. There's still quite a bit involved to do correctly and I want to make sure that before I showcase anything off, the code is usable, not just functioning.
