Moving Along

I’m slowly but surely making progress. I’ve since added an UpdateManager, which essentially manages the updating of other manager. Some engines call what I refer to as managers as systems. I have an IUpdateQuery interface that a manager can inherit from. When all the managers have loaded, the UpdateManager goes through each manager and queries for that interface, then adds their update entry to a list in the order specified in a JSON file that is passed in. And by list I mean a two-dimensional array. Updates are carried out a row at a time, top to bottom. Entries in the same row are considered “safe to do at the same time”. This means that each row is multi-threaded.

I’m abusing tasks/jobs very heavily in my engine. I figure, I’m trying to multi-thread as much as possible and the job system is a great way to manage all that. Also allows me to keep track of usage and other statistics if I so choose. Except for a few cases during initialization/startup, it’s pretty safe to assume that almost any segment of code could be run on any thread.

I’m currently working creating a graphics engine for Shibboleth, using Gleam as my building blocks. Supporting multiple graphics devices and outputs has proven to be a pretty difficult challenge. I’ve almost completed the camera management. Some challenges ahead are managing spatial data structures for object culling and scene management from a hierarchical transform standpoint. I’ve currently stubbed out a SpatialManager and am working on a smart and effective way to keep track and manage object hierarchies. I’m thinking maybe just having a SceneManager that contains a scene graph. And by graph I mean tree. I’m not exactly sure I’ve ever seen a scene graph actually carry graph like properties. They usually end up looking like trees. So, I personally think scene tree would be a more accurate name for that data structure. Anyhow, I’m thinking the SceneManager will be used for things like skeletons and meshes and handling model space transforms. The hierarchy defines an object. If you want two separate objects to move relative to each other, the physics engine should take care of that. In Havok this would be the equivalent of having rigid bodies share their motion. I’m unsure of what PhysX or Bullet calls it, but it’s probably something along those lines as well. For non-physics objects, it should be relatively simple to watch for changes to an object. I have an object’s transform wrapped inside a Watcher class, that will call a bunch of registered callbacks when it’s value is changed. This way, non-physics objects that want to move with another object don’t have to query every frame for whether an object has moved.

Whew, that was a good brain dump. Now I have a semi-thought out plan in writing! Hopefully next time I will have part of this implemented.

More Reading
Newer// Graffix!