Josh

Here's an idea. Add a property grid in the bottom half of the hierarchy panel. When an embedded material or texture is selected, show its properties there where you can edit them and see the effect on the model.

Here's a revision. The relative file path is shown in the window titlebar. I also made the menu and status bars span the entire window. This wastes some vertical space the side panel was using before, but the lines looks a lot cleaner this way.

I'm thinking the Leadwerks way is probably perfect. It shows everything at once, and it prevents you from opening too many files at once.

Something like this might be better for models with embedded assets, where you can select a material or texture in the tree on the left, and then the properties on the right show the item properties. If you use tabs for a window like this, then you end up with something that looks kind of odd when a texture or material is selected. Since there is no need for any left-side pane for these assets, the window looks quite wide for them.

I uploaded another build that opens each asset in its own window, called "UltraEngine_b.exe", so you can run both and compare. It would be better if a new window was offset from the previous one a little bit, instead of being in the same default position/size but that can be added later. Right now I just want to get this out to you as fast as possible so your input can help steer the design.

Here we have three items opened with the tabs removed so each asset opens in its own window. I also replaced the window text with the name of the file:

Here's a quick test. I opened a model in one window and two textures in the other window. Not sure about the tabs, they make things confused and complicated...

Here's a mockup. I don't know if I like it. When you open a material's texture, what would happen? Would it open on the left panel? What if you change a texture setting and want to see the effect on the model? There are some other options: Make each asset open in its own window (one Asset Editor window for each opened file) Make a model editor, material editor, and texture editor window like in Leadwerks Don't worry about this and leave the behavior as-is Leadwerks, for comparison. What I like about this is you can instantly see all the properties for every file at a glance. If you focus on one of these files, you find what you are looking for with a picture, instead of searching for the right file name in a tab.

So the walls you are creating, they are from a pre-formed piece segment, right?

The one part of the new editor I am experiencing some friction is when I adjust material settings and want to see their effect on a model that uses that material. Switching back and forth between tabs each time you change something is tedious. Leadwerks avoided this problem by opening textures, materials, and models in separate editor interfaces that were designed differently from one another, and Ultra is using a single interface with tabs. Do you have any ideas of how to get around this without making the interface confusing? I'd rather not have a bunch of options like "Open asset in new window" / "Open in new tab" because it forces the user to craft their own UI. I'd rather things just work simply and intuitively by default, without the user even noticing. Do you have any other suggestions to improve the workflow so far?

This is the code I used to make the tessellation comparison screenshot: #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->SetPosition(0, 1.5, 0); camera->SetRotation(90, 0, 0); camera->SetWireframe(true); world->SetAmbientLight(1); //Create a box auto p1 = CreatePlane(world, 1, 1, 1, 1, MESH_TRIANGLES); p1->SetPosition(-0.75, 0, 0); auto p2 = CreatePlane(world, 1, 1, 1, 1, MESH_QUADS); p2->SetPosition(0.75, 0, 0); auto mtl = CreateMaterial(); mtl->SetTessellation(true); p1->SetMaterial(mtl); p2->SetMaterial(mtl); camera->SetTessellation(20); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyDown(KEY_UP)) camera->Move(0, 0, 0.01); if (window->KeyDown(KEY_DOWN)) camera->Move(0, 0, -0.01); world->Update(); world->Render(framebuffer); } return 0; }

Updated 1.0.2 First build of "Asset Explorer", the precursor to the Ultra Engine editor is up. Run "UltraEngine.exe" in the client install directory to run it. The first thing you should do is select the File > Open Folder menu item and select one of your Ultra Engine project folders. The rest should be pretty self-explanatory, especially if you have used Leadwerks before. It's still the early days but the app is already very useful for file format conversion and fine-tuning of textures. Please let me know what you think, especially regarding the workflow and design choices.

I'm going to create a formal spec for the quads extension: https://github.com/UltraEngine/glTF/blob/main/extensions/2.0/Vendor/ULTRA_primitive_quads/README.md

Vulkan accepts quads and ngons but in wireframe they will appear like triangles.

There is also an unofficial FB_ngon_encoding extension but I don't know its current status: https://github.com/facebookincubator/FBX2glTF/issues/300

