Peregrine
-
Wow, this tool is a huge breakthrough. If all of the features that reported are implemented, the time it takes to build might just be reduced by a factor of 90%. Theatre building could done in months rather than years.
-
Fixed a source for full world satellite/precipitation cloud layer.
-
This is great.
You can also incorporate CATE with a good script (for Auto-tiling) and some campaign setup (countries, etc). You can also go beyond just terrain generation and add features like “Add New Aircraft” because a lot of it is just editing text files. I think you can get a tool to automatically build the entire theatre, users would only have to specify their aircraft models and skins and artwork. You can look at PMC forum for some hints on how to do certain things too.
Keep us updated.
-
This is great.
You can also incorporate CATE with a good script (for Auto-tiling) and some campaign setup (countries, etc). You can also go beyond just terrain generation and add features like “Add New Aircraft” because a lot of it is just editing text files. I think you can get a tool to automatically build the entire theatre, users would only have to specify their aircraft models and skins and artwork. You can look at PMC forum for some hints on how to do certain things too.
Keep us updated.
CATE will be obsolete. Peregrine will tile elevations based on GMTED data, from there, you’ll be able to tile areas with satellite imagery. Once BMS get’s past it’s 4096 tile texture limit (dev’s, pm me if you want me to help), I can automate texture tiling across the entire map.
-
Excellent, looks very promising, thanks for your effort on this!
Perhaps you might be able to find a solution too on how to make the flat terrain currently (since falcon day-1) to a true earth sphere.
-
Excellent, looks very promising, thanks for your effort on this!
Perhaps you might be able to find a solution too on how to make the flat terrain currently (since falcon day-1) to a true earth sphere.
Elevation can be re-spherized based on the arc/degree of the data, sure. Would still be a “flat map” but elevations would be added to project the curvature back into the mesh.
-
CATE will be obsolete. Peregrine will tile elevations based on GMTED data, from there, you’ll be able to tile areas with satellite imagery. Once BMS get’s past it’s 4096 tile texture limit (dev’s, pm me if you want me to help), I can automate texture tiling across the entire map.
Hi, tiling is obsolete I think… the main problem with tiles is the huge number of textures which basically causing a lot of overhead for the DX API (crazy number of draw calls).
Interesting stuff BTW
-
Hi, tiling is obsolete I think… the main problem with tiles is the huge number of textures which basically causing a lot of overhead for the DX API (crazy number of draw calls).
Interesting stuff BTW
I-Hawk, if BMS went to a DX11 API, you could offload much of the texture computations of to the GPU. Furthermore, Updating to a GFX Engine like Python would make the change to DX11 much simpler and make the base BMS program much less CPU intensive in turn.
-
Sure. Can you code it??
-
I-Hawk, if BMS went to a DX11 API, you could offload much of the texture computations of to the GPU. Furthermore, Updating to a GFX Engine like Python would make the change to DX11 much simpler and make the base BMS program much less CPU intensive in turn.
Well… upgrading to DX11 isn’t a simple task. But I don’t see how DX11 will solve the API problems, in fact AFAIK in DX11 such overhead from number of textures/draw-calls for terrain will become worse… The terrain engine must change drastically in order to output quality results with decent performance.
-
… Here is what I’ve come up with so far after a few weeks worth of work.
Why …
… didn’t you create Peregrine already 10 years ago?
According to your post it sounds coding it is easy and quick to do,
although I personally think it’s not that easy.Anyway, great stuff.
Cheers,
LS -
Can you re-code a new 3d modelling tools, plug-ins or integrate tools from 3dsmax to bms? to be much easier than now and quicker?
-
Sure. Can you code it??
Actually, we have a brilliant coder here on this forum who can: SHalik.
-
Well… upgrading to DX11 isn’t a simple task. But I don’t see how DX11 will solve the API problems, in fact AFAIK in DX11 such overhead from number of textures/draw-calls for terrain will become worse… The terrain engine must change drastically in order to output quality results with decent performance.
That’s why I was suggesting upgrade to DX11 be done in conjunction with a replacement GFX Engine like Python. The Python engine would remove many of the obstacles, short coming that we have like the 4K tile limit. Also, Python is an API written for Native DX11, thus is is much more efficient at draw-cycles than our legacy code.
-
That’s why I was suggesting upgrade to DX11 be done in conjunction with a replacement GFX Engine like Python. The Python engine would remove many of the obstacles, short coming that we have like the 4K tile limit. Also, Python is an API written for Native DX11, thus is is much more efficient at draw-cycles than our legacy code.
I’m against a python engine, rather, I’d like a move to C++ OpenGL 4 (I know both DX/OpenGL). That would lend itself to better cross-platform later.
-
Hi, tiling is obsolete I think… the main problem with tiles is the huge number of textures which basically causing a lot of overhead for the DX API (crazy number of draw calls).
Interesting stuff BTW
This problem was solved years ago. It’s called Virtual Texture Fetch or “MegaTextures”. The idea is the terrain “tiles” are indexed into a texture (512x512 encoded rgba) which gives unsigned int number of tiles. When a terrain tile is drawn, a simple texture fetch is performed in one pass to gather all the textures needed to draw. OpenGL 4/DX11 have a limit on the number of textures in a shader. Old limit was 16, new limit is 32. 32 textures, 16 day, 16 night. You can draw an entire segment in one pass.
Chunked Quadtree Tiling is often a common approach to landscape engines. My personal favorite is Geoclipmapping (I’ve implemented it on both the CPU and the GPU). With Geoclipmapping, you “stitch” different level of details of a mesh as you traverse it. Texture lookups are handled at the LOD level. a 64x64 patch is usually standard affair here. But at the lowest LOD setting, that 64x64 patch is 1000km. I’ve developed game engines in the past and always loved it when we got to the terrain engine.
So “tiles” aren’t dead, they just were reinvented.
http://research.microsoft.com/en-us/um/people/hoppe/gpugcm.pdf
This explains Geometry Clipmaps pretty well. Though it’s old and new ways were discovered. It’s still the goto paper. When it was released, it rocked the game industry. -
You certainly have my attention. Fingers crossed
-
I’ve developed game engines in the past and always loved it when we got to the terrain engine.
This is really very exciting and promising. We all share great interest in terrains in computer games and simulations. Falcon, after all those years, sure deserves some revitalizing in Terrain department.
Having said this, we should also realize, that to pull off such an innovative (and yet being around for some years) approach to the problem of rendering the terrain in fast and performance always hungry flightsim requires practical solution to many technical and logistic problems. The volume of the graphics required to be handled, being perhaps just one of them.
Still, as long as your interest in improving Falcon terrain is serious, you should be having all deserving attention here and willingness to help. Keep this discussion going and thanks. :munch:
-
This problem was solved years ago. It’s called Virtual Texture Fetch or “MegaTextures”. The idea is the terrain “tiles” are indexed into a texture (512x512 encoded rgba) which gives unsigned int number of tiles. When a terrain tile is drawn, a simple texture fetch is performed in one pass to gather all the textures needed to draw. OpenGL 4/DX11 have a limit on the number of textures in a shader. Old limit was 16, new limit is 32. 32 textures, 16 day, 16 night. You can draw an entire segment in one pass.
Chunked Quadtree Tiling is often a common approach to landscape engines. My personal favorite is Geoclipmapping (I’ve implemented it on both the CPU and the GPU). With Geoclipmapping, you “stitch” different level of details of a mesh as you traverse it. Texture lookups are handled at the LOD level. a 64x64 patch is usually standard affair here. But at the lowest LOD setting, that 64x64 patch is 1000km. I’ve developed game engines in the past and always loved it when we got to the terrain engine.
So “tiles” aren’t dead, they just were reinvented.
http://research.microsoft.com/en-us/um/people/hoppe/gpugcm.pdf
This explains Geometry Clipmaps pretty well. Though it’s old and new ways were discovered. It’s still the goto paper. When it was released, it rocked the game industry.Thanx for the answer
AFAIK, DX11 supports up to 128 textures in a shader. But still, instead of loading (and managing, including micro-art work because we all know that photoreal not always match game view 100%) 1000s of tiles, with multi-texturing and smart blending, you can achieve some awesome results. At least according to what I’ve seen on the network about DX11 terrain engines, all use multi-texturing (and DX11 tessellation), something like this:
But, I’m really talking a lot compared to what I know about DX, so I should get back to the books and demos
-
This is really very exciting and promising. We all share great interest in terrains in computer games and simulations. Falcon, after all those years, sure deserves some revitalizing in Terrain department.
Having said this, we should also realize, that to pull off such an innovative (and yet being around for some years) approach to the problem of rendering the terrain in fast and performance always hungry flightsim requires practical solution to many technical and logistic problems. The volume of the graphics required to be handled, being perhaps just one of them.
Still, as long as your interest in improving Falcon terrain is serious, you should be having all deserving attention here and willingness to help. Keep this discussion going and thanks. :munch:
Thanks. Yeah, resource management is at the core of any game engine. Terrain Systems like quad tree’s and have their own textures per leaf and can be loaded @ runtime using multi-threading techniques, and unloaded when the leaf is. Things get a little more complicated from there like with Geometry Clipmapping. Basically, you need a running buffer that you can flush and populate at all the different LOD’s of the pyramid. Remembering from math class that f(x) = x + (y * stride) we can keep a running buffer of a rectangle indexer into the larger texture data. This is EXACTLY how tools like Peregrine can index into much larger images of data (3Mpx x 3Mpx resolution 300dpi). The math is known, it’s the data that needs catching up. Having high res tiles of the world takes up an EXTREME about of space. 2-3 TB there abouts. It’s all about resource management here too. Opening a file handle but NOT reading, only seeking to the desired rect helps, but keeping data centralized while delivering it on-demand is better. Peregrine itself streams tiles from all sorts of providers, both free and commercial (more about that later), and provides caching of those tiles so that additional lookups aren’t downloading data. However, data cache is finite and eventually “stale” data needs to be flushed to make room for “fresh” data. This all happens on a separate thread, along with the garbage collector. Essentially it is a garbage collector.
Let’s take, for example, a 64 size terrain. Standard size here. 16x16 tiles in a segment, 64*64 segments. 1024x1024 tiles. 512px textures RGBA (alpha being nightlight!).
let ImageSizeInBytes = 5125124 (4 byte color RGBA) 1048576 bytes or 1MB!
let TerrainSize = (1024*1024) 1048576 images required! interesting, the same size as our packed RGBA data for each tile.
let AmountOfStorageRequired = (ImageSizeInBytes * TerrainSize)1.0995116e+12 bytes = 1099511600000 bytes or 1TB.
Here’s where we cheat. a 64x64 segment terrain of 16x16 tiles won’t work. However, a 16x16 chunked grid w/ 1 texture on each chunk (with a finer mesh) does. Almost all hardware nowadays can load a 4096x4096 texture.
(409640164) * (16*16) = 16.844324864 GB. Large yes, but doable, those super large textures could be reduced further without compromising the mesh @ the expense of blurring of features on the texture.
(102410244) * (16*16) = 1.073741824 GB. A gigabyte is nothing nowadays.
But I digress…