Josh

This shows how an extension can be written that adds custom data to models and other asset files.

I use these for my own programs and they are continually being improved. Go crazy: https://github.com/UltraEngine/Extras/tree/main/Code/C%2B%2B/CustomWidgets These types of things are not built into the default widget set because the behavior of these is not as well-defined as the basic widgets, and different applications may need different features. If the basic widgets are the building blocks, then these are examples of cool things you can make with them.

You can use an enum like this. The only problem is you have to cast your own custom events to the EventId enum. I don't know how to make it so CustomEventId gets automatically cast to EventId: enum CustomEventId { EVENT_RENDER = ALLOCEVENTID, EVENT_PROGRAMSTART = ALLOCEVENTID, EVENT_CONSOLEEXECUTE = ALLOCEVENTID, EVENT_THUMBNAILLOADED = ALLOCEVENTID, EVENT_OBJECTTEMPLATESELECT = ALLOCEVENTID, EVENT_RESETLAYOUT = ALLOCEVENTID };

Ha...this actually increments the value each time it appears in the code. This needs modification to work right... #define EVENT_TEST ALLOCEVENTID void main(int argc, const char* argv[]) { Print(String(EVENT_TEST)); Print(String(EVENT_TEST)); return; } Prints: 10001 10002

Lots of model stats. Some of this is good for quickly spotting problems. For example, if you see a model that uses 100 meshes you probably want to optimize that.

What program are you using?

I will add sliders. Right now I am trying to get the basic structure down. Now using a property grid in the side panel. This lets me fit more stuff into the interface, and it also will make it easy to add new functionality with an extension. For example, you could add a "Quake Texture" group for files loaded from a Quake WAD package, and add special Quake-specific properties to be edited there.

Yeah, the problem is that only enums and defines can be used in switch statements, and even if you use if/else if you also an ugly situation before event IDs are initialized.

This will assign new event Ids at compile time. This avoids the unpleasant situation where you need to assign the value of an event Id at startup, while still ensuring each ID is unique: #define ALLOCEVENTID EventId(10001 + __COUNTER__) #define EVENT_TEST1 ALLOCEVENTID #define EVENT_TEST2 ALLOCEVENTID You can use ALLOCEVENTID anywhere, across different files, so you don't need to worry about making sure your custom event IDs are all different. The Event Ids above can be used in switch statements since they are constant.

I've got embedded assets displaying now. You can open a material or texture that is packed into a model file, view, and modify it. glTF and OBJ supports embedded materials, glTF supports embedded textures, and there are some other obscure formats like Quake MDL that do this as well. Embedded files show their name in square brackets and link back to the file they are embedded in. You can use this to modify materials embedded in a glTF, or use it to extract materials and textures from a model and save them as a standalone file.

glTF model:

I believe most graphics drivers will automatically move textures that haven't been used in a while into "virtual memory", i.e. they write it to a file to unload it from VRAM. There is no good reason to keep texture data in system memory, and Ultra doesn't ever do that. I'll keep this in mind and we can revisit it if it will make an improvement.

RAM or VRAM? Textures should not consume any system memory.

What would that be used for?

Here's another shot showing how you can view any mipmap level.

I have thought of the idea of using the terrain material painting system to apply multiple materials to a mesh. As long as they all use the same shader family it will work. Stay tuned on this...

Dan is infinitely more interesting than its "Problem Glasses AI" counterpart, even if he is trying to destroy humanity.

Animation is done with a 3D texture. When more than one texture layer exists, as in 3D textures and cube maps, a layer selector appears that lets you select the layer to view.

Update:

I wanted to take some time to investigate geospatial features and see if it was possible to use GIS systems with Ultra Engine. My investigations were a success and resulted in some beautiful lunar landscapes in a relatively short period of time in the new game engine. I have plans for this, but nothing I can say anything specific about right now, so now I am working on the editor again. Leadwerks had a very well-defined workflow, which made it simple to use but also somewhat limited. Ultra goes in the opposite direction, with extremely flexible support for plugins and extensions. It's a challenge to keep things together because if you make things to flexible it just turns into indecisiveness, and nothing will ever get finished that way. I think I am finding a good balance or things that should be hard-coded and things that should be configurable. Instead of separate windows for viewing models, textures, and materials, we just have one asset editor window, with tabs for separate items. The texture interface is the simplest and just shows some information about the asset on the left-side panel. When you select the Save as menu item, the save file dialog is automatically populated with information loaded from all the plugins the engine has loaded. You can add support for new image formats at any time just by dropping a plugin in the right folder. In fact, the only hard-coded format in the list is DDS. You can save to an image format, or to the more advanced DDS and KTX2 formats, which include mipmaps and other features. Even more impressive is the ability to load Leadwerks texture files (TEX) and save them directly into DDS format in their original pixel format, with no loss of image quality. Here we have a Leadwerks texture that uses DXT1 compression, converted to DDS without recompressing the pixels: There are several tricks to make the new editor start up as fast as possible. One of these is that the various windows the editor uses don't actually get created until the first time they are used. This saves a little bit of time to give the application a snappier feel at startup. I hope the end result will provide a very intuitive workflow like the Leadwerks editor has, with enough power and flexibility to make the editor into a living growing platform with many people adding new capabilities for you to use. I think this is actually my favorite stuff to work on because this is where all the technology is exposed to you, the end user, and I get to carefully hand-craft an interface that makes you feel happy when you use it.

Are you saying that marching cubes creates some "stair-stepping" due to the fact the minimum change in elevation is equal to the voxel size, so the minimum change in height is equal to the distance between terrain points?