Josh

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.

I will have an update ready tomorrow.

Thanks, I just finished something very big but now there will be time for other things...

0.9.5 is now available on the beta branch. This provides 250% increase in the performance benchmarks. Engine now runs on a wider range of hardware. Brush face tool is fixed. Added camera MSAA. Multi-camera rendering not supported yet. Lots of new post-processing effects included. Projects must be updated to get new shaders. I recommend making a copy of any important projects you are working on. Terrain creation may crash on AMD cards. The issue will be reported to AMD. Rendering won't work on Intel integrated graphics, but almost every chip will initialize, and at least we are making progress. Thumbnails in the editor currently will not be generated. I recommend making a copy of your project. 0.9.4 is available on the default branch if you want to hold back and let us work out the details.

There's a good reason for this. If you apply a material to a mesh, all instances of that mesh will receive the material. There is no mechanism in the scene file format that saves mesh materials. If there was, then maps would not get updated if you changed the material of the original model. I might consider adding a per-entity material override in the future, but for now it is working as intended.