When FGFS could be like this?

[abassign]

When FGFS could be like this?








https://www.youtube.com/watch?v=SifLjLiblHA

I know it may seem like a provocation, and in fact this is a provocation!
Personally, as already noted for another intervention on the quality of texture, I do not think we are so far. The problem is the effect of the lights that were well made is Rembrandt, but for someone they were too different from other techniques and then followed another road. Here it seems to me that they work very well and the MAC of my friend who made the movie has an ATI graphics card much less powerful than mine.
To me it seems that the Rembrandt-like method of X-Plane works very well!
Certainly the results of ALS are interesting, the Shuttle has a nice effect lights, but it is a difficult trick to implement.
Perhaps a kind of pre-compiler to do what he does Rembrandt "on the fly" for static lights would not hurt and would simplify the work of creative people who hardly have any programming skills to GLSL etc ...
You should check for Rembrandt-ALS environments by taking each of these two codes the best part.
Right now I'm working on the filters for the visual part and I must say that GLSL keeps promises, but obviously has a very sharp learning curve.
However there would be a lot of work to improve the texture and improve the attractiveness planes.

The plane of the movie is not anything fancy, but it does the right things in the right place, for example enough vertices to ensure that everything do not seems to a plane made with LEGO, it's amazing how long to lose the designers to remove vertices, then when these so much more abundant, back on stage for the trees, the houses, the streets, clouds ... As often said the vertices must be abundant in places where the eye focuses, namely in high-contrast points or corners. Often rendering programs already make them such "dirty work" and instead of criticizing it, let them! Meanwhile, the performance does not change.

More than a year ago I flew a sphere with 500,000 vertices only reducing a few percent frame rate, as I showed you. So if a plane is too slow for older cards do an alternative low-resolution version as often I see do some time for the liveries, or do nothing, so over time the quality of the video cards increases, while the CPU remain + / - always at the same point.

For CPUs, when better exploit the horses under the hood?
For example, because, waiting for Python , it would seem useful to bring NASAL on a different processor. Of course now we can use a second processor, but the option to be manually configured! ... perhaps there is an option somewhere, but why? The weather advanced, whether I like it because it can not be stored on their status in the parameter file as is done for ALS?

It seems incredible, people spend hours to criticize a trivial filter to reduce the color temperature, but does not use that time to improve the work on the system that requires a large and continuous refinement.

A FGFS example



The windsock, located next to the runway, I've never seen ... If the pilot errs a few meters ... goodbye windsock, and goodbye wing!

The PAPI lights are sprites, can be used as a standard for something better, such as those made for LOWI? Even the start and the end of the runway lights could be those of LOWI (you could insert these objects automatically when the airport) is loaded, perhaps with a separate thread in order to avoid the slowdown when loading.

But the most ridiculous thing is that kind of city in the background, but they are houses or is it a rock quarry? Better get rid of everything and returning the grass on the hills, believe me! Of course I can do that with an option, but maybe you could do better ...

So, to make a beautiful airport would suffice just a little 'more care and taste ...

[wlbragg]

I guess I am confused about what part of FG your comparing and critiquing?

My long time observations about flight gear are not the lack of techniques, but the lack of fine tuning and continuing improvement by developers and artists and most importantly, man hours.

Sure there are lots of areas that technically can be improved, but there are many more areas that need only the man hour time of artists, modelers and coders, IMHO.

[abassign]

I guess I am confused about what part of FG your comparing and critiquing?

You're right, I put too many things I'm sorry, but the pen has run faster than I thought!

Behind it all there is only one concept:

Less engineers, but more artists. We must begin to think that the instrument (FGFs) that we have in our hands can do many more things if we want to. Do fewer planes, but do them better, with more care and attention.
For the effects we have to try new things with different minds and different visions. I have set the example of visual filters, such as HDR (I'm trying to implement in these days), in order to make it more beautiful, to our eyes, all I want to do.

It's funny, but we continue to use FGFs as a reserve of X-Plane or other commercial simulators, forgetting that instead can give much more. (I think of the work you've done with the landscapes of two US states). Certainly each of us can bring only small contribution, but if we are many to help because we are attracted by the beauty of the results, then there is hope for progress faster.

I can do so many examples of what we can do to improve, maybe in a more comprehensive project:

