Oolite Bulletins

For information and discussion about Oolite.
It is currently Mon Sep 25, 2017 4:28 am

All times are UTC




Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4 5
Author Message
 Post subject: Re: WebGL effort
PostPosted: Thu Jul 23, 2015 8:52 pm 
Offline
Competent
Competent

Joined: Sat Jun 27, 2015 2:48 pm
Posts: 42
Well, something very confusing happened. As I was switching to kilometer for the unit base, I divided the vertex coordinates for the mesh of the Cobra by one thousand, and I was hoping to see no difference whatsoever. I mean, normally when you shrink something, it should look exactly the same as long as you look it from closer, right?

Well, apparently not. As I got closer to the model, it got clipped before it could look "big" on the screen :

Image

After some thought I suspected it was because of the 1 in the (w, w) term of my projection matrix. So I switched it to zero and that made things better, but not much.

There's something I don't quite get here. I'll need to think about it before going further.


Top
   
 Post subject: Re: WebGL effort
PostPosted: Fri Jul 24, 2015 6:07 am 
Offline
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
User avatar

Joined: Fri Nov 11, 2011 6:19 pm
Posts: 4012
What you're running into here looks like the near plane/far plane/z-buffer issue. http://www.sjbaker.org/steve/omniv/love ... uffer.html is an old article (it talks about 16/24 bit buffers when the choice on modern hardware tends to be 24/32) but still a good one.

Put the scale in km, and the near plane at 1km cuts off the ship as you approach.
Put the scale in m, and the resolution near the far plane is too poor to draw a planet-sized object properly.

You also may get problems when exceeding ~10^8/10^9 units due to OpenGL using single-precision floats for positions and transformation.

In Oolite these issues are mitigated by:
- using double-precision floats for almost everything until they are finally converted down to pass to OpenGL (JS by default uses double-precision floating-point for its numbers, so this you probably already have)
- having two separate rendering passes - one for everything within a hundred metres of the camera, and one for everything outside it. There are various complicated issues with how objects on the boundary of the rendering are managed which still aren't completely solved in Oolite.
- drawing the planets at 1% of their real size

_________________
OXPs: [EliteWiki] New Cargoes, [EliteWiki] Skilled NPCs, [EliteWiki] Curse of the Black Sunspot, and more


Top
   
 Post subject: Re: WebGL effort
PostPosted: Fri Jul 24, 2015 10:37 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Mon May 20, 2013 9:53 pm
Posts: 2396
Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
Quote:
drawing the planets at 1% of their real size
In [wiki]FarPlanets[/wiki] I used realistic planet sizes but got similar problems exactly from the size of the Mars so I choosed to stay within this size.

_________________
OXPs by Norby


Top
   
 Post subject: Re: WebGL effort
PostPosted: Fri Jul 24, 2015 2:56 pm 
Offline
Competent
Competent

Joined: Sat Jun 27, 2015 2:48 pm
Posts: 42
Quote:
- having two separate rendering passes - one for everything within a hundred metres of the camera, and one for everything outside it. There are various complicated issues with how objects on the boundary of the rendering are managed which still aren't completely solved in Oolite.
I should try something like that. I'm wondering if I could not treat ships and celestial bodies differently. With different shaders and projection matrices, for instance.
Quote:
- drawing the planets at 1% of their real size
I really would like to avoid doing that.


Top
   
 Post subject: Re: WebGL effort
PostPosted: Fri Jul 24, 2015 6:24 pm 
Offline
Competent
Competent

Joined: Sat Jun 27, 2015 2:48 pm
Posts: 42
I kind of got something working :

Image

I pushed the result, it's here until I make other changes.

As you can see here mars is in real size with a radius of 3.4Mm. It is seen from 30Mm.

The line :
Code:
    mars.near = 1000
gives it a near field which is used by the camera to display it with a near clip distance of one kilometer (I switched back to using the meter as a unit). I could probably go with more, I'll see if it's needed. In any case if I don't put this line I get the ugly artifacts mentioned earlier.

