Huge EF2000 fan here….this could be big! Is the heightmap 250m or 500m postings (or other?)
Posts made by fingon
-
RE: Norway Theater - Lets do it!
-
RE: WIP: Dassault Rafale
and where and who exactly is BMS?Once again this utopia copyrights talk… like all the dev’s and mods here have baught the tools they use to develop or mod, nor to talk about Falcon code and so on and so forth…Please???And a Greek saying: In the house of the hanged man they don’t talk about ropes.
Hahaha, late to thread, but had to say: this made me chuckle.OPThe 3D model is awesome! Such a weird/beautiful plane.
-
RE: Concept: "Fins" for 3D Forests
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?”
-
-
RE: Lock granularity, bubbles, shaders, texture filtering
That would be the platonic ideal
-
RE: Lock granularity, bubbles, shaders, texture filtering
sqrt: Yeah? good to hear, low-hanging fruit…
-
RE: Lock granularity, bubbles, shaders, texture filtering
Hehe, well, re skyscrapers: those should be true Falcon objectives (at least those over a certain height maybe), while things like road infrastructure (except bridges) residential housing and trees - I really don’t mind if they are not fully physical - Falcon is first and foremost a simulation of the in-cockpit experience .
-
RE: Lock granularity, bubbles, shaders, texture filtering
In terms of CPU-bound campaigns I’d be interested to know what kind of schedule is applied to things like simple distance checks between units (agg 2D or de-agg 3D) as they move. These kinds of things can kill performance unnecessarily if done in aggressive timings. Who knows, maybe FPS could be gained by simple things like switching to distance calculations without the square root operation in places where it can work, and using tables to adjust (if they don’t already do things like that).
-
RE: Lock granularity, bubbles, shaders, texture filtering
sthalik, what do you mean by “clipping”? Just so we don’t talk past eachother.
Either way, I personally would have no problem if future procedurally generated geometry is a visual effect only., It should be MP-safe by being deterministic, but only to make sure people see the same things (eg earlier on clouds were not shared, which was crappy), not for targeting/objective purposes. It would be far too inefficient to treat autogen objects as full Falcon campaign objects. Existing campaign objectives should receive an X-plane-like exclusion zone so that they “pop out” of the autogen stuff.
Lotsa wishful thinking here…
-
RE: Lock granularity, bubbles, shaders, texture filtering
Autogen can be non-deterministic, it depends on whether or not a random seed is stored along with each campaign/region/tile. If the original seed is stored, and a “deterministic random number generator” used, the same random sequence can be replayed.
-
RE: Lock granularity, bubbles, shaders, texture filtering
I second a look at the X-plane scenery tech mentioned above, not because we should totally rebuild everything (Kai Zen!), but because, thinking long-term, the abstract methodologies and practical implementations (file-formats/specs) over there are a very flexible and stable mechanism to build up a geographically “correct” simulated world. The author’s ideas of rendering a planet are good forward-thinking: http://wiki.x-plane.com/What%27s_New_in_X-Plane_10#The_Main_Driver_of_X-Plane_10:.C2.A0The_New_Plausible.2C_Dynamic_World
Nonetheless, these would be radical departures from the existing system, and I would rather see development of tools to ease the production of campaigns/terrains within the existing paradigm, and better docs and specs detailing the existing infrastructure. Grid’s are cool - it’s hip to be square. If generalizations are made in the right places, adapting to things like expanded tilesets, new rendering techniques and changing presumptions could be made less challenging. Solving issues like building placement with regards to the underlying terrain tile image would be big pluses for ensuring work is not wasted on all levels. These solutions would require a mix of code and convention.
We need to define the “strata” (terrain, objectives, art resources, code etc) of Falcon worldbuilding, and define interfaces that allow people to work within these strata and feel confident their work will be useful to those in other layers. If we need to build radical new things, we should also look at ways in which old work could be piped into new formats via shims, transformations and batch processing (see old PCX texture pipeline -> new DDS based one).
-
RE: BMS Mod/Software/Cockpit/Texture/Misc Central List
A great collection of links!
Here’s my snap-view mod (never got around to making a package of it, but lot’s of technical details):
https://www.benchmarksims.org/forum/showthread.php?6353-Fingon-s-Snap-view-Mod
Cheers!
-
RE: Suggestion for database, data supply
Good discussion here! Don’t stop!
Like the Falcon itself, I began with aerial combat but started shifting to enjoy a-g. An improving IP-onwards environment will be appreciated!
-
RE: 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.
-
RE: Concept: "Fins" for 3D Forests
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.
-
RE: MiG31-LowPoly
You can always reduce the screen resolution, even to 640 x 480 if you wan
Hmmmm. I was generalizing. I actually get quite high average frame-rates even with my older machine, at 1280x1024, the problem is loading stutters/pauses. See here: https://www.benchmarksims.org/forum/showthread.php?14056-Targets-LowPoly-Edition&p=199300&viewfull=1#post199300
-
RE: MiG31-LowPoly
I dig it. Great work! Maybe one day we’ll have a true “low-poly mode” option in BMS for those willing to sacrifice pixels for fps.
-
RE: Korea '80s Theater - discussion
May give it a shot.
Are the installation instructions based on default BMS U4? -
RE: WARNING - CREATING A NEW F16 MODEL
Ok well, then in a very limited sense the model geometry IS being used in the flight model calculations.
Hopefully people start collecting this knowledge together (like in that new BMS wiki that’s started up).
-
RE: WARNING - CREATING A NEW F16 MODEL
Wow, does this imply that the new BMS flight model is actually making use of 3D model geometry to calculate physics (kinda like X-Plane does) - did it always do this?