Lock granularity, bubbles, shaders, texture filtering
-
OK, so for all recent Max yearly releases, an importer is needed, that is, compatible with the Max API for given year? Or do modders prefer one given version?
Is there source code for the existing LOD editor importer? This would ease the burden of writing stuff for it significantly.
Moreover, for the actual LOD Editor replacement, what features do you need? Is it enough to export everything to Max in one format or another, along with viewing functionality, as well as exporting to .LOD format, -or- do you want it done some other way?
If someone could make a quick, informal description, I’d be grateful.
Additionally, if someone could draw up the UI screens on a piece of paper, how they’d IDEALLY look like (within reason, of course), that’d limit my role to a coder, as I know rather little about what you need from the tool… having a spec is helpful
Edit: Why write the actual LOD editor replacement and not just ‘better’ importer/exporter?
Importer exporter is already in development, contact waveydave for team work
-
Dave is away until next week.
-
As for me, never could take money from Falcon dev work, not being a snake, or a snake-man…
I’ll be reading LODEditor to find out what it does, what are the data structures, etc…
OK guys, time to work on lodeditor… Read the manual of BaldEagle and so on… I’m putting the terrain tools on hold because of this.Nooooooo, … I was so much in hope that you finish what you’ve started first.
There is already a good working 3DSMAX to LOD export tool by WD,
and sure, LodEditor could become more user friendly, but it works.
… and that’s why there are so many new 3D models around.On the other hand look at the terrain tools.
There are just a few old specific tools out there, which we could just feed with old data at the start.
Dem2Terrain for example, feeded with old SRTM and “unfiltered” feature data (.e00).… and that’s why there are no finished terrains/theaters out there,
because developing a theater is a pain in the the as job with the current tools available.So IMHO those new terrain tools are way more needed than a new LE.
Now if you put the terrain tools on hold to code a new LE,
and maybe become a BMS coder, then (I’m almost sure) the community will never see new terrain tools from you.… just my 2 euro cent
Cheers,
LS -
I think we dont need another Lodeditor. WD 3dmax exporter works like a charm. LODED as is is sufficient to edit some parents or CTs for testing and setup for new models. All other is done via 3ddb compiler in data repository. I will tell you sthalik, what we desparately need. We need tool like TacEdit with source so we can expand save game format and db and not to be stuck with original TacEdit. To me that tool is far more needed than another Loded. I can imagine if done properly it can be considered as entry project to the team. Just my 2 cents.
As i saw you like to work with data structures and get how all that works. For new TacEdit you dont need BMS code. SP3 exe code that is/wasavailable for download on internet is suffcient for such a tool as this formats are untouched in BMS code for obvious reason to do not break compatibility with original TacEdit from what we do not have source of course.
-
I agree with ab, as waveydave exporter importer is so well advanced tacedit replacement would be more usefull
-
A particle system tool that would allow people to run and visually see the effect they made would be great to have as well.
-
Hi sthalik
I dimly recall it was you who said some year (?) ago that lock granularity is bad and too often threads are spawned… To whoever BMS member said that, I recommended refactor. Never got a response…
Nope… not me. To start with, I’m not a professional coder, and TBH not an expert to threads and processes.
Don’t you get bottlenecks in the executed code? If you do get any, either CPU or GPU, bubble can be further extended without perf loss.
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.
It’s doable Takes some man-hours (And I’m anything but fast and efficient, more methodical, triple-checking), but done both 3D (bicubic texture filtering in software, wined3d hacking on 2 occasions) and parallelization work (commercial software, FTNOIR locking bugs correction from 1.6 to now) so it’s possible.
For instance, do you know a program called apitrace? It’s a GPU profiler, a good one at that. Together with Wine programmer, Stefan Dossinger, we found out why Falcon BMS worked so slow on ATI Linux driver.
I’ve done some MPI and Open MP coding in some parallel processing university course (Although not CS or SW degree) and that’s my main knowledge of parallel processing. Never tried to check if something like that can fit Falcon code. I guess that if someone with expertise in multi threading and multi-core coding methods will try to get something implemented, it could work, even locally in some high processing load areas of the code (if that makes any sense…)
a breakthrough in that direction will be revolutionary for a sim like Falcon which can starve sometimes for CPU cycles.
I think we dont need another Lodeditor. WD 3dmax exporter works like a charm. LODED as is is sufficient to edit some parents or CTs for testing and setup for new models. All other is done via 3ddb compiler in data repository. I will tell you sthalik, what we desparately need. We need tool like TacEdit with source so we can expand save game format and db and not to be stuck with original TacEdit. To me that tool is far more needed than another Loded. I can imagine if done properly it can be considered as entry project to the team. Just my 2 cents.
As i saw you like to work with data structures and get how all that works. For new TacEdit you dont need BMS code. SP3 exe code that is/wasavailable for download on internet is suffcient for such a tool as this formats are untouched in BMS code for obvious reason to do not break compatibility with original TacEdit from what we do not have source of course.
100% agree!
A particle system tool that would allow people to run and visually see the effect they made would be great to have as well.
You can do that already D
.sfx command, no?
-
Hehe…I hate using that. :mrgreen:
I’d rather have a tool so I can work on my laptop without having BMS installed.
-
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.