The next development release of scenProc will include two new steps for placing points: LineToPoint and PolygonToPoint. In the future these steps will replace the existing steps to place points along lines or inside polygons. As i realise some of these steps are used in many of your scripts, I will not deprecate the old ones very soon. But for new scripts I encourage you to use the new steps.
Why did I make this change? There are a couple of reasons:
When I add the LineToPolygon and PointToPolygon step a while back, the idea was already to have similar steps for other conversions between feature types. So the new LineToPoint and PolygonToPoint steps are in the same philosophy.
Until now there were multiple steps to place points along a line or inside a polygon. Each with slightly different characteristics, but also with a lot of overlap. So it is easier to have all this logic in one step.
The manual has been updated to reflect these new steps as well. Both in the description of the steps and in the sample scripts.
The latest development release of scenProc makes a set of new steps to create terrain vector scenery generally available. This means that you can now use scenProc to make terrain vectors with the shp2vec tool.
The manual contains a sample script that shows you how you can make terrain vectors from OpenStreetMap data, but of course you can also tune this script to use the attributes of your vector data.
You can use this functionality for example to create freeway traffic BGL files for your scenery based on a road vector data.
I have just made available the new development release version of scenProc. This takes the tool from version 2.0 to version 3.0. This new version has been in development for quite a while already, so it includes many new features. To main improvements are:
Polygonal features with holes are supported much better. This means that importing and processing features with holes goes much faster.
It is possible to create XML bridges now in scenProc.
The texture filter editor has been redesigned completely, so this means that the feature detection is much more powerful now.
The scenProc Batch Runner tool has been added, which replaces the old tool to create batch files. This makes it much easier to run a script in batch mode.
And there are many more improvements. I have also updated the entire manual, so please check the manual first if you want to learn about the new features. And else feel free to ask questions in the forum. I hope you enjoy the new version.
I have just released a new stable release of scenProc, this new stable release is version 2.0. It has the same functionalities as yesterdays development release. You can find the download links on the scenProc page.
The main reason to release this new stable release now, is that the version 3.0 development release is just around the corner. I hope to have it released in about a week from now. Since version 3.0 includes many changes I thought it would be a good moment to have a new stable release first.
I’m updating the Assimp library that ModelConverterX uses to a recent version and in the process I am also trying to read skin and bones animations from other formats using this new version.
I don’t think I have it all right yet, but this video was too funny not to share with you. It directly reminded my of Monty Python. Enjoy and hopefully soon I get the skins and bones to read correctly.
At the moment the Ground Polygon Wizard in MCX only supports seasonal textures when you export using the FS2002 style code. But inspired by this thread on FSDeveloper I have started now to add support for seasonal textures to P3D v4 MDL files as well.
I have some success already with using visibility conditions to switch different versions of a modelpart, where each then has a different texture. And I plan to experiment with using material scripts as well.
My plan is to support this both in the GPW, but also for normal 3D objects. The user will just have to indicate that seasonal textures are desired and specify the season settings for the specific region. MCX will then on export take care of inserting all the code that is needed (either visibility conditions or script based).
Just wanted to let you know this is coming, I still need some time to change the GPW to support these new options though (underwater I need to cleanup some of the code in the old FS2002 style output as well to keep things organised).
The FSElite website has been running a developers month over the last weeks and I’m one of the developers that has been interviewed. I thought it was nice to give some insight about developers that support other developers as well. You can read the interview at the link below.
The latest development release of ModelConverterX adds new functionalities to the hierarchy editor. With them you can edit animations and transformations in your model and add new animations and transformations as well.
In this video tutorial I demonstrate how it works:
I hope this new functionality makes it easier to tweak your models. If you have any questions or problems with this new functionality, please post your question on the ModelConverterX forum at FSDeveloper.
Many scenery and aircraft objects contain some conditional code. For example a bit of the object that is only shown when certain conditions are met. To be able to process such conditions on import of pre-FSX objects MCX needs to know what the value of the variables in these conditions is. So when such conditions are found in the object, you will get a form where you can enter the value of the variables found in the object. See screenshot of this form you can see below.
Sometimes it can be annoying to get this additional form where you need to enter the values. Therefore ModelConverterX has different modes to work with these variables. You can set them in the options. I have now added a new option to this setting. The possible values are:
AlwaysTrue: the value of the variable is not checked, the condition is always true.
AlwaysFalse: the value of the variable is not checked, the condition is always false.
VisibilityCondition: the value of the variable is not checked, a FSX style visibility is made and used to represent the condition.
UserSpecified: the form mentioned above is shown where the user can enter the values of the variables. Then using these values it is checked if the condition is true or false.
DefaultValues (new): This one works like UserSpecified, but instead of showing the form it uses the default values for the different variables. This are the values that are shown in the form initially as well.