Josh

Since you are adding a fixed amount to the current frame each time, I think you will need to multiply that by the speed to handle differing framerates.

No pressure, I am just observing its wonder and awe

Actually, you can use Script:Draw if you keep track of the timing. Then the animation only gets updated when the entity is drawn. Ultra is so much simpler in some aspects, it just has Update().

In Ultra Engine, meshes have a name...

I think the one-shot animation issue is something I only discovered in the Ultra code that carried over from Leadwerks. The best thing to do here is control the animation frame by setting it in each Update call. You can set the exact frame time of an animation with Entity::SetAnimationFrame

Why in the world did they design it like this?: "KHR_materials_variants" : { "mappings": [ { "material": 2, "variants": [0, 3], }, { "material": 4, "variants": [1], }, { "material": 5, "variants": [2], }, ], When what they really meant was this: "KHR_materials_variants" : { "mappings": [2, 4, 5, 2] },

It looks like the material variant feature is supported in the official Blender exporter. https://docs.blender.org/manual/en/3.4/addons/import_export/scene_gltf2.html#gltf-variants You might want to look into that and see how it works. And here is a sample model using the feature: https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/MaterialsVariantsShoe It looks like this is the right way to go.

Actually using a 3D texture would be a really bad idea because the mipmaps gets blended together on the Z axis as well, so the separate skin mipmaps would start to bleed into each other...scratch that.

Here's a 3D texture in the editor. You can scroll through the layers and view each slice, so 3D textures aren't (figuratively) opaque any more they used to be. There is some per-object scrolling stuff in there, which could handle both animation and skin switching. However, I might have had to make room to fit a lightmap index in...I will need to revisit this and see what can be done.

There's something like that here: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_variants/README.md I don't know what applications support it or how it would fit into the rendering pipeline yet...

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.