[SOLVED] [2.1] Issue with forward plus and VR type apps

[al2950]

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

[dark_sylinc]

Any help with this would be appreciated, as I am currently stuck using Basic forward rendering for my VR apps

That's all you need!

Firstly Forward3D::fillConstBufferData && ForwardClustered::fillConstBufferData do not take into account the viewport size (only render target size)

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?

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

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, 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)

[al2950]

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?

Yes and no! First off you dont have access to the VP so I just multiple the width by 0.5 for my tests.
- 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!

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

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.

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)

I shall go and check that now, sounds like something I may have overlooked

[xrgo]

that don't render to the whole render target, eg half viewport

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]

that don't render to the whole render target, eg half viewport

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?

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.
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

[xrgo]

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

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

I want all :/

[al2950]

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)?

maybe if its the same for me, you can do it like I do and avoid those problems

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]

Or do you have one compositor that takes 2 render targets (channels)?

yes!

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
}

in the second target renderAux, the render_scene that only does the overlays reuse all the stuffs, I don't remember well (can't test until monday) but I think I did that so it does not use the cull info of this render_scene for the right eye target renderAux, and maintain the data of the first target renderAux corresponding to the left eye. I think if I don't do that the right eye was all black.

[al2950]

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.

[al2950]

FYI I recent'ish commit broke this fix, but there is a PR here to resolve the issue
**EDIT** It has been merged