Daikan

The trial version works okay for me although it's limited to 30 seconds. As discussing video capture software is kinda off-topic I suggest you check out this thread instead.

Do you mean video recording? Sadly, the built-in recording of X-Plane 10 only works in 32 bit mode, which I think almost nobody uses anymore nowadays... You will have to use some third-party software like Fraps etc.

Thanks! One question: How recent is the OSM data (pbf) for those countries?

Well, this could simply be caused by the fact that a LOT more funcionality has been added since 0.2.0... How much physical RAM do you have and what is the peak memory usage reported by W2XP?

And good job blacky75 I suppose those fences should work well with barrier=fence and barrier_type=chain_link or barrier_type=*wire tags.

Excellent idea!

Filtering the OSM data prior to processing is of course a good idea but I think the parameters given above filter too much (i.e. landuse=meadow, farm and farmland which are used for the tree line rules). Also, I think the "drop" is not really needed as the "keep" parameter is already quite specific.

There are no buildings from my 3D Warehouse sceneries in Geneva (Zurich City and +47+008 have much better coverage and will probably manage to kill your framerate if used together). But as you can see for yourself Geneva is already pretty good-looking

It seems you're talking about my Switzerland 3D Warehouse Objects for Zurich City, +47+008, +46+007, +46+008, correct? First of all you can already combine these with any OSM scenery as long as you give them a higher priority in scenery_packs.ini. Regarding re-using the textures in W2XP: While this could be done in theory it is highly impractical as the texture files are not optimized for large scale, multi-instance usage and the converted objects are often split into many small sub-objects as a result of the "single texture file/atlas per object" limitation of X-Plane (which GMaps cannot work around, either).

Curiously, what Switzerland scenery are you talking about? Regardless, to use any third-party content in W2XP the permission of the original author(s) is needed except where this is explicitely allowed (i.e. libraries etc.).

I don't think that torrents would make much sense at this stage. As everything is still very much WIP those files would become outdated fairly quickly... For now I'm offering my reasonably sized Swiss scenery 'as is' for public download here: http://www.mediafire.com/download/vz591fbl1e31l5h/OSM_CH.7z (~72MB, 7Zip compressed) It was generated with the latest Alpha (0.0.6) using the current OSM country export from Geofabrik and the following custom options: - LOD 10km (default = 12km) - Smart exclusions = true - Building exclusion range = 100m - Forest exclusion range = 500m Just unzip the contained folder "OSM_CH" into your Custom Scenery making sure it is at the right priority in scenery_packs.ini e.g. just above any custom meshes, orthophoto, OSM Europe from Simheaven, Treelines and Farms from Alpilotx, etc. Also, it is recommended to use Simheaven's Europe Library as otherwise the autogen outside the smart exclusion zones will show US-style buildings...

Edited my post to include HiRes versions.

Here are a couple of side-by-side shots of my latest Swiss scenery (done with Alpha 3 + default rules + latest world models + ZL16 orthophoto + HD mesh v2) along with the real thing: HiRes HiRes HiRes HiRes From these one can probably get a good idea of the current level of plausibility in a region that's reasonably covered in OSM. PS: A few objects are from my scenery Switzerland 3D Warehouse Objects for +47+008 1.0 (for example the Prime Tower can be seen in the last shot).

Maybe a stupid question but wouldn't it be possible to achieve the same (or similar) by just using a different set of objects which are referenced by the DSF? Of course leaving any filenames unchanged...

Very nice! Interesting mix of architecture :-) Given that the "hardcoded" way of regionalization via DSF already works reasonably well I am tempted to say that we should prefer it to the built-in library system at this point, even if that means losing some flexibility with post-processing. I really like the possibility to have fine control over region borders. To be honest, I doubt that there will be high enough demand for the possibility to tweak the region appearance via changes in library assets after the OSM custom scenery has been released. For instance it's probably not something an average user would like or be able to do, so in that sense it will remain part of the job that experienced custom scenery providers like Simheaven do and as such I don't think it would make much of a difference if the regionalization is inherent to the DSF or not. It would perhaps be interesting to hear PilotBalu's opinion on this...

