Josh

What engine are you using?

Dropbox or Google drive?

The world does not store a list of entities, but the map object that is returned by LoadMap does.

The map loaded fine and only contains a terrain. I will need the model files and textures in order to test this. Loading material "Models/!SciFiAssetsPack/Martian surface - rocky area/Textures/Stone Ground 1.mat" Error: Failed to load material "Models/!SciFiAssetsPack/Martian surface - rocky area/Textures/Stone Ground 1.mat". Loading material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_00.mat" Error: Failed to load material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_00.mat". Loading material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_01.mat" Error: Failed to load material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_01.mat". Loading material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_02.mat" Error: Failed to load material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_02.mat". Loading material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_03.mat" Error: Failed to load material "Models/!SciFiAssetsPack/Lunar Landscape 3D/Resources/Textures/Ground_03.mat". Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/Materials/Textures/_FX/StarinSpace.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Platerform_Metal_02.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Platerform_Metal_01.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Pipe_Tube_01.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Pipe_Bent_01.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Platerform_Metal_03.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Platerform_Metal_03.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/_Creepy_Cat/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Platerform_Metal_03.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Container_02.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crane_Base_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crystal_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crystal_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crystal_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crystal_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Crystal_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Desktop_Part_01.mdl" Error: Failed to load model "Models/gltf_models/!SciFiAssetsPack/_Creepy_Cat/_3D Scifi Kit Vol 3/Meshes/3DMDL/Desktop_Computer_01.mdl" Error: Failed to load model "Models/!SciFiAssetsPack/kb3d_missiontominerva/Models/untitled.glb" Error: Failed to load model "Models/!SciFiAssetsPack/Imagine Life/Scifi Crate/Models/ScifiCrate.obj" Error: Failed to load model "Models/!SciFiAssetsPack/kb3d_missiontominerva/Models/LandingPad.glb" Error: Failed to load model "Models/!SciFiAssetsPack/kb3d_missiontominerva/Models/TheOliverSudden.glb"

Ah, okay, so this is to pack files into a single EXE? That makes some sense...

This is a detail of Lua. I chose not to modify the behavior of the built-in functions, even if I disagree with their design. Basicaly the lua command print() does not flush the stream, so the text doesn't actually appear until the stream is flushed, typically at the end of the program.

Also, I should mention the LOAD_QUIET load flag will cause asset loading messages to not print. Generally, these get passed along when an auxillary asset is loaded, so if you pass LOAD_QUIET to LoadModel it won't print texture loading messages.

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.

Have you tried this approach? It's probably more advanced than what I am doing above: https://github.com/graphitemaster/incbin

The standalone version of Ultra Engine can now be ordered with immediate delivery of your new software: https://www.ultraengine.com/get There is an option for a perpetual license or subscription.

Occasionally I have seen the preview app hang, although it has not occurred in the more recent builds for me (the last couple of weeks). It might be an improvement if the preview generator gets launched to do a folder at a time. Right now it communicates with the editor back and forth via the CLI.

Default channel is renamed to 0.9.0. Client app is updated with change to EULA. $100K limit is removed and replaced with 20 person "total workforce" limit. I think this will be better for everyone and will not scare people.

The thought has occurred to me, but what is the purpose of loading plugins from memory? Here is something I wrote a while back that might be useful: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto stream = ReadFile("Source/IncBinFiles.cpp"); std::vector<String> sarr; bool pause = false; while (!stream->EOF()) { auto s = stream->ReadLine(); if (s.Trim() == "//begin incbin") pause = true; if (!pause) sarr.push_back(s); if (s.Trim() == "//end incbin") { sarr.push_back("//begin incbin"); auto j3 = LoadJSON("Source/IncBin.json"); if (j3["IncBinFiles"].is_array()) { for (int n = 0; n < j3["IncBinFiles"].size(); ++n) { auto bin = ReadFile(std::string(j3["IncBinFiles"][n])); if (bin == NULL) { continue; } sarr.push_back(" if (rpath == RealPath(\""+std::string(j3["IncBinFiles"][n])+"\"))"); sarr.push_back(" {"); uint64_t sz = Ceil(float(bin->GetSize()) / 8.0f) * 8; String s = " static const std::array<uint64_t, " + String(sz/8) + "> data = {"; s.reserve(bin->GetSize() * 4 + s.size()); auto buf = CreateBuffer(sz); bin->Read(buf->Data(), bin->GetSize()); uint64_t v; for (uint64_t n = 0; n < buf->GetSize() / 8; ++n) { memcpy(&v, buf->Data() + (n*8), 8); if (n > 0) s += ","; //s += "UINT64_C(" + String(v) + ")"; s += Hex(v) + "ULL"; } //while (!bin->EOF()) //{ // s += "," + String(int(bin->ReadByte())); //} s += " };"; sarr.push_back(s); sarr.push_back(" auto buffer = CreateBuffer(" +String(bin->GetSize())+ "); "); sarr.push_back(" buffer->Poke(0,(const char*)data.data(),"+String(bin->GetSize())+");"); sarr.push_back(" return CreateBufferStream(buffer);"); sarr.push_back(" }"); } } sarr.push_back("//end incbin"); pause = false; } } stream->Close(); stream = WriteFile("Source/IncBinFiles.cpp"); for (auto s : sarr) { stream->WriteLine(s); } stream->Close(); return 0; }

Wow, this is so so good. Can it convert a folder of panoramas to environment maps? This will convert a whole folder of HDRIs. This saves so much time: UltraPBRTextureGen.exe -b -p -d ./hdris FYI, with big textures and a 1024 sample count, some graphics cards can time out on that IBL shader and produce the VK_DEVICE_LOST error: https://github.com/KhronosGroup/glTF-IBL-Sampler/issues/8 I remember setting some OS setting or reg key to allow a longer timeout with the Vulkan driver, when I was using the Khronos app.

Sorry, I should have mentioned that event.text will contain the printed text, so you can use that to filter which messages get printed and which get skipped. Return true and the message will go into the Print routine.

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.

Copied current build on /dev to new default channel /1.0.0.

Vulkan raytracing extension, works with all vendors: https://www.khronos.org/blog/ray-tracing-in-vulkan

1. Ambient occlusion maps are supported in materials, and in the glTF format. SSAO can also be used. 2. I would expect it to look exactly the same in Ultra. 3D scanned models always look good.

Paste in the console: function hook() return false end ListenEvent(EVENT_PRINT, nil, hook)

Hi, I am from the future and I have your new game engine:

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.

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: 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! 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. 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. 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. 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!

I think I have a solution. In the terrain loading code, if the y component of the terrain scale is not one, then it gets set to one and every terrain point's height gets multiplied by that scale value.

Fixed!