Additional heightmap compression.

Found a paper describing exactly what I am trying to do, here. http://www.cs.unc.edu/~ravishm/ray_patch/patch.pdf
So far, I'm not seeing anything I've messed up on, which makes me worry that the artifacts are simply precision error. Still, there are some other promising approximations described here which I would like to try.

It's amazing how you can keep learning new things about the stuff you are using every day. For instance, the collision point I thought I was getting with the block raytracer is actually the origin of each block rather than the intersection of the block along the ray path. This has been throwing off my estimates for days but I never connected the dots.

fr0stbyte124 wrote:

I thought I was getting with the block raytracer is actually the origin of each block rather than the intersection of the block along the ray path.  This has been throwing off my estimates for days but I never connected the dots.

Ha. Ha. Ha.

Tiel+ wrote:

fr0stbyte124 wrote:

I thought I was getting with the block raytracer is actually the origin of each block rather than the intersection of the block along the ray path.  This has been throwing off my estimates for days but I never connected the dots.

Ha. Ha. Ha.

Ha ha. Ha ha. Ha ha.

That somehow makes it worse...

Lovely.


Anyway, new pic.



Smooth is my current algorithm, and the blocky one is the raytraced version.  Almost there.

*edit*
I'm going to elaborate a little more on this. In this scene, the true surface is between 0 and +1 above the raytraced endpoint in the Y axis, regardless of perspective. Since this is the case, you can extend a ray from the true surface downward to the next lowest Y and that will cover the top surface for the target cubes. The only way it won't hit that surface is if it hits a vertical wall before that, Walls happen at the intersection of each plane where Y is a whole number and the true surface. This can also be solved in the same way that the first true surface intersection was solved, but then you are left with a rounded terrace. I'm not quite sure how to turn it into blocks from here, but that is the next thing to work out.

I could have sworn I made another post after this one...

No matter, new pic.



Got terracing down.  It's close enough to the final surface that I only need about 4 steps of raytracing to hit the final surface, and there is no longer any clipping issue with the surface mesh.  Gray cubes run at about 70fps at 720p on my work computer, and I suspect I can still double it.

*edit*
Just checked my 560ti at home.  800fps, and in some places I can break 1k. Freaking awesome.

Is this going to be used on ships as well?

Tiel+ wrote:

Is this going to be used on ships as well?

Good question.

I guess the right question is how would the ships interact with the main environment ?

I just noticed this hardly can be used for ships, as ships aren´t terrain ==> no hight to make a hightmap of.

Tiel+ wrote:

Is this going to be used on ships as well?

Well if people would read the essays I have on the subject, you would know the answer to that.   

The heightmap method the workhorse of the planet renderer, but it is to limited to handle everything.  There will also be a literal polygon layer (vanilla style chunks), generic volumetric layer, and probably a special layer for water and vegetation (trees look awful when attached to the heightmap).  The volumetric layer will either be raytraced or blocked out with marching cubes/dual contours.  In other words, turn it into polygons with LOD.  I haven't started on that, and the results from tuning the heightmap layer will let me know what sort of detail I can get away with.

Ships will use the literal polygon layer and the volumetric layer.
Ship physics and interactions are completely separate from what the renderer is doing. For the most part, the client doesn't even mess with the physics beyond the area immediately surrounding the player.

I didnt mean physically interract ... nvm ...

fr0stbyte124 wrote:

Tiel+ wrote:

Is this going to be used on ships as well?

Well if people would read the essays I have on the subject, you would know the answer to that.   

The heightmap method the workhorse of the planet renderer, but it is to limited to handle everything.  There will also be a literal polygon layer (vanilla style chunks), generic volumetric layer, and probably a special layer for water and vegetation (trees look awful when attached to the heightmap).  The volumetric layer will either be raytraced or blocked out with marching cubes/dual contours.  In other words, turn it into polygons with LOD.  I haven't started on that, and the results from tuning the heightmap layer will let me know what sort of detail I can get away with.

Ships will use the literal polygon layer and the volumetric layer.
Ship physics and interactions are completely separate from what the renderer is doing.  For the most part, the client doesn't even mess with the physics beyond the area immediately surrounding the player.

What I got out of what you said is that the same method would be used for ships, otherwise I wouldn't be inquiring as to confirmation in the first place.

We'll mark it down as "it's complicated".

Bottom line: raytracing has a bigger performance impact than I had hoped, so we'll need to to keep its usage to a minimum, and that limits our options going forward.

For those who might have been wondering, I've been spending more time discussing development of the mod on the MCF thread than here, because people over there seem more interested in discussing the mod.

Current things on the agenda:

Trying out geometry shaders to produce 3-sided block columns in the the highest two octaves.  Raytracing never worked well at this level, and it's not taking any advantage of interpolation.  Normally people avoid the geometry shader because it doesn't scale terribly well, but in theory it should do well here.  Unlike raytracing, this will have a fixed cost regardless of screen space, and if it's cheap enough, it may very well be profitable to do so.  I've also thought about tessellation at the outer levels, but it's going to be difficult to beat the quadric solution.

Coastlines are somewhat messed up in the mid-ranges.  Not sure how big of a problem that is going to be, but I've decided to define the water surface via local elevation instead of accurate XZ mapping.  Water going up the side of mountains seemed like a bigger issue than islands looking funny.  Hopefully with the right application of fog and LOD blending, this will work acceptably.

I looked just a little bit into atmospheric scattering to see how hard it would be to implement.  Turns out, pretty hard.  I don't understand Rayleigh scattering at all, and I don't know how to modify the formulas to look right on our tiny worlds.  There is also the matter of the scattering simulating a spherical atmosphere instead of a cube one, which would have to change, or the upper atmosphere will look goofy as hell.  There is also the cost concern.  For a gaming gpu it is well within budget, but I doubt we can include it by default, meaning we'll need a low tech alternative anyway.

Without atmospheric scattering, I have no idea how fog ought to behave on this scale, and the test terrain I am using is really poorly suited for distant features; they're like little bumps in the distance.

I'm reading some papers on implementing tree imposters, but I have no idea whether it will work for us yet.

The blockifying pass looks really good at close and mid range, but the aliasing becomes really intense at about 1km out, or closer depending on your screen resolution.  Super-sampling helps a lot, but it is way too expensive to rely on.  I also tried removing all the blocking and that removes the aliasing, but there's not enough detail.  I think the compromise is going to end up being applying a normal map in addition to the heightmap and adjusting light on that.  Not 1m resolution, but something more detailed than the current heights should be sufficient. Again, I really need to start generating some bigger features to get an idea of how this is all going to play out in the final product.