Lock granularity, bubbles, shaders, texture filtering
-
Yea problem is that for the rendering part, one will need code access.
(and don’t look at me… yea I might create such a tool, after Todo list is empty… probably at 2032 or so :mrgreen:)
Seriously though, forgetting the rendering part, I guess one with tools building orientation (cough Falcas cough) can create some nice PS.ini management tool. Think all effects can be set as header roots with subroots for emitters, each with subroots for its parameters that can be changed, and a compile command to create the .ini itself.
-
So IMHO those new terrain tools are way more needed than a new LE.
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.
@ataribaby, I think new .sav/.cam editor can wait until terrain work is done.
-
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).