Ultra Engine testing

[Josh]

21 minutes ago, klepto2 said:

Another thing is that my Computepipeline isn't working anymore. There seems to be some changes regarding image initialisation. I need a way to savely retreive the current VkImageLayout to transition to the required one. Maybe its due to the new VulkanSDK as well, but this is the current message i get:

Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x1f970310e50, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x1f970310e50[] expects VkImage 0x7992cc00000002d1[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.

Any idea?
 

If the image layout is undefined that means the initial image has not been initialized / had any pixel data sent to it yet. I gave up on image layouts and I just use the general layout for everything, but there is still the first transition from UNDEFINED to GENERAL.

The CreateTexture function is designed to avoid this problem, but maybe a texture is being created somehow without any pixel data being applied?

[Josh]

You guys in the developer group can see the store page WIP:
https://www.ultraengine.com/community/store/product/11-ultra-engine-early-access/

The interface allows you to purchase any number of months at a time, so that takes care of one request we had, without making a separate product.

[klepto2]

I only use textures generated with createtexture, but as I register the hooks right from the start it might be, that the textures are not initialized in the first run. I will check this tomorrow. But how can I check if a texture is already initialized? 
Maybe if I wait for the first transfer hook to finish, before I run anything else?

[Josh]

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.

[Josh]

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

[klepto2]

Yes, in release it works as expected. But It could be that it is just ignored until it has the correct layout.

[Josh]

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.

[klepto2]

I already have found this, but I can’t access it  well, with some small modifications to the texture.h it would be possible. But not out of the box.

[Josh]

You can't get the RenderTexture object?

[Josh]

I'll see what I can do...

[klepto2]

The texture class has only protected member for the rendertexture, like most more deeper members. And as it is protected only friend classes can access them. Same goes for some members of the camera class which could be handy ( all matrix stuff for example).

[klepto2]

Ok, I investigated it a bit further. It seems to be a synchronization problem due to the async architecture of vulkan itself.

As it works in release or by deactivating the validationlayers in debug mode. I will not look into it right now as i plan to refactor the whole system anyway later to have its own cmdbuffer and queues, which ideally should solve this.

for those who are interested: to deactivate all validation layers in Ultraengine:

UltraRender::GPUDevice::validationlayers.clear();

Put this on top of your application. 

[Josh]

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.

49 minutes ago, klepto2 said:

Ok, I investigated it a bit further. It seems to be a synchronization problem due to the async architecture of vulkan itself.

It should never happen. I will have an update tonight that adds a new function UltraRender::GetRenderTexture so you can test.

[klepto2]

I get the access to Rendertexture by modifing the headers a bit: 

i added a class predfintion in the texture.h like:  class TextureMemberAccessor;

and in the Texture class i added a friend class TextureMemberAccessor;

Then i could do the following in my code:

namespace UltraEngine
{
	class TextureMemberAccessor
	{
	public:
		static shared_ptr<UltraRender::RenderTexture> GetRenderTexture(shared_ptr<Texture> texture)
		{
			return texture->rendertexture;
		}
	};
}

It is a very ugly way, but for testing purposes it is temporay valid.

But the GetLayout() member returns GENERAL, but as your code keeps sink of it, it might not yet be the correct state in the vulkan layer. I will test this a bit further.

[Josh]

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?

[klepto2]

no, I just create the views myself. But I have tracked it a bit further down. It is definitly not on your side. In my Atmospheric scattering code i run around 30 computeshaders, and only one is causing the trouble ant that might be due to a pingpong algorithm i use. All other shaders work flawlessly. I think it might be just a simple access problem which is now catched with the new sdk and was not catched before.

 

[klepto2]

Ok, i found the problem

It seems that the ktx2 and png loaders are broken. if i change all of my textures to be dds or generated on the fly it works. But as soon as i load a ktx2 or png image i get this validation error. I will check if i can provide a sample.

[klepto2]

#include "UltraEngine.h"
#include "ComponentSystem.h"

using namespace UltraEngine;

int main(int argc, const char* argv[])
{
    auto plg = LoadPlugin("Plugins/KTX2TextureLoader");
    auto plg2 = LoadPlugin("Plugins/FITextureLoader");

    //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, -3);

    //Create a light
    auto light = CreateBoxLight(world);
    light->SetRotation(35, 45, 0);
    light->SetRange(-10, 10);

    //Create a box
    auto box = CreateBox(world);
    box->SetColor(0,0,1);

    auto box_mat = CreateMaterial();
    auto texture = LoadTexture("Materials/curlNoise.png");
    box_mat->SetTexture(texture, TEXTURE_DIFFUSE);
    box->SetMaterial(box_mat);

    //Entity component system
    auto actor = CreateActor(box);
    auto component = actor->AddComponent<Mover>();
    component->rotation.y = 45;

    //Main loop
    while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false)
    {
        world->Update();
        world->Render(framebuffer);
    }
    return 0;
}

if you run the above code, you will still see a blue box. The app output states that the image is loaded succesfully, but it seems it is not uploaded.

[SpiderPig]

I have also found something - moving away from the world origin makes the environment background jitter wildly and it gets very pixelated.  I haven't measured it but it must only be a few hundred metres away form the origin, if that.

[Josh]

Update

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

[Josh]

7 hours ago, SpiderPig said:

I have also found something - moving away from the world origin makes the environment background jitter wildly and it gets very pixelated.  I haven't measured it but it must only be a few hundred metres away form the origin, if that.

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;
}

 

[SpiderPig]

Okay I may have drastically underestimated the distance based on forgetting how fast I actually made my camera move!  You will see some wiggling at 10,000 and the pixilation at 100,000.  This is the point where it needs double precision yes?

 camera->SetPosition(100000, 0, 0);

 

Also confirming the shader reload has been fixed. 

[klepto2]

This, or make the camerarange 1.0 to 1000.0 instead of 0.1 to 1000.0

[Josh]

21 minutes ago, SpiderPig said:

This is the point where it needs double precision yes?

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

[SpiderPig]

How do I run in 64bit mode?  Do I just define DOUBLE_FLOAT in UltraEngine.h?