Josh

Geometry shaders are supported, but I am not using them for anything. Well, actually I was using them in the GPU voxel rasterizer.

Whoa, that is really slow. Is this in debug mode?

@SpiderPig I cannot load that tree model because the glTF bin file is missing.

As I understand it, geometry shaders are pretty much useless because they have to sync with the CPU: http://www.joshbarczak.com/blog/?p=667 I have not read that entire article, and I don't fully understand the issue, I just know this is common belief and I didn't bother looking into it beyond that. Instancing will be very fast and culling will not slow down the renderer at all. One of the benchmark tests shows 64,000 instanced objects. Ultra might not need any special vegetation techniques at all because it already is so fast. For very large scale stuff I have some ideas in mind, but we are talking tens of millions of objects.

Repository for free assets created. There are some ready to use environment maps: https://github.com/UltraEngine/Assets You have the IBL sampler application in the Tools folder now. The way I made these is by dragging an HDR image from here onto run.bat: https://github.com/KhronosGroup/glTF-Sample-Environments And then I run this code to convert the KTX2 files into a BC8H DDS: https://www.ultraengine.com/community/blogs/entry/2780-building-a-single-file-4k-hdr-skybox-with-bc6-compression/?tab=comments#comment-14747

Update Fixed glTF not loading normal maps Compiled with "fast" floating point mode. I don't think it will have any effect on framerate

There is an Lod glTF extension from Microsoft but I have not implemented it: https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Vendor/MSFT_lod I don't know if it's really a great idea because no 3D modeling package will support it. If you merge Lod levels into a single glTF file, you are creating a one-way conversion step that can't be pulled back into a modeling program for editing, and avoiding that was one of the major reasons to use glTF in the first place.

Okay, Christmas is saved. I will finalize the shaders and hopefully we can get that issue fixed this weekend.

I'm going to do the final shader adjustments last because...I don't know why, I just feel it is right. I would really like to test on an AMD 480/580 but no one will help me. 😪

To Brave support, yes. Just because a new version doesn't work doesn't mean there isn't a bug in Brave. PHP was updated from 7.4 to 8.0.

Same here. I tried Edge and Chrome, and they both worked correctly. IPS tells me it is a browser problem.

Yes but not immediately

I know two million people who are going to be very happy to have that available.

I am seeing the same thing.

Should be working now. The documentation should be noticeably faster than before. I'm using Github as a CDN so scripts and images will be loaded from the nearest server. I was also including some very big scripts from the search system in every page, and that was not needed. I could probably make it faster if I generated static pages and stored them in Github, but I think it's okay for now. Using a real CDN for the forum system would probably make image loading faster. I am interested in trying this in the future.

Thank you for point this out. I need to install something call "GMP PHP extension".

Did they go away? The documentation should be a lot snappier now. I figured out I can use github.io as a free CDN.

SetMaxTorque controls the maximum force the joint can use to control the rotation of the entity, so you would want that to be a big number. If the max torque is zero the joint will rotate freely.

Leadwerks supports Ubuntu 16.04. Ultra is planned to work on Linux later, without the restrictions Leadwerks has.

Update Fixed culling bug, I think Component::LoadState, SaveState are now Component::Load/Save.

@SpiderPig Here is a simpler app that demonstrates the erorr: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto plugin = LoadPlugin("Plugins/LELegacy.dll"); //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->SetFov(70); camera->SetPosition(0, 0, -4); auto box = CreateBox(world); box->SetColor(1, 0, 0); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyDown(KEY_D)) { camera->Move(1, 0, 0); box->Move(1, 0, 0); } if (window->KeyDown(KEY_A)) { camera->Move(-1, 0, 0); box->Move(-1, 0, 0); } world->Update(); world->Render(framebuffer); } return 0; }

Ah yes, I have seen this myself. I need to get that worked out.

Ultra runs the unique geometry test faster because it has fewer objects. The Instanced geometry test has 32768 boxes and the unique geometry test only has 4096 boxes. Since unique geometry is no problem for Ultra, that one runs much faster. On my sort of low-end laptop GPU Ultra is slightly faster than Leadwerks on the lighting test. On my GEForce 1080 Ultra was running much faster. However, that was a build from ITSEC last year. I tried the old build on my laptop, and it was a little bit slower than the current build on the same laptop. I still have some questions about that test, but right now it looks like Leadwerks might run faster on low-end cards due to the more expensive PBR calculations, whereas Ultra runs faster on mid to high end cards due to the decreased memory bandwidth of the forward renderer.