Peregrine
-
A noob’s question if I may…will it be possible to enable real mesh, real textures and real sceneries in BMS with the current engine’s limitations or handicaps.
Or…will it be possible to upgrade/ change the current graphical engine within BMS to enable it?
I know if it’s possible it might take years…but…just interested of the prospects.Outside the scope of this project. This project aims to make creating theater’s for BMS easier. Not to replace any internal BMS functionality. That said, those with the source code would be able to make any modifications to BMS’s internal simulation code, not me.
-
Great! Will love to see autopopped cities and towns!
If defining an area on a tile as a city or whatever creates autogen buildings than it will work. I can only work within the restrictions of BMS as it is currently in 4.33.
-
A noob’s question if I may…will it be possible to enable real mesh, real textures and real sceneries in BMS with the current engine’s limitations or handicaps.
Or…will it be possible to upgrade/ change the current graphical engine within BMS to enable it?
I know if it’s possible it might take years…but…just interested of the prospects.If BMS terrain engine will change, probably RL tiles will NOT be the way to go… modern games aren’t using dedicated tiles, but more likely mutli-texturing techniques. The land should come to life with autogen/real objects and not with dedicated tiles.
Using a lot of textures will probably be less efficient always because however you look at it, you will need to load/swap a lot of memory, even assuming that you load textures as Array, still for including enough tiles there is a need for MANY textures.
-
I could see there still being a call for using photoreal textures for specific areas. I was just going through some satellite imagery of north korea yesterday wondering if the features I was looking at were modelled in BMS (pyongsan mine, punggye-ri test site, the yongbyon complex and a few others). Seems like more satellite imagery would be one easy way to tile areas realistically without worrying about how accurate it is to real life.
-
Photoreal for specific (and special) areas which cannot be filled with “generic” textures is OK I guess as long as the photoreal usage is sane.
-
Well obviously it would be far better to have objects instead of relying on tiles for detail… but I guess there is problems with that too.
-
What about painting areas for the autogen ?
So it should be possible to paint or to rub the areas by using a brush.Unfortunately, the way autogen works, it doesn’t really lend itself to painting. However, it’s really easy to add autogen features to tiles using the tile editor part of Peregrine. That’s separate from the terrain itself. The reason being is that it’s the Tile that holds the data for the autogen and the autogen data is nothing more than an area (point, radius). However, in the future, I might look into providing a circular “brush” for the terrain where when you click it intersects all the tiles and makes sure there’s a corresponding “autogen area” attached. This would be similar to painting but it wouldn’t, because we are limited to the number of area’s on a tile. But, then again, as we move forward, the BMS plugin for Peregrine WILL be open source, so who knows.
I don’t know how easy it will be to add autogen features to tiles using the tile editor part of Peregrine,
but at least you will have to create some circles of various size (click center -> move size -> release)
to cover the territory of a tile which you want to autogen.This is a time consuming and boring process.
(click click click click click click click click click click click click click click click …)
… for each sort of areas. (tree, bush, gras, etc… )The idea is to paint the territory of a tile which you want to autogen,
and an algorithm will convert that painted “shape” into fitting area circles.Using a small brush size we could also paint 3 little single tree areas by just 3 clicks.
This should be quicker and more intuitively than creating thousand of circles.
Once the mentioned converting algorithm exist, we could further simplify the
area creating process by getting the “painted territory” from a saved .bmp.The idea would be that a tile creator will have differently layers in photoshop anyway.
(plain, water, forest, gras, … etc.)
So it would be easy for him to create a 2 colored bitmap, black/white where black is plain
and white is trees territory for example.Loading such an bitmap into Peregrine and let the converting algorithm taking care
of it would almost automate the process.… just ideas.
Cheers,
LS -
mutli-texturing techniques.
….
Photoreal for specific (and special) areas which cannot be filled with “generic” textures is OK I guess as long as the photoreal usage is sane.
I think mutli-texturing techniques + the current 4096 tiles max. will be fine for me.
Well obviously it would be far better to have objects instead of relying on tiles for detail… but I guess there is problems with that too.
IMHO both would be nice for eyecandy. (tiles with matching 3D on top)
… but I dunno about performance.Cheers,
LS -
You guys are getting way ahead of yourselves here.
- no modifications to bms’ terrain system is going to happen here.
- painting tiles is the primary goal along with some tile transition tiling algorithm with it.
- satellite imagery is there to help you create tiles as well as line up GIS data.
- tile editing exists for adding autogen data but at this time I’m not planning on making it so you can paint them on the terrain
- having more than enough experience building terrain systems, usually they are integral to the systems so it’s not simply a rip/replace.
- the plugin will be open source, so there’s no telling what will be added in the future after release.
- all great discussions on terrain systems but let’s reign back to bms here.
- despite everything, viewing 32x32 segments at a time eats up around 4-5gb of ram. (512512)(1024*1024)*4 bytes for a 64x64 segment theater, assuming 1 tile = 1km and and is tiled at 512px with a 10 degree arc coverage across the theater.
Those with lower end machines won’t find the editing tools of peregrine any faster than what’s available, except maybe with satellite photos and vfr/ifr data. - Soon after release I’ll build a plugin using my game engine that will show the terrain in 3D. Both the falcon bms tiles as well as the satellite map tiles with meshes (and probably include the features to export that data as 3ds or something)
- I’m working hard just to finish up the BMS plugin so hopefully soon you guys will better understand everything.
-
I think mutli-texturing techniques + the current 4096 tiles max. will be fine for me.
4096 is WAY WAY too much for multi-texturing, the idea is to not NEED that much. I guess with something like MAXIMUM 256 textures and decent blending techniques, you can create many many different looks to the land.
-
You guys are getting way ahead of yourselves here.
That is because there is so much :bowd::woohoo::bowd: in what is being currently done.
Just short observation regarding 3D building autogen. Despite “popular demand” for robust 3D cities this may be harder than it sounds. First, for the buildings in adition point coordinates + radius to designate areas of buildings wont be sufficient like it is in case of the trees. Orientation for each 3D unit needs to be added as this needs to be coordinated with possibly streets,roads, etc.
There is this problem of collision/damage/destruction for buildings as well as the fact that unlike as autogen trees which employ 1 single model, buildings tend to be little more varied in shape and size. GU movement through frequent 3D objects may prove to be difficult.So generally we are potentially stuck with the current way all of the features are rendered. All in database and bunched up as an objectives and perhaps only making them more expanded is the way to go for now. That requires quite a lot of work and time, and will possibly not be willing to accept any “magic” autogen treelike solution.
-
4096 is WAY WAY too much for multi-texturing, the idea is to not NEED that much. I guess with something like MAXIMUM 256 textures and decent blending techniques, you can create many many different looks to the land.
Post# 25 sounds like a solution … ???
256 are nice to bring variations into a (size of) 64 seg. terrain,
but what about greater terrains, and what about dedicated landmark and city tiles
in a (size of) 128+ seg. terrain then?At least the possibility to use more than 256 textures would be nice IMHO,
… how many textures a dev will then NEED is terrain specific, I guess.
(iran - europe for example)BUT, feel free to prove me wrong someday.
No need to reply on this, I-Hawk. … we are slightly OT anyway.
… sorry reiser.Cheers,
LS -
Photoreal for specific (and special) areas which cannot be filled with “generic” textures is OK I guess as long as the photoreal usage is sane.
Well that is the “problem” with a simulator. Every little bit of the whole theater is special and would need a special tile
Look at most of the areas build for FSX, all very accurate as you want to recognize and navigate by looking at the ground.Gr Falcas
-
Well that is the “problem” with a simulator. Every little bit of the whole theater is special and would need a special tile
Look at most of the areas build for FSX, all very accurate as you want to recognize and navigate by looking at the ground.Gr Falcas
One of the big things our Guam theatre/project is trying to show is that we can build a 100% photo-real theatre and still have good FPS. Every land tile tile including the airports in Guam is made of unique, high resolution satellite imagery. The way we stay under the 4096 limit is entirely due to the large bodies of water around the land masses. So hopefully, one of my many wishes is that in the future, code changes can allow us increase the 4096 tile limit tenfold or more and Peregine will allow to construct a 100% photo-real real theatre much faster than the techniques we used in Guam.
-
This really applies to everyone.
At this stage of this program development it is crucial that all of those who had dealt with terrain making for BMS give their input what and how to possibly improve this process. I know, that this is in a way little heavy handed and even rude to give just suggestions to a programmer and be expecting all that can be implemented. Pushing this correctness aside and in order to accomplished progress here, I think, this could be rather helpful.
Isn’ this basically the way we’ve been “steering” BMS development for quite a while now, by just throwing ideas over the fence and hope the devs pick them up at some point?
I really don’t have a problem with this approach and this tool looks much too promising to pass on the chance of getting all that is needed in there, maybe not for version 0.01, but also for any updates that might come later in the development process.
Thanks to everyone involved, this really looks fantastic (I’m in the boat with those who only understand less than half of what’s being discussed here ;))
Cheers, Uwe
-
Look at most of the areas build for FSX, all very accurate as you want to recognize and navigate by looking at the ground.
This is accomplished by vector polygons, and other GIS available data, which are retraced and layered (when needed) from sat photos and maps - all using own (to the program) textures. Technique started with MSFS (FS9)and this is the way all other simulations replicate and render terrain successfully. It is in a way pretty work and time consuming process, but one which ensures decent performance, decent looks and bulletproof legality of graphic materials used for terrain textures.
Edit: This is how EDGE is being created and it explains why it is taking quite long (in russian, but one can get idea).
Sorry, it is not intended as derailment of this Peregrine thread.
-
Well that is the “problem” with a simulator. Every little bit of the whole theater is special and would need a special tile
Look at most of the areas build for FSX, all very accurate as you want to recognize and navigate by looking at the ground.Gr Falcas
FSX isn’t a good reference I’m afraid for performance… Number of draw calls for the terrain and memory usage is too high, probably.
One of the big things our Guam theatre/project is trying to show is that we can build a 100% photo-real theatre and still have good FPS. Every land tile tile including the airports in Guam is made of unique, high resolution satellite imagery. The way we stay under the 4096 limit is entirely due to the large bodies of water around the land masses. So hopefully, one of my many wishes is that in the future, code changes can allow us increase the 4096 tile limit tenfold or more and Peregine will allow to construct a 100% photo-real real theatre much faster than the techniques we used in Guam.
I sure hope next generation terrain will not need anything close to 4096 textures…
Guys see this kind of terrain, this is the ultimate terrain engine AFAIK, and it doesn’t seem to use any photoreal, does it?
http://www.outerra.com/wgallery.html -
FSX isn’t a good reference I’m afraid for performance… Number of draw calls for the terrain and memory usage is too high, probably.
I sure hope next generation terrain will not need anything close to 4096 textures…
Guys see this kind of terrain, this is the ultimate terrain engine AFAIK, and it doesn’t seem to use any photoreal, does it?
http://www.outerra.com/wgallery.htmlBut the real question is, being realistic, what could be done with the current code in a reasonable amount of time and effort to improve it, and to what degree?
-
But the real question is, being realistic, what could be done with the current code in a reasonable amount of time and effort to improve it, and to what degree?
Current code? building a new terrain engine will not be “current code” anymore, I guess. I don’t know about a timeline and for sure something like this will take time (assuming it WILL start someday!).
-
Current code? building a new terrain engine will not be “current code” anymore, I guess. I don’t know about a timeline and for sure something like this will take time (assuming it WILL start someday!).
What I meant is if there is any improvments that could be added to the corrent code to allow dealing with heigher terrain resolution and larger tiles without building a whole new terrain engine which would most likly take falcon years rather than weeks (in that case we might as well just call it falcon 5 :p)