Jump to content

Blogs

Pre-Alpha v1.1

After three weeks of work, Pre-Alpha v1.1 is ready.   Terrain The terrain has seen some behind the scenes improvements with speed as well as visual improvements to geometry and texturing.  When I manage to get Texture Arrays working I will be able to finish of the new texturing shader that will include Tessellation and over 16 different texture maps as well as various masks that will paint according to erosion and forest locations. An image of one of the mountains randomly placed in the First World, textured with two 4k textures.  The way the generator works is there is a predefined list of terrain features, like mountains, rivers and valleys.  Based on a low resolution base map which is unique for each fragment, these features are placed at different scales, positions and rotations.  They will also merge with one another to provide enough variation that it will be hard to see any similarities. At the moment though there are not enough maps to make this unnoticeable.           Saving and Loading I have now implemented the ability to save and load a game.  Currently the only states that are saved are the players position, stats and inventory. Each slot shows the date and time that it was saved on as well as the save name and version number.  Slots can be deleted and overwritten.  The version number will change over the course of the updates, but the ability to load older versions will always be available.  And to save a new game, click the empty slot then click save. Now that this mechanic is done I can work on more game play.             What's Next The next step is to improve the blacksmith and general store.  These two places will be the first to provide work opportunities for the player.  These opportunities will improve skill and eventually allow you to buy and use crafting equipment outside of the towns. I will also be implementing some other mercenary characters and animals to hunt.  The mercenaries will just offer some fun conflict to begin with and the animals will offer another source of income.  I hope to have a deer and wolf done by the next update in a few weeks.   The full change log is packaged with the game, here.

Lethal Raptor Games

Lethal Raptor Games

Leadwerks Software to Provide VR Services to NASA

