Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Problems viewing vast landscapes  (Read 1517 times)
0 Members and 1 Guest are viewing this topic.
Offline zingbat

Senior Member




Java games rock!


« Posted 2003-11-01 09:14:37 »

I want to do a small demo of a vast landscape, something like 30,000Km by 30,000Km and still be able to walk in it and iteract with objects as small as 1cm. I solved the problem of loding such of vast region so it should render like if it was a normal map with average content. The solution was random and dynamic terrain generation based on a overal map representation of the land and an heavy use terrain tiles, one for each lod level arround the player.

The problem is the clipping planes have some limitations. There is some formula about setting the cliping planes that prevent me for have such range of view (min 1cm, max 30000Km).

I have some questions about this.

What ways there are in Java3d to avoid this ?

Is there any way to distort the biggest land tiles (some weird perspective projection) so that they render in the samller region allowed by the clipping planes ?

If i use the last version of OpenGL (with the bindings) do i have this limitation ?
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-11-01 11:08:28 »

The Z-range limitations have nothing to do with Java3D and are the same for OpenGL. It is just a problem of the accurary of the Z-buffer. So if you need nearclip at 1cm, farclip should be somewhere around 30m.

You could think of depthsorting terrain yourself and switch off z-buffering at all (dunno how to do that with Java3D by heart).

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline tom
« Reply #2 - Posted 2003-11-01 12:41:14 »

Here is the most general solution I can think of. Should work in any version of opengl.

Divide your minz and maxz into acceptable ranges. In your example you might use the following ranges:  [0.03, 3], [3, 3000], [3000, 30000], [30000, 30000000] Then render the whole scene for each range and use the values in frustum minz and maxz.

How many ranges to use depends on the resolution of the depth buffer. You need less iterations with a 32 bit depth buffer compared to a 16 bit.

This is of course a bit slow Smiley, but It's easy to do in opengl. Don't know if it's possible in java3d. You would need a way to change the frustum when rendering the graph, or a way to do multipass rendering. Anyone got any idees?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zingbat

Senior Member




Java games rock!


« Reply #3 - Posted 2003-11-02 08:42:20 »

You used values like 3000/3 which says that that the maxz/miz must be at most 1000, for 16bits right ? What about for 32bits z-buffer ? Most modern graphics cards have 32bit zbuffer.

And by the way how do you get to the 3000/3 value. For a zbuffer of 16bits and if you work with cm units it means that multiplying 1cm by 2^16 ~ 60000 it gets a maxz of 60000cm or 600m.

Now working with a 32bit z-buffer and units of 1cm it gives 2^32 cm ~ 4x10^9 cm or 40000km which i believe is more than enough to represent our entire planet with a 1cm precision. There is something fishy about this. Wink
Offline tom
« Reply #4 - Posted 2003-11-02 14:34:59 »

From the javadoc of javax.media.j3d.View:

The ratio of the back distance divided by the front distance, in physical eye coordinates, affects Z-buffer precision. This ratio should be less than about 3000 to accommodate 16-bit Z-buffers. Values of 100 to less than 1000 will produce better results.

So I used 1000. (although I did some mistakes in my last post  Embarrassed )

If you know you have got a 32 bit z-buffer, squaring the 16 bit range would be ok I guess (1.000*1.000 = 1.000.000). But how do you set or get the depth buffer resolution in java3d? If you don't find a way to do this, you must assume you've got a 16 bit z buffer.

Offline zingbat

Senior Member




Java games rock!


« Reply #5 - Posted 2003-11-02 19:02:24 »

I think i would rater inform anyone who would see the demo that a 32bit zfuffer is required. If java3d can take advatage of it that is.

The number 3000 doesnt make much sense even for a 16bit z-buffer. It probably means that for the 16bits in the zbuffer value only 12 or 11 bits are used for the actual z value 2^12 ~ 4000, 2^11 ~ 2000. The other 4 bits must be internal data.

Maybe they guessed at the time that for every g card they would need to cut some bits into the zvalue and made a rough calculation.

Anyway if the number of bits to cut out is 4 then for 32bit zuffer it gives 32-4=28 thus 2^28 ~ 2.5e8cm or 2.5e3km.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2003-11-02 19:22:33 »

Quote
The number 3000 doesnt make much sense even for a 16bit z-buffer. It probably means that for the 16bits in the zbuffer value only 12 or 11 bits are used for the actual z value 2^12 ~ 4000, 2^11 ~ 2000. The other 4 bits must be internal data.


Eh? Why the hell would 4 bits just be discarded? 16bit zbuffer means exactly that, 16 bits of precision in the depth buffer.

AFAIK, graphics cards can use the 16bits however they want, however we're talking floating point here, not integer values as you seem to think judging by your 11/12 bit guess. And they're likely to be in screen space, so it'll be in the range of 0 to 1 anyway.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline zingbat

Senior Member




Java games rock!


« Reply #7 - Posted 2003-11-02 20:00:30 »

Are you shure about zbuffer values being representing has floating poit numbers in the range [0;1] ?

But that doesnt make make any difference since you still have has many numbers has you can put in a 16bit value. I just said they must have cut some bits because if they used the all amount of bits the ration between the front/back cliping plane would be much bigger than 3000.

Let me try to explain this because its a little hard. If you have 16bits to store an integer value you can store 2^16 different numbers. If you have a floating point format unless the format itself wastes some bits you have exactly the same range of numbers you can store in 16bits. Except that in a floating point format the dynamic range is 0 to 1 and with an integer the dynamic range is 0 to 2^16. In the end no matter what number format is used the precision which is what maters here is exactly the same.

Offline tom
« Reply #8 - Posted 2003-11-02 20:29:48 »

The z values are being normalized into a [0, 1] range. Where 0 is near clipping plane, and 1 is the far clipping plane. But they are probably stored as integers, kind of like this: "unsigned short z = (int)(z_as_float_in_range_0_1 * 2^16)"

Anyway, all the bits in the z buffer is used because 0 is mapped to near clipping plane, and the maximum value of the z buffer is mapped to the far clipping plane.

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #9 - Posted 2003-11-03 05:03:27 »

The additional problem is that Zbuffers are linear in Z, whereas the percievable world is linear in 1/Z

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #10 - Posted 2003-11-03 06:14:34 »

Hi
 A long time ago I found this article, which has the information on why and what z buffer/ratios to use and how to work them out.
 Also note, that it's high powered 3D workstation cards that have 32 bit z buffer, most games cards have 24 bit z buffer, still better than 16 bit though Smiley

HTH

Endolf

Offline zingbat

Senior Member




Java games rock!


« Reply #11 - Posted 2003-11-04 07:45:48 »

If trhe problem is on the non-linearity of the zvalues in the way opengl handles the zbuffer the problem is easy to solve. I could just divide my scene landscape into tiles and scale down the faraway tiles until they are inside the front/back plane range without touching the inner tiles where the camera is in.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (40 views)
2014-09-24 16:13:29

Pippogeek (31 views)
2014-09-24 16:12:22

Pippogeek (21 views)
2014-09-24 16:12:06

Grunnt (47 views)
2014-09-23 14:38:19

radar3301 (29 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (43 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06

BurntPizza (55 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!