Josh

You will also need to call camera->SetClearMode(CLEAR_DEPTH) so the camera does not wipe the screen.

The way brush picking has changed and I believe your issue is resolved, on the dev channel. Please let me know if that is not the case.

Okay, I have simplified this and it appears to be some sort of clipping problem. Space key recreates the button: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 300, 300, displays[0], WINDOW_DEFAULT); //Create a world auto menuWold = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create camera auto camera = CreateCamera(menuWold); auto uiCamera = CreateCamera(menuWold, PROJECTION_ORTHOGRAPHIC); uiCamera->SetRenderLayers(2); uiCamera->SetPosition(framebuffer->size.x / 2.0f, framebuffer->size.y / 2.0f); auto ui = CreateInterface(menuWold, LoadFont("Fonts\\arial.ttf"), iVec2(300)); ui->SetRenderLayers(2); //This works: //auto panel = CreatePanel(10, 19, 200, 50, ui->background); //This does not work: auto panel = CreatePanel(10, 20, 200, 50, ui->background); panel->SetColor(1, 0, 0, 1); auto btn = CreateButton("Btn", 10, 0, 20, 20, panel); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_SPACE)) { btn->SetParent(nullptr); btn = CreateButton(String(Random(100)), 10, 0, 20, 20, panel); } while (PeekEvent()) { const Event ev = WaitEvent(); ui->ProcessEvent(ev); } menuWold->Update(); menuWold->Render(framebuffer); } return 0; }

BTW, you don't need to call Self()->As<Widget>(), you can just call As<Widget>().

You can set the background / root panel's background color to 0,0,0,0 to make is see-through. Then create a smaller panel on it for your visible GUI area.

You apply materials, not textures. You can right-click on any texture file in the asset browser and select the "Generate Material" menu item and it will detect the available files and create a material file for you: https://www.ultraengine.com/learn/pbrmaterials

I don't see where your orthogonal camera is being created. You want to create one camera that is just for the GUI. You can use Interface::SetRenderLayers and Camera::SetRenderLayers to make it so the GUI camera only draws the GUI and does not draw the scene twice. Your GUI camera should be created after your 3D camera so that it renders last.

I asked the OP to create a thread like this for his ideas after some discussion in Discord. C# has getters and setters, which are a hidden method that gets called by assigning a value. Lua can do this as well, but I haven't done much with it because it seemed redundant to have two ways of doing everything, and it was easier to have Lua follow the C++ API as closely as possible. C++ does not have getters and setters, so we always call SetPosition and GetPosition, or sometimes we can access a read-only property like entity->position. If and when C# support is added then it would make sense to me to implement getter and setter commands to make onboarding easier for people coming from unity. In Ultra it would just work like this: entity.position = Vec3(1, 2, 3); I am mostly interested in hearing your ideas on what components would be useful for common gameplay purposes. I looked at unity's stock components during development and found the default components were very sparse, mostly just related to basic object types instead of gameplay interactions.

https://www.ultraengine.com/learn/CreateInterface The second example shows how to create an interface that appears in a 3D rendering viewport.

Ultra Engine uses Vulkan, not OpenGL. There is a system for custom hooks that run in the rendering thread, but it is unofficial and not documented. The World::AddHook method allows you to add a hook that will run either in the data transfer step, or in the render loop using HOOKID_RENDER or HOOKID_TRANSFER. @klepto2 has done some very interesting things with this: The texture class has two undocumented commands that must ONLY be run in one of the hooks above: VkImage Texture::GetImage() VkSampler Texture::GetSampler() I think this probably gives you the pieces you need to do what you want, but Vulkan is a difficult beast to tame. You might have better luck using compute shaders, if you are not committed to Cuda.

Yes, absolutely agree.

The Ultra Engine client app is only needed if you have the standalone version from our website. The Steam version just installs like any normal Steam game.

Good discussion! I will respond with some proposals before the meeting Saturday. Please limit the scope of this discussion to object selection, object creation, and terrain editing. There are other small areas in the editor that can be further refined, but this is the problem I want to focus on first because it is very central to the user experience.

Thanks for clarifying that. On the same page, there is even a section called "Debate" in which people argue about exact definitions: https://en.m.wikipedia.org/wiki/Entity_component_system#Debate To me, ECS means components attached to entities that add characteristics or behavior. Let's look at the page's definition of "system": The core engine is an OOP hierarchy, so this example probably does not apply. The physics system internally does the same thing, but that's more about syncing data across multiple threads and is not part of the user-facing API. The user-exposed component system does not currently have the ability to query a list of entities that have a specified component type attached to them, but I can see how this could be very useful: void Player::Respawn() { auto spawnpoints = world->GetEntitiesWithComponent<SpawnPoint>(); if (spawnpoints.empty()) return; int n = Random(0, spawnpoints.size() - 1); GetEntity()->SetPosition(spawnpoints[n]->position); } If people would find this useful it would not be difficult for me to add. Is this more along the lines of what you were thinking?

