Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualNorman Barrows

Posted 03 September 2013 - 10:08 AM

i guess what i'm looking for is a way to decouple generic terrain mesh drawing from game specific heightmap info, and game specific texturing info.

 

with a static chunk, the "heightmap" is predefined in the y values of the vertices.   so a generic chunk drawer, perhaps generic to the point of user defined chunk size, can be pretty much game data independent as far as the heightmap is concerned. it doesn't care about height maps,  it just draws meshes passed to it.

 

with a dynamic quad or large dynamic mesh, a function that returns y altitude for a given x,z location can be used to decouple the heightmap source data structure (procedural, bitmap based, whatever) from the mesh drawing routine. this way you could swap in and out different heightmap systems, and the ground drawing routine wouldn't care. so it would be suitable for both bitmap height mapped levels, and procedurally generated open worlds.    the idea would be to provide a few built in optional heightmap systems, say, bitmap, procedural Perlin, and procedural sinusoidal. or the user could hook up their own through the "float user_heightmap(float x,float z)"   API.

 

but when it comes to de-coupling the game specific texturing from the mesh drawing, i'm not so sure it can be done, or is practical.  

 

so this seems to have evolved into a discussion on how to best couple ground mesh drawing and texturing. 

 

well, lets see...

 

you'd choose some texturing method, lets say splatted mega texture with all the usual "map" channels (normal, displacement, etc).

 

and some mesh drawing method, static chunks perhaps.

 

then you'd combine them to make a terrain drawing routine.

 

game specific heightmap data is implicit in the y values of the vertices of a chunk, so your drawing routine doesn't deal with game specific heightmap info. it just draws meshes.

 

generally speaking, heightmap info can be in any form, and the drawing routine can use it.

 

but game specific texturing info will need to be in a format usable by the texturing method.

 

so i guess it can only be split into two decouple-able parts:   the heightmap, and the actual mesh drawing and texturing.

 

so you'd have

 

[  chunks |  dymanic mesh  |  dynamic quads |  etc   ]    combined with [ mega &|  splat &| other effects ]     coupled to [ perlin | bitmap | other heightmap] 

 

i suppose the thing to do would be to provide a few different combos of mesh/texture drawing routines for the engine / library. as well as a couple different heightmap systems to choose from.

 

so for me, the next question would be: how is outdoor terrain typically drawn in a shooter?     i use chunks in my open world fps/rpg, but a pure shooter might tend to do things more level oriented.     then again, i suppose a level is just a "chunk of one".   for RTS, probably one big mesh, or chunks, depending on map size.   in fact, that's probably the general rule of thumb for all games:  "one big mesh, or chunks, depending on map size".    flight sims would almost definitely need chunks due to the large size of their "game worlds".

 

static could be used, except where chunks are modifiable. in that case, dynamic could be used, either permanently, or temporarily while the terrain is changing, then copied to a static buffer for future drawing.   temporary dynamic sounds most efficient.

 

so it would seem chunks  may be the best general option.  and user defined chunk size shouldn't bee too hard.   the user (gamedev) would specify chunk size, and clip range from the camera, and the drawing routine would use the game's chunk and texture data to draw chunks around the camera.

 

sound good?


#3Norman Barrows

Posted 03 September 2013 - 10:03 AM

i guess what i'm looking for is a way to decouple generic terrain mesh drawing from game specific heightmap info, and game specific texturing info.

 

with a static chunk, the "heightmap" is predefined in the y values of the vertices.   so a generic chunk drawer, perhaps generic to the point of user defined chunk size, can be pretty much game data independent as far as the heightmap is concerned. it doesn't care about height maps,  it just draws meshes passed to it.

 

with a dynamic quad or large dynamic mesh, a function that returns y altitude for a given x,z location can be used to decouple the heightmap source data structure (procedural, bitmap based, whatever) from the mesh drawing routine. this way you could swap in and out different heightmap systems, and the ground drawing routine wouldn't care. so it would be suitable for both bitmap height mapped levels, and procedurally generated open worlds.    the idea would be to provide a few built in optional heightmap systems, say, bitmap, procedural Perlin, and procedural sinusoidal. or the user could hook up their own through the "float user_heightmap(float x,float z)"   API.

 

but when it comes to de-coupling the game specific texturing from the mesh drawing, i'm not so sure it can be done, or is practical.  

 

so this seems to have evolved into a discussion on how to best couple ground mesh drawing and texturing. 

 

well, lets see...

 

you'd choose some texturing method, lets say splatted mega texture with all the usual "map" channels (normal, displacement, etc).

 

and some mesh drawing method, static chunks perhaps.

 

then you'd combine them to make a chunk drawing routine.

 

game specific heightmap data is implicit in the y values of the vertices of a chunk, so your drawing routine doesn't deal with game specific heightmap info. it just draws meshes.

 

generally speaking, heightmap info can be in any form, and the drawing routine can use it.

 

but game specific texturing info will need to be in a format usable by the texturing method.

 

so i guess it can only be split into two decouple-able parts:   the heightmap, and the actual mesh drawing and texturing.

 

so you'd have

 

[  chunks |  dymanic mesh  |  dynamic quads |  etc   ]    combined with [ mega &|  splat &| other effects ]     coupled to [ perlin | bitmap | other heightmap] 

 

i suppose the thing to do would be to provide a few different combos of mesh/texture drawing routines for the engine / library. as well as a couple different heightmap systems to choose from.

 

