Jump to content

Beta update available with deferred decals



An update is now available on the beta branch.


A new decal entity type is available. Decals are used to project an image into surrounding geometry. A decal requires a material using a decal shader, located in the "Shaders\Decals" folder. The FPSGun.lua script has been updated to add bullet marks and gunshot wounds to objects a bullet hits. You can also place a decal in a map for adding large details to walls, terrain, or anything else.




Decals are rendered similarly to the way a deferred light works; they are rendered onto the screen gbuffer. This allows them to work on any geometry, including animated models and GPU-generated details like tessellation. They will also map onto any surface, based on the direction of the surface normal. There are two new commands, Decals::Create() and Decal::SetRenderMode().


Because decals render onto the scene gbuffer, a way to differentiate pixels is needed. Otherwise, a scene decal will appear on objects that pass through that area. The Decal::SetRenderMode(int mode) command can be used to indicate whether a decal should be a static scene decal (mode=0) or a dynamic decal, like for a bullet mark (mode=1). Materials also have a new parameter for their decal mode, which can be 0 (static), 1 (dynamic), or 2 (none).


The blending of decals required that I modify the channel allocation of the gbuffer, and the lighting and model shaders have changed. Previously, data was stored like this:

0: Diffuse RGBA

1: Normal XYZ, specular

2: Emission RGB, material flags


Now the gbuffer is storing information as follows:

0: Diffuse RGBA

1: Normal XYZ, material flags

2: Emission RGB, specular


Any modified model shaders or shaders that are rendered before lighting need to be changed to accommodate this change, as well as any post-processing effects that read the specular value or material flags.


Particle emitters will now use simple collision if the emitter has a collision type other than zero. This is a nice touch that makes bullet shrapnel bounce off floors instead of going straight through.


I previously talked about four big features I was researching, terrain tessellation, terrain horizontal offsets, deferred decals, and vegetation. I made headway on each of these, but discovered that deferred decals were fairly easy to wrap up, while the other three features were more involved. Based on this development, I am revising my plan to release a new version in August with decals and the other recent improvements, then focus on finishing the vegetation system for a subsequent update. The important thing is to have the final update with vegetation out by November 1, at the latest, although that could end up being much sooner if things go smoothly.


I also expect to release the game launcher in August, as an early preview release on Steam.


(Build #691949 was update to #711604.)


Recommended Comments

The FPSGun script sets blood decals to mode 1, which means the material has to have the same decal mode to accept them. Therefore, any character materials should use decal mode = 1 for blood to show up on them.


For vectronic, this will add some nice burn marks on the walls, and you can make sparks flying off the impact spot. Use the directional rotation setting to make sparks, then they will bounce off the walls and floors. It will look really good.


You need to update your project to get new materials and shaders.

Share this comment

Link to comment

I mostly want them for the indicator lights. Before, I had planes that were raised a smitch off the ground. But I'll look into those other uses and ideas as I'm in the process of giving the balls a new identity :)

Share this comment

Link to comment

Only had a quick look before work and my first impressions of the decals are really good. Would have had more time but had a few shaders to update like Shadmars vegetation one, but that was quick enough to do.


Looking forward to looking at the particles with collision.



Share this comment

Link to comment

You can use an alpha channel in the diffuse texture and set the blend mode to alpha. You could also add a new shader that performs an alpha discard.

Share this comment

Link to comment

Decals look good and work quite well. I am getting very bad performance after this update though (10-15 fps less than before the update) and can't seem to do anything to make it better.

Share this comment

Link to comment

It is possible that decals could make it run slower if any are visible in the scene, but when none are present the FPS should be the same as before.

Share this comment

Link to comment

Other than updating shaders I haven't changed or added anything. It seems like the terrain rendering is much slower because my games without a terrain have the same performance as before.

