Lock granularity, bubbles, shaders, texture filtering
-
A particle system tool that would allow people to run and visually see the effect they made would be great to have as well.
For examole vapor effect on airframe or muzzle firce effect?
-
Agreedā¦ But the thing is, old tools donāt help any 'cause they canāt be used due to lack of source codeā¦
Additionally, while O2/L2 has been parsed already, the fields in them arenāt explained anywhere.
So tell me, has O2/L2 format handling changed since Cobra-RV? I have that code through some ādealingsā and as such, could read it in order to understand the fieldsā meanings (think f1, f2, f3 float member variables).
Donāt have to tell that a new terrain tool is tons of work and that if itās ever completed, itāll take a ton more work than LODEditor ever would.
Consider we might (Translation for everyone ā> Might = nothing practical, just saying, āif maybe, everā) try at some point to implement a new terrain engineā¦ so if tools for terrain will take forever, and may not be compatible later, would it worth all the efforts? considering your words that itāll take longer than LEā¦ I guess also will be longer than a TacEdit replacementā¦
As for terrain code, I donāt think something had changed regarding the file formats, but anyway better contact more knowledgeable people (Blueprint maybe).
For examole vapor effect on airframe or muzzle firce effect?
Vapor effect canāt be done with just data changes.
-
Consider we might (Translation for everyone ā> Might = nothing practical, just saying, āif maybe, everā) try at some point to implement a new terrain engineā¦
ThatĀ“s phantastic !
I have personally invested good time understanding the methods and the technologies other products meanwhile use.
I even obtained applications of various sorts, experimenting with the possibilities just to find ānewā solutions for our F4 environment.
But to be honestā¦seeing first hand what IS possible very effectively on one side and being LIMITED by the STRUGGLING solutions provided to us in F4 on the other side ā¦ one really feels like giving up sometimes.PS: Stahlik can be a VERY resourcefull person if it comes to software-solutions
-
What about using xplanes scenery technology? Especially the hd mesh data is great if you look at neveda oder New Zealand proā¦
-
so if tools for terrain will take forever, and may not be compatible later, would it worth all the efforts? considering your words that itāll take longer than LEā¦ I guess also will be longer than a TacEdit replacementā¦
Not forever, but definitely longer than LODEditor, which seems to handle camera projection, normals, as well as usual ad-hoc binary file formats snafuā¦ And some dialog screens for various data structures.
My āterrain IDEā idea is based on autotiling, transition generation, elevation import and adjustmentā¦ On top of that, there are GUI issues with PyPy, only Tk seems to work, and version 8.4, not newer
-
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).
-
Isnāt autogen nondeterministic? I donāt like thatā¦
-
TBH, I donāt know (I know bubble code mainly from reading some)ā¦ but assuming the main bubble function(s) took some changes (probably some rewrites) through the years, I donāt think there are serious bottlenecks, as if there were, they would have been detected by profiling and a fix would have been at least tried or searched for, and that isnāt the case, AFAIK.
Now I remember more about the post Iāve read - it said that more than 3 cores cause bottlenecks because of inefficient multithreading. That hyperthreading causes inefficiency, too, because 2-3 cores is optimal, else performance is actually lost.
As for multi-core renderer, as far as I understand it, the actual primitive-drawing is done only on one core. The matter is putting other expensive tasks on a pinned thread and balancing, such-that theyāre busy with actual useful work, not spinning on a synchronization primitive, performing calculations that are unnecessary, etcā¦ At least I wouldnāt create multiple concurrent command streams for graphics. Have no of experience in the area, but learning about it would be a breath of fresh air from usual stuff
What Iāve meant is that if parallelization and other optimizations are done, code made more efficient because of this, bubble can be made less restrictive. And yes, Iām staring at a āblack boxā here, only knowing what you told me
-sh
-
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.
-
Autogen typically allows for changing density, this removes (or reduces) possibility for MP-shared clipping of objects. Same issue as with the community 3D cities project, clipping through objects, either in MP or always.
But yeah, autogen seems to be the way to go, given how much work it saves from theater creators. Iāve only used X-Plane for a couple hours total, but densely-populated cities look real awesome at sunset.
-
I know nothing but couldnt you do a autogen for the theater makers to place trees in ātree areasā that gets saved when the theater maker saves his/her work?
Cheers
-
Yeah. Letās bikeshed some whether to use Perlin or Voronoi or Gauss or what for tree spacing
-
Now I remember more about the post Iāve read - it said that more than 3 cores cause bottlenecks because of inefficient multithreading. That hyperthreading causes inefficiency, too, because 2-3 cores is optimal, else performance is actually lost.
As for multi-core renderer, as far as I understand it, the actual primitive-drawing is done only on one core. The matter is putting other expensive tasks on a pinned thread and balancing, such-that theyāre busy with actual useful work, not spinning on a synchronization primitive, performing calculations that are unnecessary, etcā¦ At least I wouldnāt create multiple concurrent command streams for graphics. Have no of experience in the area, but learning about it would be a breath of fresh air from usual stuff
What Iāve meant is that if parallelization and other optimizations are done, code made more efficient because of this, bubble can be made less restrictive. And yes, Iām staring at a āblack boxā here, only knowing what you told me
-sh
Actually, regardless of rendering, from what I know, the main load in Falcon is in campaign missions with high number of units within the bubble. I can only guess that while every unitās processing code isnāt such a heavy load (as 10 ACs and a column of tanks in TE will not cause serious load on average system), adding more and more units, eventually will cause a heavy load, and FPS drop will be noticed very well, even on very strong systems. If we could get those processes to run on multiple cores, that will be the optimal solution for all Falcon performance problems. Because in relatively light environment (Empty TEs and camp flying with not many units in the bubble), Falcon FPS is already pretty good, usually bound by GPU.
While parallel processing for GPU will sure help, the real bottleneck is CPU load in camp missions because of high number of units in the bubble.
-
Theaters could be mixed with autogen and non autogen zones. X-plane uses exclusion zones. A theater designer could create military targets as he wishes and these areas would not be mxied. Furthermore the landclass and street system of X-plane based on osm data is a big deal. Imagine to have a converter tool which reads all military objects from existing theaters and combine it with the osm and mesh data in order to create a second gen theater. ā¦
-
While parallel processing for GPU will sure help, the real bottleneck is CPU load in camp missions because of high number of units in the bubble.
AI can be optimized, including preprocessing path data for A* or whatever is usedā¦ So only āforksā in the road data are treated as āopen setā dataā¦
Donāt know whatās causing the load though, doubt could use the public PDB for profiling. But itās worth at least a try optimizing it, definitely.
As for parallel GPU, renderer thread needs no actual resources, except for synchronous flushes which sleep anyway (unless configured otherwise). Pushing into the CS is extremely cheap. So unless it computes/allocates memory (it shouldnāt!), no biggie.
Iām also curious about heat exhaust and HDR. Donāt know (again) how well theyāre optimized for SIMD GPU processing, but getting rid of āifā statements in shaders (if any) would speed up GPU processing immensely
-
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ā¦
-
by clipping, meant can through skyscrapers with no damage.
Autogen is tons of work, ask Ben Supnik from X-Plane team nice fellah btw, helped me a lot with the wined3d fork.
-
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).
-
FWIW original falcon 4.0 uses squared distance, no sqrt applied
-
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 .