so for me, the next question would be: how is outdoor terrain typically drawn in a shooter?     i use chunks in my open world fps/rpg, but a pure shooter might tend to do things more level oriented.     then again, i suppose a level is just a "chunk of one".   for RTS, probably one big mesh, or chunks, depending on map size.   in fact, that's probably the general rule of thumb for all games:  "one big mesh, or chunks, depending on map size".    flight sims would almost definitely need chunks due to the large size of their "game worlds".

 

static could be used, except where chunks are modifiable. in that case, dynamic could be used, either permanently, or temporarily while the terrain is changing, then copied to a static buffer for future drawing.   temporary dynamic sounds most efficient.

 

so it would seem chunks  may be the best general option.  and user defined chunk size shouldn't bee too hard.   the user (gamedev) would specify chunk size, and clip range from the camera, and the drawing routine would use the game's chunk and texture data to draw chunks around the camera.

 

sound good?


#2Norman Barrows

Posted 03 September 2013 - 09:58 AM

i guess what i'm looking for is a way to decouple generic terrain mesh drawing from game specific heightmap info, and game specific texturing info.

 

with a static chunk, the "heightmap" is predefined in the y values of the vertices.   so a generic chunk drawer, perhaps generic to the point of user defined chunk size, can be pretty much game data independent as far as the heightmap is concerned.

 

with a dynamic quad or large dynamic mesh, a function that returns y altitude for a given x,z location can be used to decouple the heightmap source data structure (procedural, bitmap based, whatever) from the mesh drawing routine. this way you could swap in and out different heightmap systems, and the ground drawing routine wouldn't care. so it would be suitable for both bitmap height mapped levels, and procedurally generated open worlds.    the idea would be to provide a few built in optional heightmap systems, say, bitmap, procedural Perlin, and procedural sinusoidal. or the user could hook up their own through the "float user_heightmap(float x,float z)"   API.

 

but when it comes de-coupling the game specific texturing from the mesh drawing, i'm not so sure it can be done, or is practical.  

 

so this seems to have evolved into a discussion on how to best couple ground mesh drawing and texturing. 

 

well, lets see...

 

you'd choose some texturing method, lets say splatted mega texture with all the usual "map" channels (normal, displacement, etc).

 

and some mesh drawing method, static chunks perhaps.

 

then you'd combine them to make a chunk drawing routine.

 

game specific heightmap data is implicit in the y values of the vertices of a chunk, so your drawing routine doesn't deal with game specific heightmap info. it just draws meshes.

 

generally speaking, heightmap info can be in any form, and the drawing routine can use it.

 

but game specific texturing info will need to be in a format usable by the texturing method.

 

so i guess it can only be split into two de-couple-able parts:   the heightmap, and the actual mesh drawing and texturing.

 

so you'd have

 

[  chunks |  dymanic mesh  |  dynamic quads |  etc   ]    combined with [ mega &|  splat &| other effects ]     coupled to [ perlin | bitmap | other heightmap] 

 

i suppose the thing to do would be to provide a few different combos of mesh/texture drawing routines for the engine / library. as well as a couple different heightmap systems to choose from.

 

so for me, the next question would be how is outdoor terrain typically drawn in a shooter?     i use chunks in my open world fps/rpg, but a pure shooter might tend to do things more level oriented.     then again, i suppose a level is just a "chunk of one".   for RTS, probably one big mesh, or chunks, depending on map size.   in fact, that's probably the general rule of thumb for all games:  "one big mesh, or chunks, depending on map size".    flight sims would almost definitely need chunks due to the large size of their "game worlds".

 

static could be used, except where chunks are modifiable. in that case, dynamic could be used, either permanently, or temporarily while the terrain is changing, then copied to a static buffer for future drawing.   temporary dynamic sounds most efficient.

 

so it would seem chunks  may be the best general option.  and user defined chunk size shouldn't bee too hard.   the user (gamedev) would specify chunk size, and clip range from the camera, and the drawing routine would use the game's chunk and texture data to draw chunks around the camera.

 

sound good?


#1Norman Barrows

Posted 03 September 2013 - 09:23 AM

i guess what i'm looking for is a way to decouple generic terrain mesh drawing from game specific heightmap info, and game specific texturing info.

 

with a static chunk, the "heightmap" is predefined in the y values of the vertices.   so a generic chunk drawer, perhaps generic to the point of user defined chunk size, can be pretty much game data independent as far as the heightmap is concerned.

 

with a dynamic quad or large dynamic mesh, a function that returns y altitude for a given x,z location can be used to decouple the heightmap source data structure (procedural, bitmap based, whatever) from the mesh drawing routine. this way you could swap in and out different heightmap systems, and the ground drawing routine wouldn't care. so it would be suitable for both bitmap height mapped levels, and procedurally generated open worlds.    the idea would be to provide a few built in optional heightmap systems, say, bitmap, procedural Perlin, and procedural sinusoidal. or the user could hook up their own through the "float user_heightmap(float x,float z)"   API.

 

but when it comes de-coupling the game specific texturing frrom the mesh drawing, i'm not so sure it can be done, or is practical.  

 

so this seems to have evolved into a discussion how to best couple mesh drawing and texturing. 

 

a bitmap system combined with a chunk system gives you an instant chunk editor (add code and stir).


PARTNERS