Of course it would make sense to use the built-in regionalization of the X-Plane library system whenever possible but I think the 1x1 degree limitation is quite a bit harsh, even considering the spill-overs at country borders. I'm not sure if it would look good (nor how noticable it would be) to see the types of buildings suddenly change along some artificial straight line at a DSF border.... In fact, for a small and diverse country like Switzerland a quite noticable distinction in building architecture is mainly due to a mix of topographical (flatland / mountains) and climate properties (mainly North / South of the alps) and it doesn't even depend much on administrative borders. All in all I fear this would collide with the 1x1 degree limitation but maybe I just don't understand the advanced possibilities that it provides in order to consider more fine-grained "natural" (topographical / climate) properties for art asset replacement rules...

It would be great to have a regional hierarchy structure, for example Switzerland -> Central Europe -> World. This would allow objects from a parent region to fill in should they provide a better match than the regional ones. As for the region polygons, you can easily get them as .poly files from Geofabrik, for example, here's the one for Switzerland. They're not exactly simple, but since you're using the JTS library (which I used for the MultiOSM2XP tool as well btw) I'm quite sure there is a simplify() function in there...

I just committed a first batch of swiss buildings to the repository all of which are residential houses except for one which is a barn. I used the prefix "BAR_" for it, as there was no suggested naming convention for this type of building. I hope that's okay. Curiously, how is regionalization supposed to work? And is there a fallback mechanism in the sense that regional objects are always prioritized over global/generic objets unless there is a better match?

A very interesting project you have here! At Simheaven.com we added the multipolygons (mainly buildings and forests) using a separate tool (MultiOSM2XP) which I wrote in Java. It works but it's quite messy and has it's limitations. For example one unsolved problem are multipart buildings where the parts share one or more sides (or "ways" in OSM terms). Currently this results in some facades that cause ugly Z-Buffer thrashing ("clipping"). Also, the facade rules are currently hard-coded, which isn't very flexible... Looking forward to see your dynamic facade colors and complex rules put to work!

Okay, so here you can browse through some screenshots for comparison of Low, Med and High overcast quality: http://imgur.com/a/uVX00/ The cloud settings were the same and are visible in the last screenshot. The pictures were taken at an altitude of 5372 ft, so that's right inside the stratus layer. My rendering settings are the same as mentioned in the OP. Is this really what I'm supposed to see?

SMP (+Gizmo) are the only plugins I'm running right now and by reading what others had to say about it, I guess that's good enough in terms of "housekeeping", right? As I said, last time I checked I didn't notice any (qualitative) difference whatsoever using different overcast quality settings together with the mentioned XP weather settings. I can see if I can post some screenshots later today but perhaps it would be better if you could tell me what exactly I should be looking out for? E.g. what do you mean by "some variation"? Increased number of puffs? View distance? Haze? Layers?

Getting back to my OP as I think nobody commented on the following: Am I seeing the expected behavior? And if so, why is there no differentiation between the quality settings? I can see how having a zero-thickness layer is good for performance and therfore belongs into "Low" settings (same as with cumulus overcast), but I would expect a little bit more from "Med" and "High" (at least some representation of actual non-zero thickness would be really nice).

That might be true but I'm sure there are also other user created "core-level modifications" that probably nobody here has even heard of yet. And sooner or later people will want to use those along with SkyMaxx and that's where the potential fun begins... Therefore, as long as there is no proper (read: built-in) extension mechanism for these resources it is quite important to know what exactly is being touched and used by the plugin. Anyways, now that it has been explained (thanks SunDog) it would be nice if this info was included in the official manual, too.

+1 Unfortunately, this is not the only addon / extension that messes with the X-Plane core file system directly (e.g. not over an extension mechanism like Custom Scenery and plugins), adding to the potential chaos... Hence, an X-Plane update might cause some unwanted surprises (or at least raise some questions about which files are safe to be overwritten).

In that case I guess we will have to live with "Med" not being true overcast in the sense that it provides a 100% opaque layer... fair enough. But what about the High setting then? You said you couldn't reproduce it on your end? Would you care to post a video of a layer transition with some intersecting terrain nearby? Who knows, maybe its a driver issue or something else interfering with the draw order...