Editor workflow discussion

[reepblue]

Can the engine support delayed signals without needing a delay relay component in the middle? I want to say X tell Y this after 0.125 milliseconds. Or will this be hard because there will need to be a timer for every output imaginable?

[Josh]

I think that's no problem. It's mostly just a matter of deciding how the user interface should work.

Lua Collide function is working now. Here's an example:

https://www.ultraengine.com/learn/Component_Collide?lang=lua

[Josh]

Adding Component:Connect in Lua. This gives you the ability to create flowgraph connections in code, with any number of arbitrary arguments, including tables, functions, and other special Lua stuff:

sender:Connect(sender.Send, receiver, receiver.Receive, { true, 2, "Hello!" })

Whenever the send method is called, whether it is by code or another flowgraph input, at the end of it the receiver will be triggered to execute the Receive method, with the supplied arguments.

https://www.ultraengine.com/learn/Component_Connect?lang=lua

[Josh]

You can use Lua and JSON together now. The same JSON objects are accessible to both C++ and Lua with no fiddling around with stacks and things:

local j3 = Json()
j3.key1 = "value"
j3.key2 = 3
j3["key3"] = true
Print(tostring(j3))

This prints out:

{
	"key1": "value",
	"key2": 3,
	"key3": true
}

LoadJson() and SaveJson() are also available.

This is how I plan on handling user-defined settings in the editor:

program.settings.mainwindow.position.x = 50
program.settings.mainwindow.position.y = 100

That will directly modify the program->settings json object and those changes will be saved to the settings file.

I'm shocked that it worked so neatly.

Other stuff to try:
https://www.ultraengine.com/learn/Component_Connect?lang=lua
https://www.ultraengine.com/learn/Component_Collide?lang=lua

 

[Josh]

JSON example. The only thing missing are key/value pairs. The reason this is so cool is because it allows Lua to modify JSON data stored in C++ without having to pass the entire structure back and forth between nlohmann::json and Lua for each change. So this can be used to read and write values to scene files, insert custom user data into glTF files, and add custom user settings in the editor.

local j3array = JsonArray()

j3array[1] = "test value 1"
j3array[2] = "test value 2"
j3array[3] = "test value 3"
j3array[4] = "test value 4"
j3array[5] = "test value 5"

--Array
for n = 1, #j3array do
    Print(tostring(n)..": "..j3array[n])
end

--iPairs
for k, v in ipairs(j3array) do
    Print(tostring(k)..": "..tostring(v))
end

local j3object = Json()

j3object["color"] = "blue"
j3object["weight"] = 100
j3object["happy"] = true

--Pairs
for k, v in pairs(j3object) do
    Print(tostring(k)..": "..tostring(v))
end

The Lua component save / load methods can work just like C++:

function component:Save(J3)
	j3["health"] = self.health
	return true
end

Of course with Lua that can be pre-serialized, and then the function would just be used for any adjustments you want to make, like saving data of loaded resources, and other things that don't get saved automatically.

JSON objects can only store numbers, strings, booleans, and other JSON objects, so they can always be saved to a file and loaded back the same.

[reepblue]

I was wondering how Json was gonna work in lua, that's pretty neat.

[Josh]

This will blow your mind:

I was able to work out an API for complete control of Lua via C++. See release notes for details.

This is very very powerful because the sol::object class can handle any C++ type, even new classes you just declared and haven't even bound with sol. This was always a problem in Leadwerks, and the reason why the C++/Lua interface was never fleshed out.

The new CallFunction function can handle any number of and type of arguments, and supports multiple return values.

You can get and set Lua fields for every class derived from Object, and even call method-style functions with CallMethod, and the object passed to Lua will be whatever type you pass to the function. This was impossible in Leadwerks, and everything just got cast to Object or Entity and had to be re-cast in Lua if you wanted to access a derived class. You can declare a C++ class, bind it to Lua, pass it to a function, and immediately start using it in Lua, without touching the Lua API.

This is how I always pictured how an interface between C++ and Lua should work, but it was never possible until now.

#include "UltraEngine.h"

using namespace UltraEngine;

int main(int argc, const char* argv[])
{
    //Create an object
    auto box = CreateBox(NULL);
    box->name = "Bob";

    //Declare a variable in Lua
    SetGlobal("entity", box);

    //Run a script that attaches a function to the entity
    ExecuteString("function entity:Rename( newname ) self.name = newname end");

    //Call the method
    CallMethod(box, "Rename", { "Fred" });

    //Check if it worked
    Print(box->name);

    return 0;
}

This will also work:

    //Run a script that attaches a function to the entity
    ExecuteString("function _G:Rename( newname ) self.name = newname end");

    //Call the method
    CallFunction("Rename", { box, "Fred" });

This works absolutely fine:

class SomeClassIJustMadeUp
{
  int idk = 1;
};

SomeClassIJustMadeUp foo;

SetGlobal("something", foo);

 

[Josh]

I'm very very happy how this has turned out. All of these interrelated aspects of the software have been resolved in a consistent manner with an overarching design:

