Skybox or Skydome?

Started by
3 comments, last by DraganO 15 years, 9 months ago
I was looking at different ideas presented for showing a general skybox and I read that there is two main ones, Skybox and Skydome. However, no matter how hard I try I can not find anything on how to actually set either one of these up. Does anyone have a tutorial or a demo project on how to do this?
Advertisement
Well I think you should use the skybox, its easy and it work a bit like this: You have an inverted box ( from the inside ) and apply textures ( seamsless skytextures ) on each side. Than you render it with the zbuffer off.
There's also the possibility to fix the distance to the camera object. So no matter how much the camera moves, it will never reach the skybox.
Maybe this link will help you a little bit:
http://www.toymaker.info/Games/html/skybox.html

Greetings,
Skalli
"Never argue with an idiot, he'll bring you down to his level - then beat you with experience"
For your first sky, I'd recommend a skybox due to its simplicity. However, I recently implemented this and was unhappy with it as no matter how much I tweaked, there were artifacts at the edges/corners. I've implemented domes before and they were much better, but you still get artifacts at the poles/where the texture edges meet. I found an article on 'sky planes' which are a nice alternative to boxes/domes - one advantage over domes is that you dont have to wrap the texture round it and so you dont get artifacts where the two texture edges join up.

http://www.hyzgame.com.cn/CMGDK/Download/Sky%20Domes.pdf (pdf) is the article (scroll down about half way for the skyplanes).

But I'm using a strange method of generating sky which might suit planes better - basically instead of using a texture I'm doing all the color calculation in the pixel shader using a kind of ray tracing to determine what color the sky should be at that pixel. Using a few mathmatical equations you can take input of just the ray and produce the sun and a nice fading horizon. The drawback on this method is its more computationally demanding than just doing a single texture lookup, but it has almost no impact on the framerate.

A couple of sample images (I've not yet implemented bloom/HDR - they are next on my todo list, after trees :) ):



If you are interested, the pixel shader looks like this:

...
float4 Out;
float simil = (0.5 + 0.5*dot(normalize(In.Pos-float3(0.0, -skyY, 0.0)), -normalize(sunDirection)));

//float azimuth = atan2(In.Pos.z, In.Pos.x);
float base = length(float2(In.Pos.x, In.Pos.z));
float zenith = atan2(In.Pos.y+skyY, base)/3.14159;

//float base_sun = length(float2(sunDirection.x, sunDirection.z));
//float azimuth_sun = atan2(-sunDirection.z, -sunDirection.x);
//float zenith_sun = atan2(-sunDirection.y, base);

float br = (1.5 - pow(saturate(zenith),0.25));
float3 zenfade = skyColor*br;
float sunfade = pow(simil,500.0) + saturate(pow(simil+0.01,50.0))/5.0 + pow(simil,1.5)*0.5;//saturate();
Out = skyColor*br*saturate(1.0-sunfade) + sunColor*sunfade*1.02;
return Out;
...

One thing that annoys me about this code is the amount of constants in it that had to be painstakingly determined by trial and improvement, its not a nice method but I think it beats the alternative of fully implementing the 'atmospheric scattering' technique.

[Edited by - EvilDonut on July 23, 2008 1:39:39 PM]
Quote:Original post by EvilDonut
However, I recently implemented this and was unhappy with it as no matter how much I tweaked, there were artifacts at the edges/corners.


Did you try setting the clamp texture address mode? If you don't do this you will most likely have artefacts on your texture edges.

This topic is closed to new replies.

Advertisement