gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Choosing the scale of a 3D world

#164865 - Rajveer - Thu Nov 27, 2008 6:50 pm

Ok I'm finally getting around to rewriting my 3D engine now that I have more time on my hands, and one of the areas I need to get resolved is the scaling of the world I'll be using. I'm looking to create a very large world: approximately 3000 times the size of the player, but failing that I'd settle for around half of that. I can't physically split the world into different areas and load a new area at a time, as this will be a fast racing game and everything needs to be seamless. So I guess the question is, how do you guys settle on the size of your world?

Right now I'm trying to decide how I should store this world, and I've got 2 different lines of thinking. The first is that I scale the whole thing down into 1.3.12/v16. This format will give me the added bonus of being able to use boxtest for culling my partitioning tree. I can use a 1.7.24 format for collision testing, which will give me enough size and precision. Problem is since everything needs to be stored within -32768 - 32767, this format will give my racers a size of approximately 20*20*20 v16 units which is ridiculously small precision wise, and upon testing I'm running into rendering issues.

The second is that I try to keep everything as small as possible, but not restrict my world to 1.3.12, stiching together the world stored within my tree with glTranslate calls. I can't use boxtest as my world will be greater than v16, but my frustum culling code is quite efficient. My racers are the smallest elements in my world, and upon testing the smallest I could render them allowing the camera to get close up without any issues and using the smallest clipping plane I could (around 200) gave them a size of 0.15*0.15*0.15, or 614*614*614 units in 1.3.12. For collisions I would probably use 1.19.12.

Ideally I would like to go with the first option, as I can use boxtest and the 1.7.24 fixed-point format will be both large enough and precise enough for collision testing. So have you guys got any advice? I feel like I am I being oblivious to something important.

#164870 - Synthetic - Fri Nov 28, 2008 5:12 am

I've had similar problems before, and I'm afraid the only way to get around the v16 limitations is the second option. Its a but of a pain, but it's more straightforward than anything else.

Personally, I'd try to scale the game so that the viewable region is as close to the v16 limit as possible, and use a background and hardware fogging to obscure the clipping plane. With good art, it looks fairly nice and it gives you the best precision for models and collision.

#164876 - M3d10n - Fri Nov 28, 2008 3:55 pm

Go for stitching. You can do massive scenes that way. You can do it automatically if you're generating display lists:

- Either keep your scene split into chunks in your modeling app, or do the splitting in your converter code.
- For each chunk:
- calculate it's bounding box center.
- Offset all vertices positions so they are relative to the center.
- Optionally you can also scale the vertices around the center to have them fit the v16 limits (or normalize them to fully use the v16 range).
- You can either pack the translate commands directly into the display list (if you're grouping your chunks in a single list) or store them somewhere else to be used by your 3D engine.

Also, you can use boxtest for large boxes by using matrix commands: use glTranslate to the center of the box and glScale to the size of the box and just text with a unit box (parameters: -0.5, -0.5, -0.5, 1, 1, 1).

#164877 - a128 - Fri Nov 28, 2008 5:45 pm

M3d10n wrote:


Also, you can use boxtest for large boxes by using matrix commands: use glTranslate to the center of the box and glScale to the size of the box and just text with a unit box (parameters: -0.5, -0.5, -0.5, 1, 1, 1).



Oh. you mean this for boxtest ?!
Code:

glTranslate(center)
glScale(size of box);
BoxTest(-0.5, -0.5, -0.5, 1, 1, 1)

#164888 - sgeos - Sat Nov 29, 2008 10:47 pm

I'll throw 3D perlin noise out there just for kicks.

#164893 - M3d10n - Sun Nov 30, 2008 4:10 am

a128 wrote:
M3d10n wrote:


Also, you can use boxtest for large boxes by using matrix commands: use glTranslate to the center of the box and glScale to the size of the box and just text with a unit box (parameters: -0.5, -0.5, -0.5, 1, 1, 1).



Oh. you mean this for boxtest ?!
Code:

glTranslate(center)
glScale(size of box);
BoxTest(-0.5, -0.5, -0.5, 1, 1, 1)

Yeah (just need to convert the floats to v16s, I think). You can basically boxTest() any box you could actually render (because that's more or less what boxTest does anyway). You can even rotate them (using glRotate() or using your own matrix) so they are object-aligned instead of world-aligned.

Also, if there are too many small parts, organize their boxes in an hierarchical tree structure (during pre-processing, ideally), so you can reduce the amount of boxTest() calls during rendering.

#164899 - Rajveer - Sun Nov 30, 2008 2:52 pm

Cheers for the replies guys, seems like stitching is the right way to go then. I'll do some tests and see what fixed-point format I should be using for collision testing, most probably stick with 1.19.12.

Never thought about using boxtest like that, that's really useful, thanks. That means I can also use it for a few object-oriented boxed I plan on rendering too!

#164903 - Rajveer - Sun Nov 30, 2008 5:29 pm

On a side note, does anybody know what causes gaps between 2 polygons to appear when they are both clipped by the current frustum? It's more noticeable on smaller polygons, since the view can appear to be "closer" to a polygon scaled larger, but it's always there, I'm assuming it's the inaccuracy of the v16 type?

The current solution is to use larger 3D models, but if I could get this sorted I could reduce my models a fair amount.

(This is with both direct vertex calls and displaylists)

#164911 - silent_code - Sun Nov 30, 2008 8:29 pm

Gap on clipping: It's a known hardware thing. Scaling is your friend. :^)

EDIT: Actually, the hardware can "create" a range of "effects" when clipping, like texture warping and lighting discontinuities. But it's just "special cases," nothing regular (I think).
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Last edited by silent_code on Mon Dec 01, 2008 12:56 am; edited 1 time in total

#164912 - Rajveer - Sun Nov 30, 2008 8:39 pm

Grr, damn hardware :D