Reflections for asymmetric camera frustums

[ulf.schroeter]

When setting an asymmetric camera frustum water reflections do not render correctly. See attached example screenshot for camera frustum settings

 

• left -16
  
• right 16
  
• top 10
  
• bottom -15
  
• near 0.1
  
• far 10000.0
  

[pascal.winistoerfer]

When setting an asymmetric camera frustum water reflections do not render correctly. See attached example screenshot for camera frustum settings

 

• left -16
  
• right 16
  
• top 10
  
• bottom -15
  
• near 0.1
  
• far 10000.0
  

 

 

Hey Ulf

 

Did you try to set the Surface Opacity down? (Multiply)

 

It looks to me a bit like the surface is the reason why the ship is not correct reflected, if you mean this with your issue.

[ulf.schroeter]

Hey Ulf

 

Did you try to set the Surface Opacity down? (Multiply)

 

It looks to me a bit like the surface is the reason why the ship is not correct reflected, if you mean this with your issue.

 

Hi Pascal,

 

the problem is that the ship reflection is vertically "detached" from the ship. In the screenshot it looks like the ship is hovering above the water, but actually it is located right on the water surface. Therefore the reflection should appear directly "below" the ship hull waterline (as you can see in the first picture of these showcase screenshots rendered with symmetric camera frustum)

[ulf.schroeter]

Dear UNIGINE support,

 

any possible fixes for this bug ? At the moment this is unfortunately a show-stopper for our project :)

[Guest extaliones]

We will fix this issue, please, stand by.

[ulf.schroeter]

Small test case for problem reproduction

 

[frustum]

It seems like the problem is solved.

[ulf.schroeter]

It seems like the problem is solved.

 

Thanks a lot !

[ulf.schroeter]

It seems like the problem is solved.

 

Alexander, just 2 more questions (I am sorry :( )

 

1) Will vertical frustum shear like

 

vertical shear

left     -15
right     45
bottom   -30
top       30

vertical+horizontal shear

left     -15
right     45
bottom   -40
top       20

 

also be handled correctly ?

 

2) Do you know a clever trick to simulate mirrored scene rendering (e.g. for picture-in-picture rendering of car mirror showing the backward street scene vertically fliped)

 

When trying to achive this effect by simply specifying inverted right/left player frustum angles ( e.g left = 30.0 / right= -30.0 ) we get the following - interesting but obviously wrong - result for box geometry with the above test scene

 

[frustum]

All configurations are ok:

 

-25; 25; -25; 15

 

 

-15; 45; -30; 30

 

 

-15; 45; -40; 20

 

 

40; -30; -40; 20 with two sided material:

 

[ulf.schroeter]

I have tested SDK-2010-1101 but there still seems to be problems when view frustum is sheared up/downwards (only left/right shear works). Please find attached the modified test case with different none-working camera frustum setups in wolrd-script init().

 

 

Also there seems to be shadow/scattering rendering artifacts in case of asymmetric frustum. I will try to prepare short test case.

asymmetric-frustum-reflection.zip

[ulf.schroeter]

Also there seems to be shadow/scattering rendering artifacts in case of asymmetric frustum. I will try to prepare short test case.

 

Attached test case shows remaining reflection and scattering artifacts for asymmetric camera frustums.

 

Problem 1 Reflections

 

For VERTICAL "up/down" asymmetric camera frustum rendering of reflections is still incorrect. Moving reflections can be seen during camera rotation. For horizontal "left/right" asymmetric frustum reflections seem to be correct.

 

 

Problem 2 Scattering

 

For ALL asymmetric frustum configurations scattering changes its horizon-relative attitude both on configuration change and camera rotation. Actually horizon-relative attitude should be static.

 

 

AsymmetricFrustum.zip

[frustum]

I will fix this issue later. Support of asymmetric frustums will be controlled by console variable disabled by default because complexity of post processing shaders will be increased.

[cor]

I will fix this issue later. Support of asymmetric frustums will be controlled by console variable disabled by default because complexity of post processing shaders will be increased.

 

 

Hi

Are these asymmetric frustum problems solved now?

[ulf.schroeter]

Are these asymmetric frustum problems solved now?

 

Not yet

[frustum]

The problem is fixed in the upcoming update.

[frustum]

There is no asymmetric issues anymore.

[ulf.schroeter]

Support of asymmetric frustums will be controlled by console variable disabled by default because complexity of post processing shaders will be increased.

 

Hi Alexander, very good news ! Is above statement still valid or will asymmetric frustum support now be a general feature ?

[frustum]

Above statements are valid and all engine features will support asymmetric projections.

[cor]

There is no asymmetric issues anymore.

 

Very good news.

How will these asymmetric frustums influence peformance?

[frustum]

I was wrong about asymmetric projection slowdown. There is no difference in performance between symmetric and asymmetric projections.

