[Ogre 2.1] Skybox

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

[Ogre 2.1] Skybox

Post by Jayray »

Hi!

I was wondering: in Ogre 2.1, what is the status of the skybox / skydome / skyplane?

In previous Ogre versions, I was using a skybox with a basic material script.
In Ogre 2.1, as the fixed pipeline is gone, I have written a GLSL shader to display my skybox, but I cannot get it to display... :(

Has the SceneManager::setSkyBox function already been ported to Ogre 2.1 and should it be working?
In this case, the issue must be in my shader.
However, I have noticed that the SceneManager::setSkyBox uses the render queue with ID #0. As I only have V2 items in my scene, can it explain my issue if these items are also in the #0 render queue?

Is it planned to change the skybox function to use HLMS instead of a low-level material?

Thanks!
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [Ogre 2.1] Skybox

Post by dark_sylinc »

Sky boxes/planes/etc status: Not tested, probably not working.

They're being targetted for elimination though. They do not belong in the SceneManager; and should be handled by a helper function instead (i.e. Item* item = SomeUtil::generateSkyBox( ... ) ).

Personally I prefer to use a post-process effect with a textureCube sample via low level material shader.
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Well, that is... an excellent idea!
I did not use post-process effects before Ogre 2.1, but you are right, it should be even better than a skybox as I could write a custom shader to display the sky the way I want to :)

Thanks a lot!
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

I am having some troubles in doing what I want for the sky.
I have done a basic compositor chain:

Code: Select all

compositor_node ClearNode
{
	texture rt0 target_width target_height PF_R8G8B8
	
	target rt0
	{
		pass clear
		{
			colour_value 0.8 0.92 0.92 1
		}
	}
	
	out 0 rt0
}

compositor_node SkyNode
{
	in 0 rt_input

	target rt_input
	{
		pass render_quad
		{
	    		material Sky
			use_quad true
		}
	}
	
	out 0 rt_input
}

compositor_node RenderNode
{
	in 0 rt_input

	target rt_input
	{
		pass render_scene
		{
			rq_first	0
			rq_last		max
			visibility_mask	0xfffffffe
		}
	}
	
	out 0 rt_input
}

compositor_node FinalNode
{
	in 0 renderWindow
	in 1 rtN

	target renderWindow
	{
		pass render_quad
	    {
	    	material Copy
	    	input 0 rtN
	    }	
	}
}

workspace MainWorkspace
{
	connect ClearNode SkyNode
	connect SkyNode RenderNode
	
	connect_output FinalNode 0
	connect RenderNode 0 FinalNode 1
}
I have 2 issues when doing this:

1. If I do not set "use_quad" in the render_quad pass of the "SkyNode" node, nothing is done in this pass. Is it normal?

2. In the fragment program linked to the "Sky" material, I would like to use some parameters : view_direction, render_target_flipping, etc. However, when I try to use them, Ogre crashes because there are NULL variables: current camera, render target, etc. I have noticed that in OgreCompositorPassQuad.cpp, the call to sceneManager->_injectRenderWithPass is commented, so the current camera is not set. Are there things left to do in the quad passes before all the parameters can be used? Or am I missing something?


This is the first time than I am doing compositor effects, so I may have done something wrong in my scripts... :roll:

EDIT: I can use the view direction if I disable the "SkyNode" node on launch and then enable it after the first frame is rendered, but I am not sure I am doing the right thing...
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [Ogre 2.1] Skybox

Post by dark_sylinc »

As for the use_quad thing: it depends on your shaders. If you read the documentation manual, when it is set to false an oversized triangle is used in a way that the UVs on the screen end up in range [0; 1)
If, for example, you use the old vertex shader from 1.x where the UVs were automatically generated, it will look incorrect.
Also make sure cull_hardware is set to none just in case.

The following vertex shader will work:

Code: Select all

#version 330

in vec4 vertex;
in vec2 uv0;
uniform mat4 worldViewProj;

out vec2 oUv0;

void main()
{
    gl_Position = worldViewProj * vertex;
    oUv0 = uv0.xy;
}

Code: Select all

vertex_program Ogre/Compositor/StdQuad_GLSL_vp glsl
{
	source StdQuad_vp.glsl
    default_params
    {
        param_named_auto worldViewProj worldviewproj_matrix
    }
}

material Ogre/Copy/4xFP16
{
	technique
	{
		pass
		{
			depth_check off
			depth_write off
			
			cull_hardware none

			vertex_program_ref Ogre/Compositor/StdQuad_GLSL_vp
			{
			}

			/*Add pixel shader here
			fragment_program_ref Ogre/Copy/4xFP16_ps
			{
			}*/
		}
	}
}
As for the crashes: Most likely an Ogre bug. I didn't check the auto params too much in the low level material implementation, so things like this are very likely.
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Thanks, I will try that!
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

