Josh

I added a field that lists all the texture file formats used so you can tell at a glance whether the glTF is optimized or not.

Extending the combobox usage to add a field for the mesh material works out better. You can jump to the material, select a new one, remove it, and browse for a file, within a very simple interface.

In practice you don't really want to use .glb with embedded textures because you will want to convert your textures to DDS or Basis. When you save as glTF (text file with an accompanying binary file) you can then publish your game with just the optimized textures and leave the PNG files out of your game.

Ultra workflow is made with great love for you. Using a combobox works really well for the textures, because you can select an embedded texture, browse for a new texture, go to the existing texture, or remove it, without adding a lot of buttons that wouldn't fit.

I think this approach does not work with partial builds. I am seeing some values that appears twice and make no sense. The only thing you can do is declare all your custom event IDs in a single file.

Something I started doing in the code is using strings for properties like this: void ModelEditor::ApplyProperties(shared_ptr<Material> material) { materialproperties->SetText("Material", "Name", material->name); materialproperties->SetValue("Material", "Metalness", material->GetMetalness()); materialproperties->SetValue("Material", "Roughness", material->GetRoughness()); materialproperties->SetState("Material", "Tessellation", material->GetTessellation()); materialproperties->SetValue("Material", "Color", material->GetColor()); materialproperties->SetValue("Material", "Emission", material->GetEmission()); materialproperties->SetState("Material", "Alpha mask", material->GetAlphaMask()); materialproperties->SetState("Material", "Transparent", material->GetTransparent()); materialproperties->SetState("Material", "Shadows", material->GetShadow()); materialproperties->SetState("Material", "Two-sided", not material->GetBackFaceCullMode()); materialproperties->SetValue("Material", "Displacement", material->GetDisplacement().x); materialproperties->SetValue("Material", "Offset", material->GetDisplacement().y); } Instead of declaring a million widget variables I just set values and detect events based on the property name. This cuts the size of the code down by a lot, probably 4x less code. It's very easy to add new properties without modifying any headers. I want user-made extensions to be able to add their own properties and store them in glTF and scene files. My main focus for extensions is editing and storing custom data, and creating custom tools. Not so much concerned with the user's ability to drastically modify the existing features or program layout.

I feel my concern about handling models and materials is resolved nicely.

Question: Do you have a matching depth pass shader you are using for the depth pre-pass? You can disable camera depth pre-pass to test this.

You can modify each limb's orientation, and all the basic entity properties, and they get saved into the model file:

When you select an embedded texture in the tree view the view switches over to the texture, and texture properties are shown. This is much better than what I had before:

In fact, it probably is not necessary to show a list of embedded materials in the file. That would be designed from the programmer's point of view. It could be more relevant to the end user if the material properties are listed on the mesh the material is applied to: I feel like this approach is designed with the end user in mind, instead of worshipping the code/data and treating the end user like garbage.

It might not be hard to export the Blender mass value in the glTF file: https://github.com/KhronosGroup/glTF-Blender-IO

That's a good point. I think we should draw the line at trying to store other entity types in glTF. However, you can set the mass and other properties of a limb and save that in the glTF file, so it does eliminate the need for some simple prefabs. In my experience 90% of prefabs are just a model with a collider and a setting for mass to make the model physically interactive.

A lot of the objects in glTF have an "extras" property in the spec, so for things that you have no intention of usage outside your own app, that's the place to put that information. So the extended properties extension mentioned above is axed.

This can actually get rid of the need for prefabs because every engine property can be embedded in the glTF. However, if the model is resaved in another program those properties will probably be lost.

On the right track now I think:

The best way to describe it is that the tabs make me feel "claustrophobic".

One big difference between glTF and Leadwerks models is all the materials are embedded in a glTF file. You can apply an external material file to it, but its contents will get copied into the glTF, instead of referencing the original material file. So material files are really just for CSG solids.

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.