Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (798)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (865)
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  
  Drawing big Objects far away  (Read 4382 times)
0 Members and 1 Guest are viewing this topic.
Offline tkausl

Junior Devvie


Medals: 3
Exp: 5 years



« Posted 2014-07-15 14:02:43 »

Hey,

i want to develop a universe-game. The problem is, the planets are really really huge and they are far far away. I dont know how to draw those objects since i dont want to set the far-plane to high and still want to see the planets in the distance.
how can i solve this problem? maybe draw smaller planets closer, but then how to calculate the size/position?

My English isnt that great. Correct me, if you want, im still learning this Language Smiley
Offline Longor1996

JGO Wizard


Medals: 116
Projects: 2
Exp: 8 years


The cake is probably a lie.


« Reply #1 - Posted 2014-07-15 14:13:56 »

The solution to that is to use a floating-point Depth-Buffer, and a special Shader that changes the way OpenGL computes the depth for all vertices/fragments.

Note that changing the way the depth-buffer is used can create a (very) bad performance hit if done wrong.

Read the following blogposts, as they help a LOT:
http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html
http://outerra.blogspot.de/2013/07/logarithmic-depth-buffer-optimizations.html
http://outerra.blogspot.de/2013/07/hacking-amd-opengl-drivers.html

Read one by one, in the given order, or else some things just wont make sense.

Have a nice day!

- Longor1996

The cake is probably a lie... but it's a delicious lie!
Offline Riven
Administrator

« JGO Overlord »


Medals: 1369
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2014-07-15 14:20:34 »

32 bit floating point numbers (being multiplied by various matrices) suffer from severe inaccuracies anyway, when dealing with astronomical scales. I think it'd be easiest to scale your geometry, bring it closer to the camera, and you can't see the difference.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #3 - Posted 2014-07-15 14:31:02 »

that outerra guys are going pretty crazy on that depthbuffer issue - best stuff i could find about that topic.

a more simple idea is to split the rendering into objects "far away" and "near". give them different clipping planes.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #4 - Posted 2014-07-15 14:42:32 »

http://www.opengl.org/wiki/Depth_Buffer_Precision

see "There is no way that a standard-sized depth buffer will have enough precision for my astronomically large scene. What are my options?"
Offline Longor1996

JGO Wizard


Medals: 116
Projects: 2
Exp: 8 years


The cake is probably a lie.


« Reply #5 - Posted 2014-07-15 14:57:13 »

that outerra guys are going pretty crazy on that depthbuffer issue - best stuff i could find about that topic.

a more simple idea is to split the rendering into objects "far away" and "near". give them different clipping planes.

Nope

Doing it the way the Outerra guys are doing it (The 'Outerra-way') is MUCH simpler.
With the splitting of 'near' and 'far' object, you are going to have to deal with a lot more coding (and bugs), than with the Outerra-way.

The Outerra-way, only needs a FBO (FrameBufferObject) with floating-point Depth enabled, and slightly modified Vertex/Fragment-Shaders for drawing into that FBO. You can set the whole thing up in a couple of minutes if you already have Shaders and FBOs implemented in the Engine/Framework you use.

And from the top of my head there are only two main drawbacks of this method:
  • It costs a lot of performance if you do something wrong in the Shaders. 'A lot' meaning: A HELL of a lot.
  • You cannot have big polygons close to the camera, as that produces (very noticable) artifacts.

In the end, you have to choose between:
- A more complex implementation (more bugs), but better performance. (Near/Far Splitting)
- A more simple, but worse performance. (Outerra-way)
- And all the other ways there are.

Pick your flavor, and have a nice day!

- Longor1996

The cake is probably a lie... but it's a delicious lie!
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #6 - Posted 2014-07-15 15:16:00 »

by simple i mean, no extra shaders or fbo's. it's doable in fixed-pipeline.

writing gl_FragDepth is more simple, once your shaders and whatnots are set up.
Offline theagentd
« Reply #7 - Posted 2014-07-15 15:48:18 »

What exactly is the "Outerra way"?