For other objects (which have no near field), the default near distance is 0.5m.

The critical question is : does that messes up with the z-buffer order? The risk is that at some point the cobra is masked by mars while it's supposed to be in front of it. I think as long as the cobra remains far away from mars (that is much further than its near clip distance), it's fine. It will need to be tested more, though.


Top
   
 Post subject: Re: WebGL effort
PostPosted: Tue Sep 15, 2015 1:31 pm 
Offline
Above Average
Above Average
User avatar

Joined: Sat Jan 05, 2013 6:06 pm
Posts: 31
Location: Cologne, Germany
In Alite, I ran across the same problem, and in the end, I copied the approach from "Celestia" (http://www.shatters.net/celestia/): They use "depth buckets", which is essentially similar to cim's idea. You order your objects by z and iterate over them (farthest away from the camera first). Now, you add objects to your current "bucket", while the distance spanned by all objects in the bucket is smaller than X. If the new object is so far away from the last object that the radius of the bucket would be bigger than X, you start a new bucket.

When rendering the buckets, you clear your depth buffer before each bucket. In Alite, the partition implementation looks like that (slightly simplified; note that "allMyObjects" are already sorted along the z axis (= "distance" to the camera)):
Code:
private final void partitionDepths(final List <DepthBucket> sortedObjectsToDraw) {
    DepthBucket currentBucket = null;
    DepthBucket behind = new DepthBucket();
    behind.near = -1;
    behind.far = -1;
		
    for (Object p: allMyObjects) {
        float dist = p.distance; // Can be negative, relative to camera
        float size = p.getBoundingSphereRadius();
        if (dist < -size) {
            behind.sortedObjects.add(p);
            continue;
        }
        float near = dist - size;
        float far = dist + size;
        if (near < 1.0f && far > 1.0f) {
            near = 1.0f;
        }
        if (currentBucket == null) {					
            currentBucket = new DepthBucket();
            currentBucket.near = near;
            currentBucket.far = far;
            currentBucket.sortedObjects.add(p);		
        } else {					
            if (far > currentBucket.near) {
                currentBucket.sortedObjects.add(p);
                if (currentBucket.near > near) {
                    currentBucket.near = near;
                }
                if (currentBucket.far < far) {
                    currentBucket.far = far;
                }
         } else {
             sortedObjectsToDraw.add(currentBucket);
             float newFar = currentBucket.near;
             currentBucket = new DepthBucket();
             currentBucket.near = near;
             currentBucket.far = newFar;
             currentBucket.sortedObjects.add(p.object);						
         }					
    }

    if (currentBucket != null) {
        sortedObjectsToDraw.add(currentBucket);
    }
    if (behind.sortedObjects.size() > 0) {
        sortedObjectsToDraw.add(behind);
    }
}
And for rendering:
Code:
for (DepthBucket bucket: buckets) {			
    GLES11.glClear(GLES11.GL_DEPTH_BUFFER_BIT);	
    for (AliteObject go: bucket.sortedObjects) {
       go.render();
    }
}
Maybe this helps a little...


Top
   
 Post subject: Re: WebGL effort
PostPosted: Wed Nov 11, 2015 2:35 pm 
Offline
Competent
Competent

Joined: Sat Jun 27, 2015 2:48 pm
Posts: 42
Hello,

so as you have probably noticed I lost interest in this project lately. It was getting seriously tedious and the limitations of WebGL were frustrating as it was clear I would never get as good a result as in the native builds of Oolite.

However, apparently WebGL 2.0 is coming:

Image

It's already available on recent builds of Firefox and chrome, but unfortunately not on linux so I can't try it yet. I suspect it will come soon though.

Then it should hopefully be possible to import more things from the initial code (shaders, textures...) without having to tweak them all the time. And we could have as good of a graphical result, or possibly even better (with HDR maybe, since it's mentioned in slide 11, section sRGB).

It's a long way, but it may lead somewhere one day. Wouldn't it be nice to run Oolite in the browser, without having to install anything?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4 5

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited