Haven’t really been programming that much because I’m focusing on art again but since the last time I posted I’ve been working on animations, and it’s working right now. But it’s a tad uglier than I expected so I’ll have to introduce a new way of interpolating frames or use more keyframes in my animations.
It’s not horrible-gouge-out-my-eyeballs ugly animation but it’s just jerky enough to be a bit jarring to look at.
It’s especially noticeable during slowed down animations where the keyframes interpolate really slowly. It sort of ends up with like a pop-and-lock type movement.
Aside from this I’ve got some other features in mind to integrate. One of them being animation blending, where I just layer a bunch of animations onto a model with variable weight so you can blend a bunch of animations that affect the model with their own amount. This is especially useful in situations where you want to add a little more complexity to an animation depending on a situation the model is in, such as hunching a model over depending on how it’s hurt, but allow it to continue animating like it usually does. It’s also useful when blending from one animation to another, like walk -> run -> jump and so on.
After all that it’s time to optimize the crap out of it, or at least optimize it as well as I know how, which doesn’t say that much IMHO, but anyway.
I’m trying to make it as fast and resource efficient as possible. That’s the goal.
… I’m also performing all this on the CPU… And in immediate mode OpenGL- *ducks for cover*.
*Phew* That was close. But here me out, this is just temporary.
I’m working right now on my model pipeline and moving it over to use VBOs. I’ve been having some problems with the current state of my model format that didn’t get along with VBOs that easily, so I’ll have to rewrite the exporter and parser to make that easier.
And at that point I will also have integrated a substantial shader pipeline so performing skinning on the GPU should work fine.
Now. In different news I’m rewriting part of the scene manager for the engine, for like the third time. And I’m doing this to support better error checking and features like that. I really don’t like having problems and not understanding it, especially when it’s something I’ve created myself. So that’s why I’m prioritizing engine -> user communication. Not only for me, but also if I ever decide to release the engine (which is very unlikely at this point.).
I’m also working on abstracting and wrapping the hardware API even more and trying to generalize it as much as possible and make it as “slim” as possible. I want my engine to run on a lot of different computers with as little problems as possible.
Another thing I’m working on (It’s really piling up now, isn’t it?) is integrating a better filesystem for handling all sorts of external scripting and stuff for materials, sounds and all that. But I’m at the same time aiming at keeping it to a minimum, because using an engine with a big file overhead, the need to have hundreds of files just to run the damn thing, is not in any way desirable.
Most external scripts and definitions will be in XML… Because it’s easy to read and write.
So lastly the thing I want to delve deeper into is, as I’ve mentioned before, physics with the Bullet physics library.
I’m excited to see how well it’ll work, and I’m excited to implement cool stuff like slow-motion and different sound effects that play when materials rub together or impact each other.
For the record: I’ve been interested in implementing the physics sound stuff ever since I saw it in the Frictional Games’ Penumbra tech demo 2006. 🙂
And I have some good ideas I can implement with that to create some immerse physics.
So I’ll just go back now and make something.