When the project was created, the editor should have asked to create an environment variable. It will create a system environment variable like this, which tells the compiler where to find required files:

I have not tested Intel Arc graphics cards yet. The Intel integrated graphics chips I have seen have some limited Vulkan capabilities, even when they support Vulkan 1.3. Support for these chips is doable in the future, but it will require me to add some shader workarounds to deal with their limitations.

This is the command you will need for offsetting the player's position from the real position: https://www.ultraengine.com/learn/Hmd_SetOffset

The short answer to your question is yes. The engine is design as an object-oriented C++ framework. If you wish to use it, you have full control over the program at the very base level. This is also nice for documentation because it allows us to demonstrate how a command works in a very simple program: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create window auto window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create world auto world = CreateWorld(); //Create framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); //Main loop while (not window->Closed() and not window->KeyDown(KEY_ESCAPE)) { world->Update(); world->Render(framebuffer); } return 0; } An entity component system is also available, which is particularly useful for setting up object properties in the editor and then accessing them in component code in your game: https://www.ultraengine.com/learn/Component Someone who is making something like a space game with all procedurally placed content would not need the editor, and might not need the ECS at all. Someone else who is using the editor a lot for level design will probably want to rely on the ECS in order to set up properties in the editor and access them in the game. The ECS is also good for user-created modular code that can be reused in many projects. You don't have to choose between one or the other. You can use the ECS and you still have access to the main function in case you want to do something special there. I like to use the OOP approach for documentation examples because the user can just copy and paste one block of code into any project, without a lot of complicated setup, but the functionality demonstrated can be implemented in any entity component.

Thank you, I found the cause. I think I will wait until Tuesday to upload any more changes.

Okay, you now have access to the terrain material layer list: listbox = program.terraineditor.materiallist So you could listen for a WIDGETMENU event and make a popup menu appear when the user right-clicks on an item. That could show a menu that says "Load Splat map" and you could open a file open dialog, load a pixmap, and then apply it to all the selected objects with this: local sel = program:GetSelection() for n = 1, #sel do local terrain = Terrain(sel[n].entity) if terrain ~= nil then -- apply splat map here... end end Maybe you would want to have some menu items like this: Load Red Channel... Load Green Channel... Load Blue Channel... Load Alpha Channel... I'm just thinking of ways to make it handle more than four layers. On the other hand maybe you want to add a button to just load a splat map onto the first four layers: local panel = program.terraineditor.panel local savebutton = panel:FindChild("Save") local button = CreateButton("Splat", savebutton.position.x + savebutton.size.x, savebutton.position.y, savebutton.size.x, savebutton.size.y, panel)

Fixed navmesh saving error in editor.

It looks like the error is only in the editor, and not in the engine library itself. I updated the editor and this example works: start.zip #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto cl = ParseCommandLine(argc, argv); //Load FreeImage plugin (optional) auto fiplugin = LoadPlugin("Plugins/FITextureLoader"); //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Load the map WString mapname = "Maps/start.ultra"; auto scene = LoadMap(world, mapname); auto navmesh = scene->navmeshes[0]; navmesh->SetDebugging(true); auto agent = CreateNavAgent(navmesh); auto player = CreateBox(world); player->SetColor(0, 1, 0); player->Attach(agent); auto camera = CreateCamera(world); camera->SetPosition(0, 1, -4); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_SPACE)) agent->Navigate(1, 0, 0); world->Update(); world->Render(framebuffer); } return 0; }

Yes, I am planning on something like this.

I'm quite happy with the asset workflow in our new editor. The tools for inspecting models, materials, and textures, together with the glTF pipeline, turned out really nicely and are very powerful and intuitive. However, there are some areas of friction in the basic mapping tools though that people have pointed out, particularly in these areas: Object selection Object creation Terrain editing Now, because Ultra includes a CSG editor in its core tools, it requires that we do things a little bit differently from other editors, but I believe we can improve its basic functionality. If you haven't seen the Game from Scratch video I recommend giving this a watch: Although I wish they had gone into more detail on the available benchmarks and the paper I published with NASA, I think Mike did us a tremendous favor by highlighting some of the usability issues in the object creation workflow. Fortunately, the mouse tools are each compartmentalized in their own class, and it's not super difficult for me to adjust the controls. We will have another session on Discord this Saturday at 6:00 PM GMT (10:00 AM PST). Before then, I would like to use this thread to discuss how object selection, creation, and terrain editing can be improved. This is a design problem, not a programming problem. Once the workflow design is decided, it won't be too terribly difficult for me to make the necessary changes. Please try to think about object selection, creation, and terrain editing at once, because these three things are highly interrelated, and the solution must consider all three. Although there are other various small improvements that can be made to the individual mouse tools I would like to focus on these three issues because they are so central to the workflow. So give these a spin in the editor and please let me know in the comments below how you would like them to be improved.