7 hrs later:Thorsten wrote:This probably means you can't have fancy night illumination, too much individual configuration or realistic arrangements beyond a point, and all placement info is encoded in the texture sheet (that's not a bad feature, because that means random buildings stay in sync with the underlying sheet!)
Regarding night time texturing, that could probably be addressed by using two different textures: one for daytime texturing, one for dawn/night time. As long as this is made configurable, so that two different textures are automatically used, it would be up to modelers to come up with a texture map for night time, it would just need to be based on the daytime texture, so that they match.
Thorsten wrote:These problems mean that pre-arranged blocks are not suitable for us, blocks need to be arranged dynamically taking into account the actual terrain.
I agree with this, it would be great to have a way to dynamically assemble buildings and blocks of buildings and then combine them into a single geometry, so that the performance hit is decreased. But that would obviously require exposing some more hooks to Nasal scripts. A while ago, we actually talked about using Nasal to create 3D models procedurally:
viewtopic.php?f=5&t=10016&start=15#p101815And that's also the approach taken by the PixelCity project:
So that would definitely be possible. From an interface point of view, one would need to extend the put_model() routines such that models can be loaded not just from the file system, but also directly from string contents in the property tree. That would make it possible to use a Nasal routine to come up with the 3D model, write it to a property and then instantiate/place the model in the scenery.
Now, what Stuart has done already addresses the needs in C++ space.
Adding a C++ interface to existing C++ is much easier that way, and certainly easier than creating the whole thing from scratch.
Thorsten wrote:Hooray has (probably) some more involved dynamical city-building scheme in mind (so have I actually) - finding an algorithm which dynamically generates a street pattern and places a plausible mockup of a city dependent on its knowledge of the underlying terrain.
Yes, that's basically correct: As you know, I am aware of geodinfo() and geo.put_model() being available to scripting space. However, in order to be able to procedurally create and instantiate 3D objects and textures in scripting space, a bunch of new hooks would need to be provided.
And then, like you correctly mentioned, better access to the placement heuristics, or rather the underlying criteria would be great. That's not just related to "materials" anymore, but also access to "ground networks", such as roads, rivers, railways.
A Nasal script that may query a scenery tile and get detailed information on these properties, could come up with the heuristics to place models realistically.
Coming up with the models procedurally would be a different matter.
But it seems, Stuart has addressed this already in OSG space. So the really difficult work has probably already been done.
Coming up with an interface to access his code from scripting space should be simpler than writing his code from scratch.
Thorsten wrote:Much of the performance here depends on what models are placed - if models without an xml wrapper are used, it's going to be relatively fast, if not, then not. That's different from the situation with weather where we could never use models without xml wrapper, because the rotation effect needed to be declared there (merging the models to a whole block is also important though).
I don't disagree at all. But as can be seen by other related efforts (e.g. PixelCity) creating 3D geometry and textures procedurally is definitely possible. And Stuart's work seems to suggest that optimizing such models is indeed much simpler than just having a library of standard models and placing those.
The truth is, procedural content creation could even be done asynchronously - only the optimized and combined 3D model/textures would need to be passed to the main thread.
Thorsten wrote:But such an algorithm has never been demonstrated to work or give good results, so it would be somewhat far-fetched to ask Stuart to make a faster Nasal interface than the existing one just because someone might eventually work on it.
I agree again, but the idea was not to provide a faster interface, but just provide an interface to the new code (which happens to be faster), so that it's accessible from Nasal space. For example, Stuart's code creates buildings procedurally on a vertex-level, that's something which simply isn't currently possible otherwise. Imagine this were exposed to scripting space: You could create 3D models with configurable dimensions and apply custom textures.