As I have explained before, I plan for Ultra Engine to use glTF for our main 3D model file format, so that your final game models can be easily loaded back into a modeling program for editing whenever you need. glTF supports a lot of useful features and is widely supported, but there are a few missing pieces of information I need to add into it. Fortunately, this JSON-based file format has a mechanism for extensions that add new features and data to the format. In this article I will describe the custom extensions I am adding for Ultra Engine. ULTRA_triangle_quads All glTF models are triangle meshes, but we want to support quad meshes primarily because its better for tessellation. This extension gets added to the primitives block. If the "quads" value is set to true, this indicates that the triangle indices are stored in a manner such that the first four indices of every six indices form a quad: "extensions": { "ULTRA_triangle_quads": { "quads": true } } There is no other glTF extension for quads, and so there is no way to export a glTF quad mesh from any modeling program. To get quad meshes into Ultra Engine you can load an OBJ file and then resave it as glTF. Here is a glTF file using quads that was created this way. You can see the tessellation creates an even distribution of polygons: For comparison, here is the same mesh saved as triangles and tessellated. The long thin triangles result in a very uneven distribution of polygons. Not good! The mesh still stores triangle data so the file can be loaded back into a 3D modeling program without any issues. Here is another comparison that shows how triangle (on the left) and quads (on the right) tessellate: ULTRA_material_displacement This extension adds displacement maps to glTF materials, in a manner that is consistent with how other textures are stored: "ULTRA_material_displacement": { "displacementTexture": { "index": 3, "offset": -0.035, "strength": 0.05 } } The extension indicates a texture index, a maximum displacement value in meters, and a uniform offset, also in meters. This can be used to store material displacement data for tessellation or parallax mapping. Here is a model loaded straight from a glTF file with displacement info and tessellation: If the file is loaded in other programs, the displacement info will just be skipped. ULTRA_vertex_displacement Our game engine uses a per-vertex displacement factor to control how displacement maps affect geometry. This extension adds an extra attribute into the primitives structure to store these values: "primitives": [ { "attributes": { "NORMAL": 1, "POSITION": 0, "TEXCOORD_0": 2 }, "indices": 3, "material": 0, "mode": 4, "extensions": { "ULTRA_vertex_displacement": { "DISPLACEMENT": 7 } } } } This can be used to prevent cracks from appearing at texcoord seams. Here you can see the displacement value being loaded back from a glTF file it has been saved into. I'm using the vertex color to visually verify that it's working right: ULTRA_extended_material This extension adds other custom parameters that Ultra Engine uses. glTF handles almost everything we want to do, and there are just a few settings to add. Since the Ultra Engine material format is JSON-based, it's easy to just insert the extra parameters into the glTF like so: "ULTRA_extended_material": { "shaderFamily": "PBR", "shadow": true, "tessellation": true } In reality I do not feel that this extension is very well-defined and do not expect it to see any adoption outside of Ultra Engine. I made the displacement parameters a separate extension because they are well-defined, and there might be an opportunity to work with other application developers using that extension. Here we can see the per-material shadow property is disabled when it is loaded from the glTF: For comparison, here is what the default setting looks like: These extensions are simply meant to add special information that Ultra Engine uses into the glTF format. I do not currently have plans to try to get other developers to adopt my standards. I just want to add the extra information that our game engine needs, while also ensuring compatibility with the rest of the glTF ecosystem. If you are writing a glTF importer or exporter and would like to work together to improve the compatibility of our applications, let me know! I used the Rock Moss Set 02 model pack from Polyhaven in this article.

Yes, I hope so.

Yes. Ultra is currently using Newton 3. Newton 4 is better at handling vehicles. I have it partially implemented, and I plan to make it so you can select the physics engine when the world is created.

