#ogitor

[fdastero-blog]

Ogitor TerrainEditor

Some quick notes:

While I have plans for my project and ogitor, for now I just want to start editing the terrain. So in order to do this I will simply reuse ogitorterraintoolwidget class. I will implement the ITerrainEditor interface and hook that up to my world controller, which has all the methods for editing already (like interesection). I need to make some adjustments to brush size. 

What I want in the future is ability to do more than what is available by default with the terrain tool widget, which means I'm going to have to implement a custom widget. 

[fdastero-blog]

More Ogitor integration

This past week I've experimented with Ogitor. Since then I've settled on a design for engine integration which uses context menu on the initial root engine plugin to create sub-components. Let me explain a little:

When you register a plugin in Ogitor your registered component shows up on the object list to the right (along with the object list here you also have mesh list, material list, etc). You drag-and-drop your plugin object from this list onto the main render window in order to instantiate an object. Code wise, an object factory's CreateObject method gets invoked instantiating the actual object. 

Initially my idea was to have a main engine object which the user drag-and-drop to the render window. Then during the creation of this object, sub-component editors gets registered.  That didn't work because although you can register factories in the OnCreate method of the main "Engine" component, the object list view does not get refreshed so you can't drag-and-drop sub-components after creating the main "engine" component.

To get around this I tried registering sub-components in the plugin. This worked at first, but this doesn't map well into how my engine works. My engine has different phases: bootstrap->onInit->onLoad->onUpdate->onDestroy. In my case the bootstrapping phase occurs in the startDllPlugin function. Cut the story short a bit I didn't go with this either because it doesn't follow Ogitor's usage pattern.

So I dug around the code some more because basically I want to duplicate the behavior of the TerrainGroupEditor. With this editor you first drag-and-drop it into the render view to create a root node to the left. Then you can use a context menu to create child nodes of this root, corresponding to pages in the TerrainGroup. When one clicks on an item on the context menu, one calls OgitorsRoot to invoke the Factory of the object in question.

So here is the final mapping of my engine into Ogitors:

bootstrap -> onStartDll()

onInit -> EngineEditorFactory::onCreate()

--This creates and register all the sub-component factories and call onInit() the PRJZ objects they manage. 

onLoad -> *EditorFactory::onCreate()

--When an editor factory's onCreate method is called, all other sub-component has undergone the onInit phase. So this corresponds to onLoad phase in PRJZ.

onUpdate -> EngineEditor::LFCPUMP()

The EngineEditor corresponds to PRJZ engine's EngineController.

[fdastero-blog]

Ogitor and the engine

Some short notes on integration of the engine into Ogitor.

-Engine Controller Plugin:

Yesterday I integrated Graphics Controller into Ogitor (Graphics Controller handles all the render to texture / deferred shading stuff) as an Editor in Ogitor. I will make a slight modification to this and instead first register a base plugin, this plugin is functionally equivalent to Engine Controller in my game engine. This plugin will bootstrap every other component of the engine. This design requires minimal refactor to my existing code base (no refactoring actually; although I am code reviewing and will refactor some code). 

The use case for this plugin is the user would only see the main object on the object list to the right when they load up a scene. When they drag-and-drop the main object onto the scene, that's when the main object registers the sub-component of the engine. That's when the other components of my game engine will show up on the object list. From there the user can drag-and-drop individual components onto the scene and they will all work correctly. 

In the future I will refactor some code so I can release the individual components to my engine as plugins under MIT license. 

....

Deferred Shading in Ogitor:

In my engine, my deferred shading is setup in such a way that it requires entities to have an visibility mask. In Ogitor, every mesh that the user drag-and-drop  onto the scene has a properties page associated with it. So, the first order of business if to just modify this properties page (I already found it) to include an option to change the visibility mask. Or, a better option is to figure out how to inject such a property. Ideally, this injection would take place when the user drag-and-drop the Main plugin onto the scene, because that's when the Main plugin initializes and thus will set the visibility mask on the scene manager.