Release Notes

[Josh]

1.0.2

• UPX post-build process is added back into new Visual Studio projects, but this time it's done correctly.
  • Command: "$(UltraEnginePath)\Tools\upx.exe" "$(TargetName)$(TargetExt)"
  • Disabled by default, can be easily enabled in project settings (release mode only)
• Newton debug DLLs are eliminated. I'm using a static library, so Newton can still be debugged externally. DLLs are now only used for optional plugins and Lua modules.
• Resource files moved to /Source to try to keep as much garbage as possible out of the main folder.
• Removed Warn() function.
• Removed Microsecs() function.

[Josh]

1.0.2

I found a lot of settings to move all the garbage files VS creates into the hidden .vs folder. This is what a project looks like now, after compiling and closing visual studio. The only file it save in your game folder is the vxproj.user file, which I could not find a way to eliminate:

[Josh]

1.0.2

• "require" will now load scripts relative to "./Scripts" and DLLs relative to "./Modules". Script structure in the game template is changed.
• C++ interpreter for Lua code is updated here: https://github.com/UltraEngine/Documentation/blob/master/CPP/Scripting.md#c-interpreter-for-lua
• socket/core.dll now just renamed to "luasocket.dll"
• Compiled .luac files can now be run with RunScript().

[Josh]

1.0.2

• Component connections are added, with arguments. Arguments won't work in Lua yet, but connections should.
• Added LuaGetState

[Josh]

1.0.2

• Added Component:Connect in Lua
• Integrated nlohmann::json into Lua(!). Json structures can be easily accessed by both C++ and Lua, and changes in one environment are instantly available in the other.
• Removed the ability to add a component from a table, as this was causing problems. Components must be modules.

[Josh]

1.0.2

Added C++ control over Lua with new functions and methods:

• SetGlobal
• GetGlobal
• CallFunction
• CallMethod
• Object::SetField
• Object::GetField

 

[Josh]

1.0.2

Removed nlohmann::json from Lua due to debugger problem here: https://github.com/devcat-studio/VSCodeLuaDebug/issues/30

I like the way it works but I may need to rethink the implementation.

[Josh]

1.0.2

Added my own STL-implementation of Lua tables in C++. C++ tables can be accessed by Lua but don't use Lua code to operate. This provides similar functionality to my earlier attempt to integrate nlohmann::json into Lua, without crashing the debugger.

[Josh]

1.0.2

• Updated with what I think is the finished table++ code. Works with ipairs() now. The Lua command for a C++ table is now ctable().
• Experimental Lua pre-processor feature uses [] to create a C++ table, like how {} creates a Lua table:

b = []
b[1] = 1
b[2] = 2
b[3] = 3

for k, v in ipairs(b) do
	Print(v)
end

 

[Josh]

1.0.2

Update to fix this bug in VS Code Lia debugger.

[Josh]

1.0.2

• Entity and materials property field now using tables instead of nlohmann::json object.
• glTF files will now save and load user properties.
• [] symbol and ctable() Lua function removed. There is no reason to ever create C++ tables in Lua. They will only be used as members of a class that has already been declared in C++ and exposed to Lua.
• You can now assign a Lua table to a C++ table, and it will just copy the contents.

C++ example

auto box = CreateBox(NULL);
box->properties["health"] = 100;
box->Save(GetPath(PATH_DESKTOP) + "/box.gltf");

auto box2 = LoadModel(NULL, GetPath(PATH_DESKTOP) + "/box.gltf");
Print(box2->properties["health"]);

Lua example

local box = CreateBox(nil)
box.properties.health = 100
box:Save(GetPath(PATH_DESKTOP).."/box.gltf")

local box2 = LoadModel(nil, GetPath(PATH_DESKTOP).."/box.gltf")
Print(box2.properties.health)

glTF nodes section looks like below. You can see the engine has its properties it saves, and the user's properties are completely separate.

"nodes": [
  {
    "extras": {
      "ultra": {
        "angularDamping": 0.10000000149011612,
        "collisionType": 1,
        "elasticity": 0.4000000059604645,
        "kineticFriction": 0.5,
        "linearDamping": 0.10000000149011612,
        "navigationObstacle": true,
        "physicsMode": 1,
        "pickmode": 2,
        "staticFriction": 0.8999999761581421
      },
      "user": {
        "health": 100
      }
    },
    "mesh": 0
  }
],

The saved file is still a valid glTF file that can be loaded in Blender or another program. In fact, to my surprise, custom properties even survive being imported into Blender and exported again, if you have the "custom properties" option checked:

This means you can pull model back into Blender, modify them, and save again without having to redo all your custom properties.

[Josh]

1.0.2

• Engine properties now only get saved in glTF files if they deviate from the default values. If those default values change in the future, your existing models won't be stuck using the old defaults.
• Lua table to C++ table conversion now accounts for infinite recursion (a table with itself as a member). C++ table to JSON conversion does NOT account for this and will cause a stack overflow error.

With that whole aspect completed, I will now turn my attention back to the new editor...

[Josh]

1.0.2

• Editor updated with file thumbnails working again. Thumbnail generation is not asynchronous yet, and currently only displays whatever image Windows Explorer shows.
• Fixed the problem with upside-down thumbnails.
• Editor scripts folder updated with all the recent changes in the Lua system.
• Files in packages currently do not show thumbnail images.
• Fixed window size save setting bug.

I recommend uninstalling and reinstalling 1.0.2.

[Josh]

1.0.2

Thumbnail generation is now asynchronous. Still only showing the file icons that Windows creates, but it will be much more fluid now when changing the selected folder.

I was planning to launch another instance of the editor itself with some command-line options each time a thumbnail needs to be generated, in order to run the thumbnail generation code in a totally separate process. However, I found that while CreateProcess is relatively fast (a few milliseconds), process->Wait() takes almost a full second for each process I launch. 

[Josh]

1.0.2

Editor is now launching itself each time a thumbnail is generated. Each thumbnail takes about 200 milliseconds, which could probably be faster but is within a range where it might be acceptable. Thumbnails are now generated for all supported texture file types, and then it falls back on the Windows icon.

You can clear your stored thumbnails by deleting the folder "C:\ProgramData\Ultra Engine\Thumbnails".

[Josh]

1.0.2

Thumbnails will now be generated for files in packages, and the popup preview will have higher priority, so its thumbnail will be shown first if a lot of files are processing.

[Josh]

1.0.2

• Settings file now moved to C:\ProgramData\Ultra Engine\settings.json
• Program settings now using a C++ table instead of a JSON object
• Added OpenAI text-to-image editor extension

[Josh]

1.0.2

• Added new normal map generation option in texture editor tools.

[Josh]

1.0.2

File thumbnails will now be generated for SVG vector images, material files, and models. Model thumbnails have some errors, but I think I am going to have to change my approach here anyways. Presently I am using tinyrenderer to generate thumbnails for models and materials. It's fast enough for material, even with the big popup previews, but it goes really slowly for bigger models (20,000+ polygons). This indicates to me it's more limited by the number of polygons rather than the fillrate, since materials write to just as many pixels or more as most models. Maybe there is not very efficient early Z discard. In any case, the bigger models can take a full minute or more to render, in release mode, with 100% CPU usage, so there's probably no room to improve the threading.

I think I will have to give up on that approach and implement image retrieval from Vulkan. I hoped to avoid this, because everything Vulkan does takes so long to get right, but I don't think tiny renderer will scale to our needs.

It looks like this software renderer actually preforms pretty well, so I may give it a shot. It's about 20 FPS for simple models, and 1 FPS for a big model. That's not bad if its just used for generating thumbnails.

[Josh]

1.0.2

• Added Framebuffer::Capture, for taking screenshots.

[Josh]

1.0.2

Vulkan-based thumbnail generation is now working, for all materials and models. Currently the editor is launching an instance of itself with some command line parameters to generate a thumbnail. Launching the process takes a certain amount of time, and it's probably not ideal to be creating and recreating Vulkan rendering instances over and over. I think this should be changed so the editor keeps one process open and sends and receives messages to handle the thumbnail generation.

[Josh]

1.0.2

You can now hide file extensions from the asset browser. Add extensions you want to hide in the settings.json file:

	"hideFileExtensions":
	{
		"bin": true,
		"meta": true
	},

You can also just copy this script code and paste it into the console, and hit return to run it:

program.settings.hideFileExtensions = {}
program.settings.hideFileExtensions.bin = true
program.settings.hideFileExtensions.meta = true

Just copy the whole thing and paste it into the console, and it will really work!

I will later have a scheme to reset settings to default, where these extensions will be added by default.

[Josh]

1.0.2

• Fixed some problems with reading / writing in process streams, so inter-process communication works correctly now.
• Thumbnail server is now a separate executable (preview.exe). I ended up using Print / Input for the IO, which seems to work well and is cross-platform.
• Thumbnails for all file types are now working, faster now because it doesn't relaunch a process each time, works with 3D file types too.

[Josh]

1.0.2

• Finished model import protocol, updated Quake loader plugin with MDL support.
• Basis, FreeImage, and KTX2 plugins updated, as the texture import protocol changed slightly. You must sync your project to get the new builds of the plugins.

[Josh]

1.0.2

• Took another pass at my "smart tessellation" idea and this time it works great. See this thread for sample models. The tessellation settings currently cannot be saved in a glTF file, but you can try the feature out.
• Fixed error in OBJ loader