SceneryDesign.org
I have made a small update for RADItor. When you drop a file on the EXE, shortcut or on the main form it will now automatically be loaded. So you don’t have to manually browse for the file anymore in that situation.
The new version can be downloaded from the RADItor page.
I already made these changes a few days ago in ModelConverterX, but since I didn’t write about them yet they probably went unnoticed by most of you. So let me document the changes I made to the batch mode.
First I add a checkbox to the batch convert wizard that allows you to select if you actually want to export objects. I added this because I wanted to generate screenshots in batch mode, so in that case exporting the objects is not needed. I guess making screenshots is the only use case for this feature, as all other batch operators only make sense if you export the object afterwards.
The second change I made is that you can now also start the batch mode from the command prompt. This can be done in two ways:
modelconverterx.exe -batch yourbatch.mbc
The command above will start ModelConverterX and load the select batch settings into the batch wizard and start processing them. So in this case you should save all objects you want to convert in the batch settings file.
modelconverterx.exe myfile.mdl -batch yourbatch.mbc
With the command above the specified file (myfile.mdl) will also be added to the list of objects to process in the batch wizard. So in this case you better save the batch settings without any files to convert and then you can specify on which file the batch operations should be run from the command prompt.
I have updated the PLACEPOINTSALONGLINE step of scenProc today. So if you grab the new development release tomorrow you will notice that the step takes two more arguments. So your existing configuration files need to be updated!
Please check the updated manual for all details of the changes. Below I will give a short summary. There are two main changes:
Below is a picture showing the CONTINUOUS mode in action with a test object I made. I was actually planning to use it for cables between telephone poles, but it turned out easier to test with this median object. I’m sure you can find other ways to use it.
Imagine you have some vector data of gas stations and you want to use that to place autogen library objects. But your vector data only contains the location of the gas stations and no information about the heading at all. How to place these objects realistically in your scenery?
I have added a new step to scenProc last week already that helps in this situation. With this new step you can add a heading attribute to such features. And the heading will be derived from the direction of the nearest line to the point feature. So for the example here, that means you will align the gas station objects with the nearest road. That’s exactly what you want!
The small scenProc configuration below shows the basic usage of this new command:
IMPORTOGR|roads.shp|*|*|NOREPROJ
IMPORTOGR|gas_station.shp|*|*|NOREPROJ
#
HEADINGFROMNEARESTLINE|FROMFILE=gas_station.shp|FROMFILE=roads.shp|HDG
#
SPLITGRID|AGN|*
#
CREATEAGNLIBOBJ|FROMFILE=gas_station.shp|{117278df-5ce4-4765-8369-02dd363b08db}|HDG|0|18;2
You might notice I put the HEADINGFROMNEARESTLINE step before the SPLITGRID step. I did that on purpose, because the step only looks for lines within the same cell. So if you first split the objects, it might be that the closest line is not in the same cell anymore and you get the wrong heading.
And below is a picture to show it really works. In this blog post I have been talking about gas stations only, but I’m sure you can imagine many other types of objects that will benefit from this.
Sometimes a very simple question on the forum can lead to interesting discoveries. In this case the question was why autogen buildings that look fine in Annotator are distorted in FS. Although the answer from an expert was that this is normal, I decided to have a look into this issue. In the end that gave me a better understand of how the autogen works, and I’ll try to write that down in this blog post. And I have also been able to improve scenProc now to automatically prevent this distortion.
Where does the distortion come from?
So where does the distortion actually come from? To understand that you need to know how autogen buildings are defined in the AGN file. Each building is defined using a corner coordinate, a direction vector and the size (length and width of the building).
If you look at the image below you see two buildings that are aligned correctly with the photo in Annotator (right side), while when viewed in FSX they have an heading offset (left side). This is the distortion issue that I was trying to understand.
How much distortion there is depends on the latitude of your scenery and on the heading of the building. Building that are oriented either horizontal or vertical are not affected. Buildings with a 45 degree heading are most affected.
Each autogen tile has a fixed size in degrees (actually 0.0146484375 by 0.010986328125 degrees). But of course the closer you get to the poles of the earth each degree is equal to less meters in distance. So the autogen tiles are getting more narrow the closer you get to the poles. This is also what you see in the image above, this is some photo scenery in northern Norway and in Annotator you can see the distortion in the photo scenery.
Due to the size of the autogen tile in degrees they correspond to a square area in meters at a latitude of 41.41 degrees. So around this latitude you don’t notice the problem, at a lower of higher latitude you will notice some distortion.
But where does that distortion come from? In Annotator you draw the orientation of the building on a photo that is shown in degrees and this orientation is stored as a direction vector in the AGN file. But it turns out that FSX uses this orientation is used when drawing the building in meters. So what does that mean? Let’s assume you drew the orientation as shown below on the left in Annotator in degrees. So your object has a heading of around 45 degrees. But since you are at a high latitude if you would draw the same arrow in meters you would get a heading as shown on the right. As you can see this is more like 60 degrees.
So this is the problem we are facing. Annotator shows the photo scenery in a different way and therefore you define the orientation wrong for the way that FSX later uses the information to render the autogen building. So actually it’s not an issue in FSX, it’s an issue in the Annotator tool.
The maximum heading offset you can get due to this problem is around around 20 degrees when you are at latitude 70 degrees. At latitude 41.41 there is no offset and at the equator there is an offset of around 8 degrees. These numbers apply to buildings at a 45 degree heading, for other headings the offset is less.
scenProc correction
So now that the cause of the heading distortion is understood, it was not so hard for me to alter the scenProc output to actually correct for this issue. So if you create the autogen with scenProc you shouldn’t encounter this anymore.
There is one “problem” with this correction however. When you look at your autogen in Annotator the objects will appear to have the wrong orientation. But once viewed in FSX everything is fine. This is shown in the image below.
And if you are not using scenProc to make your autogen and drawing it manually in Annotator, I’m afraid the only solution for now is to manually draw the objects at a different heading. But since the exact offset depends on the orientation of the building as well, that can be quite tricky to get right.
Ever since the release of FSX SP2 enabling drawcall batching has been a popular method of increasing the performance of scenery. The basic idea behind drawcall batching is that the scenery engine will gather all polygons with the same material, even if they belong to different objects, and then render them in one go. This eliminates the overhead of switching material and texture settings multiple times and therefore improves the performance.
But is it a good idea to always enable drawcall batching on objects? For a while we already know that drawcalls with too many polygons in them give trouble. They can result in disappearing objects for example. So in that case you better turn off the drawcall batching.
Last week while debugging an issue reported on the forum I found out that drawcall batching can have one more negative side effect. It turns out that when objects are used at higher altitude, the drawcall batching results in an offset of the position of the object. I never noticed this myself, since I’m from the Netherlands and always test my objects at sea level. But when you make scenery in a mountainous area you will for sure encounter this. So also in that case it might be better to turn off drawcall batching.
By default ModelConverterX has drawcall batching enabled, but you can easily disable it in the exporter options. If you encounter any of the issues described above, it might be a good try.
So it turns out that drawcall batching is not the magic performance solution we have thought for a long time, but if you are aware of the limitations you can still make good use of it.
A little while ago a bug was reported in the position accuracy of the scenProc placed autogen library objects. After some debugging it indeed turned out that the location of these objects was wrong. And the bigger the size of the library object, the bigger the position offset.
I have now fixed this issue, so from tomorrow’s development release you should see that your library objects are placed more accurate.
A bug was already reported in the heading of the library objects. I still have to investigate that, but there seems to be a small offset in there as well. More news about that soon hopefully.
The features that are generated using the detect features step of scenProc are not simplified. Before these polygons would be a bit blocky because of the raster image that has been converted into the polygon. But with the simplification a more smooth polygon results. In the image below you can see an example without (left) and with (right) the simplification applied.
The simplification makes the polygons less complex and therefore also reduces the size of the AGN files. And with this simplification it also becomes possible to use the feature detect polygons for buildings. For the blocky polygons it was not possible to calculate the best fitting rectangle correctly, but for the simplified ones that no longer applies.
As you have most likely heard by now Microsoft has stopped supporting Windows XP as operating system. I know there are still many users using my tools on Windows XP as well and the decision of Microsoft doesn’t mean of course that my tools will stop working on Windows XP.
However given that official support has stopped now, I have decided that I won’t fix bugs that occur only on Windows XP from now. So if a problem doesn’t occur in Windows 7 or 8, but only happens on XP, I will not spend time to fix it anymore.
For the rest I expect that my tools will keep working on XP as well for the foreseeable future.
I have returned from my vacation yesterday. As usual I don’t bring a computer on vacation, so I haven’t done anything on FSDeveloper or my tools in the last 3 weeks. But of course that doesn’t stop my brain from coming up with new ideas. Luckily I had brought a notebook (you know, a paper one) to write those ideas down. So now I have returned full of interesting ideas to try again.
At the moment the things I want to work on first are:
The photo on the right is a photo I took in Shanghai (China) from the hotel we stayed. I guess it would be a real challenge to represent just a city realistically with autogen. And also during our train travels through China I have seen a nice variation of buildings that would be interesting as autogen objects. You see, even when I am on vacation and just enjoying the landscape, my mind keeps busy with how to present something like that in a scenery.
As you might see ModelConverterX is not so high on the current prio list (but those lists tend to be quite fluid, as I quickly can get distracted by other interesting ideas to try). But I hope to spend a day in the near future to look at some of the recently reported bugs.