Background textures in a 3d game
Peter Ashford
I'm sure this is a 'solved problem' but I can't find anything about it on
the web... (p.s. I'm using openGL)
I'm attempting to do a 3d space sim, and I'm wondering about how to
texture the background. Obviously, it needs to look like the inside of a
textured sphere, but I would assume that you could get away with using a
cube as long as you account for stretching in the source
texture. Alternatively, I could map a rectangular texture on to a sphere
and approximate the result on a highly tesselated GL sphere.
Does anyone have any good ideas about how to do this, or links to any
information on the web regarding this issue?
Thanks for any help,
Kaffiene.
---
"Think like a child. Children ask wonderfully innocent and
deep questions. They would make great programmers if they
didn't leave the keyboard all sticky."
-- Michael Abrash
Posch
he's got a demo called CriticalVelocity (with source-code), i like the
space-background (don't know if u like it...)
good luck,
sebastian
Moritz Voss
"Peter Ashford" <pash...@g8labs.co.nz> schrieb im Newsbeitrag
news:Pine.LNX.4.21.00071...@dibbler.g8labs.co.nz...
> Hi There,
> I'm attempting to do a 3d space sim, and I'm wondering about how to
> texture the background. Obviously, it needs to look like the inside of a
> textured sphere, but I would assume that you could get away with using a
> cube as long as you account for stretching in the source
> texture. Alternatively, I could map a rectangular texture on to a sphere
> and approximate the result on a highly tesselated GL sphere.
Better would it be to generate a texture that is large and map it to a
simple rectangle that fills the screen. When you turn your ship, you adjust
your texture coordinates accordingly, and wrap them once your ship is back
at its original angle.
This way, you save polygons and precious geometry calculation time.
--
--
Moritz "Thygrrr" Voss
Client-Server & OpenGL Coder
spirit.link.studios - http://o2.ods.org
alexey yakovenko
i think, "x: beyond the frontier" uses the same technique.
"Peter Ashford" <pash...@g8labs.co.nz> wrote in message
news:Pine.LNX.4.21.00071...@dibbler.g8labs.co.nz...
> Hi There,
>
> I'm sure this is a 'solved problem' but I can't find anything about it on
> the web... (p.s. I'm using openGL)
>
> I'm attempting to do a 3d space sim, and I'm wondering about how to
> texture the background. Obviously, it needs to look like the inside of a
> textured sphere, but I would assume that you could get away with using a
> cube as long as you account for stretching in the source
> texture. Alternatively, I could map a rectangular texture on to a sphere
> and approximate the result on a highly tesselated GL sphere.
>
Peter Ashford
> i used textured cube... looks ok.
> i think, "x: beyond the frontier" uses the same technique.
If they used a textured cube, then how would they have dealt with texture
stretching given that your viewing angle changes quite a bit from the
middle of a cube face to the corners of the cube? This is what mainly
concerns me about using a cube.
--
alexey yakovenko
jon coomber
<pash...@g8labs.co.nz> wrote:
>If they used a textured cube, then how would they have dealt with texture
>stretching given that your viewing angle changes quite a bit from the
>middle of a cube face to the corners of the cube? This is what mainly
>concerns me about using a cube.
I believe proggies such as 3DS Max have special skybox features that
bork about with the textures before applying them to a skybox that
compensates for this phenomenon.
j.
Jason Shankel
Peter Ashford wrote:
> On Mon, 17 Jul 2000, alexey yakovenko wrote:
>
> > i used textured cube... looks ok.
> > i think, "x: beyond the frontier" uses the same technique.
>
> If they used a textured cube, then how would they have dealt with texture
> stretching given that your viewing angle changes quite a bit from the
> middle of a cube face to the corners of the cube? This is what mainly
> concerns me about using a cube.
>
You can correct for this by introducing more vertices within the
cube face, creating a cube-based geodesic sphere. If you use spherical
linear interpolation to place the additional vertices and plain linear
interpolation to interpolate the texture coordinates, the additional vertices
will correct the texture distortion.
--
Jason Shankel
Maxis/EA
s h a n k e l
at
p o b o x . c o m
Enjoy smooth, refreshing OpenTrek at http://www.pobox.com/~shankel/opentrek.html
Peter Ashford
>
> > On Mon, 17 Jul 2000, alexey yakovenko wrote:
> >
> > > i used textured cube... looks ok.
> > > i think, "x: beyond the frontier" uses the same technique.
> >
> > If they used a textured cube, then how would they have dealt with texture
> > stretching given that your viewing angle changes quite a bit from the
> > middle of a cube face to the corners of the cube? This is what mainly
> > concerns me about using a cube.
> >
>
> You can correct for this by introducing more vertices within the
> cube face, creating a cube-based geodesic sphere. If you use spherical
> linear interpolation to place the additional vertices and plain linear
> interpolation to interpolate the texture coordinates, the additional vertices
> will correct the texture distortion.
Excellent! Thanks!
Peter.
Tim Auld
of it by rendering the six textures required from six cameras located at the
center of your scene, each looking in the six different directions, and each
with a field of view of 90 degrees and an aspect ratio of 1 (to make a
square texture). You'll have to work out the orientation of each camera and
the respective texture coordinates in your game. Half-Life, Quake etc. and
countless other games use sky boxes. I'm using a sky box in my space sim
game, and it works great - you can barely tell where the seams are
(screenshots at http://www.tne.net.au/astro/projects/spacegame.html ).
Granted, I haven't really made any skies for myself (I'm not much of an
artist), but you can grab some place holders out of the Half-Life pak file.
I think there are other programs to generate sky box textures around.. Bryce
does it but I think it's for terrain only. Homeworld takes a different
approach by colouring each vertex of a sky mesh and blending between them,
but sky boxes are a simple and very effective technique.
Good luck and post a link to your game some time (love space sims... nice
ones anyway)
Tim
Jason Shankel
Tim Auld wrote:
> No! You don't want geometry that you can't appreciate!
<snippage about rendering 6 faces>
But it's not geometry you can't appreciate. Typically, using
one 256x256 texture for a skybox face is unsatisfactory,
especially if you're running a screen resolutions above 640x480.
I've found that skybox faces should have at least four, if not
nine textures apiece to look good. Since you have to add
vertices to accomodate the extra textures anyway, you might
as well place them properly.
--
Jason Shankel
Maxis/EA
s h a n k e l 'at' p o b o x . c o m
Enjoy smooth, refreshing OpenTrek at http://www.pobox.com/~shankel/opentrek.html
If you can't get a bigger boat, get a smaller shark.
Tim Auld
> one 256x256 texture for a skybox face is unsatisfactory,
> especially if you're running a screen resolutions above 640x480.
> I've found that skybox faces should have at least four, if not
> nine textures apiece to look good. Since you have to add
> vertices to accomodate the extra textures anyway, you might
> as well place them properly.
How are you rendering the sky textures for the geodesic sphere in the first
place? To use a geodesic sphere you would have to have the texture map a
sphere pretty closely, which would be harder than rendering the six faces.
Wouldn't that approach also lead to distortion noticible at the seams?
For your nine textures a side, do you mean nine 256*256 textures? That
equates to a lot of memory... over 10MB. One 256*256 texture is ok if the
image isn't very detailed with single points such as stars. If you want
stars you could plot points yourself or use sprites.
Do you have any demos or screenshots of what you are talking about Jason?
Tim
Jason Shankel
Tim Auld wrote:
>
> How are you rendering the sky textures for the geodesic sphere in the first
> place? To use a geodesic sphere you would have to have the texture map a
> sphere pretty closely, which would be harder than rendering the six faces.
> Wouldn't that approach also lead to distortion noticible at the seams?
>
> For your nine textures a side, do you mean nine 256*256 textures? That
> equates to a lot of memory... over 10MB. One 256*256 texture is ok if the
> image isn't very detailed with single points such as stars. If you want
> stars you could plot points yourself or use sprites.
>
> Do you have any demos or screenshots of what you are talking about Jason?
>
You can check out an example of what I'm talking about at:
http://www.best.com/~shankel/image1.jpg
I'll be the first to admit that a cubic skybox is probably fine for a space
game. But if you texture a starfield (which I agree you probably shouldn't
do),
or some other noisy/uncorrected signal onto a sphere, the edges and corners
of the cube will be apparent. In my experience, adding a single vertex to the
center of each face is adequate to ameliorate this. This upgrades you from
12 polygons to a whopping 24, which shouldn't choke your budget.
As for the number of textures per side, I'm actually in the midst of playing
with that right now. In the past, I've used one texture since that's about all
you could afford, but the texture filtering is pretty ugly. Basically, you're
stretching a 256x256 texture across the entire screen. At 640x480, this
is noticeable but not that bad. When you go to 800x600 or 1024x768,
it's hideous.
So far, I've tried 9 128x128 textures. That works out to 1.7 or 3.4 megs
depending on bit depth. That's a lot of traffic for a Voodoo 2 (especially
for something like a skybox) but the GeForce eats it for breakfast.
4 256x256 textures looks pretty good. That's 3-6 megs. Again, a bit
much for a Riva 128 but no problem for the latest and greatest.
Of course, 9 256x256 looks great (>1 texel per pixel), but at a minimum
of 7 megs, even I balk.
It all depends on how important your skybox is to you. Right now
I'm working on a project with the skybox has to blend almost seamlessly
into the navigable space, so I need the skybox image to be almost
indistinguishable from the rest of the geometry. If your skybox is just
a backdrop, then you don't need to worry about it so much.
Peter Ashford
> Tim Auld wrote:
< snip! >
> You can check out an example of what I'm talking about at:
> http://www.best.com/~shankel/image1.jpg
...and I bet this looks a lot worse when it's animated.
Thanks very much for the input Jason, it's been very usefull. I think I'm
going to be implementing two approaches - a lowly tesselated sphere (as
you suggest) for the places I want nebulae in the background and just GL
points or bitmapped particles for stars everywhere else. While I was
thinking about this problem it occured to me that most places in space
won't actually have lots of gas clouds in the visible distance ;-)
Jason Shankel
Peter Ashford wrote:
>
> Thanks very much for the input Jason, it's been very usefull. I think I'm
> going to be implementing two approaches - a lowly tesselated sphere (as
> you suggest) for the places I want nebulae in the background and just GL
> points or bitmapped particles for stars everywhere else. While I was
> thinking about this problem it occured to me that most places in space
> won't actually have lots of gas clouds in the visible distance ;-)
>
It depends on what you mean by 'visible'. If you look at the pictures from
the Hubble, all of these amazing objects are visible from the Earth (obviously),
but it's not like you can look up at the night sky and see the Eagle Nebula
glowing like a Star Trek effect. For that, you need long broadband exposures,
not just human vision.
We're currently working on a project dealing with deep space exploration.
Distant nebulae are on a skybox, but nearby clouds are done with volumetric
fog and implicit surfaces. I'm using GL points and sprites for nearby stars.
I'm currently putting distant stars on the skybox, but since I'm still using
one texture per box face it is ug-ly.
Peter Ashford
> Peter Ashford wrote:
> >
> > Thanks very much for the input Jason, it's been very usefull. I think I'm
> > going to be implementing two approaches - a lowly tesselated sphere (as
> > you suggest) for the places I want nebulae in the background and just GL
> > points or bitmapped particles for stars everywhere else. While I was
> > thinking about this problem it occured to me that most places in space
> > won't actually have lots of gas clouds in the visible distance ;-)
> >
>
> It depends on what you mean by 'visible'. If you look at the pictures from
> the Hubble, all of these amazing objects are visible from the Earth (obviously),
> but it's not like you can look up at the night sky and see the Eagle Nebula
> glowing like a Star Trek effect. For that, you need long broadband exposures,
> not just human vision.
I'm concerned about vision with the naked eye vision, where the places in
the universe where you'll see nebulae are few. They look great in games -
which is enough reason to use them, but they can be overused such as in
X-Beyond the Frontier where every part of space appears like someone has
vommited over it =).
>
> We're currently working on a project dealing with deep space exploration.
> Distant nebulae are on a skybox, but nearby clouds are done with volumetric
> fog and implicit surfaces.
That's interesting. Do you mind if I ask how you're rendering the
implicit surfaces? I've made code to render IS's in a ray-tracer before
and I'd be interested to know how you can make them render fast enough for
real time.
> I'm using GL points and sprites for nearby stars.
> I'm currently putting distant stars on the skybox, but since I'm still using
> one texture per box face it is ug-ly.
;-)
Peter.
Jason Shankel
Peter Ashford wrote:
>
> That's interesting. Do you mind if I ask how you're rendering the
> implicit surfaces? I've made code to render IS's in a ray-tracer before
> and I'd be interested to know how you can make them render fast enough for
> real time.
Sure. I'm using an approach very similar to the one outlined in the last two
issues of Game Developer. My nebula is modeled as a huge 3d array of
floating point density values between zero and one. Then I just use marching
cubes to generate polygons at every cube that contains the nebula boundary
(nebula boundary is set arbitrarily...values below 0.5 are "outside", values
above 0.5 are "inside").
The polygons are stored in a oct-tree and rendered back-to-front.
It's a little involved to describe here. If you do a google search for "marching
cubes" I'm sure you'll find better explanations than I can provide. And
definitely check out the last two months of Game Developer. There is a two-part
article about using marching cubes and implicit surfaces to model fluids.