Share this comment

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 10
      Current generation graphics hardware only supports up to a 32-bit floating point depth buffer, and that isn't adequate for large-scale rendering because there isn't enough precision to make objects appear in the correct order and prevent z-fighting.

      After trying out a few different approaches I found that the best way to support large-scale rendering is to allow the user to create several cameras. The first camera should have a range of 0.1-1000 meters, the second would use the same near / far ratio and start where the first one left off, with a depth range of 1000-10,000 meters. Because the ratio of near to far ranges is what matters, not the actual distance, the numbers can get very big very fast. A third camera could be added with a range out to 100,000 kilometers!
      The trick is to set the new Camera::SetClearMode() command to make it so only the furthest-range camera clears the color buffer. Additional cameras clear the depth buffer and then render on top of the previous draw. You can use the new Camera::SetOrder() command to ensure that they are drawn in the order you want.
      auto camera1 = CreateCamera(world); camera1->SetRange(0.1,1000); camera1->SetClearMode(CLEAR_DEPTH); camera1->SetOrder(1); auto camera2 = CreateCamera(world); camera2->SetRange(1000,10000); camera2->SetClearMode(CLEAR_DEPTH); camera2->SetOrder(2); auto camera3 = CreateCamera(world); camera3->SetRange(10000,100000000); camera3->SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); camera3->SetOrder(3); Using this technique I was able to render the Earth, sun, and moon to-scale. The three objects are actually sized correctly, at the correct distance. You can see that from Earth orbit the sun and moon appear roughly the same size. The sun is much bigger, but also much further away, so this is exactly what we would expect.

      You can also use these features to render several cameras in one pass to show different views. For example, we can create a rear-view mirror easily with a second camera:
      auto mirrorcam = CreateCamera(world); mirrorcam->SetParent(maincamera); mirrorcam->SetRotation(0,180,0); mirrorcam=>SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); //Set the camera viewport to only render to a small rectangle at the top of the screen: mirrorcam->SetViewport(framebuffer->GetSize().x/2-200,10,400,50); This creates a "picture-in-picture" effect like what is shown in the image below:

      Want to render some 3D HUD elements on top of your scene? This can be done with an orthographic camera:
      auto uicam = CreateCamera(world); uicam=>SetClearMode(CLEAR_DEPTH); uicam->SetProjectionMode(PROJECTION_ORTHOGRAPHIC); This will make 3D elements appear on top of your scene without clearing the previous render result. You would probably want to move the UI camera far away from the scene so only your HUD elements appear in the last pass.
    • By tipforeveryone in tipforeveryone's Blog 12
      I spent a whole week for learning UE4 with cpp, yep, UE4 is a great engine for sure, but I found out that my mind could not understand the way UE4 works easily. It is too complex and made me tired. Then I returned to my Leadwerks project and felt so familiar. Soooo... sweet, everything is simple as it is
      It felt like I have had a long trip to UE city then return to my hometown. I miss Leadwerks indeed.
      Last year, I thought I could only use Leadwerks with LUA and never touch its CPP side. But I tried my best, learned Cpp for 8 months. Now I am not a cpp pro but I am confident in using this language. At least I can rewrite my whole project in CPP instead. this 3-years project helped me to understand my potential and interest in gamedev.
      I wish Josh be successful in progress of making Turbo, a new hope for much better Leadwerks.
      To all people who are using Leadwerks and help me these years, love you.
    • By Josh in Josh's Dev Blog 2
      Still a lot of things left to do. Now that I have very large-scale rendering working, people want to fill it up with very big terrains. A special system will be required to handle this, which adds another layer to the terrain system. Also, I want to resume work on the voxel GI system, as I feel these results are much better than the performance penalty of ray-tracing. There are a few odds and ends like AI navigation and cascaded shadow maps to finish up.
      I am planning to have the engine more or less finished in the spring, and begin work on the new editor. Our workflow isn't going to change much. The new editor is just going to be a more refined version of what we already have, although it is a complete new program written from scratch, this time in C++.
      It's kind of overwhelming but I have confidence in the whole direction and strategy of this new product.
  • Create New...