> With the clouds issue, I have this feeling that something is amiss with > the > way clouds are generated, but i can't put my finger on it.. :(. > Thorsten, have you done the same test with individual textures instead > of a > big one ?
Huh? Not sure what you mean, I don't think I have a single instance of just one cloud on a texture. altocumulus_textures.rgb is a sheet containing 9 different textures referenced by 10 distinct 2-layer *.ac models - all of which are part of the 2500 cloud sheet being generated. So the sheet contains about ~250 identical copies of each of the 10 distinct models. Can you be more specific what you'd like to test. > Taking a closer look on the Local Weather, I can see that each cloud is > placed per .xml. Or better said: you can take the UFO and place each of > the clouds in the scenery. Quite so. > But the fact is, the more .xml has to be > loaded the more slower FGFS runs. That's one issue behind making Paris > unusuable for most of our users. That's (at best) part of the issue: When I replace the rgb by a png or dds texture, the xml wrapper stays the same - and yet I see 1/3 difference in rendering speed of the final result and dramatic differences in loading speeds. I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. As a side note, loading speeds depend on the presence/absence of a second available CPU. Not sure what that means. My problem is that I have no real knowledge about 3d rendering. I can do the experiments and know what scales with what, but I lack the theory to understand what is going on behind the scenes. * Thorsten ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
