[SOLVED] [2.1] Issue with forward plus and VR type apps
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
[SOLVED] [2.1] Issue with forward plus and VR type apps
Hi I have been fighting an issue with the forward plus implementations with non standard renders. These inlcude VR type apps that have custom projection matrix and apps that dont render to the whole render target, eg half viewport.
I have altered the Forward 3D demo to show these issues, src which can be found here;
https://bitbucket.org/al2950/ogre-2.x-u ... lus_Issues
There are a number of issues that I found.
Firstly Forward3D::fillConstBufferData && ForwardClustered::fillConstBufferData do not take into account the viewport size (only render target size)
Secondly ForwardClustered re-engineers a camera projection matrix from input values (eg FoV, aspect ratio, etc), which is unhelpful when using custom projection matrix, also it does not take into account frustrum offsets. As you can see from the following code I try to re-engineer some values required by ForwardClustered, but probably have mistakes, although they do improve the issues;
https://bitbucket.org/al2950/ogre-2.x-u ... d3D.cpp-62
Any help with this would be appreciated, as I am currently stuck using Basic forward rendering for my VR apps
I have altered the Forward 3D demo to show these issues, src which can be found here;
https://bitbucket.org/al2950/ogre-2.x-u ... lus_Issues
There are a number of issues that I found.
Firstly Forward3D::fillConstBufferData && ForwardClustered::fillConstBufferData do not take into account the viewport size (only render target size)
Secondly ForwardClustered re-engineers a camera projection matrix from input values (eg FoV, aspect ratio, etc), which is unhelpful when using custom projection matrix, also it does not take into account frustrum offsets. As you can see from the following code I try to re-engineer some values required by ForwardClustered, but probably have mistakes, although they do improve the issues;
https://bitbucket.org/al2950/ogre-2.x-u ... d3D.cpp-62
Any help with this would be appreciated, as I am currently stuck using Basic forward rendering for my VR apps
Last edited by al2950 on Fri Sep 22, 2017 11:12 pm, edited 1 time in total.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Issue with forward plus and VR type apps
That's all you need!al2950 wrote:Any help with this would be appreciated, as I am currently stuck using Basic forward rendering for my VR apps
Mmm... interesting problem.al2950 wrote:Firstly Forward3D::fillConstBufferData && ForwardClustered::fillConstBufferData do not take into account the viewport size (only render target size)
Does the problem get fixed if you modify it to use vp->getActualWidth() and getActualHeight()? Or it still breaks because the right eye shader needs to consider left and top?
Interesting. It sounds like adding:Secondly ForwardClustered re-engineers a camera projection matrix from input values (eg FoV, aspect ratio, etc), which is unhelpful when using custom projection matrix, also it does not take into account frustrum offsets. As you can see from the following code I try to re-engineer some values required by ForwardClustered, but probably have mistakes, although they do improve the issues;
https://bitbucket.org/al2950/ogre-2.x-u ... d3D.cpp-62
Code: Select all
camera->setCustomProjectionMatrix( mCurrentCamera->isCustomProjectionMatrixEnabled(),
mCurrentCamera->getProjectionMatrix() );
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [2.1] Issue with forward plus and VR type apps
Yes and no! First off you dont have access to the VP so I just multiple the width by 0.5 for my tests.dark_sylinc wrote:Mmm... interesting problem.
Does the problem get fixed if you modify it to use vp->getActualWidth() and getActualHeight()? Or it still breaks because the right eye shader needs to consider left and top?
- for Forward3D it seems to fix the issues (although the example I put together still seems to have issues, but works fine in my real app !)
- for ForwardClustered it does not. However if I also ensure the camera FoV, aspectRatio & frustrm offset are sensible AND ensure ForwardClustered uses frustrum offset, the left viewport works and the right hand viewport does not. I assumed this was down to some assumptions about gl_fragCoord in the shaders..??
The big issue with VR frustrums are that they are asymmetric, creating mathematical headaches everywhere!
This might work for Forward3D but ForwardClustered seems to create a number of its own frustums based on slice near & far distances. As a result, at least the current way its written you cant do this. I dont understand the maths enough to know how it might be changed to work with custom frustrums.dark_sylinc wrote: Interesting. It sounds like adding:
CODE: SELECT ALL
camera->setCustomProjectionMatrix( mCurrentCamera->isCustomProjectionMatrixEnabled(),
mCurrentCamera->getProjectionMatrix() );
When we clone the FOVs and other settings should fix it
I shall go and check that now, sounds like something I may have overlookeddark_sylinc wrote:plus you need to modify ForwardPlusBase::getCachedGridFor so that it considers comparing projections matrices; otherwise Ogre will attempt to reuse cached results when it shouldn't (because the custom projection matrix is different / doesn't use custom proj. matrix)
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Issue with forward plus and VR type apps
I think I tried this but I don't remember how it went... sorry, now I just use a single texture per eye so I don't have to deal with that, openVR is working with no problem... but I am always seeking for any performance boost, in you experience, is it faster rendering like that?al2950 wrote:that don't render to the whole render target, eg half viewport
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [2.1] Issue with forward plus and VR type apps
I have not had the time to do any real world official tests, but just looking at FPS I gained 75% more performance on my laptop (Dell XPS 15 9560) where I was doing the development. The performance improvements come from a number of areas.xrgo wrote:I think I tried this but I don't remember how it went... sorry, now I just use a single texture per eye so I don't have to deal with that, openVR is working with no problem... but I am always seeking for any performance boost, in you experience, is it faster rendering like that?al2950 wrote:that don't render to the whole render target, eg half viewport
1) doing render target clears and other full screen things like post processing (tonemapping, blur etc) only needs to be done once. (It of course is more pixels but its more friendly to the GPU, then splitting it into 2 and doing it twice)
2) re-using shadow nodes. It makes it much easier to create compositor scripts which reuse the shadow nodes, so shadow cameras are rendered only once not twice.
3) re-using culling data. It again makes it easier to share culling data between eyes. So I have a culling frustrum that covers both eyes, but only run the culling code once, and then reuse it for the other eye.
To be honest there are many other things that would improve performance further, but would require changes to Ogre. This is a brief but useful presentation on some of the techniques; (I am using the 'submit entire scene twice' technique)
https://docs.google.com/presentation/d/ ... 0d2a7c_061
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Issue with forward plus and VR type apps
thanks for the answer, I am doing 2) and 3) with no problem (I guess, maybe I am doing it wrong and its not working :S)... I don't think I'll get much improvement in 1),my post process is very simple and clears (I think) are very cheap, still.. I am going to try... maybe if its the same for me, you can do it like I do and avoid those problems
I want all :/al2950 wrote:To be honest there are many other things that would improve performance further, but would require changes to Ogre. This is a brief but useful presentation on some of the techniques; (I am using the 'submit entire scene twice' technique)
https://docs.google.com/presentation/d/ ... 0d2a7c_061
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [2.1] Issue with forward plus and VR type apps
Can you reuse shadow nodes across different compositors!? I always assumed that would not work! Or do you have one compositor that takes 2 render targets (channels)?
i guess it all depends on your requirements. I unfortunately was trying to get our application to run on a laptop with a 1060, running at 90+ FPS with a VR render + another render window with completely different camera, with full dynamic (lighting) scene with volumetric clouds, 100s of lights, oh and 2 other USB monitors running their own 3D apps! #badweekintheoffice!xrgo wrote:maybe if its the same for me, you can do it like I do and avoid those problems
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Issue with forward plus and VR type apps
yes!al2950 wrote:Or do you have one compositor that takes 2 render targets (channels)?
Code: Select all
compositor_node MainEngineRenderingNodeStereo
{
in 0 renderTexLeft
in 1 renderTexRight
in 2 TerraShadowTexture
texture renderAux target_width target_height PF_FLOAT16_RGB
target renderAux
{
pass clear
{
colour_value 0 0 0 1
}
pass render_scene
{
expose TerraShadowTexture
camera CameraLeft
cull_camera CameraCull
overlays off
shadows MainEngineShadowNode first
}
}
target renderTexLeft
{
pass render_quad
{
overlays off
material FinalProcessingMat
input 0 renderAux
}
pass render_scene
{
cull_camera CameraCull
cull_reuse_data true
lod_update_list off
shadows MainEngineShadowNode reuse
//Render Overlays
overlays on
rq_first 254
rq_last 255
}
}
target renderAux
{
pass clear
{
colour_value 0 0 0 1
}
pass render_scene
{
camera CameraRight
cull_camera CameraCull
cull_reuse_data true
lod_update_list off
overlays off
shadows MainEngineShadowNode reuse
}
}
target renderTexRight
{
pass render_quad
{
overlays off
material FinalProcessingMat
input 0 renderAux
}
pass render_scene
{
lod_update_list off
//Render Overlays
overlays on
rq_first 254
rq_last 255
}
}
}
workspace MainEngineWorkspaceStereo
{
connect_external 0 MainEngineRenderingNodeStereo 0
connect_external 1 MainEngineRenderingNodeStereo 1
connect_external 2 MainEngineRenderingNodeStereo 2
}
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [2.1] Issue with forward plus and VR type apps
Thanks for the info.
I have created a pull request that fixes all the issues described here
https://bitbucket.org/sinbad/ogre/pull- ... fixes/diff
Please note it does do a breaking change for setExtents. I have tried to make it clearer and fix an issues caused by getExtents returning tan half angles when the system was expecting clip plane positions. As a result both getExtents and setExtents take an enum (instead of a bool) which describes/requests the format for the extents.
I have created a pull request that fixes all the issues described here
https://bitbucket.org/sinbad/ogre/pull- ... fixes/diff
Please note it does do a breaking change for setExtents. I have tried to make it clearer and fix an issues caused by getExtents returning tan half angles when the system was expecting clip plane positions. As a result both getExtents and setExtents take an enum (instead of a bool) which describes/requests the format for the extents.
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [SOLVED] [2.1] Issue with forward plus and VR type apps
FYI I recent'ish commit broke this fix, but there is a PR here to resolve the issue
**EDIT** It has been merged
**EDIT** It has been merged