Jump to content
  • Advertisement

Recommended Posts

Hi,

I finally managed to get the DX11 emulating Vulkan device working but everything is flipped vertically now because Vulkan has a different clipping space. What are the best practices out there to keep these implementation consistent? I tried using a vertically flipped viewport, and while it works on Nvidia 1050, the Vulkan debug layer is throwing error messages that this is not supported in the spec so it might not work on others. There is also the possibility to flip the clip scpace position Y coordinate before writing out with vertex shader, but that requires changing and recompiling every shader. I could also bake it into the camera projection matrices, though I want to avoid that because then I need to track down for the whole engine where I upload matrices... Any chance of an easy extension or something? If not, I will probably go with changing the vertex shaders.

Share this post


Link to post
Share on other sites
Advertisement
Posted (edited)

I flip the coordinates in my vertex shader, but I also generate my shaders from another representation, and the fixup happens "automatically". A similar fixup is done in my OpenGL shaders to reconcile the clip-space differences there (z-range).

Edited by mellinoe

Share this post


Link to post
Share on other sites

Thank you both, for the time being I will go with flipping in the vertex shaders. Though I have no system in place, I will have to manually add that with a SPIRV macro. This way I don't have to mess with culling direction.

Share this post


Link to post
Share on other sites

Hi turanszkij, I have different matrix projection methods in Matrix4x4 class:

Matrix4x4::PerspectiveFovVulkan

Matrix4x4::PerspectiveFovDirect3D(also can be used for OpenGL)

Matrix4x4::OrthoVulkan

Matrix4x4::OrthoDirect3D

My implementation Direct3D11Render/VulkanRender/OpenGLRender knows wich methods of Matrix4x4 need to call.

Share this post


Link to post
Share on other sites
On ‎20‎/‎04‎/‎2018 at 8:52 PM, Andrey OGL_D3D said:

Hi turanszkij, I have different matrix projection methods in Matrix4x4 class:

Matrix4x4::PerspectiveFovVulkan

Matrix4x4::PerspectiveFovDirect3D(also can be used for OpenGL)

Matrix4x4::OrthoVulkan

Matrix4x4::OrthoDirect3D

My implementation Direct3D11Render/VulkanRender/OpenGLRender knows wich methods of Matrix4x4 need to call.

Interesting idea. I also thought about it but I have problems with: I need to track down every instance of using a projection matrix. And sometimes I don't even use a projection matrix, for example full screen triangle. This results in discrepancy and for those cases I also need to rewrite the shader or flip viewport. Also, I don't want to couple the math lib with graphics api. :)

Share this post


Link to post
Share on other sites

Hi turanszkij, 

Quote

 I need to track down every instance of using a projection matrix.

Also, I don't want to couple the math lib with graphics api. 

Anyway, if you have multi graphics rendering support, you should resolve any cases with different matrix/viewPort/clipping in the Rendering implementation side or in user side. For example, user should set Light Projection matrix for Shadow Map, but this matrix is different for Direct3D11/Vulkan. How to resolve this ?

1) You can add some macro definition to resolve clip cases in your shaders.

2) Call Matrix method renderInterace->CreateProjectionMatrix

 

Share this post


Link to post
Share on other sites

I am now facing the exact same problem. I have just tried viewport height negating with VK_KHR_maintenance1 extension and it seems to work fine at least for the main framebuffer. It also works in cases when shaders do not rely on projection matrix, so that my test triangle looks identical in all 4 support APIs.

Share this post


Link to post
Share on other sites

After updating to the LunarG SDK version 1.1.73.0 I noticed that glslangvalidator has gained this parameter:

--invert-y | --iy invert position.Y output in vertex shader

Sounds like exactly what we need. I haven't tried it out yet though.

Share this post


Link to post
Share on other sites

I tried out the parameter last night and it does what it says on the can, so that's probably the easiest way to fix it up without having to flip the coordinate manually in the shader code.

Not related to this, but I had some very strange issues with glslangvalidator 1.1.73.0 generating sub-optimal SPIR-V, almost as if the spirv-opt step that's supposed to be built into the LunarG version of the program was not run. Anyway, I had to revert to 1.1.70.0, but as it turned out the invert-y parameter is available with that version too :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!