Huge EF2000 fan here….this could be big! Is the heightmap 250m or 500m postings (or other?)
Latest 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.