In OpenGL, the typical way that I've seen to set up a skybox using cubemapping is to create a cube in camera space, prepare a cubemap sampler with the appropriate six-sided texture, and then in the pixel shader use the camera space direction of the pixel as the input to texCUBE. What I'm wondering is, if instead of this, I set up the same cube, but then simply textured each face of the cube with the appropriate face of the cubemap texture, and then rendered the cube with a standard shader, would it achieve the same visual effect?
\$\begingroup\$
\$\endgroup\$
1
-
1\$\begingroup\$ See gamedev.stackexchange.com/questions/60313/… \$\endgroup\$– msellCommented Jul 10, 2014 at 18:20
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
7
The only difference you would have is that you are doing texture lookup based on UV instead of direction.
This would mean that each cube vertex would need a uv or you would need a routine to calculate the appropriate uv based on the view direction ... which is basically us back at using texCUBE, with the exception that texCUBE is probably going to be more efficient that anything added as a function in the shader.
So, yes that would be the same in look, and probably about the same in actual performance, but texCUBE will likely always be slightly faster.
I did this once with a textured sphere - because I happened to have a textured sphere already, obviously drawing a sphere is slower than drawing a cube because there are more vertices.
-
1\$\begingroup\$ Why would texCube be faster? Because of the texture switches? \$\endgroup\$– TaraCommented Dec 26, 2014 at 19:26
-
\$\begingroup\$ @Dudeson - because you're using an intrinsic function which can have direct hardware support. \$\endgroup\$ Commented Dec 26, 2014 at 21:57
-
1\$\begingroup\$ What? Are you implying texture2D doesn't have direct hardware support? \$\endgroup\$– TaraCommented Dec 26, 2014 at 22:34
-
\$\begingroup\$ In the answer I say it would be faster than anything "added as a function in the shader". There is no comparison to texture2D's speed. I am saying that a custom function to calculate which UV to use based on the view direction will likely be slower than using texCUBE as it can have hardware support. This is only if you want to use the view direction for lookup. If using a cube with UVs then you're just extending the vertex buffer a little - which still leaves the texCUBE method slightly more efficient. \$\endgroup\$ Commented Dec 27, 2014 at 16:07
-
1\$\begingroup\$ @Dudeson - the comments area is not for discussion, that is what the chat room is for. Yes texCUBE is slower than texture2D, essentially because it does the vector to uv conversion, which is why it's better than doing that conversion yourself and using texture2D. I have no preference for either and usually use whatever is easiest given the rendering system I'm using. \$\endgroup\$ Commented Dec 27, 2014 at 17:38