* Enter Python as a scripting language to replace NASAL may attract new programmers who are used, like me, to work with different tools.
* Generate airports with objects attained better, such as those found in LOWI, and insert them automatically in place of the current ones. Maybe this can be done while charging of the airport with a parallel process.
* Improve the quality of the texture, increase their size by defining a HiRes version. I saw the job done for textures typically European by French enthusiasts, are not bad, and certainly better than current version, ... version where the industrial areas contain only rail cars and are black as coal!
* Light the streets and let insert fake moving car with headlights, X-Plane does this for almost ten years!
* Reduce the load of CPU / GPU of the trees, I know it's hard but there are several techniques that can give us a hand.
* Make realistic lights as Rembrandt did well, not just the ones that illuminate the cabin and instrumentation, but also external ones, as seen in the movie!
* Improve coastlines ... I remember some time ago, we could see the waves crashing, now I do not see them anymore! You have to work you can not have a coastline, cut into slices like a cake!
* Same concept applies to the banks of rivers, there are GLSL functions need for this work.
* automatically generate the cities and houses in the program by integrating the python code osm2city.py. A year ago I did a test to generate the osm2city.py objects automatically when was flying over a territory. It worked well and allowed anyone to exploit this opportunity.
* ... 100 other things ...

Or try to get organized, let's split the job and who does it we force to include proper documentation to allow others to continue.
Then create a constraint: accepted are well documented works! This is the lever for others to start contributing.

[D-ECHO]

I think many of your points are good, just a few comments:
*Fake moving cars: Already done (osm2city->roads.py) though only working without ALS (why?)
*How to improve load of trees?

[psadro_gm]

In regard to the crazy city texture stretching on the mountain, this is something that seems like a fundamental flaw in our texture coordinate calculations. We only calculate them in 2-D ( lon, lat ), so any cliff, steep slope stretch the texture out. The landclass shader mitigates this programatically, but with just plain textures, it looks awful.

I may look at this during the next-gen scenery experiments, but I need to read up on how to apply texture coords on steep slopes...

Looks like the solution: https://gamedevelopment.tutsplus.com/ar ... edev-13821

Actually, it looks like that comes with a pretty big performance hit. Thorsten had some ideas on this as well - with procedural texturing, but I don't think that will be easy with city textures.
Ideally, city textures would be just gravel, etc, and could be done procedural, then random / osm building could be placed on top.

[Hooray]

City textures are unlikely to work too well on slopes, i.e. they're usually made with the assumption that they're taken from a bird's eye-view (straight down), so applying them to a slope would require dealing with that assumption in a sane way, which would probably require some fairly fragile heuristics (basically changing the projection of the texture at runtime, which is unlikely to look that good, because the re-projection would need to extrapolate texels because it is lacking most relevant information, such as the color of a wall, because it only knows the color of the roof-top).

Probably, it would be best to move away from static city textures and decompose the whole thing into its components and then re-add those procedurally, like you say. We already have most parts for this in place, they're just not very well integrated at the moment (think materials, effects, shaders, photo-scenery/texture draping, FBOs/canvas)

For instance, if/when the Canvas system is extended to allow arbitrary Canvas textures to be registered as "materials" (in the Scenery/SimGear sense), that would make effects/shaders automatically available to Canvas textures, and the only other addition required is allowing a Canvas texture to be draped onto the terrain mesh, e.g. by using a customized subset of the existing photo-scenery patches.

This may not be the most elegant, or the fastest, option - but it would provide for a truly generic toolbox to conduct various scenery/texturing related experiments without requiring major C++ changes apart from two entirely self-contained additions that would be useful even regardless of this particular use-case.

This would also enable revamping the autogen/random buildings/vegation components in FlightGear at the same time.

Support for more native GIS tooling/features (think OGR/GDAL) could be added some time later - but shapefile support would be a huge technology-enabler for any charting/mapping applications in FlightGear, including not just modern avionics, but also fancy charting applications built right into FlightGear, including even the Phi use-case:

Atlas still in use ?

I'd really like to use the Atlas generated maps as a layer in the browser map. Is anybody out there looking for an adventure and is able to modify the Atlas map generator to generate maps on-the-fly? Input would be three parameters: z/x/y where z is the zoom level and x/y are numeric parameters describing latitude and longitude (based on image size). Output should be a generated tile of 256x256 and format png in a memory buffer.

This could be compiled as a Apache httpd module (like osm's "renderd") or linked against a standalone webserver to akt as a tileserver for any openlayers compatible map.
[...]
What I have in mind for the map is to render the map tiles (small 256x256px fragments of a map) from flightgear scenery data on the fly when the user requests them from within the map application. Thats how openstreetmaps works and I like the idea of reusing proven concepts. There is no need at all - in fact, it's not even desireable - to do that in the main loop. Running a standalone application (or call it process if you like) creating and serving the tiles will add no load to the FlightGear process, no matter how complex the map is.


Torsten