Jump to content

Finishing Touches


Josh

3,591 views

 Share

At long last, the engine that felt like it would never be done is here. This is all the result of an idea I had and wanted to put to the test. Of course I never anticipated it was possible to deliver a 10x improvement in rendering performance, but here we are with the benchmarks to prove it.

Research & Development

The last four years of research and development were an opportunity to rethink and redesign what a game engine should be. Along the way there were a few ideas I had that turned out to be not that great of an idea in practice:

Variance shadow maps: Although I love the look of these under very controlled settings, the technique has extremely bad artifacts that can never be fixed. Depth shadow maps really are the best approach to texture-based shadows. They are also extremely slow to render shadow updates. I would like to see some better hardware filtering options in the future, though.

Voxel-based indirect lighting: Compelling in theory but extremely messy in practice. I learned a lot and this prompted me to integrate compute shaders into the engine, but ultimately the results I got weren't compelling enough to turn into a finished product. Given the problems everyone else has with this approach, I think it makes sense to focus on hardware raytracing as the next step up in lighting.

Novel entity component system: My idea was to make it so when you called a component method, all the components that had that method would get called. I had some complicated Lua code set up that handled this, and early builds of Ultra used a C++ preprocessor that analyzed header files and created some complicated wrappers to make C++ work in roughly the same way. Ultimately I decided the confusion wasn't worth the questionable benefit and I implemented a conventional multi-component system like everyone had asked for, without any preprocessor.

Tabbed Asset Editor: Another thing that sounded good in theory but was not great in practice was to use a single asset editor window with tabs for the different opened files. All it took was a day of using this to realize how much better it was to open each item in its own window. Hunting and clicking file names in tabs is just not fun. I get claustrophobic just looking at this:

image.thumb.jpeg.d932da0b6b9a3c0b57c14a516c3bb2c6.jpeg

The Results

Besides the performance, here are the things that I think turned out better than I imagined:

glTF Integration: Khronos glTF has proven to be a wonderful workflow, and eliminates any "black box" file formats for 3D content. Your game-ready files can always be pulled back into your modeling program, edited, and saved, with no need for secretive conversion pipelines. A wide variety of game-ready content is available for you to use with Ultra, so I am expecting to see no more programmer art!

large.37753377_10156301149921183_2048314579712212992_n.jpg.9b112ca254b8b2484a85731d4f67110c.jpg.34819a46f59731552d7b61c8779a07fd.thumb.jpg.53d28eb5a1208a0716bf92d51502d992.jpg

Physically-based Rendering: This aligns closely with glTF integration because the file format includes a well-defined PBR materials system. The secret to good PBR is to have good imagery for reflections. To achieve this, I put a lot of work into the volumetric environment probes system that first appeared in Leadwerks. Probe volumes can now be drawn like a brush object for easier creation and precise sizing in the editor. A configurable fade distance for each edge lets you control how probes blend together. Probes also incorporate the sky lighting so you can have seamless transitions between bright outdoor areas and dark enclosed spaces.

image.thumb.jpeg.3f3eb06b2bae8092af8baa05f692aa01.jpeg

Lua Integration: The VSCode Lua debugger turns Lua into a first-class game programming language and is a dream to work with. The editor scripting integration is in my opinion the best scripting integration of any 3D program I've ever seen. You can access the entire engine API from within editor scripts to add new functionality or modify the program. Additional documentation for the editor's innards will arrive in the coming days.

Ultra GUI: This took a lot of time but having control over every pixel and event made it worthwhile. Taking control of the user experience by writing my own GUI was one of the best decisions I made. The interface doubles up as the editor's own UI drawn using GDI+ and the in-game UI rendered with Vulkan.

ss_f0a2b0e8b1f06ac5cc8997a00b6948162360ec60.1920x1080.thumb.jpg.ce6b85cb154644fb47b7a8cde104a98e.jpg

C++ API: The most significant change is the user of shared pointers, which forever eliminate the problems with uninitialized and invalid pointers games were prone to as they grew more complex. Additionally, the API is generally better thought out and consistent than what we had in Leadwerks.

Terrain: You wanted more terrain material layers, so you got them. Up to 256, in fact, with fast performance. You can create multiple terrains, position, rotate, and scale them, and even create non-square terrains to fill in any area.

image.thumb.jpeg.77815c2d6147071301954a52a785c063.jpeg

 

Player Physics: Yes, you can crouch now. ;)

Pathfinding: It's dynamic and you can create multiple navmeshes, for different areas or differently sized characters. Pathfinding and physics are now decoupled so you can have armies of characters that only use the pathfinding system for movement.

3D Brush Editing: I was not planning on this feature until the last minute, but you can can create, move, scale, rotate, and shear brushes in any viewport, including the 3D view. the long-asked-for vertex tool is included as well as a face tool for adjusting texture mapping and geometry.

