Posts by nickhod

    If I have well understood the Life project from Jeff the path of vehicles movement can only be created manually under 3DS Max for now. It is the manual side that bothers me (in addition to the license of the proprietary 3D software). In the long run, could these paths be created automatically, for example from the OSM route network?

    There are two things going on here, one is the routes for vehicles to follow, and the other is whether to render roads on top of ortho photo roads.

    Aerofly should definitely implement vehicle routes from OSM data. Given how well the animations work in Jeff's demo, with minimal performance impact, it's probably not a huge leap to read these animation paths from elsewhere. Seems like a relatively easy win to me.

    As for whether to render roads on top of orthophoto roads, I've never thought that roads in X-Plane look particularly realistic. Being vector, they're well detailed if you get close, but they generally stand out like a 'sore thumb' against the ortho backdrop. The asphalt, concrete and tarmac used on roads come in so many different shades that it never matches well.

    I noticed that the on the MSFS 2020 trailer video the roads show vehicles moving on top of high-res orthophotos. They haven't tried to render the roads as geometry.

    I’d like to be able to search for an airport

    This is really needed. Several times I know I want to fly from an airport but, in the case of unfamiliar airports, don't know exactly where it is.

    I end up taking off the Oculus, using Google Maps to find the airport, putting the Oculus back on then trying to zoom to the same region.

    The location map is a nice interface, but it needs an airport search box.

    Are you using a multi-material assigned to the ground plane, then assigning different vertices to different sub-material IDs (usually with vertex painter).

    I think the wiki is wrong there. The screenshot shows the polygon being set to material ID 2, which is the runway material.

    Maybe post the diagram from the Slate Material Editor (not the classic material editor) so we can see what's going on?

    If I remember correctly, Aerofly is fussy with material bitmap naming, and I think the files have to end with _color for ambient and diffuse.

    That's why for me an xml editor style would slow things down, I'm just not used to reading xml code. But if you're used to it I see that it might speed things up for you. and that's a good thing. The only issue that I would see is: how do I add comments and how do I indent parameters in a block form, e.g. like for aerowings. Usually I do " 1.0 0.0 0.0 " for the string, with leading and trailing white space, which might look weird in xml.... but in tmd block form it works great: [ 1.0 0.0 0.0 ] looks more like my c++ code ( 1.0 0.0 0.0 ) and without that it looks too cramped and isn't easy to read [1.0 0.0 0.0 ]. This makes a difference after 8 hours of work. In Jeremy Clarkson's voice: "Whitespace gooood. No whitespace baaaad." 8o^^

    And on top of the readability... I wonder how do you "ctrl+s", "alt+tab" + reload in aerofly then? I imagine you would have to compile your xml back to tmd first and that takes a couple more clicks or key strokes I guess? Unless you hook it up to your IDE commands. And I sometimes do that 10x a minute, so even the "ctrl+s" and "alt+tab" already gets annoying.

    I think you're right that it depends what you're used to. In my professional work, if I'm not in a C#, Java or Typescript file, I'm in an XML or JSON file. Your brain learns to scan what you see all the time.

    Splitting the project up into multiple files was the main driver for this utility and definitely helped a newbie like me get a handle on all the individual parts that make up a plane. In any dev project I'd take small self describing files over one huge file.

    The TMD file felt like an intimidating slab of unfamiliar markup to me, but if you edit them day in, day out, I can see why it wouldn't seem like that.

    On those other things

    Comments / White space

    I only needed to go from TMD to XML once. After that it's only XML to TMD.

    Nothing is reformatting the XML so I can use XML comments, white space, line breaks in attributes as I need.

    The extra spaces or line breaks for vectors work fine.

    Reload Workflow

    Yesterday I sent an hour coding a "watch" command that writes the TMD when any included XML file is changed, which removes having to remember to run the convert action each time.

    Short hand version

    I'd argue that using "off the shelf" markup languages makes sense as everything can process them and everyone is familiar with them.

    Your example is most similar to YAML, which could also work well here, along with JSON.

    (I understand that the TMD format is good as an output format as it's so easy and quick to parse).

    It may be the case that no one else needs this utility as they are OK with TMD, but it's definitely helped me out.

    But with that said, I am working on my own AI as well that follows designated points but it's too erratic at the moment to release into my demo, however it does somewhat work :)

    Curious about this Jeff. I assume you mean by editing the simulator code itself? I can't see how anything other than pre-made animation paths are possible at the moment to 3rd party developers.

    I'm thinking that we haven't heard any rumors of what might or might not be coming down the line from Just Flight. Maybe nothing, maybe a wonderful new product. I suppose we will all know in due time. Meanwhile, I just read the post from Jeff about his upcoming "Aerofly Life Project" where he mentioned the "possibility" of including aircraft flying around even doing some touch and go's.

    If there was a way, via the SDK, to get a handle to a scenery object and set its animation path as a series of vectors, it'd actually open up a lot of possibilities like this.

    Having to pre-bake animation paths into the model export holds things back at the moment.

    I've recently dipped my feet into developing aircraft. (More on that project later). One thing that I just couldn't get to grips with is the huge TMD files. Scrolling around a file with tens of thousands of lines with no syntax highlighting or error checking isn't fun. I felt like I couldn't get a handle on all the different parts of the file and how they tie together.

    So, I spent a couple of evenings coding up a simple utility that can convert XML to TMD or TMC files (let's call them TMX) and also TMX to XML.

    Doing this gives a few of advantages:

    • You can edit the XML with your favour editor and get syntax highlighting
    • You'll also get real-time XML syntax checking from your editor
    • You can fold sections away with your XML editor
    • Using XML includes you can break the file into lots of smaller files, neatly arranged into a separate folders

    A picture is worth a 1000 words and all that...

    Here's my root file for the aircraft (early days, don't judge), all in XML, and it just imports other files.

    If you take a look at the left sidebar you'll see how I've broken the aircraft source up into many different files and folders.

    In my opinion this makes things so much easier to deal with.

    The aircraft code becomes a real project with a logical layout. You know where to find things without searching.

    In this screenshot there's one XML include file, this one is specific to cameras.

    I can put all the documentation I need in these individual files as they are specific to one area of the aircraft.

    When I want to compile things down to a single TMD I run.

    Xml2Tmx ConvertToTmx -input "c208.xml" -output "c208.tmd"

    If you want to convert an existing TMD to XML, to allow it to be split up you can do the opposite

    Xml2Tmx ConvertToXml -input "c208.tmd" -output "c208.xml"

    Obviously, this is very niche appeal. I wrote it for myself, but if anyone else thinks it might be of use to them, let me know, and I'll add some error checking a do a public release.

    I wonder if it would be possible for some talented 3D modeler to build a prototype detailed cloud model that has super highres, photorealistic textures like we are used to seeing in other sims. If we could then control it's orientation, size, and lonlat position with altitude in a TSC file , we could make a sample. beautiful cloud system just for test purposes over our own select airport area - like some thunderstorm buildups over Dallas for example. Perhaps this is not possible because it needs to have special geometry features not available in a static model without a shader script.

    The clouds in other flight sims are mostly flat, billboard clouds the same as Aerofly. Some do look nicer, but the implementation is the same.

    I'm not sure if you can place billboard objects from a TSC.

    Volumetric clouds that you see in some games are a different beast. They're not something you can import as a normal 3D model and expect a good result.

    There are several approaches to volumetric clouds, but the geometry of the cloud is usually dynamically created and updated. A shader then might use raymarching to make the cloud respond to light in the correct way.

    They are typically performance intensive, which is why other sims that have performance issues at the best of times presumably haven't pushed the technology.

    FWIW, I believe IPACS use SugDog Software clouds, the same a P3D. They have info on volumetric 3D clouds on their site, so maybe we might see those one day.

    And what can I do now with the information filed in the archives? Is it usable, or do we have to start this same area again?

    It might be the case that the ttc files are valid, but have just been generated several times over.

    I don't know why your Aerofly is locking up when you try to use the generated files. You'll need to look at the Aerofly log file.

    Like I said, try a much smaller square first to prove things are working for you.

    If you do need to run GeoConvert again on this square, you can do so without re-running everything:

    1) Select the square

    2) Set the option, in the left sidebar dropdown, to choose which actions to run.

    3) Select to only run GeoConvert.

    I have started with Aeroscenery, a single tile as proof in the NW of Spain. The PC has been working continuously for 7 hours.

    It shouldn't take 7 hours.

    GeoConvert has a fun "feature" where if you touch / move / minimize the window it can restart processing everything without telling you.

    This is an IPACS problem that I can't fix.

    (Another issue I hope drhotwing1 (IPACS) can look at soon)

    That might be what's happening here.

    In settings disable GeoConvert wrapper. The start it running when you're not using your PC for an hour and let it do its thing.

    You could try doing a small, level 12 sized tile, at zoom level 16 to confirm that you have everything working OK.

    I hide the two runways deliberately(!) because I like the original view more than the artificial runways (but that's just my opinion.). And this solves the problem of crossing decals, as a kind of workaround.

    The issue is with any ground models that are near or crossing each other, be that runway, taxiways or decals.

    Obviously removing the models removes the problem!

    Sorry to be a Debbie Downer here, but the problem with this approach is that it doesn't work for anything other than a single runway.

    You can't overlay individual runway models, as Spit40 found out a while ago when he started FSCloudPort.

    Even runways close together can conflict due to terrain smoothing.

    The only way to handle more complex airports in Aerofly is to have a single ground poly, which is pretty hard to generate automatically.

    Taking KPDX from krzysk1's repo (textures are flashing and popping where runways cross)

    Obviously for single runway airports this is a welcome resource though.

    Thanks Chris,

    The next beta release will focus on fixing some bugs, like this one, and adding some other requested features like multi-tile install.