Josh

Thanks, this is correct on the standalone, will be in next Steam build later today.

In my current build this code is working correctly. Please let me know if you have problems after today's update. Two things to remember: A window with a framebuffer will not be deleted until after two calls to World::Render with a different framebuffer, because it has to make a round-trip to the rendering thread and back to delete the window's graphics context before the window is deleted. You don't have this problem in your code, but remember to clear out events to prevent windows from being stuck in memory. #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); shared_ptr<Window> window; shared_ptr<Framebuffer> framebuffer; shared_ptr<World> menuWold; //Create a window window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_TITLEBAR); //Create a world menuWold = CreateWorld(); //Create a framebuffer framebuffer = CreateFramebuffer(window); //Create light auto light = CreateBoxLight(menuWold); light->SetRange(-10, 10); light->SetRotation(15, 15, 0); light->SetColor(2); //Create camera auto camera = CreateCamera(menuWold); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -3); camera->SetFov(70); //Create scenery auto box = CreateBox(menuWold); int x = 0; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { while (PeekEvent()) WaitEvent(); if (window->KeyHit(KEY_SPACE)) { x += 100; window = CreateWindow("Ultra Engine", x, x, 800, 600, displays[0], WINDOW_TITLEBAR); framebuffer = CreateFramebuffer(window); } menuWold->Update(); menuWold->Render(framebuffer); } return 0; }

Use TEXTURE_LUMINANCE. It will give you a grayscale image with alpha 1.0, using a single color channel.

Okay, I will try my Nvidia card tomorrow.

Saving animation is presently not supported.

Here is what I see when I run it. Is this the correct behavior?

Okay, this has to do with resource cleanup and I have to treat this very carefully...stay tuned.

Confirmed, although rendering is working fine for me. I have simplified your example and am testing... #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); shared_ptr<Window> window; shared_ptr<Framebuffer> framebuffer; shared_ptr<World> menuWold; //Create a window window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_TITLEBAR); //Create a world menuWold = CreateWorld(); //Create a framebuffer framebuffer = CreateFramebuffer(window); //Create light auto light = CreateBoxLight(menuWold); light->SetRange(-10, 10); light->SetRotation(15, 15, 0); light->SetColor(2); //Create camera auto camera = CreateCamera(menuWold); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -3); camera->SetFov(70); //Create scenery auto box = CreateBox(menuWold); int x = 0; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_SPACE)) { x += 100; window = CreateWindow("Ultra Engine", x, x, 800, 600, displays[0], WINDOW_TITLEBAR); framebuffer = CreateFramebuffer(window); } menuWold->Update(); menuWold->Render(framebuffer); } return 0; }

Also asked for help here: https://steamcommunity.com/groups/steamworks/discussions/0/1354868867715025209/

The single-viewport issue is fixed in 0.9.5. I am not sure if the map loading issue is still active. Please try to avoid mixing different issues together in the same thread, thanks.

Is the map saved with a name? If not it will open the dialog so you can select a name to save the map as.

I believe this is fixed in the build that will go out today. Please let me know if it doesn't work, or mark this as the solution if it does.

Fixed. Note that camera->Render() just ensures the camera renders once during the next world render. Calling camera->Render() twice in succession will not make the camera render for two frames.

Here is what I see when I run it. I guess that camera should not even render once...

Fixed in 0.9.5.

Fixed in 0.9.5, or may be a Windows compositor issue. I found what works best is do a render before showing the window, show the window, then do one more render.

Fixed.

0.9.5 Fixed some bugs. CreateTextureBuffer now uses 0 for default samples argument. Added command AnisotropicFilter(anisotropy). Only works on texture initialization, once textures are initialized they are static.

Fixed for build later today. If you hit an assert, just send me some code to produce it, like you did here.

Fixed for today's build, also added some new functionality: if (e.id == EVENT_STARTRENDERER) { Print("Renderer has started with code: " + String(e.data)); if (e.extra) { auto caps = e.extra->As<GraphicsCaps>(); Print(caps->vendor); Print(caps->device); Print(caps->driver); } }

Try this: auto texbuffer = CreateTextureBuffer(256, 256, 1, true, 0); This will tell the engine to create a non-MSAA texture. MSAA textures are a different sampler type and cannot be read by the default shaders, so if you do render to texture, you should specify 0 for the number of samples. This is actually a situation where AMD pulled an Nvidia. On AMD, it just works, even though that behavior is not conformant with the OpenGL spec, which I believe would say the behavior in this situation is "undefined". So AMD deals with the error by hiding it, while Nvidia displays the bad behavior. Usually it's the other way around.

Are both of these models coming from the same program?

Okay, the scale issue is an error in their exporter that they need to fix. You can refer them to the glTF specification and point out that in glTF, units are always in meters. The model seems to be tiny, just 8 mm tall: However, there does seem to be an animation issue that is separate, and I am investigating this. This is a useful tool for examining glTF files: https://sandbox.babylonjs.com/ Model looks nice, BTW.