Last but not least, the engine's multithreaded design is crazy advanced! Your game code runs on its own thread, giving you a full 16 milliseconds to operate without slowing down the renderer. Physics, pathfinding, animation, rendering, and culling all operate on separate threads. It's an amazing feat in engineering that was only possible because I had seen all the bottlenecks people could create in Leadwerks, so I could plan a way around them when designing Ultra.

Early Access

The 1.0 release will be marked "Early Access" because there are still a few extra features to add, and we will have a period where changes to the workflow can still be considered based on user feedback. Once decals, particle emitters, VR support, flowgraphs, and brush smooth groups are added, that will be considered version 1.1 (no "early access"). So there will still be a few months of time where I can revise any parts of the workflow you think can be improved. There are also still some compatibility issues with AMD cards that are being resolved, so please be aware of that.

A big thanks goes out to all the testers who helped me smooth things out before the release. The good times are finally here!

  • Like 7
  • Thanks 1
 Share

14 Comments


Recommended Comments

Congrats. Looking forward to get and play with Ultra.
The new features sounds amazing. I'm also glad to see that flowgraphs will come back. 


Some questions, I hope this is the right place to ask :) 

Are you planning to bring back the water system?

Also, If I preorder I get access to Ultra right way or I have to wait for the official release on steam?

 

Link to comment
6 minutes ago, DoomSlayer said:

Are you planning to bring back the water system?

Also, If I preorder I get access to Ultra right way or I have to wait for the official release on steam?

1. In Ultra, every surface is reflective, so there is actually no need for a special water surface (AAA games nowadays are taking the same approach, see Phantom Liberty). Water consists of two things:

  • An animated or scrolling texture
  • Some kind of buoyancy physics volume

I do not have the second part set up yet, but plan to do so. Also, we can probably do something interesting with the player physics to allow swimming.

2. The standalone version will be available before the Steam build is.

  • Like 1
Link to comment
Quote

I think it makes sense to focus on hardware raytracing as the next step up in lighting.

So it will be NVIDIA RTX that games using nowadays?

Link to comment
5 hours ago, Josh said:

1. In Ultra, every surface is reflective, so there is actually no need for a special water surface (AAA games nowadays are taking the same approach, see Phantom Liberty). Water consists of two things:

  • An animated or scrolling texture
  • Some kind of buoyancy physics volume

I do not have the second part set up yet, but plan to do so. Also, we can probably do something interesting with the player physics to allow swimming.

This is true. It is very easy to modify the current pbr shaders into a new shader family to achieve a water effect. But therefore a few other things need to be (re)added:

  • animated textures (currently not included, but can be achieved by creating a new shader family with a modified fragment.glsl file) 
  • adding some advanced material options:
    • Refractionindex (is already in there, but not used)
    • Thickness (also included, but not used)
    • a custom alpha calculation method based on visibility

If this is all included, i can only think of one case, where a special surface is needed (mainly for performance) is the usage of oceans. 

 

  • Upvote 2
Link to comment
11 hours ago, Dreikblack said:

So it will be NVIDIA RTX that games using nowadays?

Starfield just released without RTX because they realize it's just a scam by nvidia to sell you useless expensive hardware.

Link to comment

What a wild six years this has been. I remember the first build being a. bunch of boxes in a blue void and look where it is now. Congrats on the release and it should only get better from here. Thank you for having me as part of the process through out the years! 

Now I'm gonna harass tell all my friends about how they should be using this instead of whatever they are currently using. :D 

  • Like 1
Link to comment

Can you please answer me:
1. Am I correct in understanding that you are planning to release a version called 1.0, which will have a minimally functioning engine, but modules for developing flowgraph scenes and particle emitters will be unavailable?
2. Will 1.0 also be released on Steam, or will it be an exclusive release for the website?

Link to comment
8 minutes ago, ERKGames said:

Can you please answer me:
1. Am I correct in understanding that you are planning to release a version called 1.0, which will have a minimally functioning engine, but modules for developing flowgraph scenes and particle emitters will be unavailable?
2. Will 1.0 also be released on Steam, or will it be an exclusive release for the website?

1.0 is considered "Early Access" and does not include the following:

  • Flowgraph editor
  • Decals
  • Particle emitters
  • Brush smooth groups
  • Other various editor enhancements

Additionally, AMD GPUs will display visual artifacts in the current build.

Releasing now as "Early Access" is good because there is a ton of new things for people to learn, and I want additional user feedback on the design of some of the remaining items. People can only make good suggestions if they understand how the core engine works.

Version 1.1 will be a free update to finish out these items, and at that point the software will no longer be considered "Early Access". I think March 2024 is a comfortable deadline to finalize that, with updates along the way on the dev branch.

The standalone version of the software will first be available on the website here, followed by a release on Steam in early November.

Link to comment

