Leadwerks 5 beta update adds model saving and static shadow caching

Entry posted by Josh · June 24, 2020

1,884 views

A new update is available for beta testers.

The dCustomJoints and dContainers DLLs are now optional if your game is not using any joints (even if you are using physics).

The following methods have been added to the collider class. These let you perform low-level collision tests yourself:

Collider::ClosestPoint
Collider::Collide
Collider::GetBounds
Collider::IntersectsPoint
Collider::Pick

The PluginSDK now supports model saving and an OBJ save plugin is provided. It's very easy to convert models this way using the new Model::Save() method:

auto plugin = LoadPlugin("Plugins/OBJ.dll");
auto model = LoadModel(world,"Models/Vehicles/car.mdl");
model->Save("car.obj");

Or create models from scratch and save them:

auto box = CreateBox(world,10,2,10);
box->Save("box.obj");

I have used this to recover some of my old models from Leadwerks 2 and convert them into GLTF format:

There is additional documentation now on the details of the plugin system and all the features and options.

Thread handling is improved so you can run a simple application that handles 3D objects and exits out without ever initializing graphics.

Increased strictness of headers for private and public members and methods.

Fixed a bug where directional lights couldn't be hidden. (Check out the example for the CreateLight command in the new docs.)

All the Lua scripts in the "Scripts\Start" folder are now executed when the engine initializes, instead of when the first script is run. These will be executed for all programs automatically, so it is useful for automatically loading plugins or workflows. If you don't want to use Lua at all, you can delete the "Scripts" folder and the Lua DLL, but you will need to load any required plugins yourself with the LoadPlugin command.

Shadow settings are simplified. In Leadwerks 4, entities could be set to static or dynamic shadows, and lights could use a combination of static, dynamic, and buffered modes. You can read the full explanation of this feature in the documentation here. In Leadwerks 5, I have distilled that down to two commands. Entity::SetShadows accepts a boolean, true to cast shadows and false not to. Additionally, there is a new Entity::MakeStatic method. Once this is called on an entity it cannot be moved or changed in any way until it is deleted. If MakeStatic() is called on a light, the light will store an intermediate cached shadowmap of all static objects. When a dynamic object moves and triggers a shadow redraw, the light will copy the static shadow buffer to the shadow map and then draw any dynamic objects in its range. For example, if a character walks across a room with a single point light, the character model has to be drawn six times but the static scene geometry doesn't have to be redrawn at all. This can result in an enormous reduction of rendered polygons. (This is something id Software's Doom engine does, although I implemented it first.)

In the documentation example the shadow polygon count is 27000 until I hit the space key to make the light static. The light then renders the static scene (everything except the fan blade) into an image, there thereafter that cached image is coped to the shadow map before the dynamic scene objects are drawn. This results in the shadow polygons rendered to drop by a lot, since the whole scene does not have to be redrawn each frame.

I've started using animated GIFs in some of the documentation pages and I really like it. For some reason GIFs feel so much more "solid" and stable. I always think of web videos as some iframe thing that loads separately, lags and doesn't work half the time, and is embedded "behind" the page, but a GIF feels like it is a natural part of the page.

My plan is to put 100% of my effort into the documentation and make that as good as possible. Well, if there is an increased emphasis on one thing, that necessarily means a decreased emphasis on something else. What am I reducing? I am not going to create a bunch of web pages explaining what great features we have, because the documentation already does that. I also am not going to attempt to make "how to make a game" tutorials. I will leave that to third parties, or defer it into the future. My job is to make attractive and informative primary reference material for people who need real usable information, not to teach non-developers to be developers. That is my goal with the new docs.