Hi Stuart, sorry for the silence from my side, I haven't been able to start FG up for the last week or so, I am a bit swamped in work and family issues at the moment...
> I'm slightly surprised that Thorsten's > new system doesn't > support this, as evidenced from his screenshots. glxinfo claims that it does - I get several instances of GL_ARB_multisample or GLX_ARB_multisample shown in the resulting list (at least under Linux, maybe it's a bug in the Windows driver of the card only??? - I'll check next time I boot up Windows). > 1) Forget the whole thing. Revert back to the previous model of > having one texture > for summer and one for winter, no support for snow-covered trees. I'd > still commit > changes to fix the black outlines and technique=4, so the effort won't > have been completely > wasted. With a 4096 texture sheet limit we'd be able to have 512x1024 > individual trees. What about 1a) - reverting back to the previous model at low quality, but introduce a composite tree model (where bare tree and foliage and snow are separately read and rendered on top of each other) at high quality setting? I have yet to test how bad a second texture call is in the tree fragment shader, but if it works we could have the pre-selected season model (winter and summer) for the slower systems and a completely dynamical shader-generated season model for the faster systems. This would allow to color leaves in fall, and even partially shed foliage in late fall. And have 512x1024 maximal tree size which is really quite generous. > 2) Support dynamic changing of snow-cover on trees, but not season > changes. This means > that to see a winter deciduous tree one would need to change the > season and reload the scenery, > loading in the winter material definitions which would include both > the tree texture and general > ground textures. Thorsten R. - what are your plans for ALS support > for winter? I > think you currently use the summer materials, correct? This would > allow 256x512 individual trees. ALS doesn't _depend_ in any sense on what materials definition you use, it runs fine with dds textures last time I've checked. Only the procedural terrain definitions reside in the summer definitions, but imo it wouldn't make too much sense to have them in the winter materials as well, because the terrain is snow-covered anyway, so it doesn't really matter so much what procedural details you generate because you wouldn't seem them. 2) obviously doesn't mesh with any continuous season model for the terrain or the idea of snow as a shader effect. > 3) Support dynamic changes of season, but have no support for > snow-cover on trees in the texture > itself. This is my probably my preferred option. While having > snow-covered trees is nice, the > actual circumstances when it occurs are fairly minimal as the snow is > blown off the trees by the wind. > This would allow 256x512 individual trees. I woud prefer this over 2), if only for the simple reason that it's no issue at all to add some white color sprinkles to the tree textures procedurally - snow is, after all, a pretty simple texture, white does the job remarkably well :-) > 4) Accept the limitation of 128x256 individual tree textures. I'm not too happy about that limitation - I would prefer to have a novel scheme which is an investment into the future and which can easily be adapted to yet more powerful graphics cards 5 years from now. Hope that helps. * Thorsten ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
