Josh

Update Fixed GUI transparency problem reported above.

Problems?

I think what we will do is enable purchases in a few days, so people who are hanging out on the forum can get the new engine, and then wait a couple of weeks for the email blast and big announcements to go out. Most normal people are probably very busy during Christmas.

Update is up that should fix your problem, with depth prepass enabled or disabled.

Also, the reason your example is kind of laggy is because it only evaluates one event per loop. Change your code to this to fix it: /*if*/ while (PeekEvent()) { auto ev = WaitEvent(); ui->ProcessEvent(ev); }

This is not the complete solution, but you can call uicamera->SetDepthPrepass(false) and it will probably look right. This is something you should do anyways, as there is no reason to do a depth prepass when lighting is not in use.

Did this same code work correctly in previous builds?

Update Renamed ASyncRender to AsyncRender Fixed default terrain Lod distance, added Terrain::SetLodDistance()

This video explains some of the cool features you will find in the new Ultra Engine API:

Final steps: The SSR shader needs to detect and calculate indirect lighting based on whether the material that wrote each pixel uses PBR, Spec/Gloss, or classic shading. These each use a different calculation of specular reflection. Clean shader code up a bit. Make sure the spec/gloss appearance is correct. A lot of Sketchfab models use this glTF extension. ASyncRender will be renamed to AsyncRender

It's not supported yet.

Yeah, at that distance there is no way single precision would work.

This is really polished and well done! The sound effects crack me up. Very creative and fun.

I tried to create an example of this problem but the code below works fine on my machine: #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; const WString remotepath = "https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets"; 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, -2); auto actor = CreateActor(camera); actor->AddComponent<CameraControls>(); auto specmap = LoadTexture(remotepath + "/Materials/Environment/Storm/specular.dds"); world->SetEnvironmentMap(specmap, ENVIRONMENTMAP_BACKGROUND); camera->SetPosition(1000, 0, 0); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

Update Fix for textures not loading correctly from plugins, may fix validation error Fixed shader family reloading issue

I would like to explicitly explain something because I think it is very interesting and it makes a good story. Back in the post-Steam launch days I was trying to figure out what direction to take Leadwerks in. I knew ahead of time that Steam was going to open up more and it would probably become flooded with products like the iOS App Store was, although I did not hear the term "Steam Direct" until everyone else. So I was scrambling to find a development direction and business model that would outlast Steam. I decided the only thing to do was to be a technology company first and foremost: I was contacted by NASA a couple of months after posting that blog. Now in entrepreneurship you learn that in order to achieve adoption of a technology, it has to solve a problem. It isn't enough to just have a nice product. The user you are targeting needs to be experiencing a "pain point" that your company solves. You have to give them something they can't say no to. The problem NASA was having was rendering performance in VR. When I saw what they were doing with Leadwerks, it was obvious why. They were placing high-poly CAD models with thousands of articulated parts in VR, and naturally the framerate was low. If they were making a game I would advise them to reduce the detail of their 3D models, but they weren't making a game, and they did not want to strip out important details they were trying to visualize. So I had a problem a big customer had, that maybe I could solve, and it happened to be a problem my other users all had as well. If I could solve this issue I would make everyone happy. However, it's not enough to be a little bit better. Leadwerks already performed a little bit better in most conditions. If you want people to switch to your technology, you have to offer an order-of-magnitude improvement. To my surprise, it turned out that the new engine architecture in Ultra does exactly that. These books helped me to formulate my strategy and I would strongly recommend them to everyone: The Innovator's Dilemma Crossing the Chasm Zero to One Now that the actual implementation of this technology is nearly done, it needs to be communicated. If you look at the main website landing page (https://www.ultraengine.com) you can see the advantage that is being claimed is very clear. There's no long lists of bullet points. Everything on that page is written to communicate the promise of Ultra Engine, which is basically that this engine stays fast as your game grows. Everyone who sees that page will know the reason Ultra Engine exists. Benchmarks are provided for download, and a link to my I/ITSEC paper provides validation that this is actually real. I feel this is very interesting because I formulated and executed a strategy whereby I am changing the terms of how Ultra competes with other engines, instead of just trying to badly copy what everyone else is doing. The advantage we have is that objective reality is on our side. Performance for VR or otherwise is one of the most important aspects of game development. It's clear that Ultra is the technology we should all get behind for the best possible future. So I think I solved a difficult puzzle and it will be very interesting to see this unfold. Of course it is up to the users what they will choose to do, but in a sense I feel like victory is already here. My dream was to create something that would make a real positive difference in your life, and I feel very good about the solution I have created for you.

The thing is, there IS no state in the Vulkan object. My code is just tracking the calls as they are recorded. They aren't actually executed until the queue is submitted. This is why image layout transitions are a disaster that should never have been included in the API. There's a very good chance that if my code is saying the layout is GENERAL, then it is. Are you changing image layouts yourself? Are you initializing new textures in Vulkan code?

Imagine no more slowdown It isn't hard to do Nothing to remove or optimize And fast collision too Imagine all the people Rendering efficiently You may say that I'm a dreamer But I'm not the only one I hope someday you will join us And your game at max FPS will run Ima

That might cause problems. 😨 You can remove the validation layers by editing Ultra.json. In general it's best to keep these enabled because if there is a problem we want to know as soon as possible. It should never happen. I will have an update tonight that adds a new function UltraRender::GetRenderTexture so you can test.

I'll see what I can do...

You can't get the RenderTexture object?

Check what GetImageLayout() returns. If it says UNDEFINED I would like to know. If it says GENERAL, then the validation layers might have a bug we need to report.

There actually is a RenderTexture::GetImageLayout method if you feel brave, but I would not come to rely on this.

I don't know, because I am pretty sure any textures that have been created are initialized in a step prior to user hooks being called. I have not changed anything here. Does the code still work the same in release mode? It is possible for validation layers to have bugs.