Scrubs

For the Nantucket project I have used the scenProc feature detection function to get the autogen trees from the imagery. But would a similar approach also work for scrubs?

First I tried with polygonal autogen vegetation. The detection of the polygons went OK, but the density of the resulting autogen in FSX was much too sparse to be realistic.

So the next attempt was to use the PLACEPOINTSINPOLYGON step to generate point features within the detected polygons and then create rectangular vegetation autogen from those points. That did work, but it was slooooooow. So also not a feasible way to generate scrubs for the entire island.

Therefore I have modified the feature detection step now so that it can generate point features directly, instead of polygons. This saves the step to generate them later. How does it work? Here are the main steps of the point feature detection algorithm:

  1. The first step is similar to the polygon detection algorithm. The texture filter is ran over the imagery and the result of this is a new raster image that indicates areas that match the criteria of the filter.
  2. In the polygon detection mode this raster image would be polygonized into polygons, but in the point detection mode the raster image is used differently. Using the user provided spacing in pixels the raster image is tested to see if that location matches the filter or not. If it matches a point feature is made at the location.

For Nantucket I used a spacing of 20 meters for my scrubs and that gives a much denser scrub autogen than I got with the polygonal autogen.

This update of the feature detection step is available in the next development release. Be aware that the changes to the texture filter can influence your saved texture filter configuration files. The filter now also takes a minimum and maximum value of each pixel channel and if you load an previously saved filter this maximum will be zero, resulting in no matches. So please check your existing filters with this new update.

The only problem I have found so far with the scrub detection is that it’s much slower than trees. Not really because the algorithm, just because there are potentially more areas with scrubs than trees in many images. So there are more pixels to examine. I have some ideas to speed up the feature detection by moving part of the logic from the CPU to the GPU. It will be interesting to see how much that can speed up things in the future.

Status update

After spending almost 10 weeks in hospital, our son could finally come home this week. It’s very good to have the family all at home again, not having to travel to the hospital continuously.

The only small downside is that our sleep is now interrupted in the night, but that’s normal with a small baby at home of course.

So as things return more to normal at home, I can hopefully pick up some FS related things again. I would really like to do some debugging on my tools as a way to relax after all these things.

But on the other hand we are also still busy with our new house, so time will still be sparse in the near future. So hopefully you’ll see me on the forum now and then again, but at least you now know I’m doing ok.

Time out

As you have probably noticed I haven’t been active at all recently with my tools or on FSDeveloper. I already reported before that we bought a house and are busy renovating it. But on top of that our second son was born 3 months too early. So that means that at the moment we step any spare time we have in the hospital to visit him. Logically the FS hobby is on hold for a while now. Luckily our son is doing OK, he’s still very small, but growing. The expectation is that he has to stay in hospital for another 2 months probably. So hopefully next year I can spend some time on the FS hobby again.

Busy

As you might have noticed already from the lack of activity on this blog and the fewer updates to my tools, I’m a bit busy at the moment. We have just bought a house and next week we finally get the keys. But the house also needs some modernization before we can move in, so in the last few weeks I have already  been busy planning for that.

I guess this lack of time for FS will stay until we have moved into the house. So until then expect less updates of the tools and sometimes I might also reply slower in the FSDeveloper forum. Although it is mainly the programming that suffers, since I can still check the forum from my phone, but I can’t code on ModelConverterX or scenProc that way.

The Nantucket tutorials

nantucket_blend

Over the last I have been using the island of Nantucket (Massachusetts) as a sandbox to try all kind of autogen techniques and to develop new features of scenProc. Coincidentally Bill Womack is working on a scenery of Nantucket airport as well. So my test autogen project will even end up in a real product. And with the help of Bills artistic skill the autogen textures also got much more realistic than I ever could have done.

Now that the autogen project is nearing its end and scenProc is also nearing the release of a stable version 1.0, I thought it would be a good idea to make some video tutorials about the things I have learned during this project. So with this blog post I want to announce a small series of video tutorials that will cover the different aspects of this project. I plan to give you one or two tutorials every week.

At the moment I have the following “episodes” planned, but as usual things can always change as I go along.

  1. Creating the buildings (finding the data, how to prepare it for creating FS autogen buildings)
  2. Customizing the buildings (adding custom textures and roofs)
  3. Creating the vegetation (finding the data, how to create the autogen)
  4. Customizing the vegetation (using custom vegetation models for even more realism)
  5. Creating the library objects (electricity poles, gas stations)
  6. How to merge all these custom autogen configurations when installing a scenery

Let me know if there are other topics you would like to see covered!

P3D v2 and GPW gaps

