Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualray_intellect

Posted 05 February 2013 - 09:49 AM

Actually I think the opposite might be true. The tessellator is very good for terrain rendering and LoD, however the shader is difficult to implement.

I started to write a spherical patch renderer based on a cubemap projection (similar to yours) several years ago (probably 2008).

I would probably get rid of the patched sphere terrain idea and use a spherical coordinate grid ( with north and south pole ) . I think its perfectly easy to divide the spherical coordinate sphere into patches based on latitude and longitude, and if you think about it, the patches will be very close to square at high resolution - the downside to this is the fact for bigger planets you have more terrain visible at each height before the horizon. However for larger worlds, you don't need to tessellate until you are quite near the surface, and then you just need fine detail on surfaces like mountains and bumpy areas. I know this might sound obvious. So you would want a method for determining the curvature variation for distant mountains, and of course they could often be rendered into a cube map and morphed. And what about the errors on the north and south pole ? Well you don't want your players to go there, they wouldn't want to go there because the poles suck, obviously. On a cubemap patch grid there are 8 problem regions with a lot of warping. So perhaps you could render a mesh over the top of the spheres - if you really wanted your players to go hunting Arctic hares for example - you could drape a patch over the top and morph the two models / artistically merge them.

edit: in fact if you remove the point at the top of a spherical coordinate grid and a couple of rings you have a circle of vertices at the top, if you think of these as like the hour marks on a clock, you can join 1 O'clock to 5 O'clock, and 2 to 4, 12 to 6 etc, and the same for the horizontal direction, so then you have an easy way to patch over the top.

