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 :

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.

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

- 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.

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.

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)):

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:

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?

oolite-assets is for the wavefront models (.obj) that can be directly imported from blender. oolite-binary-resources is for the textures, which
for some reason are not in oolite-assets. After the import the path to the textures must be manually modified.

Then a few tweaks are necessary : adding an other instance of the texture for each material, setting one of them to use the non-alpha channels for color diffusion, and the other one to use the alpha-channel for light emission.

I'm hoping that once the model is in blender, I should be able to export it in the new GL Transmission Format from Khronos. Normally that should allow for an easy import from a WebGL framework such as THREE (but others should work too).

glTF is a very interesting format. For one, it's designed by the Khronos group, the creators and maintainers of WebGL itself, so it's supposed to be the best there is for webGL. It's also a binary format (at least for the main part, that is geometries and stuff), so that means it should be fast to download and load in the graphics card memory.

Sorry I did not kept the earlier version of this page, so if you visit this thread in a far future, you may be confused. But hey, this is just a test page, it is not supposed to stay alive young anyway.

I'm not sure I'll do a proper library page though. I don't know quite which layout to pick and it's not
technically interesting anyway. So I'll stick with allowing the client to pick a ship to display from a select input on the front page.

I put all the models in a single blender files, which I also export in a single glTF (and its companion binary .bin file).

I also now use crossOrigin sources for textures and music. That is, I directly use the oolite github repos for them.

From now I'll be working on implementing the docking mini-game again. I did it before but it was with a very different code base
so it will require some work.

just to tell you I've lost a bit of motivation lately, so I will probably not go back to this for a bit. The perspective of setting the document layout, dealing with various UI and so on look more and more tedious as I think about it.

I will eventually go back to it, but not in the short term.

The code is freely available though if anyone wants to look at it, and I'm willing to answer questions.