TLDR: I made a long-term bet on VR and it's paying off. I haven't been able to talk much about the details until now. Here's what happened: Leadwerks 3.0 was released during GDC 2013. I gave a talk on graphics optimization and also had a booth at the expo. Something else significant happened that week.  After the expo closed I walked over to the Oculus booth and they let me try out the first Rift prototype. This was a pivotal time both for us and for the entire game industry. Mobile was on the downswing but there were new technologies emerging that I wanted to take advantage of. Our Kickstarter campaign for Linux support was very successful, reaching over 200% of its goal. This coincided with a successful Greenlight campaign to bring Leadwerks Game Engine to Steam in the newly-launched software section. The following month Valve announced the development of SteamOS, a Linux-based operating system for the Steam Machine game consoles. Because of our work in Linux and our placement in Steam, I was fortunate enough to be in close contact with much of the staff at Valve Software. The Early Days of VR It was during one of my visits to Valve HQ that I was able to try out a prototype of the technology that would go on to become the HTC Vive. In September of 2014 I bought an Oculus Rift DK2 and first started working with VR in Leadwerks. So VR has been something I have worked on in the background for a long time, but I was looking for the right opportunity to really put it to work. In 2016 I felt it was time for a technology refresh, so I wrote a blog about the general direction I wanted to take Leadwerks in. A lot of it centered around VR and performance. I didn't really know exactly how things would work out, but I knew I wanted to do a lot of work with VR. A month later I received a message on this forum that went something like this (as I recall): I thought "Okay, some stupid teenager, where is my ban button?", but when I started getting emails with nasa.gov return addresses I took notice. Now, Leadwerks Software has a long history of use in the defense and simulation industries, with orders for software from Northrop Grumman, Lockheed Martin, the British Royal Navy, and probably some others I don't know about. So NASA making an inquiry about software isn't too strange. What was strange was that they were very interested in meeting in person. Mr. Josh Goes to Washington I took my first trip to Goddard Space Center in January 2017 where I got a tour of the facility. I saw robots, giant satellites, rockets, and some crazy laser rooms that looked like a Half-Life level. It was my eleven year old self's dream come true. I was also shown some of the virtual reality work they are using Leadwerks Game Engine for. Basically, they were taking high-poly engineering models from CAD software and putting them into a real-time visualization in VR. There are some good reasons for this. VR gives you a stereoscopic view of objects that is far superior to a flat 2D screen. This makes a huge difference when you are viewing complex mechanical objects and planning robotic movements. You just can't see things on a flat screen the same way you can see them in VR. It's like the difference between looking at a photograph of an object versus holding it in your hands.
What is even going on here??? CAD models are procedural, meaning they have a precise mathematical formula that describes their shape. In order to render them in real-time, they have to be converted to polygonal models, but these objects can be tens of millions of polygons, with details down to threading on individual screws, and they were trying to view them in VR at 90 frames per second! Now with virtual reality, if there is a discrepancy between what your visual system and your vestibular system perceives, you will get sick to your stomach. That's why it's critical to maintain a steady 90 Hz frame rate. The engineers at NASA told me they first tried to use Unity3D but it was too slow, which is why they came to me. Leadwerks was giving them better performance, but it still was not fast enough for what they wanted to do next. I thought "these guys are crazy, it cannot be done". Then I remembered something else people said could never be done. So I started to think "if it were possible, how would I do it?" They had also expressed interest in an inverse kinematics simulation, so I put together this robotic arm control demo in a few days, just to show what could be easily be done with our physics system.   Turbo Game Engine is Born With the extreme performance demands of VR and my experience writing optimized rendering systems, I saw an opportunity to focus our development on something people can't live without: speed. I started building a new renderer designed specifically around the way modern PC hardware works. At first I expected to see performance increases of 2-3x. Instead what we are seeing are 10-40x performance increases under heavy loads. Once I saw this I was very encouraged, so I decided to name the new engine "Turbo Game Engine" (the point is absolutely unmissable) and bought the domain name turboengine.com. During this time I stayed in contact with people at NASA and kept them up to date on the capabilities of the new technology. At this point there was still nothing concrete to show for my efforts. NASA purchased some licenses for the Enterprise edition of Leadwerks Game Engine, but the demos I made were free of charge and I was paying my own travel expenses. The cost of plane tickets and hotels adds up quickly, and there was no guarantee any of this would work out. I did not want to talk about what I was doing on this site because it would be embarrassing if I made a lot of big plans and nothing came of it. But I saw a need for the technology I created and I figured something would work out, so I kept working away at it. Call to Duty Today I am pleased to announce I have signed a contract to put our virtual reality expertise to work for NASA. As we speak, I am preparing to travel to Washington D.C. to begin the project. In the future I plan to provide services for aerospace, defense, manufacturing, and serious games, using our new technology to deliver VR simulations with performance and realism beyond anything that has been possible until now. My software company and relationship with my customers (you) is unaffected. Development of the new engine will continue, with a strong emphasis on hyper-realism and performance. I think this is a direction everyone here will be happy with. I am going to continue to invest in the development of groundbreaking new features that will help in the aerospace and defense industries (now you understand why I have been talking about 64-bit worlds) and I think a great many people will be happy to come along for the ride in this direction. Leadwerks is still a game company, but our core focus is on enabling and creating hyper-realistic VR simulations. Thank you for your support and all the suggestions and ideas you have provided over the years that have helped me create great software for you. Things are about to get very interesting. I can't wait to see what you all create with the new technology we are building.

Josh

Josh

Vector Image Support

Building on the Asset Loader class I talked about in my previous blog post, I have added a loader to import textures from SVG files. In 2D graphics there are two types of image files. Rasterized images are made up of a grid of pixels. Vector images, on the other hand, are made up of shapes like Bezier curves. One example of vector graphics you are probably familiar with are the fonts used on your computer. SVG files are a vector image format that can be created in Adobe Illustrator and other programs: Because SVG images are resolution-independent, when you zoom in on these images they only become more detailed: This makes SVG images perfect for GUI elements. The Leadwerks GUI can be rendered at any resolution, to support 4K, 8K, or other displays. This is also great for in-game VR GUIs because you can scale the image to any resolution. SVG images can be loaded as textures to be drawn on the screen, and in the future will be able to be loaded as GUI images. You can specify a DPI to rasterize the image to, with a default setting of 96 dots per inch.