Anyway the google link I posted has a terrain renderer at the top of the search. It is based in Python ... my only criticism of the source is that to run the program on my desktop PC I had various issues - first I downloaded Python 3.3 (I don't have python on my desktop computer) and nothing worked, so I downloaded Python 2.7 and found out that the library required Python 2.5, so I downloaded this, and found out that another library needed Python 2.6, so eventually when I tried to run the code - it didn't even build.

I think if you really want to use a patch system based on a cube, then I think chunked lod is the best scheme for rendering the surface - see Thatcher Ulrich's code

However I really think CPU based patches are a Kludge compared to GPU methods.

Also you might need to look into efficient mega texturing.

#3ray_intellect

Posted 05 February 2013 - 09:18 AM

Actually I think the opposite might be true. The tessellator is very good for terrain rendering and LoD, however the shader is difficult to implement.

I started to write a spherical patch renderer based on a cubemap projection (similar to yours) several years ago (probably 2008).

I would probably get rid of the patched sphere terrain idea and use a spherical coordinate grid ( with north and south pole ) . I think its perfectly easy to divide the spherical coordinate sphere into patches based on latitude and longitude, and if you think about it, the patches will be very close to square at high resolution - the downside to this is the fact for bigger planets you have more terrain visible at each height before the horizon. However for larger worlds, you don't need to tessellate until you are quite near the surface, and then you just need fine detail on surfaces like mountains and bumpy areas. I know this might sound obvious. So you would want a method for determining the curvature variation for distant mountains, and of course they could often be rendered into a cube map and morphed. And what about the errors on the north and south pole ? Well you don't want your players to go there, they wouldn't want to go there because the poles suck, obviously. On a cubemap patch grid there are 8 problem regions with a lot of warping. So perhaps you could render a mesh over the top of the spheres - if you really wanted your players to go hunting Arctic hares for example - you could drape a patch over the top and morph the two models / artistically merge them.

Anyway the google link I posted has a terrain renderer at the top of the search. It is based in Python ... my only criticism of the source is that to run the program on my desktop PC I had various issues - first I downloaded Python 3.3 (I don't have python on my desktop computer) and nothing worked, so I downloaded Python 2.7 and found out that the library required Python 2.5, so I downloaded this, and found out that another library needed Python 2.6, so eventually when I tried to run the code - it didn't even build.

I think if you really want to use a patch system based on a cube, then I think chunked lod is the best scheme for rendering the surface - see Thatcher Ulrich's code

However I really think CPU based patches are a Kludge compared to GPU methods.

Also you might need to look into efficient mega texturing.

#2ray_intellect

Posted 05 February 2013 - 09:18 AM

Actually I think the opposite might be true. The tessellator is very good for terrain rendering and LoD, however the shader is difficult to implement.

I started to write a spherical patch renderer based on a cubemap projection (similar to yours) several years ago (probably 2008).

I would probably get rid of the patched sphere terrain idea and use a spherical coordinate grid ( with north and south pole ) . I think its perfectly easy to divide the spherical coordinate sphere into patches based on latitude and longitude, and if you think about it, the patches will be very close to square at high resolution - the downside to this is the fact for bigger planets you have more terrain visible at each height before the horizon. However for larger worlds, you don't need to tessellate until you are quite near the surface, and then you just need fine detail on surfaces like mountains and bumpy areas. I know this might sound obvious. So you would want a method for determining the curvature variation for distant mountains, and of course they could often be rendered into a cube map and morphed. And what about the errors on the north and south pole ? Well you don't want your players to go there, they wouldn't want to go there because the poles suck, obviously. On a cubemap patch grid there are 8 problem regions with a lot of warping. So perhaps you could render a mesh over the top of the spheres - if you really wanted your players to go hunting Arctic hares for example - you could drape a patch over the top and morph the two models / artistically merge them.

Anyway the google link I posted has a terrain renderer at the top of the search. It is based in Python ... my only criticism of the source is that to run the program on my desktop PC I had various issues - first I downloaded Python 3.3 (I don't have python on my desktop computer) and nothing worked, so I downloaded Python 2.7 and found out that the library required Python 2.5, so I downloaded this, and found out that another library needed Python 2.6, so eventually when I tried to run the code - it didn't even build.

I think if you really want to use a patch system based on a cube, then I think chunked lod is the best scheme for rendering the surface - see Thatcher Ulrich's code

However I really think CPU based patches are a Kludge compared to GPU methods.

Also you might need to look into efficient mega texturing.

#1ray_intellect

Posted 05 February 2013 - 09:15 AM

Actually I think the opposite might be true. The tessellator is very good for terrain rendering and LoD, however the shader is difficult to implement.

 

I started to write a spherical patch renderer based on a cubemap projection (similar to yours) several years ago (probably 2008).

 

I would probably get rid of the patched sphere terrain idea and use a spherical coordinate grid ( with north and south pole ) . I think its perfectly easy to divide the spherical coordinate sphere into patches based on latitude and longitude, and if you think about it, the patches will be very close to square at high resolution - the downside to this is the fact for bigger planets you have more terrain visible at each height before the horizon. However for larger worlds, you don't need to tessellate until you are quite near the surface, and then you just need fine detail on surfaces like mountains and bumpy areas. I know this might sound obvious. So you would want a method for determining the curvature variation for distant mountains, and of course they could often be rendered into a cube map and morphed. And what about the errors on the north and south pole ? Well you don't want your players to go there, they wouldn't want to go there because the poles suck, obviously. On a cubemap match grid there are 8 problem regions with a lot of warping. So perhaps you could render a mesh over the top of the spheres - if you really wanted your players to go hunting Arctic hares for example - you could drape a patch over the top and morph the two models / artistically merge them.

 

Anyway the google link I posted has a terrain renderer at the top of the search. It is based in Python ... my only criticism of the source is that to run the program on my desktop PC I had various issues - first I downloaded Python 3.3 (I don't have python on my desktop computer) and nothing worked, so I downloaded Python 2.7 and found out that the library required Python 2.5, so I downloaded this, and found out that another library needed Python 2.6, so eventually when I tried to run the code - it didn't even build.  

 

I think if you really want to use a patch system based on a cube, then I think chunked lod is the best scheme for rendering the surface - see Thatcher Ulrich's code

 

However I really think CPU based patches are a Kludge compared to GPU methods.

 

Also you might need to look into efficient mega texturing.


PARTNERS