Posts by nickhod

Well, after doing everything suggested I now get this.

Getting a rectangle to display in a game should definitely not be this hard.

Colouring the vertices as red, applying an ambient texture and quadifying the mesh got it to this stage.

Quote from Hartman

I have previously tried to automate the process (without luck).

Maybe you can get some tips in this thread?

SDK - airport question

Looks exactly what I need. Many thanks.

Seems like I'm missing the importance of vertex coloring (red = fully opaque / black = fully transparent) and an ambient texture. Will try later.

You'd have thought the exporter would assume no vertex color = opaque and the shader would handle a null ambient.

FWIW, I also did tried the "full" way of doing a ground poly in the Max tutorial on the Wiki.

So I now have a multi material with one slot, and the full stack of modifiers applied, as documented.

The material error goes away but no runway is shown in AFS.

Quote from drhotwing1

Have you looked at my 3DS Max tutorial yet?

Yes, I've read through it thoroughly. As far as I can tell I'm doing everything documented.

Quote from Trespassers

Hi Nick,

Are you really sure you applied a valid diffuse texture with _color suffix to your runway, and named that material in 3DSMax with "__airport__runway" suffix ?

It looks to me like there's an issue with this step, with AFS2 searching for a material named "terrain_rwy_t1g1r0d0d1"...

It's definitely material / texture related, but I don't know why.

I've followed the naming in the Kingman example and used the Kingman texture files.

I've called the Diffuse Map "runway_dark_color.bmp" because that's how it is in the Kingman max file (seems wrong as it's a tif file)

I also tried with without the .bmp, with no luck.

That material is definitely applied to the only object in the Max scene

I still get the same error and no runway is shown.

Should anyone be able to take a look, I've attached my extremely simple project with the Max 2016 file and the TMC / TSC files. I had to exclude the texture, but it's just runway_dark_color.tif from the Kingman example.

I'm trying to create a basic runway in 3DS Max and get it visible in AFS and failing.

I have a rectangle, converted to an editable poly, with a UVW Unwrap modifier and a material applied.

After applying the UVW Unwrap, I selected the runway poly in red, and applied a flatten mapping

My material is named "__airport__runway" as directed for 3DS Max.

I export the file to a TGI, which runs fine and shows that there is an object with a material in the export log

Model Converter runs without an issue and creates the TMB and TTX

The airport shows in the map, and PAPI lights are shown so the TSC is OK and the airport is in the right place.

The runway model is loaded (according to the log) but not shown. I get the following error:

"but has no second texture coordinate" is an error I'd expect if there were no UVW coordinates.

I tried collapsing the UVW Unwrap modifier, but that didn't work.

There must be something I'm not doing right in Max, but I'm not sure what.

Quote from kenventions

If Level-9 toc files will run fine on highend PCs, you may want to include that as a cultivation option in AeroScenery since it would mean fewer cultivation tiles to generate / manage.

Thanks. For cultivation I'll probably end up working in degrees so that people can still use scenProc. (It makes a lot of the processing easier too). I intend to make the number of degrees configurable.

However, I'm hoping to steer people to a 0.1 degree standard so the files are easily shareable, and for example, my 0.1 degree cultivation tiles can easily be dropped in next to your 0.1 degree cultivation tiles etc.

Quote from Spit40

With my Ac3D approach i make a mesh that's rectangular and big enough for all polys. The AC3D trick is to call it something__airport_outside (hmm i think, i'm away from my pc) and then it gets a one level of smoothing. Cut out of that mesh using boolean knife and cut away are the runways with a stronger level of smoothing as these have __airport_runway (again, i think)

Thanks, I remember seeing a screenshot of doing things that way. Seems like a good technique without the complexity of having a single mesh, quadifying it, then vertex painting etc, like in the Max tutorial.

Quote from Trespassers

That's one of the issues actually with current FSCloudport AD : it doesn't work unless the terrain is already very flat, and you can only taxi on the runway.

The runway itself is flattened though isn't it? Just not the rest of the airport because there's no geometry for it.

I'm going to guess that the mesh smoothing algorithm of AFS gets the bounding box of the runway model defined in the TSC applies a padding to the edge and then normalises the base mesh under that.

If the runway model (terrible naming, it's really the airport ground model) in the TSC contained all the runways, taxiways and aprons, the mesh smoothing bounding box would cover the whole airport by default. This would be the case for what I'm doing.

That's my theory anyway, based on zero testing so far

Quote from RjG

To this end it would be nice for AeroScenery to have a 'process up to geoconvert' and the ability to load and 'resume' project capability where one would have the opportunity edit the ortho photos prior to geoconversion.

It already does. In the Actions area of the left sidebar, select "Choose Actions To Run" and check what you want to run.

I guess the main issue is not for the uploader or downloader, it's for the person hosting all this scenery.

When the Bing legal team come knocking, not caring what someone in "licensing" said, the person responsible for that server could be looking at some serious legal problems.

The T&Cs set out pretty clearly the licensing for this stuff. Section 8.2 (b) and (o) in the link below seems to answer this question in very black and white terms.

https://www.microsoft.com/en-us/maps/product/terms

Section 9 and 10 back tracks a little in that Windows applications may download content. Technically even use of AeroScenery breaks other T&Cs, but short of police raiding your house and taking your PC there's no real concern there.

Quote from Trespassers

A question though, do you plan to manage the base mesh too, for these airports to get integrated to AFS2?

Yeah, good question, it depends what comes out of testing...

I do have data on the airport boundary, so I could create a base mesh. What I can't do very easily in an automated way is the carving out of the runway and pavements, then selecting specific faces to apply runway and pavement textures.

I've seen airports without a base mesh, where the (single) "runway" model in the TSC is just the group of polys for the runway(s) and pavement areas. These seem to work OK, so that's my preferred approach at the moment.

If doing that messes up the mesh smoothing algorithm as the outline geometry is too complex, plan B would be to create a simple base mesh, but use a transparent texture. Presumably mesh smoothing would then take place on the whole wider area.

The mesh smoothing definitely has problems when you have multiple runway definitions in the TSC file and they overlap or are near each other, but that wouldn't be the case here.

Ultimately these airports will never be as optimised or the quality of a DLC airport, but I'm hopeful I can get them "pretty good".

If people want to build optimised (freeware) airports on the back of the output of this tool they can get the Max scripts or files and have a project 70% done, ready to hand-tweak.

Quote from Jetjockey10

I'm ready to see some early work for AeroScenery using USGS data.

Got a bit side tracked with the airports Back on AeroScenery now; get a couple of new releases out.

Quote from Trespassers

In that sense, sharing is even easier with FSET since you just provide your settings file for fully automated download. Click and forget.

It's a good point. Would be simple enough to support an "AeroScenery Project" file that, when opened, selects squares to download and settings, leaving the user just to hit start.

Quote from drhotwing1

Which 3DS Max plugin version do you need?

My latest is 2017 I believe

I think more and more people have subscriptions now and are always on the latest, so ideally 2019.

For whatever reason, I can't get 2017 to run on my machine due to a bad install, hence using 2019 then 2016 to export.

I think it's only a case of changing a constant or a header reference to support a new Max version since the API calls that the plugin would use are well established.

In this case you guys might as well compile for new Max versions and mark them as 'beta' even if you can't test them directly. It's 99% likely it'll work. If not users with Max subscriptions will let you know!

If you download the SDK from this site and read through the C++ API example you'll be able to judge if everything you need is available. (I don't think that weather is).

I haven't yet done any work with the API myself but it does expose a good amount of the game as readable / writeable messages.

Path to the source is: aerofly_fs_2_sdk_tools_20180823\aerofly_fs_2_sdk_tools\external_dll\project_aerofly_fs_2_external_dll_sample

Quote from Jet-Pack

This looks quite promising. Would be great to generate airports without the need of additionally and expensive software!

In which language are you coding this?

It's C# that generates a Python Script (from a template) for 3DS Max.

I don't think this will be an end-user tool, although I'll make it available.

If I can get the end result to a useful level, my intention is to generate all 28k airports as AFS files and make them available for download.

Would be great to have an IPACS plugin for recent Max versions (hint, hint) . New versions have the Python support that I need for this. I'm currently having to save as a 2016 file and switch to that for export.

I'm no expert on the AFS API, but I think it has everything you need.

You can get the type of view with "View.DisplayName", then for the head tracker you need to have some initial reference point to calculate position and angular offset.

With those, the several View.* write properties can be set to do what you need.

I can't see why you would need to read current view information.

I like it when people show work in progress of stuff they're messing around with, so I thought I'd show where I am with my new tool XP2AFSAirportConverter.

I took a bit of time away from AeroScenery to look at converting open source airport data from "another flight sim" into a 3D model that could be brought into AFS.

I spent a few evenings writing parsers for all the "other sim" data types. Boring code to write, but once done I had a clean object model of an airport.

I then started writing a tool that compiles a 3DS Max Python Script to draw each airport.

Things are pretty rough at the moment, but interesting enough to show some screenshots. My spline renderer isn't right in all cases, leading to occasional weird shapes.

I'm using four airports to test, with increasing levels of complexity:

• Cardiff, UK (my home airport, I know what it should look like)
• Manchester, UK (also well known to me)
• Portland US (interesting crossing runways)
• Chicago US (doesn't come much more complex)

I've done some basic work on automating textures and a UVW Unwrap on the runways to prove it was doable, but nothing else is textured yet.

To be clear, this tool will draw any airport in the world, not just these four.

Hopefully at some point I can get the output of this directly playable in AFS.

I may do a phased release of world airports starting with runways, then taxi ways (if possible), then buildings (if possible)

For now, I'll do a bit more work on AeroScenery as the code behind this has made my brain hurt

Cardiff

Manchester

Portland

Chicago

Quote from kenventions

Nick, regarding AeroScenery cultivation plans, I thought it might be interesting / useful to see how the IPACS team decided to anchor the Florida TOC files

Thanks for doing that. It actually answers something I've been meaning to research, which is how many TSC files to use for a given TOC file spacing. (Same spacing as the TOC is the simple answer I think).

I may end up going with a spacing of 0.1 degrees for cultivation file spacing as that's what spenProc can do easily. Depends if I call scenProc behind the scenes or implement it myself. 0.1 degrees is pretty similar to Level 10 though.

Great to see everyone leading the way with Blender OSM. Tools like that seem like the best way to do cityscapes to me.

Blender OSM Premium should help with textures.

What's missing is a way to randomise height of buildings between certain values where the height isn't known.

For more realism it would randomise based on the distance from the city centre (buildings tend be be tallest in the centre).

If there was a way it could take in LIDAR data that would be even better.

At least it's open source, anything is possible.

I do wish IPACS would consider an official Blender plugin, or opening up the file formats to make that possible. Giving people free tools to create things is important.

Quote from TomB

My observations showed that the displaying radius mentioned above (5 -6km) is maybe correct for buildings and trees but lights are displayed in a wider radius (more than 50km).

Thanks.

This could really do with documentation or at least an "official" answer. drhotwing1 (IPACS)

To clarify the questions:

- What does [size] relate to in the TSC file (just objects or objects and cultivation)?

- Is cultivation hidden outside a fixed 5-6km radius?

- Are lights treated differently to buildings and plants with respect to the above?