I have managed to have a first version of skybox shader that I can use in a quad pass in a compositor node :)

If anyone is interested, here is the shader (only GLSL for now):

Sky.program:

Code: Select all

vertex_program Sky_vp glsl
{
	source Sky_vp.glsl
    default_params
    {
		param_named_auto worldViewProj worldviewproj_matrix
		param_named_auto viewDirection view_direction
    }
}

fragment_program Sky_ps glsl
{
	source Sky_ps.glsl
}
Sky_vp.glsl:

Code: Select all

#version 330
 
in vec4 vertex;
in vec2 uv0;

uniform mat4 worldViewProj;
uniform vec3 viewDirection;

out vec3 texturePosition;

void main()
{
    gl_Position = worldViewProj * vertex;
    
	vec3 uVec = cross(viewDirection, vec3(0, 1, 0));
	uVec = normalize(uVec);
	
	vec3 vVec = cross(viewDirection, uVec);
	vVec = normalize(vVec);
	
	texturePosition = normalize(viewDirection + (uVec * (uv0.x*2 - 1)) - (vVec * (uv0.y*2 - 1)));
}
Sky_ps.glsl:

Code: Select all

#version 330
 
in vec3 texturePosition;

uniform samplerCube cubemap;

out vec4 fragColor;
 
void main (void)
{
	fragColor = texture(cubemap, texturePosition);
}
Sky.material :

Code: Select all

material Sky
{
	technique
	{
		pass
		{
			depth_check off
			depth_write off

			cull_hardware none

			vertex_program_ref Sky_vp
			{
			}
			
			fragment_program_ref Sky_ps
			{
			}

			texture_unit
			{
				texture CubemapGimp.dds cube
				tex_address_mode clamp
			}
		}
	}
}
Compositor node (first node of the chain, before the scene is rendered):

Code: Select all

compositor_node SkyNode
{
	in 0 rt_input

	target rt_input
	{
		pass render_quad
		{
	    	material Sky
			use_quad true
		}
	}
	
	out 0 rt_input
}
However, there is 2 issues with this shader:
- It only works if Y is always the up vector of the screen (which means that a "leaning" effect will not display a correct sky)
- It does not work well when the view direction is (0, 1, 0) => limiting the vertical angle to 89,9 degrees hides the issue

Also, I do not know how this shader compares to other skyboxes on a performance point of view.
If anyone has a better idea, I am willing to hear it, but for now this shader suits my needs: I am able to display a skybox in Ogre 2.1 :D
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

Jayray wrote:EDIT: I can use the view direction if I disable the "SkyNode" node on launch and then enable it after the first frame is rendered, but I am not sure I am doing the right thing...
Hi Jayray,

Have you solved this problem or are you still launching the program with the Skynode disabled and then enable it after the first frame is rendered?


Thanks,
R.
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Hi,

At the moment I am still using this hack to make it work. But I have not tested removing it, maybe the issue has been fixed.
I will test it when I get some time :)
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

Jayray wrote:At the moment I am still using this hack to make it work. But I have not tested removing it, maybe the issue has been fixed.
It hasn't been yet fixed. :(
I'm working with the skybox right now.

I'm trying to directly fixing OGRE sources to avoid this crash.
I'll let you know if I will succeed.

In the meantime, can you explain me this part of your vertex shader?
It's not really clear to me.

I've found this article too, but it seems it uses a different approach. :/

Code: Select all

   vec3 uVec = cross(viewDirection, vec3(0, 1, 0));
   uVec = normalize(uVec);
   
   vec3 vVec = cross(viewDirection, uVec);
   vVec = normalize(vVec);
   
   texturePosition = normalize(viewDirection + (uVec * (uv0.x*2 - 1)) - (vVec * (uv0.y*2 - 1)));
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Yes, I had seen multiple articles following this approach, but I think they are not compatible with a quad pass.
If I am correct, in a quad pass, we only have 2 vertices that represent the screen, so the MVP matrix received in the shader is always the identity matrix.
Unless this is a bug in Ogre, but I doubt it.

