Thread: Sphere backdrop problems

WOAAAAA very nice!!!!

Last screenshot. Anyone who wants to help with this by contributing models, effects, or code please let me know. This should probably go on the recruitment board, but I wanted to show that a lot of code has already been written.

I need 3D models of ships, objects, space stations, etc as well as textures for lasers, lense flares, explosions, etc. Animation is just around the corner.

Some things that need to be implemented later are a small scripting engine for creating missions and controlling AI ships. There is a lot to be done here....but I need serious people only.

This is a shot just below the first planet in the system with the sun near the bottom of the pic. The sun needs a flare around it - right now it is just extremely bright. The light for the universe is the sun as is evidenced by the shadow on the planet. It is just a huge, very bright, point light source.

do you create your own textures and what is your algo for wrapping a texture to a sphere? and I guess while I am at it, what do you use for a sphere algo?

Ok I lied...another screenie. This one with a non-textured atmosphere around planet 1. Backdrop has been changed and if I can't get rid of the distortion at 180 degrees on the sphere (both sides) I'm going to change to a skybox for the backdrop. This has a lot of the light characteristics significantly altered from the previous screenshots.

Ok I've found about 20 different spherical texture mapping equations/algos. I've even tried to reverse the cartesian coord to spherical coord transformation - but it produces some weird stuff.

Code:

float PI2=D3DX_PI*2.0f;
cur_v=acos(newz/Radius)/D3DX_PI;
cur_u=acos(newx/(Radius*sin(D3DX_PI*cur_v)))/(PI2);

Where newx, newy, and newz are the spherical coordinates of the vertex and Radius is the radius of the sphere. Doesn't work well at all.

So then I thought about it and tried some spherical environment mapping.

Code:

float max_u2=tex_width/2.0f;
float max_v2=tex_height/2.0f;
 
Verts[i].u=tex_mag*((max_u2+Verts[i].normal.x*max_u2)/tex_width);
		  
Verts[i].v=tex_mag*((max_v2+Verts[i].normal.y*max_v2)/tex_height);

max_u2=Half the width of the texture
max_v2=Half the height of the texture
tex_width=Width of the texture
tex_height=Height of the texture
tex_mag=Tiling factor for texture (2.0f means that the texture will tile twice throughout the sphere)
Verts[] - array of SphereVertex type

Code:

struct SphereVertex
{
   D3DXVECTOR3 position;
   D3DXVECTOR3 normal;
   float u,v;
   static const DWORD FVF;
 
   SphereVertex(D3DXVECTOR3 _pos,float _u,float _v):position(_pos),u(_u),v(_v) {}
};
...
...

SphereVertex::FVF=(D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1);

This method still has distortion in it.

Then I thought about the structure of a sphere and realized that D3DXComputeNormals() was computing the normals incorrectly for my sphere. I do not want face normals because even though the faces of the sphere are flat, the vertexes that make up the face actually face different directions and have different normals. So if those normals are averaged with their three neighbors normals then there is a better approximation of the curvature of the face, rather than just using face normals. Then I read an article on gamasutra concerning water effects and refractive mapping.

Basically you can figure out the normal for any point on the sphere by subtracting the vertex vector from the center of the sphere vector and for non-unit spheres you then normalize the vector. This is the true normal for that point on the sphere. No need to use 3 vertices to compute a normal. We are not talking about a flat surface, it is curved and all curves wrap around the center of the sphere. So all points are equidistant from the centroid of the sphere - thus all normals point outward from the center of the sphere.

In refractive mapping you do the same except that you subtract the camera position or vector from the sphere vertex vector of the vertex in question. This then can be used to compute the u and v coordinates of the texture by computing the reflected ray using the dot product. Here is the sample code from gamasutra.

Code:

//main loop 
vertex_current = (VERTEX_TEXTURE_LIGHT *)water->mesh_info.vertex_list;
for (t0=0; t0<water->mesh_info.vertex_list_count; t0++, 
vertex_current++)
{

camera_ray.x= camera.camera_pos.x - vertex_current->x;
camera_ray.y= camera.camera_pos.y - vertex_current->y;
camera_ray.z= camera.camera_pos.z - vertex_current->z; 
//avoid round off errors
math2_normalize_vector (&camera_ray);
//let's be more clear (the compiler will optimize this)
vertex_normal.x= vertex_current->nx;
vertex_normal.y= vertex_current->ny;
vertex_normal.z= vertex_current->nz;
//reflected ray
dot= math2_dot_product (&camera_ray, &vertex_normal);
reflected_ray.x= 2.0f*dot*vertex_normal.x - camera_ray.x;
reflected_ray.y= 2.0f*dot*vertex_normal.y - camera_ray.y;
reflected_ray.z= 2.0f*dot*vertex_normal.z - camera_ray.z;
math2_normalize_vector (&reflected_ray);
//interpolate and assign as uv's
vertex_current->u= (reflected_ray.x+1.0f)/2.0f;
vertex_current->v= (reflected_ray.y+1.0f)/2.0f; 
}//end main loop

All of these seem to have some distortion in them. There has to be a simpler way to do this.

Anyone have any ideas?

Perhaps I need to write a pixel shader that actually computes the cosine of the angle between the pixel and the incoming light ray and then shades the pixel accordingly - or shades the texel accordingly.

I may also have to write a pixel shader that computes the reflected ray as well as the texel at the current pixel in question.

I'm really lost as to where to go.

Dude........that is very impressive.

that was a good idea, we should have thought of that.

Well the game will still run on your card, but it won't use the pixel shading. I will check the caps of the card before enabling the pixel shaders. Unfortunately I don't think I could emulate it in software, even in assembly language, so you won't get the cool special effects.
I will look into it though.