You might have seen this graphic comparing the size of the world in different games. I've played Fuel, and never reached the end of the world in that game. You can drive for a very long time on those roads.
We want to use the new engine for realistic simulations of air and ground movements. At normal cruising altitude of a commercial airliner, the pilot has a view range of about 400 kilometers. The image below shows that area (800 x 800 km). You can see the areas of the biggest games
A huge update is available for Turbo Engine Beta.
Hardware tessellation adds geometric detail to your models and smooths out sharp corners.
The new terrain system is live, with fast performance, displacement, and support for up to 255 material layers.
Plugins are now working, with sample code for loading MD3 models and VTF textures.
Shader families eliminate the need to specify a lot of different shaders in a material file.
Support for multiple monitors and be
New commands in Turbo Engine will add better support for multiple monitors. The new Display class lets you iterate through all your monitors:
for (int n = 0; n < CountDisplays(); ++n)
auto display = GetDisplay(n);
Print(display->GetPosition()); //monitor XY coordinates
Print(display->GetSize()); //monitor size
Print(display->GetScale()); //DPI scaling
The CreateWindow() function now takes a parameter for the monitor to create the window on / relative to.
Texture loading plugins allow us to move some big libraries like FreeImage into separate optional plugins, and it also allows you to write plugins to load new texture and image formats.
To demonstrate the feature, I have added a working VTF plugin to the GMF2 SDK. This plugin will load Valve texture files used in Source Engine games like Half-Life 2 and Portal. Here are the results, showing a texture loaded directly from VTF format and also displayed in Nem’s nifty VTFEdit tool.
I wanted to work on something a bit easier before going back into voxel ray tracing, which is another difficult problem. "Something easier" was terrain, and it ended up consuming the entire month of August, but I think you will agree it was worthwhile.
In Leadwerks Game Engine, I used clipmaps to pre-render the terrain around the camera to a series of cascading textures. You can read about the implementation here:
This worked very well with the hardware we had available at the time, b
Multithreading is very useful for processes that can be split into a lot of parallel parts, like image and video processing. I wanted to speed up the normal updating for the new terrain system so I added a new thread creation function that accepts any function as the input, so I can use std::bind with it, the same way I have been easily using this to send instructions in between threads:
shared_ptr<Thread> CreateThread(std::function<void()> instruction);
The terrain update nor
The GMF2 data format gives us fine control to enable fast load times. Vertex and indice data is stored in the exact same format the GPU uses so everything is read straight into video memory. There are some other optimizations I have wanted to make for a long time, and our use of big CAD models makes this a perfect time to implement these improvements.
Precomputed BSP Trees
For raycast (pick) operations, a BSP structure needs to be constructed from the mesh data. In Leadwerks Engine thi
My work with the MD3 format and its funny short vertex positions made me think about vertex array sizes. (Interestingly, the Quake 2 MD2 format uses a single char for vertex positions!)
Smaller vertex formats run faster, so it made sense to look into this. Here was our vertex format before, weighing in at 72 bytes:
unsigned char color;
unsigned char boneweights;
unsigned char b
The GMF2 SDK has been updated with tangents and bounds calculation, object colors, and save-to-file functionality.
The GMF2 SDK is a lightweight engine-agnostic open-source toolkit for loading and saving of game models. The GMF2 format can work as a standalone file format or simply as a data format for import and export plugins. This gives us a protocol we can pull model data into and export model data from, and a format that loads large data much faster than alternative file formats.
Not a lot of people know about this, but back in 2001 Discreet (before the company was purchased by Autodesk) released a free version of 3ds max for modding games. Back then game file formats and tools were much more highly specialized than today, so each game required a "game pack" to customize the gmax interface to support that game. I think the idea was to charge the game developer money to add support for their game. Gmax supported several titles including Quake 3 Arena and Microsoft Flight
I wanted to get a working example of the plugin system together. One thing led to another, and...well, this is going to be a very different blog.
The first thing I had to do is figure out a way for plugins to communicate with the main program. I considered using a structure they both share in memory, but those always inevitably get out of sync when either the structure changes or there is a small difference between the compilers used for the program and DLL. This scared me so I we
I started to implement quads for tessellation, and at that point the shader system reached the point of being unmanageable. Rendering an object to a shadow map and to a color buffer are two different processes that require two different shaders. Turbo introduces an early Z-pass which can use another shader, and if variance shadow maps are not in use this can be a different shader from the shadow shader. Rendering with tessellation requires another set of shaders, with one different set for each
With tessellation now fully implemented, I was very curious to see how it would perform when applied to arbitrary models. With tessellation, vertices act like control points for a Bezier mesh that is subdivided dynamically in screen space. Could tessellation be used to add new details to any low-poly model?
Here is a low-res character model with a pointy head and obvious sharp edges all around his silhouette:
When tessellation is enabled, the sharp edges go away and the mes
Previously I talked about the technical details of hardware tessellation and what it took to make it truly useful. In this article I will talk about some of the implications of this feature and the more advanced ramifications of baking tessellation into Turbo Game Engine as a first-class feature in the
Although hardware tessellation has been around for a few years, we don't see it used in games that often. There are two big problems that need to be overcome.
We need a way to preven
Now that I have all the Vulkan knowledge I need, and most work is being done with GLSL shader code, development is moving faster. Before starting voxel ray tracing, another hard problem, I decided to work one some *relatively* easier things for a few days. I want tessellation to be an every day feature in the new engine, so I decided to work out a useful implementation of it.
While there are a ton of examples out there showing how to split a triangle up into smaller triangles, useful discus
Shadow maps are now supported in the new Vulkan renderer, for point, spot, and box lights!
Our new forward renderer eliminates all the problems that deferred renderers have with transparency, so shadows and lighting works great with transparent surfaces. Transparent objects even receive lighting from their back face automatically!
There is some shadow acne, which I am not going to leave alone right now because I want to try some ideas to eliminate it completely, so you neve
After about four days of trying to get render-to-texture working in Vulkan, I have everything working except...it doesn't work. No errors, no clue what is wrong, but the renderer is not even clearing the depth attachment, which is why the texture read shown here is flat red.
There's not much else to say right now. I will keep trying to find the magic combination of cryptic obscure settings it takes to make Vulkan do what I want.
This is very hard stuff, but once I have it working
Now that we have lights working in our clustered forward Vulkan renderer (same great technique the latest DOOM games are using) I am starting to implement shadow maps. The first issue that came up was managing render-to-texture when the texture might still be in use rendering the previous frame. At first I thought multiple shadowmaps would be needed per light, like a double-buffering system, but that would double the number of shadow textures and video memory. Instead, I created a simple object
I am experimenting with a system for creating a sequence of actions using Lua coroutines. This allows you to define a bunch of behavior at startup and let the game just run without having to keep track of a lot of states.
You can add coroutines to entities and they will be executed in order. The first one will complete, and then the next one will start.
A channel parameter allows you to have separate stacks of commands so you can have multiple sequences running on the same object. For
A new beta is available. In this build I cleaned up a lot of internal stuff. I removed some parts of the engine that I want to redesign in order to clean up the source.
JSON material files loaded from MDL files are now supported.
Added ActiveWindow() command. if the game window is not the foreground window this will return null.
The Steamworks and all dependent classes are temporarily removed. There's a lot of stuff in there I don't intend to use in the future like all the Worksho
This is a good time to write about some very broad changes I expect to come about over the next year in our community as our new engine "Turbo" arrives. Turbo Game Engine, as the name suggests, offers really fast performance using a groundbreaking Vulkan-based renderer, which is relevant to everyone but particularly beneficial for VR developers who struggle to keep their framerates up using conventional game engines. I want to help get you onboard with some of the ideas that I myself am processi
A new update is available for beta subscribers.
Added support for strip lights. To create these just call CreateLight(world, LIGHT_STRIP). The entity scale on the Z axis will determine the length of the line, and the outer range will determine the radius in which light shows.
Added new properties to the JSON material scheme. "textureScroll" is a float value that can animate a texture to make it smoothly move. "textureScrollRotation" is an angle to control which dir
It's always fun when I can do something completely new that people have never seen in a game engine. I've had the idea for a while to create a new light type for light strips, and I got to implement this today. The new engine has taken a tremendous amount of effort to get working over two years, but as development continues I think I will become much more responsive to your suggestions since we have a very strong foundation to build on now.
Using this test scene provided by @reepblue you ca
A new update is available for beta subscribers. Transparent materials are now supported. Unlike the old deferred renderer, our new clustered forward renderer supports transparency really really well! You can add these in a JSON material file with a Boolean property called "transparent" set to true:
There are no separate blend modes now, since pre-multiplied alpha allows alpha and additive blending in a single pass. This is actually a really simple technique but for som
An update for the beta of the new engine is now available with the following changes:
GLTF loader is now working for most models. A large collection of GLTF files are available online for free from many sources, and they can be loaded right into the engine without any adjustment for materials or textures. Single-file GLB files also work.
Added support for GLTF extension KHR_materials_pbrSpecularGlossiness.
Disabled PNG loader gamma correction.