DuskEngine Devlog 1 - Mostly Physics Edition
In the previous episode I said that I'd be working on navmeshes, but something must have happened because I switched to physics for a while.
In any case, here are all the new and noteworthy things.
Primitive Colliders
Jolt has lots of features but the engine needs to have its own functionality that wraps it, which takes some time to write.
To save on implementation time, up until now, physics objects (which is what DuskEngine calls rigidbodies) were limited to a single collider. Said collider had to be a component on the same entity as the physics object component, and it had to be a mesh collider, either convex or regular.
As levels are starting to get larger and filled with more complex geometry such as buildings, I've added support for primitive colliders such as boxes and spheres, and now I also aggregate all colliders in the hierarchy of an object. This makes it so a physics object can have as many colliders as needed.
The primitive colliders will also come in handy for objects that move, as they'll be much faster to check for collisions, and I remember somewhere I placed a hack to make convex mesh colliders work in such a context, I'll finally be able to delete said hack.
Physics Layers
Yet another important feature that DuskEngine finally gained.
There are eight (might tweak this number) available physics layers to assign objects to, and masks can be used when e.g. casting rays or shapes. A layer collision matrix is editable in the project settings, it decides which pairs of layers can collide.
Image: this project settings window is also a recent addition
The reason I added layers now was because I wanted to improve the third person camera, so that the player cannot accidentally push it inside the level geometry.
Raycasting provided a good starting point (casting rays to see if there's an obstacle in the way), but it quickly became clear that not every piece of level geometry is equal in this respect. For example, I definitely want to tweak the camera position if there's a large building in the way, but if it's a fence, even if most of the player's character is covered by it, I think the camera could stay in place.
My current idea to handle this is to have a separate set of colliders exclusively for this purpose, essentially describing the bounds within which the camera can exist. Their parent objects are set on the CameraBounds layer which does not collide with anything, as it's only there for raycasting purposes.
Image: the camera won't go through the building
Just this is insufficient to handle arbitrary level designs however so it's something I'll tweak as I go, but this is as good a starting point as any.
I have also updated some of the existing scripts so they make use of layers. For example, some spell effects that cast shapes to check if they hit anything, now exclusively check the Characters layer.
This also reduces the data payload that needs to make it back to Lua, and the amount of work it then has to do when checking whether or not the entities that were hit by the shapecast can take damage or have some other effect applied to them.
Conclusion
No navmeshes happened in the past month, but the new features are important additions nonetheless.
There is a ton of work left to make the editor side of the new features be as user-friendly as possible. Better visualization for the colliders, ensuring that things like invalid scales originating from the editor don't make it all the way to Jolt, assigning colors to each physics layer, so colliders in different layers are colored differently, an UI letting you decide which layers get rendered at all, and lots more that I probably haven't discovered yet.
The next major physics feature that will be required someday is support for trigger-type objects (those that only raise events when they collide with something, and are otherwise pass-through).
I'll wait until I have to implement a gameplay feature that needs it, it's always more fun that way.
Now back to navmeshes... surely.
- ← Previous
DuskEngine Devlog 0 - Quick Overview