Josh

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.

The graphics update I am working on is already significantly faster than either of these versions. Let's pick this up again after it is out, and see where we are at then.

Maybe create a new thread with more specific details?

This seems to be fixed on AMD. I am not sure why because I did not merge the terrain textures like I did shadow maps.

Hmmm, that does not really make sense because there is nothing that ties a 3D interface to any particular window. There is no connection between them. A 3D interface can be drawn on the screen, it can appear on a panel in the 3D game world, or it can appear as a hovering VR menu. The same interface could appear in a framebuffer in multiple windows. Tying a 3D interface to a window would be like tying some entity to a window.

That's why I always use std::array.

This is not surprising at all.

Are you using multiple threads?

Okay, so you are saying this issue is solved on Nvidia cards?

Maybe, if you install the right Windows SDK and compiler? Why would you want to?