Skybox cubemap not showing properly

Started by
16 comments, last by Wilds 11 years, 8 months ago
Is anyone looking at my code? I am already doing the thing mhagain is doing (sorta).
Advertisement

For your method: you aren't using a skybox, you are using a backdrop. Because of the fact you never rotate the box. That is the only reason you need to pass the modelview inverse and what not.

Secondly: Why use a stencil map in your method? Since you are using only 1 face of the cubemap (a backdrop plane). Why don't u just translate it to the end of the farplane and get rid of stencil operations completely and just use depth testing?

I wouldn't say that is the proper way. You are doing extra work to generate the same texture coordinates as this guy is with a static cube that gets rotated. And needing to pass extra data and perform extra operations with the inverse. Typically that method is more for a cube mapped object in the world.

here's a trick: since we don't transform the cube it will always stay at (0, 0, 0) therefore wherever you go, it stays with you

All you need to do to get that trick without using the inverse is just don't pass the translation portion of the camera matrix and just the rotation.
[/quote]
well you'd do stenciling anyways for lighting, so it may come handy. you'd use more than one face of the cube, because of perspectivity, but it's true that if you render it to the back of your frustum than it's the same. I don't think that's extra work. it's 1 matrix mul vs 1 matrix mul... (plus only 1 matrix gets passed, vs 1 matrix passed, that is the same amount of data passed :) )
what i can conclude is that it only picks the front texture, the +Z, I concluded this by making each part of the cubemap a different color.

I have added a link to my executable! please tell me the results.
Windows only: download

The cube coordinates are not affected by the transformation as the shader gets the untransformed object space vertices from the VBO.


gl_Position shouldn't be translated either to keep the cube centered on the camera. Try Ignifex' suggestion and use Mat4 combined = mCamera->GetProjection() * mCamera->GetView(); without the translation part.
I translate the cube's position to the camera's to keep it's position at the center of the camera.
I tried what you suggested, the translation of the position shouldn't affect texture coords, only which textures I am seeing based on the cube's orientation.
Ah, that clears up your idea behind the code there and your method should work.
Honestly though, there are only a few things that can still go wrong:
- mCamera->getView() does not handle rotation, although I am sure you use it in other parts of your code as well.
- The translation you apply to move the cube toward the camera is wrong. Why the scale 85?
For the above two, the obvious thing to try is to render your texture coordinates as RGB and see what you get.
Although unlikely:
- Your binding of the cube map faces is still wrong. Could you set your uniform samplerCube cubeMap to 0, just to be safe?
Thanks for your comment I tried visually debugging the skybox, it seems the texture coordinate passed is 0,0,0 the faces are all black!

- mCamera->getView() does not handle rotation, although I am sure you use it in other parts of your code as well.
It handles rotation as it is the inverse of the camera's world matrice.

- The translation you apply to move the cube toward the camera is wrong. Why the scale 85?
This one is also correct, the 85 scale is just a test value.

For the above two, the obvious thing to try is to render your texture coordinates as RGB and see what you get.
Although unlikely:
- Your binding of the cube map faces is still wrong. Could you set your uniform samplerCube cubeMap to 0, just to be safe?
Could you tell me how I do this, as just putting 0 behind uniform samplerCube tex is not working.
Oke I solved it! thanks everyone, especially Ignifex, your tip about visually debugging helped me alot!
Good learning lesson, always name the input of the fragment shader the same as the output of the vertex shader!

The problem:
In the shaders i named the linking output and input of the vertex to fragment shaders differently.

Wrong
out vec3 outUV; // inside vertex shader
in vec3 UV; // inside fragment shader

Good:
out vec3 UV; // inside vertex shader
in Vec3 UV; // inside fragment shader

This topic is closed to new replies.

Advertisement