Josh

Fixed the mem barrier issue seen in this image:

This topic is being closed because there is no video to view. I have seen what looks like a missing memory barrier but I was able to fix this:

no!

Updated static library and Lua binaries. Updated preview.exe Removed UPX compression from editor and preview executables, to prevent antivirus false alarms.

Still happening on the GEForce 1080, so it appears to be exclusive to Nvidia...

This error seems to not be happening in the current build, on the AMD 6600 at least...

Editor updated with fix for error that was only being detected on AMD cards.

This particular issue is fixed, although I still see a few problems with specific post-processing effects. This was caused by an error in my code, not by AMD's driver. Let's see who can spot the bug: chaininfo.sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR; chaininfo.surface = surface; chaininfo.minImageCount = 2; //if (USE_TRIPLE_BUFFERING) chaininfo.minImageCount = 3; chaininfo.minImageCount = Max(int(capabilities.minImageCount), int(chaininfo.minImageCount)); if (capabilities.maxImageCount != 0) chaininfo.minImageCount = Min(int(chaininfo.minImageCount), int(capabilities.maxImageCount)); chaininfo.imageArrayLayers = 1; chaininfo.imageUsage = VK_IMAGE_USAGE_TRANSFER_DST_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT | VK_IMAGE_USAGE_TRANSFER_SRC_BIT;// | VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT; if (device->queueinfos.size() == 2) { chaininfo.imageSharingMode = VK_SHARING_MODE_CONCURRENT; chaininfo.queueFamilyIndexCount = 2; uint32_t indices[2] = { device->queueinfos[0].queueFamilyIndex, device->queueinfos[1].queueFamilyIndex }; chaininfo.pQueueFamilyIndices = &indices[0]; } else { chaininfo.imageSharingMode = VK_SHARING_MODE_EXCLUSIVE; chaininfo.queueFamilyIndexCount = 0; // Optional chaininfo.pQueueFamilyIndices = nullptr; // Optional } chaininfo.preTransform = capabilities.currentTransform; chaininfo.compositeAlpha = VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR; chaininfo.clipped = VK_TRUE; chaininfo.oldSwapchain = VK_NULL_HANDLE; res = vkCreateSwapchainKHR(device->device, &chaininfo, nullptr, &swapChain); if (res != VK_SUCCESS) return false;

I've got a validation error occurring in the release build that does not occur in the debug build. It did not occur to me that I should try running validation layers with the release build, since I thought the code was identical.

Reported to AMD here: https://community.amd.com/t5/newcomers-start-here/radeon-6000-series-failing-to-run-vulkan-application-developer/td-p/636173

I have some clues and I am investigating...

This is very bad. If I add a Print statement in the rendering thread the program works fine. If I replace the Print statement with Sleep(1000) then it crashes with no explanation. The debug build runs fine with no validation errors.

I have a 6600 now. Editor runs fine in debug mode but crashes in release mode with no messages...

It means I am busy testing an AMD card today, probably all day, but I will get to this after. I am assuming there is probably some bug.

Sorry, the albedo imagery doesn't come from LRO, I think it comes from the Clementine satellite.

I am curious, what do you plan to do with 64-bit floats that cannot be done with 32-bit? Ultra Engine is Leadwerks 5, and is due out soon, whenever I finish final testing. The main benefit of this engine is rendering performance. The engine has also been designed from the start to support double floats, but this is not included in the 1.0 version. All over the header files you can see statements like this: #ifdef DOUBLE_FLOAT dVec3 position; dMat4 matrix; #else Vec3 position; Mat4 matrix; #endif Of course there is more to it than that, but the whole engine was designed with this feature in mind. As I said, double float support by itself is not very useful. Beyond what I said above there are two more layers to the problem of realistic space simulation: There is actually no ready-to-use geospatial data set for the moon and other satellites. All the data served up by geo mapping systems is compressed to where it is unusable for 3D rendering. These are some slides from a presentation I showed NASA: To solve these problems, I developed the world's only lunar geospatial data set that is usable for 3D rendering, by processing the original full-resolution data from NASA. My program that does this takes a full day to run. I also developed a technique for recovering missing data from the moon above 60 degree latitude. (LRO's wide angle camera (WAC) does not have data for this region). It's sitting on a hard drive on my desk right now. That's just for the Earth's moon. I think Earth itself will be a bit easier to find good data for, and Mars will probably be similar to the moon data I have. Mars will probably require similar processing. I doubt there is much high-res data available for other planets, but the whole system will probably require an image server with a few terabytes at least. And then finally, because planets are not stationary in space, you need a system to track the movement of planets and even the sun. (The sun has a small orbit around a fixed point in space due to the gravitational pull of Jupiter.) I have identified the system to use for this, and compiled it in an Ultra project, but have not started working with it beyond browsing the docs. My direction is to build this to support a realistic model of Earth and space for the purposes of aerospace and defense simulations. I would probably try to license this technology to companies rather than selling it to game developers on Steam. In any case, getting the 1.0 version of Ultra out is the first step to doing anything.

Default orthographic viewport zoom now takes DPI scale into account.

Updated editor to solve viewport rendering issues reported here: https://www.ultraengine.com/community/topic/61866-windows-11-editor-issues/ V-sync is always disabled in-editor now because changing the vsync mode forces a swapchain recreation. May cause some timing issues while navigating viewports.

After a swap chain is created, if post-processing effects are enabled, it will take three calls to World::Render before anything except a black screen will appear. Related thread: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { EngineSettings settings; settings.asyncrender = false; Initialize(settings); //Get the displays auto displays = GetDisplays(); //Create window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_RESIZABLE | WINDOW_CENTER | WINDOW_TITLEBAR); //Create world auto world = CreateWorld(); //Create framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world, PROJECTION_ORTHOGRAPHIC); camera->SetClearColor(0,0,1,1); camera->SetDepthPrepass(false); auto fx = LoadPostEffect("Shaders/FXAA.fx"); camera->AddPostEffect(fx); while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { auto e = WaitEvent(); if (e.id == EVENT_KEYDOWN and e.data == KEY_SPACE) { camera->SetClearColor(Random(), Random(), Random()); world->Update(); world->Render(framebuffer); } } return 0; }

I found I can avoid this bug by drawing the viewport three times when a change of size is detected. The bug still exists in the engine, and should be fixed in the future, but it only happens in a non-realtime app and is a very specific problem. For now I am just going to avoid triggering it in the editor and that should be sufficient for our current needs. Continued here:

This simple example shows the problem. I have to hit the space key three times after each window resize before the screen renders again. Without the post effect it works fine: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { EngineSettings settings; settings.asyncrender = false; Initialize(settings); //Get the displays auto displays = GetDisplays(); //Create window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_RESIZABLE | WINDOW_CENTER | WINDOW_TITLEBAR); //Create world auto world = CreateWorld(); //Create framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world, PROJECTION_ORTHOGRAPHIC); camera->SetClearColor(0,0,1,1); camera->SetDepthPrepass(false); auto fx = LoadPostEffect("Shaders/FXAA.fx"); camera->AddPostEffect(fx); while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { auto e = WaitEvent(); if (e.id == EVENT_KEYDOWN and e.data == KEY_SPACE) { world->Update(); world->Render(framebuffer); } } return 0; }

This is a useful tool to make sure your computer is ready for Ultra: https://www.ozone3d.net/gpu_caps_viewer/ In the Vulkan section, the API version should be at least 1.3.

Yes, I just haven't gotten it yet.

My R9 280 is no longer receiving driver updates and the last driver only supports Vulkan 1.2...

I have temporarily disabled post-processing effects in the editor. Please confirm that this solves all your rendering problems.