Thorsten wrote:You have defined the problem rather well. As I see it, the current environment controller is too 'agressive' - it writes e.g. visibility every frame, so I can't set /enviroment/visibility-m from Nasal, but rather have to change the values in the config menu and then call reinit();. A controller which would only set the visibility when asked to change it would go a long way toward a common interface.
Right. FYI the /environment.visibility-m is interpolated as an L-value from the current visibility to the configured visibility for that altitude.
Thorsten wrote:As for a cloud-generating interface, that would be something... I'm a bit envious how fast your layers are created - currently waiting for clouds to appear after I have written a vector into /models is the bottleneck - all the Nasal runs fast enough. So it seems there is a lot of performance to be gained.
I think if we could have a process that allows Nasal or C code to write clouds to a property tree, and then make a reinit() call to load them all immediately.
BTW - I put a huge amount of effort to get decent performance out of the 3D clouds. You won't believe the amount of grief I get about low frame-rates
Thorsten wrote:However, I don't really know where I want to go, thinking of dynamical weather, there is still a lot of R&D to do. I may need a structure 'cloud' which is a box into which cloudlets are written, such that changing the coordinates of 'cloud' moves the whole thing, but in which I can alter the shading/texturing at runtime to simulate how a Cumulus is formed and decays.
That matches how the 3D clouds that I've got are created - a cloud which contains a set of cloudlets, each of which contains a set of billboarded sprites. (Or at least that's how it used to work - I changed the structure of the clouds about 6 months ago, and I don't recall whether they are structured with cloudlets now).
I would envisage defining a cloud as a directory node with a given lat/lon/alt, and then having some sub-nodes defining the cloudlets.
Note that this would remove the limit of a 20kmx20km box, and make it easier to set up different conditions above different airports based on METAR...
Thorsten wrote:In addition, the texture content of the box isn't random - cloud top textures need to go above, cloud bottom textures below. I'm currently working with WooT trying to use high resolution cloud textures, and it seems a large part of the effect is a good mix, and to decide where to put the cloudlets.
FYI I solved this problem rather neatly. For the C-based cloudlets, the texture is a nxm grid of individual textures. We select the horizontal texture index randomly, but the vertical texture index is based on the vertical position of the sprite within the cloud (or it might be the cloudlet, I forget).
-Stuart