I'm not going to say anything bad right now, please understand my words correctly. BUT it seems to us that your current release strategy is wrong a bit. I don't think it needs to be clarified that an early release cannot be called 1.0 and not have at least minimally functioning modules for developing something not only based on code, but also on GUI and game levels, especially after more than four years of development. Especially considering the emphasis on the new interface that you are promoting. And especially considering that the Leadwerks engine was capable (and quite capable) of doing all this, and it was an old engine of the 7th generation of game consoles. So how is this radically different from another intermediate update for monthly subscribers? And who's the potential buyer of the new engine, if even the old engine, which has been neglected for several years, is hardly known outside of this forum? People simply won't accept an unfinished product, and on platforms like Steam, it's important to show the best right from the start of sales, even if it's early access. The strategy you have mentioned will mislead people, and if they buy Ultra, they will definitely refund it within half an hour. Remember the experience with Ultra App Kit, which had serious shortcomings from the start and even with the updates made, it was not accepted by the Steam community: it seems to me that you gained absolutely nothing from its publication and mixed audience reaction, and now the situation may repeat itself with an even more negative reaction, including from the old audience, do you understand what I mean? It won't be interesting to new users in its current form, and the old audience, includes us, will remain dissatisfied that they were made to wait for almost another year.

By the way, you mentioned March 2024. That's a long time, considering that everything can change at any moment. With the level of functionality that you propose for 1.0, even our team that develops and releases games on Leadwerks (and respects you and your team), won't be able to switch to the new engine before that date (we planned to do it as soon as possible) - because it turns out that we won't be able to continue working on the game without at least having the flowgraph editor! And a Vulkan benchmark with a new interface is unlikely to help us create something worthy of audience attention. But... Apparently, there's nothing we can do about it 🌝

Alright, then I have one last question: do you plan to follow your previously announced plans and release a major update for Leadwerks? At least before March 2024, if the answer is "yes". Because this engine REALLY needs an update, and we have already submitted the main issues related to its functioning in a bug report about a year ago:


And by the way: Leadwerks, if it had a completed form, would be perfect for legacy development and would be relevant in this niche for many years to come. It has amazing features and compromised system requirements. Some of us are working on projects on older laptops, and it's still quite usable, if not for the annoying problems described by us and many others in the bug report threads. It seems to us that it's too early to write it off and radically replace it with something that isn't yet ready - it should at least be brought to working condition before that, because at least it ALREADY has a fan base.

 

Link to comment

 

The versioning is just an arbitrary number. Maybe you are right that making the final non-EA release "1.0" makes more sense. I don't have any strong opinion on this.

This is the first release of the visual editor. This allows you to set up a scene, add components to objects, and adjust properties, which makes development much easier. The programming SDK may have been premature, but no harm done. The editor is very nearly complete, with a lot of features that Leadwerks lacks, so it makes sense to get it in peoples' hands as early as possible so they can start learning the new workflow.

I would estimate most of this stuff will be done by the end of the year, but like any engineer I like to add extra padding to my estimates. The AMD issues will likely be the slowest step. If there is indeed a driver bug it will probably take a couple months before the next driver comes out. It might actually make sense to prioritize the flowgraph editor, since it has the most "downstream" effects on the workflow, whereas with something like decals there's no big questions about how they should work..

Although no definite plans for Leadwerks have been announced, I have some things I would like to do with it. I don't know how much time I will have for it, but I do know my workload has gotten much much easier as of late. All the really difficult work is done and none of my remaining tasks are super difficult, so it is possible I may have some time for this in the near future.

I understand you have put a significant amount of effort into building games on Leadwerks. Although Ultra can load Leadwerks assets, there are breaking API changes and the concepts don't always translate across with 100% accuracy. For example, Ultra supports multiple components per entity and Leadwerks just supports one. In order to overcome some of the limitations of the older system, breaking changes were necessary.

However, Ultra offers an extreme performance advantage that in my view justifies all the difficulty of developing or learning a new engine. The engine scales extremely well as you add more and more content to your game. Rather than trying to make the easiest to learn engine, I am trying to make the one that is most worth learning. It took a huge amount of work to develop this system, and Vulkan made it even more difficult, but I think the payoff is worthwhile and the people who have had the most experience with Ultra so far seem to agree with me that this was the right approach.

Link to comment

Starting on the flowgraph implementation. I'm going to try to have this done by Monday. This is rendered in GDI+.

Untitled.thumb.png.bf1e0524d7761b562ba37816fef7a0d9.png

Zoom also works, without much effort:

zoom.thumb.png.d4ff642adb720ba217793c5d8b97e7fa.png

I'm designing it as a custom widget I will post the source to, so it can be reused for other purposes if desired.

I didn't mention it but segmented line widget blocks exist in Ultra now. ;)

  • Like 6
  • Thanks 1
Link to comment
Guest
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.

×
×
  • Create New...