Jump to content
  • Advertisement
  • entries
    2
  • comments
    5
  • views
    265

About this blog

Hi.

Ehm. So i start a blog. My plan is to do what the tile says. The actual status is behind the github in my avatar. I don't plan to sell something, i am rather following what many others do, bringing some virtual realism into gaming. Inspired by projects (that all are well beyond my abilities !) like Orbiter (hail the probe !) or KSP, open source Pioneer, or the awsome work "Space Engine" and others.

I will deliver images one i have something more to show off than i have dropped in various forum posts. Atm, i struggle with the transformation of double precision to a shader understandable format, with a method described in the book "3D Engine Design for Virtual Globals" by Cozzi/Ring. A great resource for this kind of stuff.

Pretty soon i will not be consent any more with simply rendering real world height data because i expect to overtake reality soon (well, there is only data for Earth, Moon and Mars anyway). Then virtual worlds must be put into service.

Here is my initial brainstorming for the forces that shape the surface of a solar system body. The goal is to identify parameters and find a naive algorithmic solution. I just post the initial thoughts, maybe (hopefully) it catches interest, maybe not 🙂

--------------------

Simplifications: no plate tectonics, no hydro- or cryosphere, no atmosphere, no biosphere, or else this would lead too far too soon. Must have room to improve 😉

Then i would assume:

- Mass and elemental composition determines shape and differenciation.

- Number of surface craters depends on time, though most form in the early phases of a solar system.
Bigger ones earlier, smaller ones later.

- Primordial heat, heat transport and radiation will lead to temperature and density differences ...

- ... leading to interior convection ...

- ... which can result in lava flows, burying surface features.

- When cooling and solidifying has given enough "structural integrity", volcanic edifices can arise ...

- ... or, depending on ?, plate tectonics can start.

- Uplift here must have subsidence there.

- Uplift equals crustal thinning, eventually tear, subsidence equals sedimentation.

- Small impacts will erode and supply regolith, ...

- ... as will the accretion of dust and erosion through radiation and particle bombardment.

- Surface dust and small particles can be gravitationally transported, or spread by impacts.

- Ad- and cohesion will define the slopes necessary for movement.

- While primordial heat leaves the body, the heat budget is more and more dominated by radiogenic heat and surface solar irradiation.

- Eventually, circumstances allow,

 

Example:

https://erode.evsc.virginia.edu/mars.htm

--------------------

 

Yep, so that was the "about this blog" and "blog post number one" all in one.

 

Entries in this blog

 

I've been noisy ...

As a first step to generate height maps on my own i started incorporating the algorithms of libnoise (c) by Jason Bevins, under the LGPL v2.1 or higher. It has never been easier to get noisy. Mapping a texture to a sphere or near spherical body is trivial, But when it comes to 'Oumuamua shaped objects things get distorted: Surface normals computed in two different ways, geocentric vec3 centricSurfaceNormal( const vec3 pos ) { return normalize( pos ); } and geodetic vec3 geodeticSurfaceNormal( const vec3 pos ) { return normalize( pos * u_oneOverRadiiSquared ); } Normals combined vec3 normalG = geodeticSurfaceNormal( position ); vec3 normalC = centricSurfaceNormal( position ); vec3 normal = ( normalG + normalC ) / 2.0f; vec2 texCoord = computeTexCoord( normal ); and height values looked up from a spherical height map vec2 computeTexCoord( const vec3 normal ) { return vec2( atan( normal.y, normal.x ) * c_oneOverTwoPi + 0.5f, asin( normal.z ) * c_oneOverPi + 0.5f ); } and then float height = texture( s_texture, texCoord ).r * u_heightFactor; displacedPosition = position + ( normal * height ); Still, between the two methods, there are vast open plains, so to say, only the centre area and the east- and west-poles are noisy. I'll probably have to generate the height maps specifically for the assumed ellipsoidal shape of the bodies that will use it as clothing. And what about two- or multi-lobed objects ? 🤔 Tricky terrain ahead ...  

Green_Baron

Green_Baron

Terrain tiles and LOD, a first result

So, i made a video about where my project is now. Sorry for the bad quality, it is my first video from screen and i haven't wasted time on tweaking things. It shows my implementation of continuous distance dependent LOD (after F. Strugar). 4 tiles (correctly stitched together if i may say :-)), the white boxes are the tiles bounding boxes (that i plan to use later for building a structure and to check for visibility/culling/loading), the coloured boxes show the view frustum selected nodes out of the hierarchy (a quadtree) of nodes from the tiles. Each tile has its own quad tree and selection is done per frame and per tile, so the nodes come in pre-sorted and loading and unloading should be pretty easy. Rendering is done via a simple flat mesh. In this case the node size is 64/64, but i applied a multiplier (because the srtm data i use is really spacey) of 4. That means, that per post from the (16 bit greyscale) heightmap there are 4 grid positions, thus faking a much higher resolution than there really is. Between lod levels there is continuous morphing of vertices. Distribution is recalculated when changing depth of view (near- and far plane), as shown the lod levels travel in and out from the camera position. In the same way, they travel with the viewer, i hope it can be seen through the bad quality. Next steps: render relative to eye, generate and stream heightmap tiles (emanzipate from prefab dem data ;-)), shading/texturing. Again: this heavily relies on the work of others, i have just typed it in. All thoughts very welcome ! (source on github) 2019-07-03_20-34-43.flv
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!