Free Flight, Free Speech

iksni wrote:genapt now uses a texture atlas for all taxiway and runway markings. This reduces draw calls significantly. But the texture atlas has not been committed to fgdata yet - so it looks like crap

That sounds cool
Are you going to have available to have multiple taxi-signs like the ones in RJBB?
https://github.com/FGMEMBERS-SCENERY/RJ ... tomScenery

Pete, welcome to the forum

The plan looks interesting. No more terragear is nice.
Looking forward to it.

SHM

Hi Israel,

I looked at the git repo for Kansai, as I'm at work, and can't load up the scenery.
I see some custom .ac files and textures for the hold short runway signs. Is this what you are referring to?

Is there no way to generate these signs in the XPLANE/FG sign convention? Are they multi-line or something?

Pete

iksni wrote:Hi Israel,
custom .ac files and textures for the hold short runway signs. Is this what you are referring to?

yes, those

Is there no way to generate these signs in the XPLANE/FG sign convention? Are they multi-line or something?

Pete

No there is not.
It would be great this is added into the apt.dat specifications and can be drawn in WED, and then compiled into terrain with terragear.


A second point

It is very important to see what 's going on with the taxiways per the latest X-Plane specifications

Tipically all airport features were decoded in the apt.dat.
According to D-LASER (see above thread) some major features of airport have been dropped from the apt.dat --- even including taxiways!!!
X-Plane moved those to the DSF! (!?!?)

Anyhow, FG will need immediately a way so that genapts850 (maybe rename to genapts1100?) is able to use 2 different inputs: the apt.dat and the dsf(s) and build the correct complete airport structure as specified from sources

D-LASER did create some python script that can help addressing the problem one airport at a time, but the solution at this moment has very low expandability (this is the more aiports change like this, the more challenging to build the world is going to become)

the expandability of the approach taken is critical.

Furthermore, given that there are 2 different genapts now (as you point above) maybe I'll be thankful if you can keep both versioning for a longer time (in other words include new feature for both systems)

Thanks a lot
Let me know if you've got questions, or you think I can be of any help

IH-COL

iksni wrote:Papillon81 and I discussed which way to move forward and decided master would be development, much as next is in fg/sg. We regret it a bit now, as it's 3 years, now - with no real proof of concept....

Honestly the design is very atypical (to use kind words........)

But the advantage is that this can be easily reverted in git by just reassigning branch names


I dont think the "next" method FG/SG uses is any optimal either. FlightGear project has this historical ways of doing things that are non-traditional, non-intuitive and conflicting at the long term.


My suggestion

1. make scenery/ws2.0 ("the current working branch" as master)
2. make current master branch named scenery/ws3.0

that will make rather clarity that the current master is ws2.0 and that you are working on a topic branch that implies a rather massive restructuring.


That's just my 1 cent.

Laserman,

Where did you get edds.txt? On the gateway, I can see that the apt.dat indeed only has two pavement features. But the .dsf in the scenery pack is binary. I will look into supporting pulling the polygon data out of dsf files as well as apt.dat.

When you execute your script to scrape the gateway, how is the data stored? In a separate directory for each icao? Or single apt.dat only.

I'll soon be looking at reading this info in genapt, and it would be nice to do it without needing a conversion step.

Pete

iksni wrote:I'll soon be looking at reading this info in genapt, and it would be nice to do it without needing a conversion step.

Pete

This is largely appreciated Pete.
Please include the feature in both genapts versions.
Consider renaming as genapts1100 to distinguish the features now.

(since it is not longer a 8.50 airport specs)

iksni wrote:Where did you get edds.txt?

I use
gateway_pull.py from my collection of scripts:
https://github.com/mherweg/d-laser-fgtools
https://github.com/mherweg/d-laser-fgto ... ay_pull.py

It will put the ICAO.dat and (ascii dsf) ICAO.txt file into the current directory.

But the .dsf in the scenery pack is binary.

with gateway_pull you'll get the ascii text version of the dsf file.

there is also a converter from binary to ascii, example:

When you execute your script to scrape the gateway, how is the data stored?

currently approx. 4000 .dat + 4000 .dsf files all together in one single folder.

I'll soon be looking at reading this info in genapt, and it would be nice to do it without needing a conversion step.

that would be great!

Step 1)


Step 2)



Then you have the dsf .txt fiels for all airports maked as "3D"

I just noticed that find3d.py only saves the .txt files and not .dat + .txt like gateway_pull.py does it.
I have to fix that one day.

Hi!


I'm kinda outdated of infos here, but is the new World Scenery for Terragit smaller in file size? is there a rough estimate of the file size? (Whole world), does it not affect the framerate significantly? Thanks!

My sketchup expired, any idea what 3D modeller program can I use?

yes. it is smaller in size
it will take about 180GB of hard-drive
It does affect frame rates significantly ... it is faster than regular ws 2.0.

I recommend blender for 3D work