In my post from two days ago I reported about gaps in my ground polygons, this lead me to discover the different resolution of BGLComp and BGLC generated BGL files. But it turned out that the gap was also caused by a programming mistake I made. The round earth correction was not completely correct for the P3D v2 output. I have fixed that now and as a result you can use the option to divide the polygons in a grid again. For the FS2002 style polygons that gave a better performance, I guess we need more testing to see if that is also the case for P3D. But in general it should be more efficient for the rendering engine if not all polygons have to be drawn.

The observations about the different positional resolution still stand, but they were not the cause of my gaps. So gaps fixed and still something interesting learned.

GPW update for P3D v2

I have just put an update of the ground polygon wizard (GPW) in the development release of ModelConverterX. With this update it is now possible to export P3D v2 MDL files from the GPW as well. These can be used in P3D v2 and it allows you to use the full material properties on your ground polygons. As Lockheed Martin has announced this is the way forward, the old FS2002-style ground polygons will be removed in the next major release.

Are there limitations in the P3D v2 export? Yes there are:

  • Seasons are disabled in the wizard, as these can’t be combined with MDL files
  • The visibility range is disabled in the wizard, as MDL files work with LODs. For the moment only one LOD is exported.
  • It is no longer possible to split your complex ground polygons into multiple groups. For P3D v2 they are always exported to one MDL file. This is because the BGLComp placement is less accurate and with multiple groups you would get gaps in between. If this leads to performance issues I can see if there are other optimizations that can be done.
  • I did notice with my test objects that some of them seem to disappear or flicker a bit in the distance (10 nm away or so). I guess when combined with some resample photo scenery below you will hardly see this. But maybe this can be prevented by adding LODs or something else. That’s something that needs some more testing, let me know if you have any issues or ideas on this.

I would suggest that you don’t use this new feature for production work yet. I do expect there might be a few bugs here and there left. So please go ahead and try to break test this new feature. Let me know if you have any suggestions or issues.

GPW and P3D v2

Today I have been experimenting with updating the ground polygon wizard of ModelConverterX to also export P3D v2 MDL files for ground polygons. Given the recent announcement by Lockheed Martin that the FS2002 style polygons will be dropped in the future, it became time to update the GPW.

The good news is that it was quite easy for me to ouput the ground polygons as P3D v2 MDL files. The layering information is stored in the material zbias property now, but for the rest it works similar to the FS2002 style polygons approach.

But I also found a problem. It seems the positional accuracy of BGLComp compiled scenery is much lower than that of SCASM based scenery. As a result of that, gaps will appear between the polygons when they are split up in different groups. I usually do this in the GPW to increase performance. So in the old FS2002 style code there would be multiple reference points, each containing the the polygons closest to that point.

I need to do a bit more thinking on how to handle this. Either  I will drop the option to group polygons for P3D v2 output or I need somehow use the same reference point for all groups. So there is some more experimenting to do before I can finish the GPW update.

Image2014-06-15 2125.08.955

And for those of your interested in the math of the positional accuracy. In the BGLComp BGL format the latitude and longitude are stored as 32 bit integer values. This means that an increase of the lat/lon value by 1 corresponds to 3.3528e-7 degrees for latitude and 4.4703e-7 degrees for longitude (at the equator). That roughly corresponds to 4 to 5 centimetre accuracy.

In the old FS2002 style scenery the latitude and longitude are stored as a 32 bit integer plus a 16 bit integer. This means that an increase of the 1 corresponds to 1.3731e-10 deg degrees for latitude and 1.2790e-12 degrees for longitude (again at the equator). This corresponds to an accuracy of around 0.015 millimetre.

I never realised before that the accuracy of placing objects was so different between both methods. The accuracy of the old method is probably a bit over the top, as you won’t see that difference. But for the BGLComp approach I would have expected a little more accuracy actually.

Updated options and better P3D support

I have updated the options form of scenProc and also added better P3D support. Before you had to trick the tool by pointing the FSX settings to P3D. You can see a screenshot of the new form below.

At the top part of the form you can choose which FS version is supported for the auto completion. So you choose from FS2004, FSX, Prepar3D v1 and Prepar3D v2. scenProc will then read the autogen configuration files from the selected version. You can enable only the versions you are developing for. The enabled versions here don’t influence to which FS version you can export, it’s only for the auto completion in the scenProc GUI. The radio button at the wrong is used to select the preferred version that will be selected by default.

Below you can set the paths to the different versions of the BGLComp compiler. This compiler is used by the EXPORTBGL step. If you don’t export to BGL, you don’t have the set these paths.

At the bottom of the form there are a few other options that influence the behaviour of scenProc. Set them as desired.

Image2014-06-08 2216.34.197