Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Nuke on June 20, 2009, 06:16:39 am
-
lately ive been attempting to create extremely high poly terrain models using extensive detail boxing. i want to be able to go to a resolution as high as 2 polygons per square meter, yet want to cover the entire xz plane of the mission space of 1500000^2 meters (with some no-mans land to complete the illusion and provide a buffer so a skybox can be used to generate the feel of expanse). were talking 4500000000000 polies! purely impossible entirely. so how close to that can i get?
ive been using topographic maps as well as visible spectrum maps of various planets and moons generated by various space missions by nasa and other space agencies. seems the best maps are for the moon or mars. they are fairly easy to to convert to models in max, using the topographic map and the displace modifier on a subdivided plane generates some fairly accurate terrain. the trick is making the resolution of the terrain model more dynamic. you do this by tiling the model. and then having a progressive loding system drop or raise the lod of each tile depending on how close you are to it.
my closest attempt was a 1280.58^2km terrain model of a rather boring part of mars, at a resolution of roughly 2 polygons per 18^2 km. and it looks pretty good from high altitude. it worked and my fps stayed at 60, unfortunately my detail box based loding kinda sucked. in fact it didnt work at all, so only the low poly version of the model was ever visable. i setup 36 tiles, each having2 lods, one between 4k and 5k polies each, and another at about 500 each. this was actually the 2nd and 6th lods of the tiles i created, each had 7 lods. unfortunately the detail box system is rather cumbersome when dealing with that many subobjects. this of course was a prototype to see if the idea would work. and it sorta did. it took about 20 minutes for pcs2 to generate bsp trees for it, and another 10 minutes for freespace to create an ibx for it. and the model was 44 megs.
my plans for a final version require 256 tiles each 100 km^2. lods would start at 1 square by 1 square by 2 tris, and continue up exponentially from there to about 128*128*2, for 8 lods (32768 polies at the top level). the lod of the current tile beneath you would depend on your height. possibly dropping an lod per 10km of altitude above it. the detail boxes would extend slightly over eachother to provide a transition zone, so if youre over an edge 2 tiles will be rendered at the lod for your height, over a corner and 4 tiles would get rendered at that lod. to prevent too many polies from being displayed at once, the detail box overlap would need to lessen as lods get higher. one would have to put together an lod progression that keeps too many polies from rendering at once.
then comes the matter of how to lod it. theres a couple ideas i have, one is to make each tile a subobject with its own stack of lods. though im not sure if freespace does per subobject lod distances (it really should because theres no point rendering a 2000 poly turret at the other end of a 10km long ship that fills up a dozen pixels on the screen). that would certainly make things a lot easier in the long run. the detail box system is rather cumbersome. since each lod of each tile, 2048 of them!, needs special subobject properties. also detail boxes dont exactly give you much control, it either renders when youre in the box or out of it, and i dont know if its possible to set inner and outer boundaries for each detail object. you might have to group a blank poly with each lod, so if youre in the box render the detail model, if not render the dummy with detail boxes as children. put frankly detail boxes suck or this. unless of course you create them procedurally. what would be really awesome is a utility to generate terrain models with a few parameters and a topographic map, and spew out a pmf model with all the tiles pre detail boxed for you. that would be kinda cool.
-
I admire you Nuke! I wouldn't even think to do somethink like this without a team of 20 modelers an 3600 converters. :D
-
Pictures or it didn't happen :p
Seriously, I admire your spirit for adventures in the FSO engine.
-
Okay, now this sounds awesome.
-
Pictures or it didn't happen :p
Seriously, I admire your spirit for adventures in the FSO engine.
its still a wip, my proof of concept worked but it was kind of ugly, so im working on fixing it
-
May the road rise, Nuke! Looking forward to seeing what develops.
Cheers
-
Screenshots, kthx.
-
i just wanted to share the technique and see if anyones done this before (aside from a certain death star). i estimate it would take a lot of effort to do this properly (something im not exactly known for). in fact its probably easier to to write a topomap->pmf converter. give it a really big topographic map and a really big texture, set some parameters, and it spits out a pmf, tables, textures, and possibly shell into a normal map compiling program to generate those from the top lods, with all the detail boxes pre-generated for you. then all you got to do is load it into pcs2, compile bsp and collision data (this takes awhile), then load into the game and create an ibx (also takes awhile)
-
It would be completely awesome ,with this even I would be able to make terrain models.
I wish you good luck with this, Nuke.
-
i started writing a lua based tga parser. i found a module that you can use to strings to typed binary and vice versa. this lets me better work with binary files like tga, as well as pmf and pof. the tga specs are so simple i managed to get a parser working fairly well. it wont be hard to generate triangular patch grids of different resolutions. then it would be a simple matter of mapping the image over it and then set the y value of every vert according to the pixel value in the same place on the map. there will probibly be some kind of filtering done to smooth out the results, as well as amplify the effect.
im either gonna use a sdl based software renderer or no renderer at all (command line only). id go with an opengl renderer but then id have to compile a custom lua interpreter with open gl bindings. but the hard part will be understanding kazan's pmf specs.
-
What nuke wrote:
i started writing a lua based tga parser. i found a module that you can use to strings to typed binary and vice versa. this lets me better work with binary files like tga, as well as pmf and pof. the tga specs are so simple i managed to get a parser working fairly well. it wont be hard to generate triangular patch grids of different resolutions. then it would be a simple matter of mapping the image over it and then set the y value of every vert according to the pixel value in the same place on the map. there will probibly be some kind of filtering done to smooth out the results, as well as amplify the effect.
im either gonna use a sdl based software renderer or no renderer at all (command line only). id go with an opengl renderer but then id have to compile a custom lua interpreter with open gl bindings. but the hard part will be understanding kazan's pmf specs.
What I read:
I'm casting a Magic spell to help me make the impossible possible
:lol:
-
thats pretty much it. :D
-
does it need to cover the entire potential play area ? I know it would be best if it did, but I'd be inclined to do something more like a quarter and put up some invisible walls to stop smart arses' fromt straying. No where near as "cool" but it's worked for pro games for years.
-
no, but i want it to be an option. in fact i want to make terrain size and number of tiles input variables. so you can make as big of a model as you want, or a smaller more detailed one if its better suited to your modding needs. mainly im writing this util for my atmospheric flight model, but if you want to restrict the players movement, then it wouldnt be that hard, just import an inverted cube with the invisible texture with pcs2. this would allow you to use more detailed terrain, if you plan to use standard freespace physics.
so far its still not generating polygons, the tga parser works flawlessly, i got my pixel class working and my 2d vector class working. today il work on the 3d vector class and see if i can generate at least some verts with tga imported height values. im kind of concerned about memory usage. since loading a 300x300 pixel image somehow consumed 600 megs of ram. though it may have just been my ascii renderer :D
-
Why lua?
-
Because Nuke is a scripting junkie?
-
i really like lua. since ive discovered the language ive been very impressed with it. you dont have to **** with datatypes, pointers, references, and dynamic memory. you just go straight to doing what you need to do. its also a good way to prototype stuff i might eventually do in c/++. for example my (still not quite done) particle spew code was prototyped in lua.
-
So, still nothing in-game?
-
no. im starting to question if this is even possible. lua's memory usage is through the roof. just loading an 8 bit 2048^2 topographic map (much smaller that what i had planned to use) eats over 500 megs of memory. it should only be around 32 megs, but lua tables are rather inefficient when it comes to memory use. apparently named keys take up 40 bytes each, indexed keys use up 16 bytes each. unless i come up with a means to streamline the whole process my efforts may be in vain. i could start over and write it directly in c/++. which would allow an opengl rendered of sorts. but im gonna try to change some of my tables around to see if i can squeeze more memory from the whole system.
-
heres a teaser, this is a low lod of the proposed full level terrain map.
http://www.youtube.com/watch?v=MMmhsxv69uI
it also shows my atmospherics and gravity
-
LIES :pimp:
Nice video. But the actual stuff you're programming isn't what's shown in it.
-
no, that was put together in max. i only posted it because somone requested a video of my physics engine. it just had the prototype in it.
-
The atmospheric system and gauges are pretty awesome, but it's that giant map that blows my mind.
-
Heheh, ok. I like the visible seam that I can see at one point.
-
thats because i made the mistake of optimising it, and it really messed up the seams by moving verts around. either way im gonna need to do something to those edges to keep seams from forming. so i decided to stick with a strict exponential grid pattern across all lods. i also decided that adjacent tiles will be a max of 1 lod below your current tile. the highest lod will have about 64*64 grid with 2 triangles forming each grid square. the next lod will have a 32x32 grid and so on, all the way down to 1*1. tiles will fall off to lower lods in concentric circles. in this manor fewer than 50000 polygons will be displayed at any time (clipping and backface culling will eliminate many of those). when tiles are at the same lod it should be seamless, but when there is an lod difference, there will be places that dont lign up. best way to deal with that will probibly by adding an extra row of polygons that extend down to y0. these are all things i thought about when i thought about a terran generator.
lod propagation should probibly look something like this, imagine it more square. 0 being the top lod and 6 being the low lod. with this propagation and a 64*64*2 polygons at the max lod, you can have highly detailed terrain and the plycount will remain less that 50k.
6666666666666
6666655566666
6666544456666
6665433345666
6654322234566
6543211123456
6543210123456
6543211123456
6654322234566
6665433345666
6666544456666
6666655566666
6666666666666
-
Nuke, if you don't need collision detection then you can do some of this in the shader.
Vertex Shaders are permitted to move vertices around as much as they like, but obviously this won't apply to collision detection.
-
well collision detection is kind of important. i dont see why the highly detailed terrain would need to break that. i also dont see this as something that can or should be done with shaders. in a perfect world the geometry would be generated procedurally by the engine, in the way that normal flight sims do. on the other hand it doesent need to be, it can just be a highly loded model.