Josh

Only call World::Update on one world in your application, ever.

I never thought about it, but this is really bad to do. You've got non-thread-safe Newton calls running on two separate threads at the same time when you do that. I added this information to the docs: https://github.com/UltraEngine/Documentation/blob/master/CPP/World_Update.md#remarks

If the platform uses physics to move, the box would just automatically turn since it is resting on it....?

for (auto mesh : player->lods[0]->meshes) { mesh->Translate(0, 0.5, 0); } player->UpdateBounds();

I encountered a similar problem with the Sprite::SetText method, and I solved it like this: If the new mesh data is bigger than the existing mesh, get rid of the existing mesh and create a new mesh. If the new mesh data is smaller or equal to the size of the existing mesh, copy the new mesh data to the existing mesh and set the extra vertices to all use position (0,0,0), so they will be invisible. This is similar to how STL vectors resize when a bigger size is needed, but don't allocate new memory of the new size is smaller. Over times the resize events get more and more infrequent. You can also add some padding to minimize resizes as the mesh is growing. The reason you can see flickering when a mesh changes is because the old visibility set is still being used, the old mesh goes out of scope and is deleted, but the new mesh has not cycled through the culling update yet. It's a tricky problem. This problem demonstrates the major weakness of IMgui's design vs. the persistent objects the built-in GUI uses, but if people still want to use IMgui I don't mind at all. This makes a good test case of a problem we may encounter in other areas in the future. This is not my complete answer, just some preliminary thoughts.

Fixed!

Looks like the other viewport grids aren't getting hidden for some reason...

I assume this issue this persists, and that installing the VulkanSDK does not produce any validation errors?

1.0.3 Mouse tool menu items are now synced correctly with the currently selected mouse tool.

The fix is uploaded now.

Displacement requires that a displacement map be present on the material, and also material tessellation must be enabled. I think there is a more general bug occurring here. The little arrows on spinners don't seem to be emitting events when they are pressed.

1.0.3 All toolbar buttons now working correctly.

1.0.3 Fixed some annoying rendering glitches in the editor that were appearing upon first viewport render, and when the window is resized (other viewort grids appearing, text labels disappearing or appearing twice, etc.)

I will be working on another computer soon...

The editor does not use asynchronous rendering.

It's been like this for a while, at least a week I think.

I have disabled a feature I had that was doing partial redraws of viewport contents under some circumstances, so this behavior may have improved since then.

I ran the code with just one display (changed the display ID to always use 0) and it ran correctly. I will need to set up a second monitor to test this.

Videos have been removed.

It sounds like maybe the wrong toolkit is installed?: https://learn.microsoft.com/en-us/answers/questions/1130957/link-fatal-error-c1007-unrecognized-flag-zc-nrvo-i My Windows SDK version is 10.0, platform toolset is 143.

Fixed for next build...

Program is going into an infinite loop...one moment... #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, 800, 600, displays[0], WINDOW_TITLEBAR | WINDOW_RESIZABLE); //Create User Interface auto ui = CreateInterface(window); //Create widget auto sz = ui->root->ClientSize(); int gap = 20; auto removal_p = CreatePanel(0, gap, sz.x - 50, 162, ui->root, PANEL_GROUP); removal_p->SetText("Removal"); auto dir_m = CreateButton("Directional", 0, gap, 120, 30, removal_p, BUTTON_RADIO); dir_m->SetState(WIDGETSTATE_SELECTED); auto amb_m = CreateButton("Ambient", 100, gap, 120, 30, removal_p, BUTTON_RADIO); while (true) { const auto& event = WaitEvent(); } return 0; }

Appears to be working correctly now in Ultra Engine: #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, 800, 600, displays[0], WINDOW_TITLEBAR | WINDOW_RESIZABLE); //Create User Interface auto ui = CreateInterface(window); //Create widget auto sz = ui->root->ClientSize(); auto treeview = CreateTreeView(10, 10, sz.x - 20, sz.y - 20, ui->root, TREEVIEW_DRAGANDDROP | TREEVIEW_DRAGINSERT); treeview->SetLayout(1, 1, 1, 1); auto node = treeview->root->AddNode("Node 1"); node->AddNode("Subnode 1"); node->AddNode("Subnode 2"); node->AddNode("Subnode 3"); node = treeview->root->AddNode("Node 2"); node->AddNode("Subnode 1"); node->AddNode("Subnode 2"); node->AddNode("Subnode 3"); node = treeview->root->AddNode("Node 3"); node->AddNode("Subnode 1"); node->AddNode("Subnode 2"); node->AddNode("Subnode 3"); ui->SetScale(2); while (true) { const auto& event = WaitEvent(); switch (event.id) { case EVENT_WIDGETSELECT: if (event.source == treeview and event.data == 1) { node = event.extra->As<Widget>(); Print("Selected: " + node->text); } break; case EVENT_WIDGETACTION: if (event.source == treeview) { node = event.extra->As<Widget>(); Print("Action: " + node->text); if (!node->kids.empty()) { if (node->Collapsed()) { node->Expand(); } else { node->Collapse(); } } } break; case EVENT_WIDGETDROP: { auto child = event.source->As<Widget>(); auto parent = event.extra->As<Widget>(); child->SetParent(parent, event.data); } break; case EVENT_WINDOWCLOSE: return 0; break; } } return 0; }

My solution is to disable custom font scaling for menus, because they are complicated and having different scaled menu items together does not make any sense. Scaling the entire UI will still work correctly.

Closing this since most of this stuff seems to be outdated.