Myomyomyo.
Offline Longor1996

JGO Wizard


Medals: 116
Projects: 2
Exp: 8 years


The cake is probably a lie.


« Reply #8 - Posted 2014-07-15 16:20:11 »

What exactly is the "Outerra way"?

This is the 'Outerra-way':
http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html
http://outerra.blogspot.de/2013/07/logarithmic-depth-buffer-optimizations.html
http://outerra.blogspot.de/2013/07/hacking-amd-opengl-drivers.html

This is also the method that the 'Space-Engine' uses.
I you don't know what 'Space-Engine' is, I recommend to check it out, its awesome.

Have a nice day.

- Longor1996

The cake is probably a lie... but it's a delicious lie!
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #9 - Posted 2014-07-15 19:04:28 »

outerra is an exceptional piece of software.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mike

« JGO Spiffy Duke »


Medals: 149
Projects: 1
Exp: 6 years


Java guru wannabe


« Reply #10 - Posted 2014-08-19 07:47:24 »

I was testing some large drawing distances (perspective from 0.1 to 12.000) and while it looks awesome to see mountains kilometers away, the depth buffer started getting really inaccurate, causing some horrible artifacts.

Looking at "the Outerra way" I added the following, but it doesn't seem to make any difference at all. Did anyone successfully implement it or understand it good enough to give me a bump in the right direction?

I added in the initialization of OpenGL (right after Display.create):
NVDepthBufferFloat.glDepthRangedNV(-1, 1);

I changed the internal format for the depth buffer component of all FBOs to:
ARBDepthBufferFloat.GL_DEPTH_COMPONENT32F

I added the following at the end of all of my vertex shaders:
float Fcoef = 2.0 / log2(12000.0 + 1.0); //Fixed far plane of 12000 for testing
gl_Position.z = log2(max(1e-6, 1.0 + gl_Position.w)) * Fcoef - 1.0;

Any idea?

Kind regards,
Mike

My current game, Minecraft meets Farmville and goes online Smiley
State of Fortune | Discussion thread @ JGO
Offline Mike

« JGO Spiffy Duke »


Medals: 149
Projects: 1
Exp: 6 years


Java guru wannabe


« Reply #11 - Posted 2014-08-20 20:24:38 »

After a lot of testing I'll answer my own question Smiley

The documents explain two ways to solve the issue, using the glDepthRangedNV function (which also works on new AMD drivers), OR using the shaders, there is no point in mixing the two.

As glDepthRangedNV was a lot easier to implement and the huge drawing distance is more for newer graphics cards anyway I went for that. The results are great, I'm getting 0.1mm resolution on a distance of 100.000 meters. No more flickering evah!

Note:
Set NVDepthBufferFloat.glDepthRangedNV(-1, 1) after the binding of the FBO, not after Display.create()
The internal depth buffer format of the FBO needs to be a 24 or 32 bit float or it won't work
You need to change two values of the projection matrix, something like this if you are handling the matrices old style:
GL11.glGetFloat(GL11.GL_PROJECTION_MATRIX, projection);
projection.put(10, nearPlane / (nearPlane - farPlane));
projection.put(14, farPlane * nearPlane / (nearPlane - farPlane));
GL11.glLoadMatrix(projection);

Mike

My current game, Minecraft meets Farmville and goes online Smiley
State of Fortune | Discussion thread @ JGO
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #12 - Posted 2014-08-20 20:38:31 »

sweet, thanks for the info!
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (35 views)
2019-09-04 15:33:17

hadezbladez (3999 views)
2018-11-16 13:46:03

hadezbladez (1448 views)
2018-11-16 13:41:33

hadezbladez (4011 views)
2018-11-16 13:35:35

hadezbladez (772 views)
2018-11-16 13:32:03

EgonOlsen (4088 views)
2018-06-10 19:43:48

EgonOlsen (4666 views)
2018-06-10 19:43:44

EgonOlsen (2756 views)
2018-06-10 19:43:20

DesertCoockie (3648 views)
2018-05-13 18:23:11

nelsongames (3852 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
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!