Josh

You have two things going on: The size of the physical monitor, which usually corresponds to the resolution, i.e. a 1980x1080 monitor is bigger than a 1280x720 monitor. The size of the pixels. A 3920x2050 monitor will be about the same physical size as a 1920x1080 monitor, but its pixels will be twice as small. The first issue is fairly easy to deal with, just position your UI elements relative to a corner. If you have a display item that is 200x200 pixels, maybe it will be positioned at screenresolution - 220, for example. Another option is to create your UI at whatever default resolution you want, create all widgets, lock them to edges with Widget::SetLayout, and then call Interface::SetSize to slide everything into place. For the second problem, the display scale is the best indication of how big the pixels are. The best way to incorporate this into your UI is to first create your GUI with the assumption that everything is using 100% scaling, and then scale the UI using the display scale. If you use Widget::SetLayout to control which edges each widget is locked to, then everything will scale up perfectly. Additionally, whenever possible you should use Widget::SetIcon instead of Widget::SetPixmap, as icons are resolution-independent images loaded from SVG format.

Updated 1.0.1 Removed PickInfo::GetTexCoords(). Use the texcoords[2] member instead: https://www.ultraengine.com/learn/PickInfo?lang=cpp

Okay, it's fixed. This example shows both working at once: #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 a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -4); //Create a light auto light = CreateBoxLight(world); light->SetRotation(45, 35, 0); light->SetRange(-10, 10); light->SetColor(2); //Create a model auto model = CreateSphere(world); for (int v = 0; v < model->lods[0]->meshes[0]->vertices.size(); ++v) { model->lods[0]->meshes[0]->SetVertexColor(v, Random(), Random(), Random()); } auto font = LoadFont("Fonts/arial.ttf"); auto sprite = CreateSprite(world, font, "Hello", 18); sprite->SetPosition(2, 0, 0); sprite->SetScale(1.0f / 18.0f); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { model->Turn(0, 1, 0); world->Update(); world->Render(framebuffer); } return 0; }

Updated 1.0.1 Vertex colors now using bone indices slot instead of bone weights, since this was interfering with vertex displacement Added 3D GUI example here: https://www.ultraengine.com/learn/CreateInterface?lang=cpp

Okay, this is actually caused because I was storing per-vertex displacement in the fourth bone weight component....I need to rethink this.

Yes, this is necessary so that the each face has flat normals. I noticed in my example the sphere seems to be using unique vertices for each face. This might be unnecessary but I'm not sure.

An update is available now. Make sure your sync your project to get the shader changes: https://www.ultraengine.com/learn/Mesh_SetVertexColor?lang=cpp

Updated 1.0.1 Added Mesh::Get/SetVertexColor glTF loader now loads vertex colors and second UV set Window::style is now a read-only public member

That is an excellent point, and it applies to any skinned mesh. We would probably want decals to be applied based on the unskinned vertex position, so that the decals stretches with the mesh.

You can also look at Recast here and see if there are any features you think should be added to our engine: https://github.com/recastnavigation/recastnavigation

AMD! 😭 Thank you for the videos. It may take me a while to get this fixed but I promise it will be resolved.

The new forward renderer allows a lot of things that were not possible before. Although decals are not yet implemented, they will be able to modify the color (including alpha), normal, displacement, and other values. You could use decals to punch see-through holes in the sail. I'm going to go ahead and implement vertex colors as an option when mesh skinning is not in use, but I am not 100% sure this is the final configuration of the vertex layout, and it is possible there could be some kind of small behavioral changes in the future. It could be possible to store colors one component of the second UV set, but only if they are 32-bit floats that can be unpacked to bytes. In earlier builds I was using half-floats for position and texcoords, but some GPUs do not support this. Vertex data is packed into the GPU-ready format on the main thread, because it usually has time to spare and this relieves the rendering thread from any extra overhead. However, the renderer doesn't find out whether the GPU support half-float vertex data until the first render, which occurs after meshes have already been packed. So changing that up dynamically based on the GPU capabilities is a bit tricky, and I am not sure if it will ever happen. With half-floats we could eliminate 12 bytes, probably more, and that does make a difference when the vertex pipeline is the bottleneck.

Here is an example that loads a leadwerks map and uses FPS controls: https://www.ultraengine.com/learn/Entity_SetInput?lang=cpp

I need to think about this, because there is also the possibility of reusing the second texcoord set for the bone indices and weights. It would eliminate 8 bytes from the structure, which is worth considering.

Well, meshes need to be explicitly set to be skinned if they use vertex weighting: https://www.ultraengine.com/learn/Mesh_SetSkinned?lang=cpp So it would probably be easy for me to modify the default vertex shader to display vertex colors stored in bone weights, if the mesh is not skinned. There is also a second texcoord set, which is intended for use with GI lightmaps. An animated mesh could use that if it was really needed. Four bytes for RGBA can be packed into a single float value.

Ultra does not support vertex colors because the size of the vertex structure does make a big difference in performance, especially with very detailed models, like polygonalized CAD models and 3D scans, and vertex colors are rarely used nowadays. However, the vertex bone weights could be used to store colors, and a custom shader could read that information and modify the output color of the vertex shader. You can modify the position of an existing vertex: https://www.ultraengine.com/learn/Mesh_SetVertexPosition?lang=cpp You cannot adds new vertices or indices to a mesh once it is initialized, due to the asynchronous rendering.

The Ultra Engine client application replaces the UAK launcher.

Updated 1.0.1 Fixed broken SSR shader

Okay, I removed that plane distance test and it appears to work fine. I am not sure why that was even in there. Maybe we will see a problem in the future that was supposed to solve, but I don't even know why it is in the code.

The problem is definitely related to the cubemap coord shifting in the lighting code: dist = BoxIntersectsRay(vec3(-0.5f), vec3(0.5f), orig, -reflection); if (dist > 0.0f) { cubecoord = orig - reflection * dist; vec4 p = Plane(localposition, localnormal); if (PlaneDistanceToPoint(p, cubecoord) > 0.0f) { float sinfluence = min(influence, 1.0f - probespecular.a); u_MipCount = textureQueryLevels(textureCubeSampler[shadowMapID]); lod = materialInfo.perceptualRoughness * float(u_MipCount - 1); probesample = textureLod(textureCubeSampler[shadowMapID], cubecoord, lod); probesample.rgb = min(probesample.rgb, 2.0f); probespecular.rgb += probesample.rgb * probesample.a * sinfluence; probespecular.a += sinfluence * probesample.a; } else { probespecular = vec4(1,0,0,1); } }

Same here. I can't even see the missing headers in the Scintilla repository here: https://github.com/mirror/scintilla/search?q=ScintillaStructures.h

16 is the limit.

This is just a note for others, currently the terrain can show small cracks in the geometry when tessellation is enabled. I have a solution in mind that will eliminate this but it is not yet implemented.

Let's keep it simple. Here is a valid material file: { "material": { "color": [1.0, 1.0, 1.0, 1.0], "displacement": 0.1, "emission": [0.0, 0.0, 0.0], "metallic": 0.0, "roughness": 1.0, "shaderFamily": "Shaders/PBR.json", "shadow": true, "tessellation": false, "texture0": "./defaultmeshface.tex", "transparent": false } } For textures, a file in the same folder as the material file can use a relative path by adding ./ at the beginning of the path. Otherwise it will be considered a path relative to the project folder, i.e. "Materials/brick/brick01.dds".