Josh

Josh

Asset Loader Class

There's a discussion on the forum that sort of veered into talking about Khronos' GLTF file format specification: Some of this gave me some ideas for changes in the art pipeline in Turbo Game Engine. I was not feeling very concentrated today so I decided to do some easy work and implement a loader class: class Loader : public SharedObject { public: std::vector<wstring> extensions; virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; Then I created a TEX texture loader class: class TEXTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; When the engine is initialized it creates a TEXTexLoader object and saves it in a list of texture loaders: GameEngine::Initialize() { textureloaders.push_back(make_shared<TEXTextureLoader>()); } And the class constructor itself creates an array of file extensions the loader supports: TEXTextureLoader::TEXTextureLoader() { extensions = { "tex" }; } When a texture is loaded, the engine looks for a texture loader that matches the extension or the loaded file path. At this point, all we have done is restructured the engine to do the same thing it did before, with more code. But now we can add new loaders for other file formats. And that is exactly what I did. You can now load textures directly from PNG files: class PNGTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; I've done the same thing for model file loading as well, although I have not yet added support for any other file types. If we can add a C++ loader, we should be able to add one with Lua too. I haven't worked out the details yet, but it could work something like this: function LoadModelObj( stream, model ) while stream:EOF() == false do -------------- end end AddModelLoader(LoadModelObj) So with that, you could download a Lua script that would add support for loading a new file format. I think in the new engine we will support all common image formats, including Photoshop PSD, as well as DDS, KTX, and our existing TEX files. Textures loaded from image formats will be less optimal because mipmaps will be generated on loading. Settings like clamping and filter modes will be stored in the associated .meta files, which means these files will start getting published along with your game asset files. This is a change from the Leadwerks 4 way of doing things.

Josh

Josh

Pre-Alpha v1.0

The Seventh World is a Medieval Fantasy Survival game, inspired by the likes of Skyrim and ARK Survival Evolved.   It's been under development for the last two years but only in the last eight months has a real commitment been made to it.  Spending every night after work and every other day working on it I've achieved a base from which to build on. The cuboid landmasses are called fragments.  They are arranged as a sphere to make up a planet.  Game-play will eventually include moving from one fragment to another. Each fragment face has a gravity direction toward the center of the land mass.  Each face is known as a World.  The top most face is the First World.  The left, The Second World.  The right, The Fourth World.  The North face is The Fifth World and the South face is The Sixth.  The last face, opposite to the top is The Third World. Each World is separated by an area of weak gravity known as the gravity void, making it difficult to travel between them without the right equipment.  Each world will also have unique features and biome characteristics. In total, there will be approximately 12.5 million square kilometers of explorable terrain.             There is minimal game-play at the moment.  You spawn in one of the procedurally generated towns and the most you can do is; Harvest trees. Drink from the well. Sell/buy items from the shop. Eat equitable editable items. Run around.       What I'll be working on next is fixing the obvious graphics issues.  This will include; Terrain patch seams. Billboard trees and their many issues. Bugs when nearing the gravity void. Distant fragment seams.             The Plan My overall plan is to get this to an alpha stage so it can be released on Steam.  For this stage I want to have the following implemented; VR Multiplayer Building mechanics. Basic Missions. Improved Graphics.   Bug Warning Physics shapes are not releasing and are causing memory usage to increase.   Various other small memory leaks. Crashes in the gravity void sometimes. Feedback and suggestions are welcome.  I hope to have a progress update every one to weeks. Download Here

Lethal Raptor Games

Lethal Raptor Games

Test Driving on Mars :D

And the screen, really a pain in the ***..... Well, the test drive on Mars, results with just applying the engine to the rear tires, I still feel it jumps a lot, hopefully in the next leadwerks update to get better control of the joints. Let's hope that update is soon. Another thing is that I think it is impossible to reach high speeds, because it starts to bounce a lot. And happy with the OBS video recording program, he doesn't get slow when he makes a video. Translated with www.DeepL.com/Translator  

Yue

Yue

Glass material

Well, it wasn't the desired result, but it's not that it's too bad, the vehicle's glass looks like this, even though it would have been better transparent, but like many things in life, this is out of my knowledge ("shaders") and it's up to us to adapt to what we have.



Yue

Yue

Steering system realized

Among other things, we already have vehicle glass, which is simple but adaptable to the needs. On the steering rims, they can be moved from left to right with their respective rim headstock. The steering is not automatic at the moment, i.e. it does not return to the central axis without pressing the keys, this has to be done manually, and the speed of the steering rotation will have to be in accordance with the speed of the car in motion. Translated with www.DeepL.com/Translator



Yue

Yue

Motivation has returned

The world moves on the basis of motivation, so again we are here with my learning projects to the limit of being able to think that if I am able to make a game, and is that in Leadwerks, everything is much more wonderful thinking about productivity, of course, there can be better things than this engine, but is what I feel most comfortable with.  Well, the project initially involves rolling a car on the surface of Mars, this is thanks to the work that the engine offers in hinge and sliding joints. I have the job done in the best and most efficient way when the shock absorbers and the engine of each tire, the next step is to set the engine of the car, and set the direction of the front tires so that the scout vehicle can turn and move in different directions on the ground.  So I'll see you in more advance.  Translated with www.DeepL.com/Translator

Yue

Yue

More Work on Shadows

I found and fixed the cause of the cubemap seams in variance shadow maps so we now have nice soft seamless shadows. I also changed the engine so that point lights use six 2D textures instead of a separate cubemap texture array. This means that all light types are sharing one big 2D array texture, and it frees up one texture slot. I am not sure if I want to have a hard limit on number of shadow-casting lights in the scene, or if I want to implement a system that moves lights in and out of a fixed number of shadowmap slots.

Josh

Josh

Three Massive improvements the new engine will make in your life

As I work with the new engine more and more I keep finding new ways it makes life happy and productive. Smart Pointers I have talked about how great these are at length, but I keep finding new reasons I love them. The behind-the-scenes design has been a lot of fun, and it's so cool to be able to write lines of code like this without any fear of memory leaks: LoadSound("Sound/Music/fully_loaded_60.wav")->Play(); What do you think that code does? It plays a sound, keeps it in memory, and then unloads it when the sound finishes playing (assuming it is not loaded anywhere else). Smart Pointers make the new API almost magical to work with, and they don't have the performance overhead that garbage collection would, and they work great with Lua script. User Interface Leadwerks GUI will be used in our new editor, which allows me to innovate in many new ways. But we're also using Visual Studio Code for the script editor, which gives you a sleek modern scripting environment. Better Scene Management Cached shadow maps.are a feature in Leadwerks 4 that separate geometry into static and dynamic shadow-casting types. Static shadows are rendered into a cache texture. When the shadow updates only the dynamic objects are redrawn on top of the saved static cache. This requires that you set the light shadow mode to Dynamic|Static|Buffered. In the new engine this will be automatic. By default lights will use a shadow cache, and if the light moves after the first shadow render, the cache will be disabled. Any geometry can be marked as static in the new editor. Static objects are more optimal for lighting, navigation, and global illumination, and will not respond to movement commands. (This can also be used to mark which brushes should get merged when the scene is loaded). If you don't explicitly select whether an object in the scene should be static or not, the engine will guess. For example, any object with non-zero mass or a script attached to it should not be automatically marked as static. If you didn't understand any of that, don't worry! Just don't do anything, and your scene will already be running efficiently, because the engine makes intelligent choices based on your game's behavior. It's all turning out really nice.

Josh

Josh

Test: Customizable NPC controller

Working out of this subject:   I tested a script for a simple "GoToPoint()" function for a customizable character controller for NPC. This may not be so good as the implemented LE character controller with classic navigation system but it could be promising to use it in open world (so not in much corridored dungeon game!) where the the NPC should crawl or swim or whatever do things as for example underscaled world (thats what I am actually interested in 😁) The NPCs are using an "intelligent" World:Pick() system to find their way. The positive things in this are: - No need nav mesh to be build / free moving system - dynamic way searching so removing a block may let the NPCs go through - swim, crawl, crouch with triggers should be no problem - NPC are not only following a prepared way but they can be thrown as Patrol, choosing randomize positions to go, inside an area. - Scale as you want - The system let the NPC make a little analyse out of the Pick Infos so the way should be a human-logical way   The negative point are: - The path will not be planned so far as allows the actually Navigation Leadwerks System so it is for sure not impossible that a NPC doesn't find the best way to go. This system does definiv not allow a NPC to "know" his way through the entire map. All NPCs are trying to find the best way from the position where they stay at the mooment, so never sure if/what they will find (no return of true/false that let you know the NPC found a way...) (even if this could be solved with "forcing" through a pivot where the way may be too complicated to find...) - The NPCs doen't move "round" but straight from point to point. - For sure more...? 🤔 Here is a little demo: Testing 13.08.2018 20_00_48.mp4    

Marcousik

Marcousik

Turbo Game Engine Beta Update

The Turbo Game Engine beta is updated! This will allow you to load your own maps in the new engine and see the speed difference the new renderer makes. LoadScene() has replaced the LoadMap() function, but it still loads your existing map files. To create a PBR material, insert a line into the material file that says "lightingmodel=1". Blinn-Phong is the default lighting model. The red and green channels on texture unit 2 represent metalness and roughness. You generally don't need to assign shaders to your materials. The engine will automatically select one based on what textures you have. Point and spot lights work. Directional lights do not. Setting the world skybox only affects PBR reflections and Blinn-Phong ambient lighting. No sky will be visible. Physics, scripting, particles, and terrain do not work. Variance shadow maps are in use. There are currently some problems with lines appearing at cubemap seams and some flickering pixels. Objects should always cast a shadow or they won't appear correctly with VSMs. I had to include glew.c in the project because the functions weren't being detected from the static lib. I'm not sure why. The static libraries are huge. The release build is nearly one gigabyte. But when compiled, your executable is small. #include "Leadwerks.h" using namespace Leadwerks; int main(int argc, const char *argv[]) { //Create a window auto window = CreateWindow("MyGame", 0, 0, 1280, 720); //Create a rendering context auto context = CreateContext(window); //Create the world auto world = CreateWorld(); //This only affects reflections at this time world->SetSkybox("Models/Damaged Helmet/papermill.tex"); shared_ptr<Camera> camera; auto scene = LoadScene(world, "Maps/turbotest.map"); for (auto entity : scene->entities) { if (dynamic_pointer_cast<Camera>(entity)) { camera = dynamic_pointer_cast<Camera>(entity); } } auto model = LoadModel(world, "Models/Damaged Helmet/DamagedHelmet.mdl"); model->Move(0, 1, 0); model->SetShadowMode(LIGHT_DYNAMIC, true); //Create a camera if one was not found if (camera == nullptr) { camera = CreateCamera(world); camera->Move(0, 1, -3); } //Set background color camera->SetClearColor(0.15); //Enable camera free look and hide mouse camera->SetFreeLookMode(true); window->HideMouse(); //Create a light auto light = CreateLight(world, LIGHT_POINT); light->SetShadowMode(LIGHT_DYNAMIC | LIGHT_STATIC | LIGHT_CACHED); light->SetPosition(0, 4, -4); light->SetRange(15); while (window->KeyHit(KEY_ESCAPE) == false and window->Closed() == false) { //Rotate model model->Turn(0, 0.5, 0); //Camera movement if (window->KeyDown(Key::A)) camera->Move(-0.1, 0, 0); if (window->KeyDown(Key::D)) camera->Move(0.1, 0, 0); if (window->KeyDown(Key::W)) camera->Move(0, 0, 0.1); if (window->KeyDown(Key::S)) camera->Move(0, 0, -0.1); //Update the world world->Update(); //Render the world world->Render(context); } Shutdown(); return 0; }

Josh

Josh

Next Steps

I've got the basic GI algorithm working but it needs a lot of work to be correct. I tend to do very well when the exact outcome is well-defined, but I am not as good at dealing with open-ended "artistic" programming. I may end up outsourcing the details of the GI shader to someone else, but the underlying data management is solid enough that I am not scared of it anymore. There's a lot of aspects of the design I'm not scared of anymore. We worked out smart pointers (including Lua integration), physically-based rendering, and most importantly the crazy ideas I had for the super efficient architecture work really well. At this point I think I am going to put the GI on hold, since I could play around with that endlessly, and focus on getting a new build out to the beta subscribers. We're going to just use a single skybox for ambient and specular reflections right now, and when it's ready GI and environment probes will provide that.  After that I think I will focus on the physics and navigation systems, exposing the entire API to Lua, and getting some of the outsourced work started. There's a few things I plan to farm out: Visual Studio Code Lua debugger GI details Weather system Water and clouds systems Everything else is pretty well under my control. This started out as an idea for an impossible design, but everything has fallen into place pretty neatly.

Josh

Josh

Beta Branch Updated

The beta branch has been updated. The following changes have been made: Rolled beta branch back to release version, with changes below. Added new FBX converter. Fixed Visual Studio project template debug directory. Fixed Visual Studio project template Windows Platform SDK version problem. If everything is okay with this then it will go out on the default branch soon.

Josh

Josh

Real-time Global Illumination

I finally have a cool screenshot to show you of our new real-time global illumination working. Here is a comparison screenshot showing direct lighting only: Now there are still lots of small issues to worry about. Right now I am only using a single cone trace. More cones will improve accuracy, but I think light leaking is just always going to be a fact of life with this technique. Still, the results looks great, require no precalculation, respond to environment changes, and don't require any setup. Win!

Josh

Josh

Cone Step Tracing

Now that we have our voxel light data in a 3D texture we can generate mipmaps and perform cone step tracing. The basic idea is to cast a ray out from each side of each voxel and use a lower-resolution mipmap for each ray step. We start with mipmap 1 at a distance that is 1.5 texels away from the position we are testing, and then double the distance with each steo of the ray. Because we are using linear filtering we don't have to make the sample coordinates line up exactly to a texel center, and it will work fine: Here are the first results when cone step tracing is applied. You can see light bouncing off the floor and reflecting on the ceiling: This dark hallway is lit with indirect lighting: There's lots of work left to do, but we can see here the basic idea works.

Josh

Josh

3D Texture Filled with Voxel Lighting

I have successfully transferred lit voxel data into a 3D texture. The texture is now being used to display the lighting at each voxel. Soft edges are appearing due to linear filtering in the texture. To achieve this, I used an OpenGL 4.2 feature which allows you to write values into any arbitrary position in a texture. This could also be used for motion blur or fluid simulations in the future. However, since Mac support for OpenGL only goes up to 4.1, it means we cannot use real-time GI on a Mac, unless a separate workaround is written to handle this, or unless a renderer is written using Vulkan / Metal. At the time I am going to stick with OpenGL, because it would be too hard to implement an experimental new architecture with an API I don't know much about. Now that we have our lit voxel 3D texture it should be possible to generate mipmaps and begin cone tracing to simulate global illumination.

Josh

Josh

Voxel Direct Lighting on the GPU

We left off on voxels when I realized the direct lighting needed to be performed on the GPU. So I had to go and implement a new clustered forward renderer before I could do anything else. Well, I did that and now I finally have voxel lighting calculation being performed with the same code that renders lighting. This gives us the data we need to perform cone step tracing for real-time dynamic global illumination. The shadows you see here are calculated using the scene shadowmaps, not by raycasting other voxels: I created a GPU timer to find out how much time the lighting took to process. On the CPU, a similar scene took 368 milliseconds to calculate direct lighting. On the GPU, on integrated graphics, (so I guess it was still the CPU!) this scene took 11.61064 milliseconds to process. With a discrete GPU this difference would increase, a lot. So that's great, and we're now at the third step in the diagram below: Next we will move this data into a downsampled cube texture and start performing the cone step tracing that gives us fast real-time GI.

Josh

Josh

×