• Lua debugging
• Entity components between C++, Lua, and an exploratory attempt to expose components to C#
• Underlying code that powers flowgraph connections, with arguments accounted for
• Lua API for C++
• Accessing engine and user-defined C++ classes in Lua
• Editor extensions
• Custom user data embedded in glTF, scene, and material files
• Application settings and user-defined settings in editor extensions accessible from both C++ and Lua with no weirdness
• Storing and loading data to and from JSON files
• Scene serialization for game saves

If you don't understand the things I have been talking about in the last week, I don't blame you, but trust me that this is going to empower the engine and editor to do some really wonderful things, and provide the basis for a great scripting and extensions ecosystem for the new engine.

I don't think I have ever worked on something this complex and yet it all came together so neatly. I feel like I have reached a new level of development / design / engineering with this. It will take a while for people to understand what it is, but you will love it.

I just updated the engine with table.to_json() (outputs a string) and a table constructor that accepts an nlohman::json object (because I'm not going to write a JSON parser). Here is a demonstration. The output is as you would expect:

table t;

//Pure integer keys get output as a JSON array
for (int n = 0; n < 10; ++n)
{
    t[n] = n;
}
Print(t.to_json());

Print("\n-------------------------------------\n");

//Mix string and integer keys
t["health"] = 100;
t["money"] = 0;
t["nullvalue"] = nullptr;
t["zvalue"] = true;

t["subtable"] = {};
t["subtable"]["position"] = 50;
t["subtable"]["size"] = 300;
t["subtable1"] = t["subtable"];

t["subarray"] = {};
t["subarray"][0] = 1;
t["subarray"][1] = 2;
t["subarray"][2] = 3;

Print(t.to_json());
     
Print("\n-------------------------------------\n");

// Save and reload test
auto stream = CreateBufferStream();
stream->WriteString(t.to_json(), false);

stream->Seek(0);
auto j3 = LoadJson(stream);

table t2 = j3;
Print(t2.to_json());

 

[reepblue]

FYI, loading Leadwerks material assets no longer works.  I think this is because it gets tripped up with the "./", which the Leadwerks editor inserts by default.

[reepblue]

I launched the editor yesterday with it still being attached to my Cyclone workspace. It tried to convert all the fbx files into gltf and made a bunch of broken files.

Good news is that I can load Leadwerks models fine. Bad news is that I have to delete of garbage data.

[Josh]

You can remove the script in Scripts/Start/Converters and the converter will no longer be active.

[Josh]

I'm designing the new flowgraph editor now. This is what I've got:

It's using the windowed GUI, not a 3D viewport, and I think this will give it a better appearance. I plan for the entity to display each component it has, with the input and output functions for each component. I want a slider to scale / zoom the interface, and some way to add, edit, and select multiple "pages" (which are separate flowgraphs within the same scene, but not connected to each other).

I don't know what the UI for this should look like. Ideas?

[reepblue]

I have a few ideas, I'll try to do a mock up when I get a chance.

[Josh]

 

[Josh]

I'm going to experiment with placing the logic view in a viewport, so to get to it you just switch the viewport's view to "logic". Then it will appear in the editor main window alongside the 3D view, and you can switch it to a single viewport and back when you need more space.

[reepblue]

Interesting idea, but I think putting the viewpoint system in a tabber would be a better way. You can have a tab for 3D, and another one for logic.

You should put it in a tabber anyway so we can load multiple files at once. A huge step down from other editors.

Worth mentioning, I want it to be possible for prefabs to keep their logic intact too. I want to be able to create a logic cluster if entities and reuse that throughout the game. 

[Josh]

I don't like tabs for two reasons:

• You can't see the two areas of content at once. With the flowgraph, being able to see the selected objects in the 3D viewport and see how that correlates to the nodes in the graph is very helpful.
• It sacrifices a lot of screen space for something that is rarely used.

[Josh]

I think it will be necessary to get a 1.0 release out, see all the ramifications of how the flowgraph works with the new component system, and then take that knowledge and design something more advanced for a future release. I think I will just focus on delivering the same functionality Leadwerks had, plus zooming. Otherwise I am likely to design something, and then remove and redesign it in another update.

[reepblue]

Can you still make it render in a viewpoint? The separate window was annoying.

[Josh]

I can try it and see what happens!

[redhacker2]

On 4/4/2023 at 9:35 AM, Josh said:

The Quake people are telling me they use the 3D editing mode in TrenchBroom exclusively, and the 2D viewports are just an afterthought. These people are the most intense CSG mappers in the world so I think I need to listen to them.

I know this is old, but I use Source 2 Hammer from time to time, which although is mesh based and not CSG based I do have to say, I mostly agree with them... The 2D views are occasionally useful for lining things up and ensuring everything is on the grid, but 3D is so much more powerful in the general case. This is the default setup DOTA 2 and HL:A use. (Note it is Optimized for Ultrawide monitors by default, so you do need to do a bit of size adjustment)

 

[Josh]

Source 2 does not look good. 

[reepblue]

1 hour ago, Josh said:

Source 2 does not look good. 

It's not. I've been told the source code is littered with comments from the developers on how much they hate their lives and people who are able to licence it say it's the worst mistake of their entire lives.