More pretty stuff: atmospheres and planet surfaces
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
That city generator is NICE.
are you creating buildings dyanmically too pr are you using primitives?
and how is your coordinate system?
could you possibly, lets say, build that city around a sphere?
currently, the planet geom generator makes a 3D search space.
a planet-> player vector is used to search the search space for a set of land-area-sectors.
these sectors are then returned in the form of a sector list, each containing a polycon vertex list.
if the vertex lists are empty, they are generated on demand.
essentially, the planet is treated as a 3d model, that builds itself as needed.
the geometry data can be read into VS as a model. and treated as a model.
therefore, there is no way to fuse the planet generator with the procedural cuty generator, because the planet generator is procedural only to a planetary-sector scale... which would encompass an entire city, making the city be there as a whole, or be missing completely.
the city generator, being procedural, would it be able to build a city on the surface of a planet, without having control over the planet itself? for example, if you could have an altitude @ building, would it be enough to greate the city? the buildings themselves could be positioned somehow to sit on the surface where they belong when needed.
-schehearzade
are you creating buildings dyanmically too pr are you using primitives?
and how is your coordinate system?
could you possibly, lets say, build that city around a sphere?
currently, the planet geom generator makes a 3D search space.
a planet-> player vector is used to search the search space for a set of land-area-sectors.
these sectors are then returned in the form of a sector list, each containing a polycon vertex list.
if the vertex lists are empty, they are generated on demand.
essentially, the planet is treated as a 3d model, that builds itself as needed.
the geometry data can be read into VS as a model. and treated as a model.
therefore, there is no way to fuse the planet generator with the procedural cuty generator, because the planet generator is procedural only to a planetary-sector scale... which would encompass an entire city, making the city be there as a whole, or be missing completely.
the city generator, being procedural, would it be able to build a city on the surface of a planet, without having control over the planet itself? for example, if you could have an altitude @ building, would it be enough to greate the city? the buildings themselves could be positioned somehow to sit on the surface where they belong when needed.
-schehearzade
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
i designed the planet gen to be abstracted away from the engine itself. so it could work as a plugin basically.
instead of :
load planet model.
draw planet model
do :
instantiate the planet gen class (once per planet)
give it a vector
call refresh
check if there is a change
if change, checkout new geometry
draw planet model
this way you can use the same planet drawing method as with a static model. you jsut replace the model wiht hte data you checked out of the planet gen class.
I think that if you want, we can get together and decide on a system that would be able to actually replace the vegastrike planet drawing section, with a totally new and robust planet generator with procedural cities, skies, clouds, etc. atmospheric effects, etc etc etc...
-scheherazade
instead of :
load planet model.
draw planet model
do :
instantiate the planet gen class (once per planet)
give it a vector
call refresh
check if there is a change
if change, checkout new geometry
draw planet model
this way you can use the same planet drawing method as with a static model. you jsut replace the model wiht hte data you checked out of the planet gen class.
I think that if you want, we can get together and decide on a system that would be able to actually replace the vegastrike planet drawing section, with a totally new and robust planet generator with procedural cities, skies, clouds, etc. atmospheric effects, etc etc etc...
-scheherazade
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
-
- Elite
- Posts: 1671
- Joined: Fri Jan 03, 2003 12:46 am
- Location: Earth, Sol system.
- Contact:
*drool*scheherazade wrote: I think that if you want, we can get together and decide on a system that would be able to actually replace the vegastrike planet drawing section, with a totally new and robust planet generator with procedural cities, skies, clouds, etc. atmospheric effects, etc etc etc...
-
- Hunter
- Posts: 79
- Joined: Fri Sep 10, 2004 12:16 pm
- Location: Australia
- Contact:
-
- Bounty Hunter
- Posts: 201
- Joined: Wed Jan 14, 2004 11:11 pm
- Location: londonengland, england
- Contact:
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
i don't commit anything until it works right.
specifically so others dont modify it before i'm done.
last thing i want is to be working on something and it changing before my eyes and messing up my plans.
once it's working and uploaded, anyone is WELCOME to change it however they like. have at it!
-scheherazade
specifically so others dont modify it before i'm done.
last thing i want is to be working on something and it changing before my eyes and messing up my plans.
once it's working and uploaded, anyone is WELCOME to change it however they like. have at it!
-scheherazade
-
- Explorer
- Posts: 11
- Joined: Fri Oct 01, 2004 4:42 pm
- Location: Munich, Germany
- Contact:
how things work
Hi there!
Warning a lot of text ahead
Wow I didn't expect such good reactions In fact my university tutor said that much more details could be added. He is kind of Blade Runner fan (me too) and he wanted to see something like the opening scene of the film with the city flight through. Anyway I still consider myself as a starter in CG so don't have too high trust in me
Because Schehearzade asked and to point out things I'll explain briefly how the generator works:
1. Street generator
The street generator builds a street network using an L-System with simple rules like "add three street segments at the end of another to form an intersection". Furthermore these new segments are modified by a street pattern. These are radial like Paris, following gradients like San Francisco, checker board like New York and natural pattern following population density. However the result of this process is just a kind of suggestion which is adapted to the local surroundings. For example a intersection is added if sehgments intersect, segment is adjusted (shortened, other angle, deleted etc.) if in water or the gradient is too steep. The important part is this intersection test which really makes the network. As you might now L-System are generating tree like structures. Unfortunatly I don't do this test clever right now, so it's soooo sluggish...
2. Lot generation
Now we have a network of lines. These are now "thickened" to create streets. Blocks are extracted and these are subdivided into smaller lots between a minimum and maximum size. So a lot is basically just a polygon now (in fact these polygons are even flattened to be 2d).
3. Building generation
A L-System creates a string of actions to create a building, like "Extrude by x then scale with factor y then extrude by z...". Currently I have implemented an extrude, bevel and scale funtion. These are the applied to the lots/polygons from the privious step and makes quite low poly skyskraper stuff.
4. Textures
A terrain texture is generated which has all streets in it. Furthermore building textures are generated by using a wall tile and adding a window tile on top of it. By tiling each of these componets quite a variety of textures can be achived. The retrieved tile is then tiled across the building.
5. Terrain
Basic terrain from a heighmap. So it is not on a sphere or something....
I hope this make things clearer now.... and you understand what I say
I believe this city generator can be adapted to meet the needs of VegaStrike...
@schehearzade: I think your plugin idea for planets is really really good...
I think we can fit the city gen in there. The planet generator knows where a city is right? So you can darken or use another terrain texture on this spot. If you get close enough a tweaked/faster city generator kicks in and adds details like buildings in a kind of sub mesh of the planet... I for my part think that only the building generation is needed and no street gen (why drive when you can fly?)
Furthermore I think future citys will have a low number of very large structures, kind of a whole city in a single building (I forgot how they are called but they were in SimCity 2000)... As this is then just few large meshes LOD and frustum culling can be done effeciently to achieve nice frames per second...
As a plus maybe a similar system can be done to make procedural space stations/asteroid station... and L-System might be used for their original purpose of generation plants/trees for a planet enviroment... or Bioships
A university of possibilities....
cu Macross
PS:
I really appreciate and like the work of the many talented computer graphic artists workin for VegaStrike at the moment. I don't want to make them unemployed, but I think they can then focus on "key points of interest" in the VS...
Warning a lot of text ahead
Wow I didn't expect such good reactions In fact my university tutor said that much more details could be added. He is kind of Blade Runner fan (me too) and he wanted to see something like the opening scene of the film with the city flight through. Anyway I still consider myself as a starter in CG so don't have too high trust in me
Because Schehearzade asked and to point out things I'll explain briefly how the generator works:
1. Street generator
The street generator builds a street network using an L-System with simple rules like "add three street segments at the end of another to form an intersection". Furthermore these new segments are modified by a street pattern. These are radial like Paris, following gradients like San Francisco, checker board like New York and natural pattern following population density. However the result of this process is just a kind of suggestion which is adapted to the local surroundings. For example a intersection is added if sehgments intersect, segment is adjusted (shortened, other angle, deleted etc.) if in water or the gradient is too steep. The important part is this intersection test which really makes the network. As you might now L-System are generating tree like structures. Unfortunatly I don't do this test clever right now, so it's soooo sluggish...
2. Lot generation
Now we have a network of lines. These are now "thickened" to create streets. Blocks are extracted and these are subdivided into smaller lots between a minimum and maximum size. So a lot is basically just a polygon now (in fact these polygons are even flattened to be 2d).
3. Building generation
A L-System creates a string of actions to create a building, like "Extrude by x then scale with factor y then extrude by z...". Currently I have implemented an extrude, bevel and scale funtion. These are the applied to the lots/polygons from the privious step and makes quite low poly skyskraper stuff.
4. Textures
A terrain texture is generated which has all streets in it. Furthermore building textures are generated by using a wall tile and adding a window tile on top of it. By tiling each of these componets quite a variety of textures can be achived. The retrieved tile is then tiled across the building.
5. Terrain
Basic terrain from a heighmap. So it is not on a sphere or something....
I hope this make things clearer now.... and you understand what I say
I believe this city generator can be adapted to meet the needs of VegaStrike...
@schehearzade: I think your plugin idea for planets is really really good...
I think we can fit the city gen in there. The planet generator knows where a city is right? So you can darken or use another terrain texture on this spot. If you get close enough a tweaked/faster city generator kicks in and adds details like buildings in a kind of sub mesh of the planet... I for my part think that only the building generation is needed and no street gen (why drive when you can fly?)
Furthermore I think future citys will have a low number of very large structures, kind of a whole city in a single building (I forgot how they are called but they were in SimCity 2000)... As this is then just few large meshes LOD and frustum culling can be done effeciently to achieve nice frames per second...
As a plus maybe a similar system can be done to make procedural space stations/asteroid station... and L-System might be used for their original purpose of generation plants/trees for a planet enviroment... or Bioships
A university of possibilities....
cu Macross
PS:
I really appreciate and like the work of the many talented computer graphic artists workin for VegaStrike at the moment. I don't want to make them unemployed, but I think they can then focus on "key points of interest" in the VS...
A fight to death between zombies has some inherent problems.
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
macross <<
sounds good.
I have not made this part work yet, but there is a 'refine vector'
you set a defined unit vector on the sphere.
then even at the lowest LOD (smallest planet detail is 8 triangles, increases X4 each lod).
So if i insert a vector into that planet, and it was at a face, it would split that face into 3 triangles, with the centre-shared vertex @ the city altitude.
Now, i don't expect anyone will actually use an 8 faced planet, so the surface should be relatively round.
Also, the amount of planet sectors visible (inside the horizon) decreases as you get closer to the surface. This means that the LOD of any single visible planet sector can rise because less sectors are visible. By the time you get low enough for a city to be visible, the surface should be pretty smoothe and nice.
there is a heightmap-lookup function. It reads a heightmap texture and gets the altitude.
we can use this function to attach buildings where needed onto the planet model as needed.
also, we can project a flat city poygon onto the planet surface, which is dynamically textured with the city generated overtop of it.
sort of place a square onto the curface of the planet, and then 'sink' parts of it to fit to the surface.
so long as the sity is small, the building&surface angle won't be visibly tilted at the city edges.
-scheherazade
sounds good.
I have not made this part work yet, but there is a 'refine vector'
you set a defined unit vector on the sphere.
then even at the lowest LOD (smallest planet detail is 8 triangles, increases X4 each lod).
So if i insert a vector into that planet, and it was at a face, it would split that face into 3 triangles, with the centre-shared vertex @ the city altitude.
Now, i don't expect anyone will actually use an 8 faced planet, so the surface should be relatively round.
Also, the amount of planet sectors visible (inside the horizon) decreases as you get closer to the surface. This means that the LOD of any single visible planet sector can rise because less sectors are visible. By the time you get low enough for a city to be visible, the surface should be pretty smoothe and nice.
there is a heightmap-lookup function. It reads a heightmap texture and gets the altitude.
we can use this function to attach buildings where needed onto the planet model as needed.
also, we can project a flat city poygon onto the planet surface, which is dynamically textured with the city generated overtop of it.
sort of place a square onto the curface of the planet, and then 'sink' parts of it to fit to the surface.
so long as the sity is small, the building&surface angle won't be visibly tilted at the city edges.
-scheherazade
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
-
- Hunter
- Posts: 79
- Joined: Fri Sep 10, 2004 12:16 pm
- Location: Australia
- Contact:
You only really have to generate the city once dont you?
You could work out a simple way of storing the city (I can think of a few) then do a simpler make as they get closer.
Get a profiler for your code and send me the slowest bit and I'll see if I can optimise it. I managed to do a few processor intensive problems that completed in two minutes.
http://www.sppcontest.org/2004/Problems2004.html
I can show you how we optimised some of the stuff to go quickly. Dynamic programming and other precalculation-caching tequniques. Unless you have already implemented these.
From what I have read, you seem to say that intersection calculation takes a while. This only need be done once and the street pattern be stored some way that inclueds the intersections.
Also the subplot division sounds like it might take some time.
You could store the city as a bitmap (This isn't a very good solution, just a start) and have the intersections as nodes and have linked nodes numbered so they join. Like start from somewhere with 1, and everything it connects too is numbered. You have a seperate file that tells it how to link them. It would work, you just have to try to draw a situation where it doesn't. Keep in mind that everywhere a street intersects is marked. So you wont have two nodes connected to one another with the same number, because there will be a street intersecting on of the lines, introducing a different node between them.
You would reservrve 1 number and use it as the dividers between buildings. And have some way of storing the bulding as you have already done. Extrude and scale.
Make sense. The bitmap solution is not the best one, you could still compress the bitmap to save some room, and even change the base of the bitmap. If the maximum number you get to is 20, you dont need an 8 bit byte, only a 5 bit byte (max 31, this yields a saving of more than 30%). Or even better, a base 20 system.
I'm not good at working with networks though.
You may even just store the intersection somehow and overlay them on the generated map.
You could work out a simple way of storing the city (I can think of a few) then do a simpler make as they get closer.
Get a profiler for your code and send me the slowest bit and I'll see if I can optimise it. I managed to do a few processor intensive problems that completed in two minutes.
http://www.sppcontest.org/2004/Problems2004.html
I can show you how we optimised some of the stuff to go quickly. Dynamic programming and other precalculation-caching tequniques. Unless you have already implemented these.
From what I have read, you seem to say that intersection calculation takes a while. This only need be done once and the street pattern be stored some way that inclueds the intersections.
Also the subplot division sounds like it might take some time.
You could store the city as a bitmap (This isn't a very good solution, just a start) and have the intersections as nodes and have linked nodes numbered so they join. Like start from somewhere with 1, and everything it connects too is numbered. You have a seperate file that tells it how to link them. It would work, you just have to try to draw a situation where it doesn't. Keep in mind that everywhere a street intersects is marked. So you wont have two nodes connected to one another with the same number, because there will be a street intersecting on of the lines, introducing a different node between them.
You would reservrve 1 number and use it as the dividers between buildings. And have some way of storing the bulding as you have already done. Extrude and scale.
Make sense. The bitmap solution is not the best one, you could still compress the bitmap to save some room, and even change the base of the bitmap. If the maximum number you get to is 20, you dont need an 8 bit byte, only a 5 bit byte (max 31, this yields a saving of more than 30%). Or even better, a base 20 system.
I'm not good at working with networks though.
You may even just store the intersection somehow and overlay them on the generated map.
2 133t for joo!!!
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
it's a lot less memory to store a single number per planet (the seed, could be the planetname+systemname for instance) than to store complex geometry...
why worry about saving anything at all--just generate it at system gen time
why worry about saving anything at all--just generate it at system gen time
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Hunter
- Posts: 79
- Joined: Fri Sep 10, 2004 12:16 pm
- Location: Australia
- Contact:
Oh yeah. That would be the simple way wouldn't it.
So let me get this right.
People want a MMORPG that lets you fly around the universe, fly into planet atmospheres and fight people. Maybe even go underwater.
Is it easier to list what you dont want?
You don't want to be able to get out of the ship.
You don't want to be able to...uhh...I think thats it.
So let me get this right.
People want a MMORPG that lets you fly around the universe, fly into planet atmospheres and fight people. Maybe even go underwater.
Is it easier to list what you dont want?
You don't want to be able to get out of the ship.
You don't want to be able to...uhh...I think thats it.
2 133t for joo!!!
Wrong, We want to get out of the ship and it is simple to program that We are happy to wait untill the seamless planet gen is completed though.Alaskan wrote:Oh yeah. That would be the simple way wouldn't it.
So let me get this right.
People want a MMORPG that lets you fly around the universe, fly into planet atmospheres and fight people. Maybe even go underwater.
Is it easier to list what you dont want?
You don't want to be able to get out of the ship.
You don't want to be able to...uhh...I think thats it.
This is an opensource project with time limited only by the coming of the end of the earth/universe so, we can do it . Go scheherazade!
This thing will blow everything out of the water... and we can keep improving and adding to it since we don't have deadlines .
-
- Explorer
- Posts: 11
- Joined: Fri Oct 01, 2004 4:42 pm
- Location: Munich, Germany
- Contact:
Building gen
Hi!
As a start for what may become a fullscale city generator for procedural planets, I suggest tostart out with something simpler. I think we could do a a improved building generator first.
In my imagination a building generator would take a polygonal building outline to start with and a random seed. Then as I previously mentioned certain geometry operations are applied to the outline to generate structures. However I would like to add more types of operations to enhance visual detail. The result is then exported as VegaStrike model. First geometry only, texturing later. What do you think?
By the way can someone point me to the file containing the class encapsulating a model in VS? I'm a bit lost in source right now...
cu macross
As a start for what may become a fullscale city generator for procedural planets, I suggest tostart out with something simpler. I think we could do a a improved building generator first.
In my imagination a building generator would take a polygonal building outline to start with and a random seed. Then as I previously mentioned certain geometry operations are applied to the outline to generate structures. However I would like to add more types of operations to enhance visual detail. The result is then exported as VegaStrike model. First geometry only, texturing later. What do you think?
By the way can someone point me to the file containing the class encapsulating a model in VS? I'm a bit lost in source right now...
cu macross
A fight to death between zombies has some inherent problems.
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
hmm... hellcat had a pic of the class relationsi think. you should be able to fin d it somewhere in the screenshots maybe? not sure. ot the main news page in earlier times.
well, you could calculate the city streets outline first, and store it to a vector graphics format. (work ahead)
bin the square centres of the street pattern along X and Y checkerboard divisions. (overlapping grid, also work ahead)
then do a X/Y lookup (rather instant) as you get into range of certain squares. retrieve the city blocks that are located in those bins. (at playtime)
then generate the building geometry from those city blocks (that's rather trivial) as you fly into the city. (at playtime)
-scheherazade
well, you could calculate the city streets outline first, and store it to a vector graphics format. (work ahead)
bin the square centres of the street pattern along X and Y checkerboard divisions. (overlapping grid, also work ahead)
then do a X/Y lookup (rather instant) as you get into range of certain squares. retrieve the city blocks that are located in those bins. (at playtime)
then generate the building geometry from those city blocks (that's rather trivial) as you fly into the city. (at playtime)
-scheherazade
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
but to be able to get out and walk around, we would have to have a localized coordinate system and coord translation (only for flying and on surface interaction). using the coords of the entire universe can be a little inaccurate. especiallt if someone makes a huge universe.
do something maybe planet centric. all people on the planet would share planet coords.
but this is far off. in large also because we don't have a set of player model avatars for people to use if htey did try to walk around outside.
-scheherazade
do something maybe planet centric. all people on the planet would share planet coords.
but this is far off. in large also because we don't have a set of player model avatars for people to use if htey did try to walk around outside.
-scheherazade
-
- Developer
- Posts: 427
- Joined: Thu Jan 09, 2003 6:03 am
-
- Elite
- Posts: 1671
- Joined: Fri Jan 03, 2003 12:46 am
- Location: Earth, Sol system.
- Contact:
In my limited experiance, I think that if we tried, and planned for a first person mode right now; it would never get done.
Its too big of a project to take up. While planning it would be fun, I cant see anyone having the dedication to spear-hea this.
Its best to work on one thing at a time. Planet generation today, and if that gets done, then we could start thinking about a first person mode.
Its too big of a project to take up. While planning it would be fun, I cant see anyone having the dedication to spear-hea this.
Its best to work on one thing at a time. Planet generation today, and if that gets done, then we could start thinking about a first person mode.
Last edited by hurleybird on Wed Oct 06, 2004 1:31 am, edited 1 time in total.
I must say that as a useless leech, er, fan, I think any elements that aren't directly consistent with Privateer-style play should be thought of as an expansion to be added later. I absolutely love what you're doing with the graphical concepts here, but first-person is an entirely separate game. Combinable, obviously, but separate.
I agree 100%. It is best to take things 1 thing at a time.hurleybird wrote:In my limited experiance, I think that if we tried, and planned for a first person mode right now; it would never get done.
Its too big of a project to take up. While planning it would be fun, I cant see anyone having the dedication to spear-hea this.
Its best to work on one thing at a time. Planet generation today, and if that gets done, then we could start thinking about a first person mode.
I don't agree, I think that while 1st person can wait, it should come to frutition eventually in VS (though you could think of it as a seperate part of the game, planets are diffrent from being free in the void of space)... Planets will be fun tho so let's focuse on seamless flight on/off etc planets (don't forget the underwater parts ). 1st person can come abit later (it won't even be hard once we have a model or 2).Anonymous wrote:I must say that as a useless leech, er, fan, I think any elements that aren't directly consistent with Privateer-style play should be thought of as an expansion to be added later. I absolutely love what you're doing with the graphical concepts here, but first-person is an entirely separate game. Combinable, obviously, but separate.
-
- Bounty Hunter
- Posts: 201
- Joined: Wed Jan 14, 2004 11:11 pm
- Location: londonengland, england
- Contact:
i also disagree. you're being confined by convention - dont think of them as seperate games! would you seperate the driving from the walking in gta?
for all the realism in the world regarding space flight physix and pretty nebulaic backgrounds, how realistic is it if you can never get out of your ship?
what's the point in building a fantastic universe if you're only gonna interact with it in one way?
the future my friends, is in freedom... and here's a list of reasons why...
gta
halo
unreal tournament 2004
frontier - elite II
starwars battlegrounds
battefield 1942
etc etc etc
for all the realism in the world regarding space flight physix and pretty nebulaic backgrounds, how realistic is it if you can never get out of your ship?
what's the point in building a fantastic universe if you're only gonna interact with it in one way?
the future my friends, is in freedom... and here's a list of reasons why...
gta
halo
unreal tournament 2004
frontier - elite II
starwars battlegrounds
battefield 1942
etc etc etc
- - above and beyond - -
I agree * 1million .strangelet wrote:i also disagree. you're being confined by convention - dont think of them as seperate games! would you seperate the driving from the walking in gta?
for all the realism in the world regarding space flight physix and pretty nebulaic backgrounds, how realistic is it if you can never get out of your ship?
what's the point in building a fantastic universe if you're only gonna interact with it in one way?
the future my friends, is in freedom... and here's a list of reasons why...
gta
halo
unreal tournament 2004
frontier - elite II
starwars battlegrounds
battefield 1942
etc etc etc