I have two goals for the art pipeline in the new game engine. Eliminate one-way 3D model conversions. Use the same game asset files on all platforms. In Leadwerks, 3D models get converted into the proprietary MDL format. Although the format is pretty straightforward and simple, there is no widespread support for loading it back into 3D modeling programs. This means you need to keep a copy of your 3D model in FBX and MDL format. You may possibly want to keep an additional file for the modeling program it was made in, such as 3D Studio Max MAX files. I wanted to simplify this by relying on the widely-support glTF file format, which can be used for final game-ready models, but can still easily loaded back into Blender or another program. Texture Compression Texture compression is where this all gets a lot more tricky. Texture compression is an important technique that can reduce video memory usage to about 25% what it would be otherwise. When texture compression is used games run faster, load faster, and look better because they can use higher resolution images. There are two problems with texture compression. Supported texture compression methods vary wildly across PC and mobile platforms. Many 3D modeling programs do not support modern texture compression formats. On the PC, BC7 is the best compression format to use for most images. BC5 is a two-channel format appropriate for normal maps, with Z reconstruction in the shader. BC6H can be used to compress HDR RGB images (mostly skyboxes). BC4 is a single-channel compressed format that is rarely used but could be useful for some special cases. The older DXTC formats should no longer be used, as they have worse artifacts with the same data size. Here are a few programs that do not support the newer BC formats, even though they are the standard for modern games: Windows Explorer Blender Microsoft 3D Object Viewer Now, the glTF model format does not actually support DDS format textures at all. The MSFT_texture_dds extension adds support for this by adding an extra image source into the file. glTF loaders that support this extension can load the DDS files, while programs that do not recognize this extension will ignore it and load the original PNG or JPEG files: "textures": [ { "source": 0, "extensions": { "MSFT_texture_dds": { "source": 1 } } } ], "images": [ { "uri": "defaultTexture.png" }, { "uri": "DDSTexture.dds" } ] I don't know any software that supports this extension except Ultra Engine. Even Microsoft's own 3D Object Viewer app does not support DDS files. The Ultra Engine editor has a feature that allows you to convert a model's textures to DDS. This will resave all textures in DDS format, and change the model materials to point to the DDS files instead of the original format the model uses (probably PNG): When a glTF file is saved after this step, the resulting glTF will keep copies of both the original PNG and the saved DDS files. The resulting glTF file can be loaded in Ultra Engine ready to use in your game, with DDS files applied, but it can still be loaded in programs that do not support DDS files, and the original PNG files will be used instead: The same model can be loaded back into Blender in case any changes need to be made. If you resave it, the references to the DDS images will be lost, so just repeat the DDS conversion step in the Ultra Engine to finalize the updated version of your model. To cut down on the size of your game files, you can just skip PNG files in the final packaging step so only DDS files are included. Basis Universal We still have to deal with the issue of hardware support for different codecs. This table from Unity's documentation shows the problem clearly: We do want to support some mobile-based VR platforms, so this is something that needs to be considered now. Basis Universal is a library from the author of Crunch that solves this problem by introducing a platform-agnostic intermediate compressed format that can be quickly transcoded into various texture compression formats, without going through a slow decompression and recompression step. We can generate Basis files in the Ultra Engine editor just like we did for DDS: There is a glTF extension that supports basis textures, so glTF models can be saved that reference the Basis files. The basis textures are stored in the glTF file the same way the DDS extension works: "textures": [ { "source": 0, "extensions": { "KHR_texture_basisu": { "source": 1 } } } ], "images": [ { "mimeType": "image/png", "bufferView": 1 }, { "mimeType": "image/ktx2", "bufferView": 2 } ] The resulting glTF files can be loaded as game-ready models with compressed textures on PC or mobile platforms, and can still be loaded back into Blender or another 3D modeling program. We don't have to store different copies of our textures in different compression formats or go through a slow conversion step when publishing the game to other platforms. If your game is only intended to run on PC platforms, then DDS is the simplest path to take, but if you plan to support mobile-based VR devices in the future then Basis solves that problem nicely. Here is our revised table: I was also working with the KTX2 format for a while, but I ended up only using it for its support for Basis compression. DDS and Basis cover all your needs and are more widely supported. Basis also supports a very lossy but efficient ETC1S method which is similar to Crunch, as well as uncompressed texture data, but in my opinion the one purpose for the Basis format is its UASTC format. This article features the lantern sample glTF model from Microsoft.

Updated 1.0.2 Added Asset::GetPackage method Added Asset::packagepath member Fixed problems in OBJ loader and saver OBJ and glTF saving will now reconstruct Z component of converted BC5 textures OBJ loader will now create fewer vertices Added Stream::Align Fixed glTF byteOffset validation error Fixed reversed vertex X position in glTF export Added support for Microsoft DDS extension in glTF export Removed KTX2 plugin Added Basis Universal plugin Added support for KHR_texture_basisu in glTF loader/saver Fixed glTF save not writing object positions Fixed glTF save not including emissive textures Added support for our own ULTRA_triangle_quads extension for packing quad meshes in glTF files Fixed problems with Model::Collapse method Fixed TEXTURE_RG read/write/convert Added some missing shader combos when tessellation is used

Will be fixed in the next build...

camera->SetViewport(200, 0, framebuffer->size.x - 200, framebuffer->size.y); If you call that code again after the new framebuffer is created, it works perfectly.

Confirmed...