reepblue

This was discussed before, but can we have a way to rename these models so the project can have a uniform naming scheme? Another idea was to have it just be the filename of the model.

This is my code from my API where it grabs whatever system environment you want. I might look into implementing the above as old Win32 API code can cause AV's to get grumpy but I haven't had problems so far. const std::wstring System::GetSystemEnviormentW(const std::string& env) { #ifdef _WIN32 wchar_t* buf = nullptr; size_t sz = 0; std::wstring wenv = String::ToWString(env); // Use _dupenv_s to get the environment variable if (_wdupenv_s(&buf, &sz, wenv.c_str()) == 0 && buf != nullptr) { std::wstring result(buf); free(buf); // Free the allocated buffer return result; } #else auto s = std::getenv(env.c_str()); if (s == NULL) return String::ToWString(s); #endif return L""; // Environment variable not found or error occurred }

Have you tried camera->SetOrder()?

Ok, hopefully that does it!

Hopefully this fixes VR but I'm not gonna count on it.

If "Show Navmeshes" is enabled and the global illumination is rebuilt, this will happen.

When you place a character controller in the map, it seems one is being made at the origin and not being moved. The only way to notice it is to have a box drop right in the center of the map, phystest.zip

That's what I'm thinking unless there's any reason for that not need to be the case. I really think the RENDERLAYER enum should come back and allow us to assign renderlayers in the editor.

Yes (for the most part), but only after I figured out that the reflections were not showing on the viewmodel because it wasn't being rendered on the same layer as it. I'm not sure if this will add friction to new users. In more recent testing, I've been getting black reflections when I changed the map without rebuilding the probes or in outdoor environments. I'd have to do more testing and make an example before I can file a bug report.

I was going to report this in the bug report, but I don't think this is really a bug. I noticed the reflections of my viewmodel (which were being rendered on a different layer) weren't reflecting the level probe. I suspected that this was because the probe is only set to renderlayer 1, and the example below proves this. It makes sense, but I expected the probes to affect all layers, but there might be a situation where you don't want that. The example and map attachment below demonstrates the conflict. I don't know what the best course of action would be. Should the probes render on all layers by default? Should there be an option to allow the mapper to set each entity to desired renderlayers? Or should this be left alone, and the programmer has to ensure the probes render on the desired renderlayers? #include "UltraEngine.h" using namespace UltraEngine; //#define TEMPFIX int main(int argc, const char* argv[]) { RegisterComponents(); auto cl = ParseCommandLine(argc, argv); //Load FreeImage plugin (optional) auto fiplugin = LoadPlugin("Plugins/FITextureLoader"); //Get the displays auto displays = GetDisplays(); //Create a window iVec2 windowsize = iVec2(1280, 720); WindowStyles windowstyle = WINDOW_CENTER | WINDOW_TITLEBAR; auto window = CreateWindow("Ultra Engine", 0, 0, windowsize.x * displays[0]->scale, windowsize.y * displays[0]->scale, displays[0], windowstyle); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a world auto world = CreateWorld(); //Load the map WString mapname = "Maps/coloredroom.ultra"; auto scene = LoadMap(world, mapname); auto maincamera = CreateCamera(world); maincamera->SetPosition(0, 1.28, -1.92); auto camera2 = CreateCamera(world); camera2->SetClearMode(CLEAR_DEPTH); camera2->SetMatrix(maincamera->GetMatrix(true), true); camera2->SetFov(maincamera->GetFov()); camera2->SetRange(maincamera->GetRange().x, maincamera->GetRange().y); camera2->SetRenderLayers(2); auto sphere = CreateSphere(world); sphere->SetPosition(0, 1.28, 0); auto mat = CreateMaterial(); mat->SetShaderFamily(LoadShaderFamily("Shaders/PBR.fam")); mat->SetRoughness(0); mat->SetMetalness(1); sphere->SetMaterial(mat); mat = NULL; sphere->SetRenderLayers(2); #ifdef TEMPFIX // Search all probes for (const auto& p : scene->entities) { auto probe = p->As<Probe>(); if (probe) { probe->SetRenderLayers(1+2); } } #endif //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; } coloredroom.zip

A lot of weird banding, maybe that's messing up the result? { "material": { "alphacutoff": 0.5, "alphamask": false, "displacement": [ 0.05000000074505806, -0.02500000037252903 ], "glossiness": 1.0, "metallic": 1.0, "pickmode": true, "roughness": 0.0, "shaderfamily": "Shaders/PBR.fam", "shadow": true, "specular": [ 1.0, 1.0, 1.0 ] } }

That map works fine. I included a simple interior map that doesn't seem to be working. I removed the roof and it works. probetest2.zip

Not sure if these broke, or you're experimenting. Ether way, the icons are no longer visible in the 2D viewport.

Updated to the latest build, sync'd my shaders and when rebuilding the probes in a simple room, the result is black. For outdoors, the entire volume is black in the default environment settings. I don't understand because obviously you've tested this, and your screen looks fine. I generated these on an RTX 4070.

This example shows the face flipping (See the cone) when rendering the scene on a texture. This is something you'll see when in VR, which might be related. #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, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create light auto light = CreateBoxLight(world); light->SetRange(-10, 10); light->SetRotation(15, 15, 0); light->SetColor(2); //Create camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -3); camera->SetFov(70); //Create scenery auto box = CreateBox(world); auto cone = CreateCone(world); cone->SetPosition(1.25, 0, 0); cone->SetColor(0, 0, 1); auto sphere = CreateSphere(world); sphere->SetPosition(-1.25, 0, 0); sphere->SetColor(1, 0, 0); //Create camera and texture buffer auto texbuffer = CreateTextureBuffer(256, 256, 1, true, 0); auto cam2 = CreateCamera(world); cam2->SetClearColor(1, 1, 1); cam2->SetRenderTarget(texbuffer); //Create material auto mtl = CreateMaterial(); mtl->SetShaderFamily(LoadShaderFamily("Shaders/Unlit.fam")); auto tex = texbuffer->GetColorAttachment(); mtl->SetTexture(tex); box->SetMaterial(mtl); //cone->SetMaterial(mtl); //sphere->SetMaterial(mtl); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { //Orient the texturebuffer camera cam2->SetPosition(0, 0, 0); cam2->Turn(0, 1, 0); cam2->Move(0, 0, -3); world->Update(); world->Render(framebuffer); } return 0; } I found this while trying to do a Portal effect.

I'm getting this bug again.

Agreed, I have more of an issue dragging the model around.

I was able to download it just fine on my laptop. Try this reupload. Edit: The site is being dumb, I sent it over discord.

I'm posting in suggestion since the current system seems to be a surface pick for selecting/moving objects. I have a frame model here that's annoying to work with as you need to select/grab the edge of the model in-order to manipulate it. My suggestion is just making the selector use the bounding box for models but there might be a better way. windowborder.zip

If you try to rotate the model below when zoomed fully in, the model will rotate on the wrong axis. test.zip

I only used the standalone and never had a crash, I can try using the Steam version and see if I have the issue.

1. Open the attached map. 2. Select all three brushes, duplicate & drag. 3. Notice the bug shown below. duplicatebug.zip

That's what's aggravating about this. When you battle test the undo system, it seems to work fine but when you're the middle of a mapping session, the undo system lets you down. I don't even know how you could debug this without doing a remote debugger on them while they map. I can try to find step by step examples, but watch it be fine on your end.

To be honest, I haven't ran into this issue since. Let's mark it as resolved it for now.