Attached photo is a new "D3D11AppWall : Unigine::App" class for configurable wall display output (3x1 in this case).

Heaven demo running on HD5870 with tessellation on three full HD displays. Side displays have asymmetric projection.

[ulf.schroeter]

I was wrong about asymmetric projection slowdown. There is no difference in performance between symmetric and asymmetric projections.

Attached photo is a new "D3D11AppWall : Unigine::App" class for configurable wall display output (3x1 in this case).

Heaven demo running on HD5870 with tessellation on three full HD displays. Side displays have asymmetric projection.

 

Looks great ! Is there some new support for rendering to multiple render contexts ? Or do you use multiple WidgetSpriteViewports ?

 

BTW: image size is 2,5 MB, not sure if my internet connection is slow, but download took quite some time...

[frustum]

UnigineRender.h will allow to call engine render functions directly into the current render target.

AppWall creates three windows and calls renderViewport() function on each window.

AppWall exports additional functions into the Unigine script also:

 

define HAS_APP_WALL.
int engine.wall.getWidth()
int engine.wall.getHeight()
void engine.wall.setPrimary(int x,int y)
void engine.wall.setEnabled(int x,int y,int enable)
engine.wall.setViewportMask(int x,int y,int mask)
engine.wall.setReflectionMask(int x,int y,int mask)
engine.wall.setProjection(int x,int y,mat4 projection)
engine.wall.setModelview(int x,int y,Mat4 modelview)

 

namespace Unigine {

/**
 * @brief Unigine render.
 */
class Render {

	protected:

		/**
		 * @brief Virtual destructor.
		 */
		virtual ~Render() { }

	public:

		/**
		 * @brief Return pointer to the existing render.
		 * @return Pointer to the existing render.
		 */
		static UNIGINE_API Render *get();

		/**
		 * @brief Enable or disable render.
		 * @param enable 1 to enable render, 0 to disable it.
		 */
		virtual void setEnabled(int enable) const = 0;
		/**
		 * @brief Return a value indicating, if the render is enabled.
		 * @return Return 1 if the render is enabled; otherwise, 0 is returned.
		 */
		virtual int isEnabled() const = 0;

		/**
		 * @brief Renders viewport into the current render target.
		 * @param projection Projection matrix.
		 * @param modelview Modelview matrix.
		 * @param materials Post materials, comma separated.
		 * @param viewport_mask Viewport bit mask.
		 * @param reflection_mask Reflection bit mask.
		 * @param shadows Shadows toggle.
		 */
		virtual void renderViewport(const mat4 &projection,const UNIGINE_MAT4 &modelview,const char *materials,int viewport_mask,int reflection_mask,int shadows) const = 0;
		/**
		 * @brief Renders specific node with all childs into the current render target.
		 * @param projection Projection matrix.
		 * @param modelview Modelview matrix.
		 * @param node Target node pointer.
		 * @param viewport_mask Viewport bit mask.
		 * @param reflection_mask Reflection bit mask.
		 * @param shadows Shadows toggle.
		 */
		virtual void renderNode(const mat4 &projection,const UNIGINE_MAT4 &modelview,NodePtr node,int viewport_mask,int reflection_mask,int shadows) const = 0;

		/**
		 * @brief Renders scene into the 2D image.
		 * @param projection Projection matrix.
		 * @param modelview Modelview matrix.
		 * @param image Destination image pointer.
		 * @param width Width of image.
		 * @param height Height of image.
		 * @param materials Post materials, comma separated.
		 * @param hdr HDR toggle.
		 */
		virtual void renderImage2D(const mat4 &projection,const UNIGINE_MAT4 &modelview,ImagePtr image,int width,int height,const char *materials,int hdr) const = 0;
		/**
		 * @brief Renders scene into the Cube image.
		 * @param projection Projection matrix.
		 * @param position World position.
		 * @param image Destination image pointer.
		 * @param size Size of image.
		 * @param materials Post materials, comma separated.
		 * @param hdr HDR toggle.
		 */
		virtual void renderImageCube(const mat4 &projection,const UNIGINE_VEC3 &position,ImagePtr image,int size,const char *materials,int hdr) const = 0;
};

} /* namespace Unigine */

[ulf.schroeter]

Great solution ! Especially as per wall window modelview/projection matrix specification will also allow to define overlapping window regions required for edge blending on projection walls. Blend masks texture and per-pixel distorsion correction can then be applied as simple window-specific post materials.

[frustum]

Not all bugs related to asymmetric projections were fixed. Horizontally asymmetrical projections resulted to wrong deferred lights and light scattering. Moreover bug with planar reflection wasn't fixed.

Asymmetric projections will work correctly with the following SDK.

 

core/scripts/wall.h will support 1x2, 2x1, 2x2, 3x1, 3x2, 4x1 and 5x1 display configurations.