Josh

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.

I can't view those links without signing into Discord in the browser. Are you dragging the material into a viewport in the main window, or in the asset editor? You can assign a material in the asset editor interface by selecting the mesh, then below that there is a drop-down box you can use to browse for a material file.

0.9.4 is moved onto the default branch.

This just prints out the program startup time when the app begins. StartTime.lua

We saw the same thing with the Unity Vulkan builds of our benchmarks. It seems like Vulkan code only works temporarily before some update breaks it.

Here you go. Just make sure you have indices as well as vertices: #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 framebuffer auto framebuffer = CreateFramebuffer(window); //Create a world auto world = CreateWorld(); world->SetAmbientLight(1); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -1); auto model = CreateSphere(world); //Create point model auto model2 = CreateModel(world); std::vector<uint32_t> indices(model->lods[0]->meshes[0]->vertices.size()); for (int n = 0; n < indices.size(); ++n) indices[n] = n; auto mesh = CreateMesh(MESH_POINTS, model->lods[0]->meshes[0]->vertices, indices); model2->AddMesh(mesh); model = nullptr; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { model2->Turn(0, 1, 0); world->Update(); world->Render(framebuffer); } return 0; }

It's best to just keep all your code for that camera within the component itself, which is located in Source/Components/Player/. However, when you load a map, the returned object has a list of top-level entities you can iterate through. You can check to see what components are attached to the entity, cast them to the appropriate class, and access all their members that way. You can also use the Entity::SetTag and World::GetTaggedEntities methods to easily keep track of things.

The engine should have asked if it could create an environment variable with the path to Ultra Engine in it. Please check to make sure this exists. https://docs.oracle.com/en/database/oracle/machine-learning/oml4r/1.5.1/oread/administrative-tasks-oracle-machine-learning-r.html#GUID-DD6F9982-60D5-48F6-8270-A27EC53807D0

Hey, there is no problem with this at all, as long as you are not uploading the engine header files or library files. It sounds interesting!

When I say a limit on instances, I mean on the number that exist in the world. The limit is due to the fact that entity indexes into a storage buffer use an unsigned short integer (2 bytes). This does not have any relation to the number of instances drawn, which may be more for things like shadows and the early z pass.