Futurecraft Forums

A forum dedicated to communication and innovation!
 
HomeCalendarFAQSearchMemberlistUsergroupsRegisterLog in
Welcome, one and all, to the Futurecraft Forums!

Share | 
 

 Additional heightmap compression.

View previous topic View next topic Go down 
Go to page : Previous  1, 2, 3, 4, 5, 6, 7
AuthorMessage
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Sat Sep 21, 2013 3:18 am

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.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 1:56 pm

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.
Back to top Go down
View user profile
Tiel+
Lord/Lady Rear Admiral 1st
Lord/Lady Rear Admiral 1st
avatar

Posts : 5497
Join date : 2012-02-20
Age : 20
Location : AFK

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 2:15 pm

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.
Back to top Go down
View user profile
Joel
Marine
Marine
avatar

Posts : 1473
Join date : 2012-04-01
Age : 20
Location : A Death World, stopping a Waaagh!

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 6:22 pm

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.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 8:42 pm

That somehow makes it worse...
Back to top Go down
View user profile
Laibach
General
General
avatar

Posts : 2024
Join date : 2012-01-23
Age : 66
Location : Frozen Fields

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 9:49 pm

fr0stbyte124 wrote:
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.
Back to top Go down
View user profile
Tau
Infantry
Infantry
avatar

Posts : 517
Join date : 2012-01-16
Age : 17
Location : Ancapistan

PostSubject: Re: Additional heightmap compression.   Tue Sep 24, 2013 10:56 pm

Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Wed Sep 25, 2013 12:33 am

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.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 3:21 am

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.
Back to top Go down
View user profile
Tiel+
Lord/Lady Rear Admiral 1st
Lord/Lady Rear Admiral 1st
avatar

Posts : 5497
Join date : 2012-02-20
Age : 20
Location : AFK

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 6:56 am

Is this going to be used on ships as well?
Back to top Go down
View user profile
Ivan2006
General
General
avatar

Posts : 2096
Join date : 2012-05-08
Age : 19
Location : The Dungeon.

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 7:46 am

Tiel+ wrote:
Is this going to be used on ships as well?
Good question.
Back to top Go down
View user profile
Iv121
General
General
avatar

Posts : 2396
Join date : 2012-02-05
Age : 22
Location : -> HERE ! <-

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 8:32 am

I guess the right question is how would the ships interact with the main environment ?
Back to top Go down
View user profile
Ivan2006
General
General
avatar

Posts : 2096
Join date : 2012-05-08
Age : 19
Location : The Dungeon.

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 12:08 pm

I just noticed this hardly can be used for ships, as ships aren´t terrain ==> no hight to make a hightmap of.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 1:19 pm

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

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.
Back to top Go down
View user profile
Iv121
General
General
avatar

Posts : 2396
Join date : 2012-02-05
Age : 22
Location : -> HERE ! <-

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 1:33 pm

I didnt mean physically interract ... nvm ...
Back to top Go down
View user profile
Tiel+
Lord/Lady Rear Admiral 1st
Lord/Lady Rear Admiral 1st
avatar

Posts : 5497
Join date : 2012-02-20
Age : 20
Location : AFK

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 1:47 pm

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

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.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Fri Sep 27, 2013 2:24 pm

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.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: Additional heightmap compression.   Wed Oct 02, 2013 1:28 pm

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.
Back to top Go down
View user profile
Sponsored content




PostSubject: Re: Additional heightmap compression.   

Back to top Go down
 
Additional heightmap compression.
View previous topic View next topic Back to top 
Page 7 of 7Go to page : Previous  1, 2, 3, 4, 5, 6, 7
 Similar topics
-
» Details about ISO compression
» EX-70 1.4.2.0 compression modes question
» [ANSWERED] Inefficient ISO compression?
» How to do at home migraine device

Permissions in this forum:You cannot reply to topics in this forum
Futurecraft Forums :: Development :: Idea Center-
Jump to: