From: Oliver W. <oj...@un...> - 2001-07-08 09:24:45
|
Just a kick-start post: Stage needs a terrain engine to be of any great use. I'd like to take charge of development of this module. Also needed is the container code for shepherd's core, which I believe will need to interface with the terrain engine. The plan is as follows: 1) Investigate COAL as a potential building block for the system. 2) Develop a terrain database system. 3) Develop the Shepherd container code. 4) Integrate the database and container code, along with the rest of shepherd. 5) Work out a map delivery system via Atlas. 5 may need to be moved back, if it looks like it will influence the database design significantly. If you reckon this might be an issue, pipe up now, otherwise we'll go with that sequence of development. Morgenes/Team: Does this meet with your approval? -- Oliver White STAGE Janitor www.worldforge.org _______________________________________________ Server mailing list Se...@ma... http://mail.worldforge.org/lists/listinfo/server |
From: Hans <han...@he...> - 2001-07-08 17:15:29
|
At 12:22 2001-07-08, Oliver White wrote: >Just a kick-start post: > >Stage needs a terrain engine to be of any great use. I'd like to take >charge of development of this module. Also needed is the container code >for shepherd's core, which I believe will need to interface with the >terrain engine. > >The plan is as follows: > >1) Investigate COAL as a potential building block for the system. >2) Develop a terrain database system. >3) Develop the Shepherd container code. >4) Integrate the database and container code, along with the rest of >shepherd. >5) Work out a map delivery system via Atlas. > > >5 may need to be moved back, if it looks like it will influence the >database design significantly. If you reckon this might be an issue, >pipe up now, otherwise we'll go with that sequence of development. > >Morgenes/Team: Does this meet with your approval? We had a discussion with James about the map format earlier today on IRC. http://grimicus.dyndns.org/logs/info.php?file=3Dstage200107080913.irc#lin= e138 As a result, I sketched up a rough diagram with some of the ideas: http://purple.worldforge.org/wf/zzorn/terrain_diagram_01.png It seems there's at least three different types of maps being passed arou= nd=20 or stored at different stages in the process; as source data on a map server, for collision and other purposes on the=20 game server, and for rendering the landscape on the client. Map server """"""""""""" First, we have source maps at the Map Server (or some map module, it=20 doesn't have to be on a separate machine). The source maps can consist of many layers: * Soil layers such as base rock layer, regolith, and topsoil, with=20 thickness and type information. * Vegetation and forest layers. * Item layers (stones, flowers, trees, etc). Density, uniform/clustered=20 distribution, minimum distance, etc. * 1D objects such as rivers, roads, and such, with various properties=20 describing how they will be "rendered". * Special effect layers, such as 'This area was under a glacier 10 000=20 years ago', 'This area was burned 50 years ago', etc. * Weather / climate layers, with average rainfall, clouds, wind, and=20 temperatures. * Layers generated by players, such as negative layers for where the=20 players have hauled away ground, and additional layers where they have deposited material. All these layers are combined, "rendered", in the map server for a specif= ic=20 area at a specific resolution, when requested. The rendered map has much fewer layers, just a terrain type layer (that=20 decides which textures are used), a height layer, a water height layer,=20 item layers for things like stones and trees, and perhaps vegetation laye= rs=20 for forest, under vegetation, or similar backgrounds (see my forest rendering article=20 http://www.worldforge.org/website/clients/rendering_forests.html ). In addition, the game server may request some specific layers, such as=20 current weather (if it is done on the map server), etc. The map server could allow for different ways to generate the map data, a= nd=20 "render" it to a final map. Different sources of map data could perhaps be used simultaneously for=20 different areas or at different detail levels. Fractal generation techniques can be used to generate detailed terrain fr= om=20 overview maps that may contain additional data for detailed terrain (fractal dimension, average height variation,=20 random seed, etc). But to start with we could just store pre-"rendered" maps of the world=20 (Acorn, Mason), and concentrate on getting the the basic map transport infrastructure working. Game Server """"""""""""""" The game server will need the map for collision detection, path planning=20 for AI (or is that done on AI clients?), and various RIMs will need different information about the environment. Client """"""" When the map is sent to the client (either from the game or map server?),= =20 some layers like item layers are removed, and instead items such as trees and stones are sent by the game server th= e=20 normal way. Also, the map sent to the client would probably have highest detail level= =20 close to the observer, and lower detail further away. This way it is easy to also display far away mountains, without reducing=20 the local area too much. The client could also indicate some way what data it already has, and wha= t=20 is needed (needs to be checked with the game server first, of course, so we know the client can see the terrain). Map format """"""""""""" All three representations could use the same map format for storing the=20 information, they will only differ in what layers they contain. The map format allows polygonal (perhaps a good idea would be to restrict= =20 ourselves to triangular) areas, which data attached to the area and/or to vertexes. Blade could perhaps be used as a base for the format. Layers would=20 probably have to be added. Thoughts? Flames? Suggestions? --=20 Hans H=E4ggstr=F6m (aka zzorn) http://www.iki.fi/zzorn/ "Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG _______________________________________________ Server mailing list Se...@ma... http://mail.worldforge.org/lists/listinfo/server |
From: Jesse J. <jes...@ha...> - 2001-07-09 16:15:44
|
>First, we have source maps at the Map Server (or some map module, it >doesn't have to be on a separate machine). >The source maps can consist of many layers: > >* Soil layers such as base rock layer, regolith, and topsoil, with >thickness and type information. >* Vegetation and forest layers. >* Item layers (stones, flowers, trees, etc). Density, >uniform/clustered distribution, minimum distance, etc. >* 1D objects such as rivers, roads, and such, with various >properties describing how they will be "rendered". >* Special effect layers, such as 'This area was under a glacier 10 >000 years ago', 'This area was burned 50 years ago', etc. >* Weather / climate layers, with average rainfall, clouds, wind, and >temperatures. >* Layers generated by players, such as negative layers for where the >players have hauled away ground, > and additional layers where they have deposited material. What are you trying to achieve with all this complexity? Wouldn't it be better to get something simple working and add frills later? For example, a 256-color heightmap, a custom texture map, and a skybox/sphere? This is really simple, but in most ways I think it's capable of doing better than Kunark level EverQuest graphics. >All these layers are combined, "rendered", in the map server for a >specific area at a specific resolution, when requested. >The rendered map has much fewer layers, just a terrain type layer >(that decides which textures are used), a height layer, a water >height layer, item layers for things like stones and trees, and >perhaps vegetation layers for forest, under vegetation, This sounds like you're hoping to automate the textures based on things like elevation, slope, and terrain type. I think that this can produce reasonable results, but it'll be tricky to do well and it'll never produce results as good as a hand generated texture map. I think the way to go is to create some tools to make it easy for artists to create the texture maps and add objects like vegetation. >Also, the map sent to the client would probably have highest detail >level close to the observer, and lower detail further away. >This way it is easy to also display far away mountains, without >reducing the local area too much. This is no longer always a Good Thing. Modern video cards can render huge amounts of polygons, but only if you shovel the data over to the card in an optimal manner. It's tough to do this with a progressive LOD scheme so brute force solutions are making a come back. -- Jesse _______________________________________________ Server mailing list Se...@ma... http://mail.worldforge.org/lists/listinfo/server |
From: John R. S. <js...@mc...> - 2001-07-09 16:15:46
|
Oliver White wrote: > Just a kick-start post: > > Stage needs a terrain engine to be of any great use. I'd like to take > charge of development of this module. Also needed is the container code > for shepherd's core, which I believe will need to interface with the > terrain engine. > > The plan is as follows: > > 1) Investigate COAL as a potential building block for the system. Cool, though I'd have to rename it to CSOAL.... (c; Seriously, if you have any questions about how COAL works and what it's capable of, ask away (preferrably on client@, though server@ works too). John -- John R. Sheets, Consultant js...@mc... McCaa, Webster & Associates, Inc. Writing GNOME Applications http://www.aw.com/cseng/titles/0-201-65791-0/ _______________________________________________ Server mailing list Se...@ma... http://mail.worldforge.org/lists/listinfo/server |