The principle of my shader is the following:
- I retrieve the view direction vector as input. This view direction represents the normalized vector going from the camera to the center of the screen.
- The texture coordinates (uv0) represents the coordinate of the pixel on my screen, between 0 and 1. This means that, with uv0 = (0.5, 0.5), the pixel being calculated is the center of my screen.
- To get the colour of the central pixel, the view direction vector can directly be used with the 3D texture. For other pixels, the view direction vector shall be adjusted with the corresponding horizontal and vertical shift.
- To calculate the horizontal and vertical shift, we first need the vectors perpendicular to the view direction. These vectors are uVec and vVec.
- Then, (uv0.x*2 - 1) gives the horizontal translation between -0,5 and 0,5 and (uv0.y*2 - 1) gives the vertical translation (actually I think that this gives the opposite of the vertical translation, this is why I had to substract it)
- This means that uVec * (uv0.x*2 - 1) gives the horizontal translation vector and (vVec * (uv0.y*2 - 1) gives the vertical translation vector.
- By adding these two vectors to the viewDirection, we get the vector going from camera to the pixel on the screen being calculated

The only issue is that uVec cannot be calculated if the view direction is the (0, 1, 0) vector, so I had to limit the pitch to 89.9 degrees instead of 90.

Hope this helps!
And let me know if you find a better way to display a skybox :D
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

Thanks!
I kinda got it.

I'm thinking if this approach is feasible for me since my camera is attached to a rigid body I cannot guarantee it will never look up or down (pitch -90 or 90 degrees).

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Another approach I thought of is to create a cube with huge dimensions around the scene and to use the shaders in the article you have found.
I think it would work. Maybe even better, I do not know...
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

I'm considering that alternative too.

Anyway, I discovered some weirdness in your solution.

One is the cubemap is strechted by a factor related to the aspect ratio of the viewport.
The sun (which is a perfect circle) in my texture becomes an ellipsoid when I change the window resolution.

Another one is there is some warp effect on the edges of the scene.
This is easily noticeable when you yaw the camera around itself (I'll upload a video of it).

Do you have the same issues?

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

You are right. I did not notice the stretch factor because it is hard to see on my current texture, but it is there indeed.
About the warp effect, I think I know what you refer to, but I am not sure.

Concerning the "cube" solution, there might be one detail that could also cause some troubles: the view distance.
From what I know, the view distance can only be set for a camera, which means that it will apply to all objects, including the skybox...

In his first answer, dark_sylinc stated that he also used a post-process effect with a low level material shader for the skybox. But I do not know how he does to avoid these issues.

By the way, I have updated my Ogre sources today, and all my low level material shaders are broken with the OpenGL3+ renderer. Do you have the same issue?
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

I'm using the latest OGRE sources too and I don't have any problems neither with OpenGL3+ and DirectX 11.
At the moment, I don't have many low level shaders, but all the ones involved in the skybox pipelines are working as expected.

My guess about the warp and distortion issues is the vertex shader, when calculates the texturePosition vector, doesn't consider the camera FOV and aspect ratio.
The cubemap texture works if you map it onto a cube, but the fullscreen quad is (most of the times) rectangular.
From this discrepancy, the distortion/warp effect comes out.

I've slightly modified your shader to support up and down lookat and I'm able to correct distortion (I guess), but I can't figure out how to fix the warp problem.

I'll post the code tomorrow morning.

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [Ogre 2.1] Skybox

Post by dark_sylinc »

Use "quad_normals camera_far_corners_world_space" in the quad compositor script; use the normals attribute,
and read the texture cube using texture( cubeMapTexture, normals ); (no cross product or anything weird; just us the vector directly)
normals may need normalization in the vertex shader due to precision issues.
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

Holy fucking shit!

I completely miss that parameter in reading the porting manual.
Shame on me. :(

In my defense, it's one hour past midnight and I was starting to solve the the problem with this approach (which is, in some way, related to the quad_normals parameter).

Thanks for the help Matias.
Obviously, now it works like a charm.

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Damn!
Well, this is... almost too easy :D
Thanks a lot, I had not seen this parameter neither, I will try that tonight!
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

I still cannot get any material to work still I have updated my Ogre sources...
They worked perfectly before the depth textures and UAV had been implemented, but now it seems that the UV values passed to them is always (0, 0).

Here is my material:

Code: Select all

material Copy
{
    technique
    {
        pass
        {
            depth_check off
            depth_write off
            
            cull_hardware none

            vertex_program_ref Quad_vp
            {
            }

            fragment_program_ref Copy_ps
            {
            }

            texture_unit
            {
                tex_address_mode clamp
                filtering none
            }
        }
    }
}
And my compositor node:

Code: Select all

compositor_node FinalNode
{
    in 0 renderWindow
    in 1 rtN

    target renderWindow
    {
        pass render_quad
        {
            material Copy
            input 0 rtN
        }    
    }
}
It works fine with D3D11, but not with OpenGL3+ any more :(

By looking at the commits, I have seen this one which could explain my issue: https://bitbucket.org/sinbad/ogre/commi ... 826f65f5db
=> "Passes now need to explicitly tell which textures will be available for addressing by materials (CONTENT_COMPOSITOR)"

I have tried adding "content_type compositor rtN 1" to the texture unit in the material, but it is not working any better.
Is that the right way to do it? In this case, what is the use of "input 0 rtN" in the material script?

Is there something else wrong in my material? As the materials are working for you TaaTT4, I suppose that my issue is not due to a regression in the OpenGL3+ renderer :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [Ogre 2.1] Skybox

Post by dark_sylinc »

Can you make a quick repro?
Does it work with FSAA off? We had a similar problem a short time ago when FSAA was enabled in GL3+.
Sounds like a silly bug somewhere.
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [Ogre 2.1] Skybox

Post by TaaTT4 »

Hi dark_sylinc,

The solution you suggested to me seems to still have a problem.
You can see a brief example of it in this video:

[youtube]9G8PDNpQARA[/youtube]

While I just rotate the camera everything is OK, but as soon as I start to move it (at 0:15) the cubemap texture seems to move itself and starts to become distorted.

I don't know if this behaviour is a bug, is intended or (maybe) if, before to draw the cubemap texture, I have to position the camera at the center of the world.
For what I know, the frustum corner vectors (obtained by the camera_far_corners_world_space compositor parameter) shouldn't be affected by camera movements.
Am I wrong?

Anyway, these are the compositor/material/program/sources:

Code: Select all

compositor_node Numen/Skybox
{
	texture render_target target_width target_height PF_R8G8B8
	
	target render_target
	{
		pass clear
		{
		}

		pass render_quad
		{
			quad_normals camera_far_corners_world_space

			material Numen/Skybox
		}
	}
	
	out 0 render_target
}


material Numen/SkyboxCube
{
	technique
	{
		pass
		{
			depth_check off
			depth_write off

			cull_hardware none

			texture_unit
			{
			}

			vertex_program_ref Numen/Skybox_vs_glsl
			{
				texture Cube.dds cubic
			}

			fragment_program_ref Numen/Skybox_ps_glsl
			{
			}
		}
	}
}


vertex_program Numen/Skybox_vs_glsl glsl
{
	source Shaders/Glsl/Skybox_vs.glsl

	default_params
	{
		param_named_auto worldViewProj worldviewproj_matrix
	}
}


fragment_program Numen/Skybox_ps_glsl glsl
{
	source Shaders/Glsl/Skybox_ps.glsl

	default_params
	{
		param_named sampler int 0
	}
}
This is the vertex shader:

Code: Select all

#version 330


in vec4 vertex;
in vec3 normal;

out vec3 ps_uvw0;


uniform mat4 worldViewProj;




void main()
{
	gl_Position = worldViewProj * vertex;

	ps_uvw0 = normalize(normal) * vec3(1.0, 1.0, -1.0);
}
And, finally, this is the pixel shader:

Code: Select all

#version 330


in vec3 ps_uvw0;

layout(location = 0) out vec4 color0;


uniform samplerCube sampler;




void main()
{
	color0 = texture(sampler, ps_uvw0);
}

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

This is strange, I do not observe this warp effect in my case, even with my shader...
At the moment I have no clue where it could come from :(

Thanks for your sources!
Concerning my issue, the problem is the same with FSAA off :(
It seems that the material can access the texture from compositor, but as the UV is always (0, 0), the whole output texture has the same colour.

I am creating a repro, I will upload it when I am done.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [Ogre 2.1] Skybox

Post by dark_sylinc »

TaaTT4 wrote:Hi dark_sylinc,

The solution you suggested to me seems to still have a problem.
You can see a brief example of it in this video:

While I just rotate the camera everything is OK, but as soon as I start to move it (at 0:15) the cubemap texture seems to move itself and starts to become distorted.

I don't know if this behaviour is a bug, is intended or (maybe) if, before to draw the cubemap texture, I have to position the camera at the center of the world.
That's a cool effect, so I'm going to say it's a feature!

I think I know what's going on. You should subtract the camera position from the "normals" (pass it via an uniform).
Maybe I should add an option so that the normals being passed already have the camera position subtracted.
Jayray wrote:Thanks for your sources!
Concerning my issue, the problem is the same with FSAA off :(
It seems that the material can access the texture from compositor, but as the UV is always (0, 0), the whole output texture has the same colour.

I am creating a repro, I will upload it when I am done.
That's weird then. It's hard to say what is wrong without analyzing the program.
By the way the UAV thing has not yet been incorporated to the main branch, it is being kept in a separate branch (for the time being)
User avatar
Jayray
Greenskin
Posts: 115
Joined: Sun Sep 09, 2012 5:29 pm
Location: Strasbourg, France
x 9

Re: [Ogre 2.1] Skybox

Post by Jayray »

Here is a quick and (very) dirty repro of my issue:
- D3D11: the texture coords are well passed
- OpenGL3+: the texture coords are always (0, 0)

Thanks for your help!
Attachments
OgreRepro.zip
(13.91 KiB) Downloaded 277 times
Post Reply