SceneryDesign.org I have a made a new video tutorial explaining the earth curve editor of ModelConverterX. It also shows the effect of not correcting for the curve of the earth and how that can result in misaligned objects. I decided to make this tutorial now, since I fixed a few bugs in the earth curve editor this week. Animated objects are working better now, before they did not always align as they should.
Heading offsets
One problem with the scenProc feature to place objects along a line was that the user could not influence the orientation of the model. It would just follow the line and for the default light everything ended up fine. But if you wanted the use an object that was oriented differently in the MDL file you would end up with wrongly aligned objects.
So it has been requested a couple of times that the user can alter the heading of the objects. I have now implemented this chance. There is an additional attribute now in the steps to create the library objects. You can specify a heading offset in degrees in that attribute. This offset will then be added to the heading as stored with the feature. So this way you can get the orientation exactly like you want.
And while testing this new feature I also found a bug in the step to place points along a line. The heading calculated was not correct anymore (probably since I fixed another bug in some other part of the code) . So that issue has been fixed as well now.
Slower development
As you have probably already noticed the development of my different tools is a bit more slow recently. That’s just because I am a bit busy at the moment. There are a few reasons for that:
- It has been quite good weather this month here, so I have been trying to ride my racing bicycle as often as possible in the weekend as long as the weather still allows me. For example this Sunday I’ll be doing a 105 km tour with a group of colleagues.
- Work has also been rather busy recently, there are some projects that are about the finish, so that means reports have to be finished etcetera.
- Last, but certainly not least, my son has changed his sleeping habit a bit, he goes to sleep a bit later than before the holidays. Which means I have more time to play with him in the evening, but of course that cuts down the time left for FS development. Not that I am complaining about that of course.
So now you know why the development is a bit slower recently. I still try to check and fix reported bugs as soon as I can. And probably when autumn starts I should have more time to work on planned new features as well. So let me go back to some bug fixing now…
FSDS objects and smoothing
Unlike many other formats the FSDS FSC format does not store the normal of each vertex separately. This means a little more work for me when reading the format when polygons are smooth shaded. Until now the FSC importer just ignored the fact that some polygons are smooth shaded. But I have changed that now.
In the next development release the smooth shaded polygons are supported as well. ModelConverterX will average the normals of all polygons that meet at a certain location when they are smooth shaded. That results in a smooth shaded effect. I am not sure if this is exactly the same way as FSDS exports the smooth shaded polygons to a FS2004 or FSX MDL file, but it seems to work well. Below you see a picture of a model that has smooth shaded polygons and as you can see the normals appear as you would affect.
Next step is to detect when an object is smooth shaded, so that I can also support writing this attribute to a FSC file. But that’s for a next update.
Back home again
For the last three weeks this was the scenerydesign.org headquarters. Needless to say I didn’t spend much time on flightsim at all. We had a great holiday in Normandy and Bretagne. I’ll probably spend a day or two to unpack, clean and store all vacation stuff again, and after that I’ll be turning my attention to flightsim again as well.
Luckily not to many new bugs were reported during my holiday. So my plan is to finish some of the work in progress that I started before the vacation. But who knows these priorities change again when I catch up with all forum discussions.
Is it easy to waste performance?
Let me start with the answer to the question I posed in the title: YES.
Earlier this week I introduced a scenProc update that could handles holes in shapefile polygons. This new features used the functions I have to do boolean operations on polygons. Things like intersect or subtract two polygons. This functionality is also used in the ground polygon wizard of ModelConverterX or in the SPLITGRID step of scenProc. Initially I noticed that loading the shapefiles with holes took quite a bit longer than loaded the shapefiles before.
So time to have a look where that extra time was spend. Not really surprisingly it was inside my boolean functions. After I used a profiler to see in which functions most time was spend (it is always in the functions that you don’t expect), I was able to optimize the algorithm quite a bit more.
So compared to the beginning of the week, my boolean functions have become at least 6 times quicker. That will not only be useful when importing shapefiles with holes, but also when performing the SPLITGRID step. So I hope you enjoy the extra speed.
Looking for presenters
As FSDeveloper we are trying to organize an online conference for FS developers, with the aim to share techniques, knowledge and just have fun. We are now one step closer to organizing this conference, as we have our call for presenters ready. So do you have a topic that you would like to talk about for other developers, let us know!
Features with holes
Holes are often used in shapefiles, for example to mark an island in an water polygon or to mark a clearing in a forest polygon. Until now scenProc did not support holes, so they were ignored when importing shapefiles. As a result of this the autogen generated would not be correct.
The scenProc code that handles the splitting of features into the autogen grid does not know about holes and also the autogen polygons in the AGN file don’t know the concept of holes. So therefore I have added functionality to the SHP importer to remove them. Instead a cut is made in the polygon, so that the entire shape can still be represented as one polygon. After that they can be processed like any other shapefile.
Interestingly you can have island within holes again (and that island can have a hole of itself). scenProc should be able to handle such situations as well, as you can see in the picture below. Although I haven’t tested it to the extreme.
The new functionality will come at a small performance cost. When importing features with holes scenProc has to do additional work to correctly represent them. So for complex files this can increase the loading time a bit. But of course you get support for the holes in return.
If you still have a file with holes that doesn’t work correctly please let me know.
Be careful for narrow houses
Two users recently reported the same problem to me with autogen files made with scenProc. In Annotator they could not see all the buildings and after saving in Annotator many of the buildings were gone.
It turned out this problem was caused by very narrow buildings. So I want to warn all scenProc users of this problem. There are two causes for narrow buildings:
- Your data already contains them
- The SPLITGRID step made them
For the first case there is not much I can do, so just check your data. But to be honest the second case is most likely the cause of this issue in most cases. Normally the SPLITGRID step does make sure all features are divided along the borders of the autogen tiles. So if a polygon crosses the border it is split into two polygons.
Now what would happen if you house just crossed the border a tiny little bit? That would result in that tiny bit being sliced away from the house and being represented as a separate polygon (and thus seen as another house). This can result in very narrow houses in some cases.
The obvious solution for this is to not slice the houses, but instead just put the entire footprint polygon of the house in the terrain tile where the centre is. This option is already possible with scenProc, it is the second argument you can give the step.
Let me show you two examples of how to use it. The first case assumes that you load all your building footprints from a separate file, let’s assume it is called buildings.shp. In that case you can tell scenProc not to slice the buildings by using the following command:
SPLITGRID|AGN|FROMFILE=buildings.shp
Another case would be where you loaded OpenStreetMap data. In that case the buildings are not in a separate file. So you would need to filter on some attribute. For example:
SPLITGRID|AGN|building=*
Tree detection – part 4
It’s a while ago that I posted about the progress of my tree detection efforts. So here is a quick update. Some other things kept me busy, so there hasn’t been too much progress recently.
I was able to run the tree detection algorithm on the entire island of Nantucket now. It took around 3.5 hours. Below you see a screenshot of the result. I have to be honest that I took the screenshot from a good angle. There are areas where there are quite a few false detections, which results in trees on locations where they should not be. Mainly in the water. So my efforts will be focussed on finding a way to eliminate those.
In one of my earlier posts I mentioned that polygonal autogen vegetation did not work well, since trees not always show up. But that was wrong. I ended up added a buffer to my detected areas to make them a few pixels bigger and that was enough to get the trees displaying. I now I conclude that the polygonal vegetation is probably still the best way to go.
