Hellö
Here are a few thoughts about finding the best way to create a dense forest, with different models, quickly, dense and allowing good performances by walking and driving.
I first try with the vegetation tool. https://www.leadwerks.com/community/profile/15151-marcousik/?status=10763&type=status
I got good results but not by driving and I find that the collision checked causes the lost of 40 FPS (from 60 by to 20) making the game unplayable.
A new beta is available in the beta forum. This adds new texture and pixmap features, Basis texture support, and support for customized project workflows. Use of Basis textures brought the download size down to less than 300 megabytes. New Lua examples are included:
Build Texture
Build Cubemap
SetSubPixels
The new engine features advanced image and texture manipulation commands that allow a much deeper level of control than the mostly automated pipeline in Leadwerks Game Engine 4. This article is a deep dive into the new image and texture system, showing how to load, modify, and save textures in a variety of file formats and compression modes.
Texture creation has been finalized. Here is the command:
shared_ptr<Texture> CreateTexture(const TextureType type, const int width, const in
It's funny how all of the various features in the new engine are interconnected and development just flows from one to another. I was working on terrain, and I needed to save out some texture data so I implemented Pixmaps, and I wanted to add Basis support and DXT decompression, and then I started converting texture formats, and now I need a way to manage this all. This is an idea I have had for several years and I finally got to try it out.
Leadwerks Game Engine 4 has a strictly defined wo
Last year Google and Binomial LLC partnered to release the Basic Universal library as open-source. This library is the successor to Crunch. Both these libraries are like OGG compression for textures. They compress data very well into small file sizes, but once loaded the data takes the same space in memory as it normally does. The benefit is that it can reduce the size of your game files. Crunch only supports DXT compression, but the newer Basis library supports modern compression formats like B
In Leadwerks Game Engine 4, terrain was a static object that could only be modified in the editor. Developers requested access to the terrain API but it was so complex I felt it was not a good idea to expose it. The new terrain system is better thought out and more flexible, but still fairly complicated because you can do so much with it. This article is a deep dive into the inner workings of the new terrain system.
Creating Terrain
Terrain can be treated as an editable object, which i
Textures in Leadwerks don't actually store any pixel data in system memory. Instead the data is sent straight from the hard drive to the GPU and dumped from memory, because there is no reason to have all that data sitting around in RAM. However, I needed to implement texture saving for our terrain system so I implemented a simple "Pixmap" class for handling image data:
class Pixmap : public SharedObject
{
VkFormat m_format;
iVec2 m_size;
shared_ptr<Buffer> m_pixels;
int
I wanted to see if any of the terrain data can be compressed down, mostly to reduce GPU memory usage. I implemented some fast texture compression algorithms for BC1, BC3, BC4, BC5, and BC7 compression. BC6 and BC7 are not terribly useful in this situation because they involve a complex lookup table, so data from different textures can't be mixed and matched. I found two areas where texture compression could be used, in alpha layers and normal maps. I implemented BC3 compression for terrain alpha
A new update is available for beta testers. This adds a new LOD system to the terrain system, fixes the terrain normals, and adds some new features. The terrain example has been updated ans shows how to apply multiple material layers and save the data.
Terrain in LE4 uses a system of tiles. The tiles are rendered at a different resolution based on distance. This works great for medium sized terrains, but problems arise when we have very large view distances. This is why it is okay to
Documentation in Leadwerks 5 will start in the header files, where functions descriptions are being added directly like this:
/// <summary>
/// Sets the height of one terrain point.
/// </summary>
/// <param name="x">Horizontal position of the point to modify.</param>
/// <param name="y">Vertical position of the point to modify.</param>
/// <param name="height">Height to set, in the range -1.0 to +1.0.</param>
virtual void SetHeight(const int x
A new update is available for beta testers.
Terrain
The terrain building API is now available and you can begin working with it, This allows you to construct and modify terrains in pure code. Terrain supports up to 256 materials, each with its own albedo, normal, and displacement maps. Collision and raycasting are currently not supported.
Fast C++ Builds
Precompiled headers have been integrated into the example project. The Debug build will compile in about 20 seconds the first run
An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
--Create terrain
local terrain = CreateTerrain(world,256,256)
terrain:SetScale(256,100,256)
Here is what it looks like:
A single material layer is then added to the terrain.
--Add a material layer
local mtl = LoadMaterial("Materials/Dirt
Here are some things I did in the last couple days to fix a computer that was basically unusable.
It seems that Superfetch was rebranded to "SysMain" in an update and automatically re-enabled. If your computer is grinding away either the CPU or disk usage while doing nothing, this is the culprit. Disable it in Windows services.
The XBox games bar is suspect. I recommend disabling it now that FRAPS supports Vulkan.
Some features in Visual Studio are making it unusably slow.
In
A new beta is uploaded with lots of new features and improvements. Things are really taking shape!
Animation is now supported and it's really fast. Two examples are included.
Package loader plugins now supported, VPK package loader for Source Engine games included with example.
Added localization example.
Shaders folder very neatly organized, now contains shader family files.
Config folder eliminated.
Engine headers cleaned up and organized.
Lots
I created a test of 1000 animated crawler models to see how the performance of Vulkan stacks up against our older OpenGL renderer. Here it is in OpenGL running at 37 FPS, which is pretty respectable considering how many animations are playing (and about 4 million polygons).
With Vulkan the same test yields a framerate of 66 FPS, 78% faster than the OpenGL version.
Here is a video of the characters animating. Each skeleton is its own unique animation system, there are no sha
It's been nearly a year since I made the decision to port our OpenGL renderer over to Vulkan, and it has been very difficult work, but we are getting back up to speed. I was able to get skinned animation working for the first time in Vulkan yesterday, using a slightly modified version of our original animation shader code.
The system works exactly the same as in Leadwerks 4, with a few differences:
Animation features are confined to the Model class only, and are no longer
Analytics is a feature I have long thought was a good candidate to be moved into a plugin.
It is an optional features that only some users care about.
It imports some pretty big third-party libraries into the engine.
It requires an extra DLL be distributed with your game.
It's a totally self-contained features that is easy to separate out from the rest of the engine.
I have uploaded my code for Analytics in Leadwerks here as a new empty Visual Studio project:
The addition of our plugin system makes the engine feel different. There is a stronger distinction between core and non-essential functionality. I removed a lot of third-party libraries from the project and am just focusing on graphics, physics, pathfinding, and other features that are core to the functioning of your game. Things like file importers terrain generation, etc. can be stored away in self-contained optional plugins, or can be part of the editor project, and do not need to reside in t
Leadwerks 4 supports compressed and encrypted game files in ZIP format, but there are many different custom package formats different games use. The plugin system in Leadwerks 5 allows us to create importers for these different package formats so we can access content directly from commercial games you have installed on your computer. The example below shows how to load a VTF texture from the game Half-Life 2 directly from the game's install files.
First we need to load some plugins to deal
I've restructured the plugin SDK for our new engine and created a new repository on Github here:
https://github.com/Leadwerks/PluginSDK
The GMF2 format will only be used as an internal data transfer protocol for model loader plugins. Our main supported file format will be GLTF.
As of now, the plugin system can be used to write texture loaders for different file formats, model loaders, or to modify behavior of particles in the new particle system. The FreeImage texture loader has been
The Leadwerks 5 beta will soon be updated with particle emitters and an example particle system plugin. Previously, I showed some impressive results with physically interactive particles that collide with and exert forces on the environment. I decided to use the plugin system for controlling particle behavior, as this offers the best performance and can be run on the physics thread.
A particle system plugin uses some predefined structures and functions to modify the behavior of particles w
I made some changes to the design of the particle system. I am less concerned with the exact behavior of particles as they move around and move interested right now in building a system with good performance and deep physics interactions. Although I want particle behavior to be customizable, I don't think scripts are the right tool for the job. C++ plugins are better suited for this for two reasons.
C++ is much faster, and particles are a system that will make heavy use of that.
L
