… of some of the components within the engine that are working poorly/not at all at this point in time.
Scene Manager: Yeah, I’m going to rip out the old code and implement a new, much better system which actually allows for the basic things a scene manager is supposed to do. The old system was also very slow so I’m going to focus some on making it as fast as possible.
Frustum culling will have to be re-implemented too, it’s a tad bit round-about right now so I’m interested in making it more straightforward and “tight”.
I’m still on the fence about implementing some general purpose culling implementation. It may sound a tad bit crazy, but my engine isn’t inherently designed to take advantage of a schema like CSG or similar stuff older engines used.
The engines that support this by default have the strength of being able to freely enforce such culling techniques such as PVS or Portal rendering.
My engine doesn’t. Since my philosophy for making game worlds doesn’t necessarily follow the rules of these very strict concepts I’m going to have to figure out something else that limits the entire level from rendering at once, but still doesn’t choke the scene manager up for no reason.
A lot of times culling is counteractive and some games run faster by not culling at all. Of course this can’t be fully depended on since it depends on how the game’s levels end up looking.
My thinking is, there’s got to be some kind of rough solution that can be deployed easily within the level editor to maybe make entire sections of the level cull away based on player distance or something like that. It’s not automatic and definitely a bit of a hack, but if it’s able to do the job in these cases, I’m good.
My other thought was creating some type of intricate algorithm that runs through the entire level and generates these triggers for the level which allow different parts of the level to be rendered when the “player” enters a certain area in the level. This is kind of like PVS(I linked earlier). The difference here is it doesn’t check polygons, but entire clusters of objects or areas. It’s of course not fully planned out as you might gather from reading this explanation, so it’s just an idea.
At this point I’m not too concerned with having a solution that’s not entirely user-friendly, seeing as I’m the only user right now. 🙂
Renderer: Yes, there’s still a ton of work to be done before this is fully functional to the point where I can point at it and not feel apologetic.
The main focus I have right now is really to trim away everything redundant. This also means I’ll be removing the backscattering I posted about a few posts back. Yes, yes- turns out I don’t have that much use for it after all. For the few things that need a faked translucency, there are other options that don’t hog up precious space in the GBuffer.
* CSM needs some work. I’m actually pretty happy with how well the CSM is playing with the rest of the engine right now, but it still needs some rubbing and polishing before I can relax.
* I no longer have any forward rendered lighting at all, all the lighting is deferred right now. Still missing out on deferred shadow maps for spotlights. I’m pretty sure there are cool things to be made with that support around so I’ve got no reason to trim that off.
* I need a new post processing pipeline which actually allows for some custom made post processing. The past one had set, optional effects running one after the other in a chain. It isn’t entirely bad, but sometimes you want to do something crazy, like set the screen on fire. The user should be able to.
* Particles. Still need to implement this in a way that isn’t terrible. Right now the depth sorting isn’t working too well so there are popping artifacts with multiple emitters. Really annoying.
It’s incredibly difficult to write a good general purpose particle system, it’s kinda crazy.
* ANIMATION! I need this so badly! I’ve just not had the energy to go back and re-implement the support yet. It’s an entire pipeline that needs double-checking, it takes time. I don’t have that much time right now.
What else… Those two are pretty much the largest problems right now. There are other things, such as the Resource Manager needing a lil’ kick in the rear to work better. But the rest is working OK at the moment.
I must add that through these years of coding engines and learning how engines work, the single biggest pain in the neck is model format support. If you back-track a loooong way in this blog, you’ll eventually start unearthing the many posts I’ve made in the past that are clad in pained wails about how it sucks to not have a model format that supports basic stuff and isn’t either closed source or in some weird format that everyone wants to make into their own.
Until the point where I said “TO HELL WITH IT, I’m making my own!” and I did.
But making your own format is actually a lot harder in the long run, because when other formats have bad support or poor documentation you can have the moral high ground of belittling work someone else did, but when your own format craps out- you just march your pretty little behind to the nearest mirror and let that guy have it!
Right now my own format only supports Blender as the 3d modeling suite, but not the latest Blender version because that broke a part of the code and I need more time to re-write that exporter… again.
But my model pipeline supports some common other formats as well, such as OBJ and very partial FBX support. I want to add some more like COLLADA and ASE because those are easy to parse. So once I get the motivation I need to make all this happen, it should be much better. Animation support will always be a very difficult subject matter though and unfortunately won’t see extensive support… Unless Autodesk finds it in their hearts to open source FBX… Please?
Edit: I should clarify that the other formats are actually converted from their source formats to my engine’s proprietary format. Just making that clear.
A lot of plans… A lot of plans… I just need that “spark” to do it all. *sigh*
Bye for now. 🙂