Concept: "Fins" for 3D Forests
-
Thaeris, your edge-dropping technique could help in a lot of situations (particularly the thinning edges of forests, where it might be a very cool effect if the textures are done right in these areas). But the worst of the effect happens when the view angle is looking at the forest far off nadir, and the fins (parallel to the ground polygons) start to be viewed almost edge on. Since the tree polygons are quite large, even with edge-dropping there will be places where the repetition of tiles starts to look like the “striped” “optical illusion” described by Molni.
Making sure that the textures on each of the n tree-fin layers (I don’t like the word fins as describing this technique) are very unique will help make each “tree” feel more bushy and random.Making H - the cumulative height of the virtual trees somewhat less than a realistic forest height might reduce the problematic effects as well. Less chance to “see between the gaps”. Then individual tree sprites (few of them) could pop out from under the fin trees to provide the taller trees.
-
Yeah. Just above tree-top level, you may get texture smearing, etc. I was actually watching videos of chaps playing Over-G fighters on the X-Box the other day, and that program uses individual tree sprites/models to tremendous effect. How you may eventually be able to achieve similar effects in BMS is not clear to me. Then again, I’m sure it’s not clear to most people.
I’ve seen vertical layers in fins before, but those never look as good as you think they will. In fact, because they’re different from the typical horizontal or parrallel-to-ground fins, they stand out more and look even more fake. If one wanted to make a good fins forest, I think you again would want to refer to the PDF linked in the first post. The forest is composed of a mesh of equalateral triangles… or, at least just a flowing triangular mesh. Perhaps with a fractal algorithm, you’d trim sections of triangles out of that forest, even on the inside. Using variations to the mean height of the forest and edge intersection with the ground, you’d have a fairly interesting shape that would simulate the appearance of the forest quite well. Used in conjunction with tree sprites, and you’d have a really healthy looking landscape.
I guess that’s the only new thing I can think of to share with regards to my musings on the matter. Just about everything else I’ve gone over still applies to the use of mass tree sprite usage. Again, the advantage to using fins is that just about everybody would be able to use them and enjoy them from just about any range. With older standards of coding, tree sprites will pop in and out of view, and only a few users with better hardware will benefit.
…In any sense, either of these suggestions are not the future. Particle systems for plant growth and fractal, procedurally-generated forests will be, though…
…And actually, that’s a new, interesting thought. If tree tiles, similar to the tiles already in Falcon (albeit much smaller) are designed to cover a particular polygon shape, would it not be possible to match some sort of particle-something to coordinates within the fin polygon? This may help alleviate the “optical illusion” effect as previously described (in a way, aren’t all graphics and art optical illusions?) while in low level flight, while also haing a similar effect to sprites. Because the fin forest already covers the area, the appearance and disappearance of particles in near fins should not be noticable. It’s kind of like the best of both worlds if you can get it to work.
-
BMS4 may have an autogen tree option.
then again, maybe not. Im pretty sure that if the community started to work on such a project though, we would find out from the devs to “stop wasting time duplicating work”, but it hasnt happened yet.
so, maybe.
In the public release version of BMS this feature has been disabled, and will be activated on the arrival of F.L.A.R.E. However you can set your theatre up ready for its arrival now
This is not a “may” case.
-
F.L.A.R.E. got quite the setback, and we have not heard anything about it (trees) since. I would love to hear otherwise, but until I do, from someone on behalf of BMS, I will continue to treat it as a “may” case.
-
Okay- Request:
Is there anyone still working on autogen Trees and houses for BMS.
We really Need trees and real looking Citys for that great sim! -
if by fins u mean the planes as in Tomcatzs pic of trees then this is how its done now. Just get falcon elevation raw file in to 3ds use a plugin (or not) to create superb forests, split them to 4x4klm areas then export and import in to Falcon. Variation and realism depend on the artist - creator and his library of sources - textures.
Is anyone willing to build vast forest areas like that? -
if by fins u mean the planes as in Tomcatzs pic of trees then this is how its done now. Just get falcon elevation raw file in to 3ds use a plugin (or not) to create superb forests, split them to 4x4klm areas then export and import in to Falcon. Variation and realism depend on the artist - creator and his library of sources - textures.
Is anyone willing to build vast forest areas like that?Hey Arty,
Since the main frame of bms is being handled by the devs, Theater construction has always been done by 3rd party individuals. It would be nice if the bms devs could share the workload on asset building with “known” good Theater builders. If the next update will have changed code with respect to asset modeling/operation then they need to (at least) share that new platform to any asset structure changes that need to be implemented. That could take a big load off the devs. Also, do you know if any of the current Theaters will be affected? Sounds to me that they will need a bit of changing.
-
I don’t know I assume from what is written in this forum that all theaters will be affected. Some think of this as a drawback, but knowing BMS history and ways I believe our jaws will fall as in the past with most recent example the 4.32 version.
So the drawback will be a minor. I hope so, kinda sure of. -
I don’t know I assume from what is written in this forum that all theaters will be affected. Some think of this as a drawback, but knowing BMS history and ways I believe our jaws will fall as in the past with most recent example the 4.32 version.
So the drawback will be a minor. I hope so, kinda sure of.Yea, I hope it will be some minor work. If there is some major re-work, I hope the devs might give you guys a “heads up”.
-
I also think it’s a cool technique. It can look great at certain angles, but problematic at others.
Maybe it can be perfected by using more subtle, transparent textures to reduce the edge-on artifacting.
FWIW, there was discussion on Frugal’s about doing this when IL-2 came out years ago. I actually made a test forest, but the fps dropped dramatically as the Falcon engine processed all the transparencies. There probably are some pictures of the test floating around somewhere.
-
FWIW, there was discussion on Frugal’s about doing this when IL-2 came out years ago. I actually made a test forest, but the fps dropped dramatically as the Falcon engine processed all the transparencies. There probably are some pictures of the test floating around somewhere.
Hey Pummy,
That was “back in the day”. Maybe now, with the DX9 engine, we might be able to create these trees without the Falcon engine doing all the hard work.
Might be worth a try looking into tree/forest generation with FLARE.
-
Cool to see this old discussion dredged up again. Here’s hoping we get something cool to play with in the next version To me, the ideal method for generating forests would follow the X-plane methods, which is quite GIS-inspired:
-
Use GIS-style vector polygon regions to define forest coverages, allowing interior rings (holes). Likely fomats could be ESRI shapefiles, spatialized SQLite files or even KML/GML. X-plane uses simple line-based text files. These are the source files edited/re-edited while working on the forests. Attributes are defined per-polygon that define how the engine can use them (avgTreeHeight, forestDensity, treeTypeCode etc).
-
GUI terrain tools could import or help create these regions, and help “adjust” them for the falcon tile-system, where required, to make sure objectives aren’t made unreachable etc.
-
This input data can be pre-processed to create optimal-loadable/renderable resources for the sim engine
-
The forests should be ‘draped’ on the terrain at 3D world loading time, or terrain elevation-post-processing time, or at run-time (if feasible), so that changes in terrain elevation due to other editing work doesn’t cause de-syncing of tree base heights from the terrain height.
-
The engine should take care of the rendering as optimally as possible using a switchable mix of old and new rendering techniques (because huge forests look awesome, and we want them, but the have potentially large overhead), and offer options for configuring the results, but the integration should not ‘disrupt’ other campaign-building processes and standards. BMS auto-forests should continue the tradition of supporting older systems by falling back to less fancy, but useable rendering techniques in place of the default modern techniques. Either way, the same canonical single source of input data must be used to create all necessary run-time resources, for whatever final run-time technique gets used.
“Please sir, can I have some more?”
-
-
FWIW, there was discussion on Frugal’s about doing this when IL-2 came out years ago. I actually made a test forest, but the fps dropped dramatically as the Falcon engine processed all the transparencies. There probably are some pictures of the test floating around somewhere.
About 6.5 years ago I read most of old threads of FF dev fourm and likely I saw you images which was captured about 2006 or 20007.
-
Transparency can be avoided but will create more edges. What is better for gpu? Transparency and one 4 edges plane or no transparency and xxx edges?
-
Transparency can be avoided but will create more edges. What is better for gpu? Transparency and one 4 edges plane or no transparency and xxx edges?
Perhaps most newer gfx cards can do the smoothing. Maybe we get as close to having trees with some transparencies, but have the gfx card run the FSAA to smooth the rest out. Also, maybe if we removed the AF (Anostropic Filtering) and set your gfx card to render that, that too might free up some CPU power for the Falcon bms engine as well. Just a thought.
-
it was already discussed in the past - texture transparency is main FPS killer, more tris are better….but
this is part of my Takistan map for F4:
each tree is 3 tris, no transparency channel…belive it wil be OK regarding FPS
more complex trees possible of course, but no joy for me
-
it was already discussed in the past - texture transparency is main FPS killer, more tris are better….but
this is part of my Takistan map for F4:
http://i844.photobucket.com/albums/ab4/Luk77/49369293_600_zps6e05b2ef.jpgeach tree is 3 tris, no transparency channel…belive it wil be OK regarding FPS
more complex trees possible of course, but no joy for me
Which tool can make such a view about terrain of Falcon?
-
its WIP - whole theater + custom texture Arma areas
this view is roughly 1 tile wide, but there are 4 tiles connectedscreenshot was not from Falcon yet, sorry…i can post more in another thread (this one is about layered forrest or something so no more offtopic)…
but there is nothing special, its 1km terrain mesh, OpenGL shoti just wanted to repeat what coders said in the past - polycount is important, but if u want to make hole, its better for FPS to model it - the way texture transparency hole is processed is more complex and slower in final
-
In this case I do not understand the point of converstation. There are in BMS4 code tree generation it is sipmly has not been activated yet.
-
yep and we all are waiting for it(autogen) since BMS 4.32 release….until then we can use manually placed(true features) trees only
i just showed the trees I like (primitive, no transparency), not important if placed by autogen or by me…i am not in hurry