Like I said before, I do understand and even agree with the points Thorsten made - and once your code is committed, it will be possible to tell how easy it really is to make it accessible to scripting space using one of the 3 methods discussed.
Stuart wrote:Given that people don't seem to making significant use of the tools already available by modifying materials.xml (at least not in a way that is making itself as far as git), I just don't see sufficient interest.
I see, but I am not sure if this statement should be made with a focus on materials.xml (obviously your preferred route of customizing things): Actually, we've seen a number of related developments - such as IntelQube's "Instant City" addon, or the more recent effort by Rickbritto. So people are clearly interested in this.
Like Thorsten also rightly pointed out, people are pulling into different directions, which are unfortunately somewhat conflicting. But overall, it's pretty obvious that people are interested in extending the scenery and populating it with buildings in particular.
Given that you have developed the code in question, and given that materials.xml is your preferred option for customizing things, my impression is that we should work on better documenting things, so that people can learn how to customize the simulator using materials.xml - I haven't checked, but I am not aware of any dedicated tutorials discussing this? If there IS documentation available, it should probably be reviewed, improved and made more prominent.
So I am really not sure if we should even try to see a trend here: Modifying an XML file is obviously simpler than scripting, so it would certainly even be the option preferred by non-developers (i.e. modelers) - and if they don't know how to make use of these possibilities, we should clearly work on better documenting the process that's involved here.
From a coder's perspective, the things that Thorsten mentioned (advanced and procedural model creation and placement) would still be interesting. Obviously that's much more advanced than what most 3D modelers will want to do though admittedly.
Like I said before: The good thing is, adding a Nasal interface to make existing C++ code accessible is fairly trivial and much simpler than writing the original backend code. And this is clearly not a task that needs to be done by the developer of the original C++ code, as can be seen by all the existing Nasal extension functions, most of which were added by people who didn't really write the corresponding backend code.