X-plane get some color (taxi/apron lines)

[www2]

X-plane have add support for color lines[1] and like to see to add to flightgear.


[1] https://developer.x-plane.com/2018/06/x ... available/

[www2]

Update i have create a wiki page for apt.dat variable:
http://wiki.flightgear.org/Www2/apt.dat

[Hooray]

I would suppose as long as this is made available as vector data, it can be treated just like any other vector data - presumably via dedicated effects/shaders ?

From an interfacing standpoint, it would be nice to also make that data available to Nasal/Canvas space - even though that would be hardly relevant from a scenery handling standpoint probably, it could still be a great asset when developing/troubleshooting related features.

[legoboyvdlp]

The unfortunate thing is that as I understand line data / polygon data is no longer contained in the apt.dat files but in .dsf files (or somewhere else altogether?) which makes it even more difficult for us to access it.

[Hooray]

as long as that data is legally compatible with fgfs use, we can obviously use it - we will just need to know more about the file format, or ideally have access to a parser to add it to our own data (or at least the terragear pipeline/scenery compiler suite).

I guess, the feasibility of accessing/using such data is best answered by psadro_gm and others familiar with the whole terragear process ? If they are not currently around/available, it would still be possible to come up with a fgdata-level parser that processes such data, populates a vector and renders that into a texture (possibly a canvas) so that this can be used by an effect/shader.

As long as the core development bottleneck persists, XML, Nasal + Canvas + effects/shaders are likely to be used more and more often by non-core developers to work around such limitations and still implement certain features.

In other words, I am willing to help in the form of code snippets and pointers to access such data and access it at runtime if none of the scenery folks are currently around to provide access in a more proper form.

[www2]

The unfortunate thing is that as I understand line data / polygon data is no longer contained in the apt.dat files but in .dsf files (or somewhere else altogether?) which makes it even more difficult for us to access it.

That is not true the list that i post are all the markings that are supported in apt.dat.
I have plan to crate a list of x-plane objects.

Hooray: the Gateway use GPLv2 for the data set.

[legoboyvdlp]

that's good then - glad I was mistaken.

thanks,
Jonathan

[Hooray]

Since there is obvious benefit in making such markings optional at runtime, I guess that a purely effect/shader based approach would not gain us anything, unless we're totally lacking native/core support.

So it would probably make more sense to extend the parser and treat them like any other airport markings, just with a different style.

I haven't been following TG development at all, so not sure if psadro_gm and papillon81 are currently around or not ?
But even if they aren't, it should be fairly straightforward to locate the corresponding C++ routines and see if/how they can be generalized to parse the new markup and create the corresponding markings - I suppose that we might even be in luck, since most of that code was originally written by Curt anyway, and he still seem to be around