Re: [Flightgear-devel] Tree issues
Stuart Sent: 19 May 2013 21:42 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, May 16, 2013 at 11:02 PM, Vivian Meazza wrote: I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. Yup, works nicely here, there's definitely an improvement. I've also modified the predicates for techniques 4 and 9 take that into account I've also fixed the black hat by increasing the bleed margins in treebin.cxx a tad: t-push_back(Vec2(variety + 1.0f, 0.234f)); t-push_back(Vec2(variety, 0.234f)); I'm using the old square texture - that would need adjusting because those margins clip the top of the higher trees. All looking really good here now. Thanks for the pointer. I've committed a change using the reduced UV coordinates, converted all the tree textures back to squares and ensured they have an appropriate spacing at the top. That all looks very good here. No artefacts that I can see, no clipped trees. Job done for now, I would say. Well Done Vivian -- 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
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 11:02 PM, Vivian Meazza wrote: I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. Yup, works nicely here, there's definitely an improvement. I've also modified the predicates for techniques 4 and 9 take that into account I've also fixed the black hat by increasing the bleed margins in treebin.cxx a tad: t-push_back(Vec2(variety + 1.0f, 0.234f)); t-push_back(Vec2(variety, 0.234f)); I'm using the old square texture - that would need adjusting because those margins clip the top of the higher trees. All looking really good here now. Thanks for the pointer. I've committed a change using the reduced UV coordinates, converted all the tree textures back to squares and ensured they have an appropriate spacing at the top. -Stuart -- 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
Re: [Flightgear-devel] Tree issues
Stuart Sent: 14 May 2013 09:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues Hi Vivian, On Sat, May 11, 2013 at 9:57 AM, Vivian Meazza wrote: That works - the hat artefact is gone. If I look very carefully I can see a vertical artefact emanating from the centre top of some trees. I hadn't realised that the high res texture was going to be quite so big. Texture sizes 4096 px are not so well supported. I wonder if you wouldn't be better disabling mipmapping for trees - it seems to be the source of all the problems? In particular, the different grazing angle on the crossing panels means that different mipmaps will be used. I can't disable mipmapping AFAIK, but I spent some time looking at the effects source code and found an undocumented (well, not in README.effects) option to control how the mipmaps are generated for each of the RGB and alpha channels.* So, it would appear that I can generate a mipmap where the alpha value is taken as the minimum of the surrounding pixels while the RGB values are created normally. I need to experiment some more with it later in the week, but I may have found a way to use a more square texture without artifacts. It should also resolve the artifact you mention above. In passing I noticed that both your and some of Thorsten's screenshots show a nasty black outline around some of the trees. I don't see that myself except, but I've also got a fix for that issue. As mentioned on the forum, the problem is that the completely transparent pixels have an RGB value of 0,0,0, so mipmaps and interpolations cause this to bleed into the surrounding edges. I'm rather surprised that you can't see the black outline around the trees. It's around all of them, but is more or less visible according to the range and angle of incidence. It is also the cause of the spike arising from the centre of the trees. The proximate cause of the black outline is alpha-to-coveragetrue/alpha-to-coverage. Commenting out techniques 4 and 9 in the tree effect removes all black artefacts. While alpha-to-coverage is intended for dense foliage or grass, I'm not sure that it is appropriate for our trees as presently drawn and textured. I think you are right to try to go back to the square texture. I hope that you can find a fix for this - I know how difficult it is to fix a bug that you can't yourself see. In the meantime should we consider reverting to the previous scheme in fgdata while you come up with a fix? Here. I've adjusted the bleed margins and commented out the relevant techniques, which produces nice trees. HTH Vivian -- 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
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 8:58 AM, Vivian Meazza wrote: I'm rather surprised that you can't see the black outline around the trees. It's around all of them, but is more or less visible according to the range and angle of incidence. It is also the cause of the spike arising from the centre of the trees. The proximate cause of the black outline is alpha-to-coveragetrue/alpha-to-coverage. Commenting out techniques 4 and 9 in the tree effect removes all black artefacts. There's a bug in the predicate for technique 4. It should only be enabled if you have ARB_multisample, but is incorrectly being enabled if you have shader language 2. I've got a fix for this that I've still to push. However, I think this issue predates my recent tree changes, though they may have exacerbated them. Were you seeing black borders around the trees before I started messing around with them recently? My system supports ARB_multisample, and IMO it provides quite a good effect at normal tree viewing distances. I'm slightly surprised that Thorsten's new system doesn't support this, as evidenced from his screenshots. Interestingly, when I disable technique 4, I start seeing the black outlines. Evidently there some very GPU-specific things going on here. On the plus side, I can at least reproduce the issue! I _do_ have a good fix for the black outlines in general, and I've modified the current textures to use it. I just need to push it - hopefully tonight. While alpha-to-coverage is intended for dense foliage or grass, I'm not sure that it is appropriate for our trees as presently drawn and textured. I think you are right to try to go back to the square texture. I hope that you can find a fix for this - Unfortunately modifying the mipmap didn't help. Partially disabling mipmaps by setting nearest meant that trees in the medium-far distance look very pixelated and artificial, and I've been unable to get the mipmap alpha channel to work. know how difficult it is to fix a bug that you can't yourself see. In the meantime should we consider reverting to the previous scheme in fgdata while you come up with a fix? Here. I've adjusted the bleed margins and commented out the relevant techniques, which produces nice trees. Let me check in the stuff I've done so far once I run a couple more tests this evening. That should fix the issues you are seeing. However, that still leaves us with very long, thin, textures as I can't see a way to go back to the square textures without causing the black hats. If we want to stay within a total texture size of 4096, the long, thin texture limits us to a maximum individual tree texture of 128x256, as there are now 32 textures in a typical sheet (8 trees, each in summer, summer+snow, winter, winter+snow variants). I think that a 128x256 texture for an individual tree isn't quite enough. While we don't need to go bird-spotting, it's not unreasonable to expect the tree to look good if it fills the screen. So, I think we have the following options: 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. 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. 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. 4) Accept the limitation of 128x256 individual tree textures. Let me know what you think. -Stuart -- 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
Re: [Flightgear-devel] Tree issues
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
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 10:28 AM, Renk Thorsten wrote: 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). Someone pointed out to me off-list that there are other control properties for multisampling, which I had set in my .fgfsrc file and had forgotten about completely. I've updated the effects file to check for these. I'd highly recommend setting them as I think they improve the visuals on the vegetation significantly: /sim/rendering/multi-sample-buffers=true /sim/rendering/multi-samples=2 I've just checked in something that should fix both issues, along with .xcf source files for the existing trees that shows how they should be created, and a little perl script to generate .dds and low resolution .pngs from a source .png file. I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. -Stuart -- 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
Re: [Flightgear-devel] Tree issues
: Stuart Sent: 16 May 2013 22:46 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, May 16, 2013 at 10:28 AM, Renk Thorsten wrote: 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). Someone pointed out to me off-list that there are other control properties for multisampling, which I had set in my .fgfsrc file and had forgotten about completely. I've updated the effects file to check for these. I'd highly recommend setting them as I think they improve the visuals on the vegetation significantly: /sim/rendering/multi-sample-buffers=true /sim/rendering/multi-samples=2 I've just checked in something that should fix both issues, along with .xcf source files for the existing trees that shows how they should be created, and a little perl script to generate .dds and low resolution .pngs from a source .png file. I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. Yup, works nicely here, there's definitely an improvement. I've also modified the predicates for techniques 4 and 9 take that into account I've also fixed the black hat by increasing the bleed margins in treebin.cxx a tad: t-push_back(Vec2(variety + 1.0f, 0.234f)); t-push_back(Vec2(variety, 0.234f)); I'm using the old square texture - that would need adjusting because those margins clip the top of the higher trees. All looking really good here now. Vivian -- 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
Re: [Flightgear-devel] Tree issues
Hi Vivian, On Sat, May 11, 2013 at 9:57 AM, Vivian Meazza wrote: That works - the hat artefact is gone. If I look very carefully I can see a vertical artefact emanating from the centre top of some trees. I hadn't realised that the high res texture was going to be quite so big. Texture sizes 4096 px are not so well supported. I wonder if you wouldn't be better disabling mipmapping for trees - it seems to be the source of all the problems? In particular, the different grazing angle on the crossing panels means that different mipmaps will be used. I can't disable mipmapping AFAIK, but I spent some time looking at the effects source code and found an undocumented (well, not in README.effects) option to control how the mipmaps are generated for each of the RGB and alpha channels.* So, it would appear that I can generate a mipmap where the alpha value is taken as the minimum of the surrounding pixels while the RGB values are created normally. I need to experiment some more with it later in the week, but I may have found a way to use a more square texture without artifacts. It should also resolve the artifact you mention above. In passing I noticed that both your and some of Thorsten's screenshots show a nasty black outline around some of the trees. I don't see that myself except, but I've also got a fix for that issue. As mentioned on the forum, the problem is that the completely transparent pixels have an RGB value of 0,0,0, so mipmaps and interpolations cause this to bleed into the surrounding edges. -Stuart * Kudos to Tim Moore for exposing this - who would have thought we could control how the mipmap of a texture is generated on a per-channel basis through XML? :) -- 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
Re: [Flightgear-devel] Tree issues
Stuart -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 10 May 2013 22:50 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Tree issues Stuart Sent: 10 May 2013 20:10 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, May 2, 2013 at 8:48 AM, Vivian Meazza wrote: I can still see that hat on middle distance trees. The effect might be less though - hard to judge. It is certainly no worse. I think it would be worth trying to spread the images out on the texture so that you avoid bleed. I'm pretty sure that is what I'm seeing here. OK, I've pushed a new fix for this that goes back to the old approach of having all textures in a strip, and using clamping to avoid bleeding. You'll need a new simgear and data pull. OK trying that That works - the hat artefact is gone. If I look very carefully I can see a vertical artefact emanating from the centre top of some trees. I hadn't realised that the high res texture was going to be quite so big. Texture sizes 4096 px are not so well supported. I wonder if you wouldn't be better disabling mipmapping for trees - it seems to be the source of all the problems? In particular, the different grazing angle on the crossing panels means that different mipmaps will be used. Vivian -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, May 2, 2013 at 8:48 AM, Vivian Meazza wrote: I can still see that hat on middle distance trees. The effect might be less though - hard to judge. It is certainly no worse. I think it would be worth trying to spread the images out on the texture so that you avoid bleed. I'm pretty sure that is what I'm seeing here. OK, I've pushed a new fix for this that goes back to the old approach of having all textures in a strip, and using clamping to avoid bleeding. You'll need a new simgear and data pull. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart Sent: 10 May 2013 20:10 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, May 2, 2013 at 8:48 AM, Vivian Meazza wrote: I can still see that hat on middle distance trees. The effect might be less though - hard to judge. It is certainly no worse. I think it would be worth trying to spread the images out on the texture so that you avoid bleed. I'm pretty sure that is what I'm seeing here. OK, I've pushed a new fix for this that goes back to the old approach of having all textures in a strip, and using clamping to avoid bleeding. You'll need a new simgear and data pull. OK trying that Vivian -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart, Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, Apr 25, 2013 at 11:50 PM, Vivian Meazza wrote: I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I've just pushed a fix to simgear that reduces the height of the UV mapping by 0.004. Please let me know if this fixes the problem. I expect that some trees will have been slightly trimmed by this. I'll go through the textures and correct them once you and Thorsten confirm the issue is fixed. I part-solved the screenshot issue. Here's a pic of the hats on the middle distance trees: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-015.png You have to be really eagle-eyed to spot them, if you change the viewing angle or zoom in they disappear. Vivian -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
-Original Message- From: Vivian Meazza I part-solved the screenshot issue. Here's a pic of the hats on the middle distance trees: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-015.png You have to be really eagle-eyed to spot them, if you change the viewing angle or zoom in they disappear. Vivian They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Alan Sent: 03 May 2013 20:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues -Original Message- From: Vivian Meazza I part-solved the screenshot issue. Here's a pic of the hats on the middle distance trees: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-015.png You have to be really eagle-eyed to spot them, if you change the viewing angle or zoom in they disappear. Vivian They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. I suppose you will want regional variations to match the stork populations? Ever noticed the bloody great gulls we have winging around the scenery? Well - I suppose it would be doable ... Vivian -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. I suppose you will want regional variations to match the stork populations? Ever noticed the bloody great gulls we have winging around the scenery? Well - I suppose it would be doable ... Vivian - I thought that the storks and gulls were part of the scheme to mark thermals for glider pilots. How did they get into the tree texture code? Alan -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Alan Sent: 03 May 2013 22:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. I suppose you will want regional variations to match the stork populations? Ever noticed the bloody great gulls we have winging around the scenery? Well - I suppose it would be doable ... Vivian - I thought that the storks and gulls were part of the scheme to mark thermals for glider pilots. How did they get into the tree texture code? Birds live in trees - simples. Vivian -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 01 May 2013 23:39 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Tree issues : Stuart Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, Apr 25, 2013 at 11:50 PM, Vivian Meazza wrote: I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I've just pushed a fix to simgear that reduces the height of the UV mapping by 0.004. Please let me know if this fixes the problem. I expect that some trees will have been slightly trimmed by this. I'll go through the textures and correct them once you and Thorsten confirm the issue is fixed. Trying that. I can still see that hat on middle distance trees. The effect might be less though - hard to judge. It is certainly no worse. I think it would be worth trying to spread the images out on the texture so that you avoid bleed. I'm pretty sure that is what I'm seeing here. I would send a screenshot - but that's still stuck here trying to write to the wrong place. Vivian Vivian -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, Apr 25, 2013 at 11:50 PM, Vivian Meazza wrote: I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I've just pushed a fix to simgear that reduces the height of the UV mapping by 0.004. Please let me know if this fixes the problem. I expect that some trees will have been slightly trimmed by this. I'll go through the textures and correct them once you and Thorsten confirm the issue is fixed. Thanks for your patience. -Stuart -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
: Stuart Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues On Thu, Apr 25, 2013 at 11:50 PM, Vivian Meazza wrote: I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I've just pushed a fix to simgear that reduces the height of the UV mapping by 0.004. Please let me know if this fixes the problem. I expect that some trees will have been slightly trimmed by this. I'll go through the textures and correct them once you and Thorsten confirm the issue is fixed. Trying that. Vivian -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
However, one reason I didn't spend more time on it was that it didn't seem particularly useful from a sim perspective. If found that to see the effect at reason (30kt) winds you either need to be sitting on the ground or at quite low altitude when your attention is elsewhere. I think you would see it quite well with a glider when ridge-riding - you're moving comparatively slow, you're close to the ground and there is strong wind. Also, helicopter pilots would probably appreciate good terrain close-up scenes in general - nowadays I quite often take a heli to some mountaintop and back to the airports, just because it's so nice to explore the terrain. In a more general sense, I find it an interesting avenue to make FG more interesting for a user community outside flight as well. For instance: Here http://www.flightgear.org/forums/viewtopic.php?f=19t=19626 is someone using Unity3D to walk through hires terrain with the skybox showing FG-rendered terrain and weather to the horizon. What if this were directly running in FG (the terrain resolution we can get is quite competitive) - so maybe we could eventually have a mode of a walker going out of the aircraft and exploring the terrain a bit. Whenever I land in L'Alpe d'Huez, I would like to go and have a virtual cup of coffee before heading back... One could start in a briefing room in the carrier and walk to the aircraft... You name it. Here is Chris driving through virtual Innsbruck with a car: http://www.flightgear.org/forums/viewtopic.php?f=19t=19294start=60#p182039 apparently it's now good enough that this starts getting exciting in its own right. Do we perhaps get more of this? Just to be able to deliver an interesting scene from the ground might open FG up a bit more along these lines, and maybe draw some modellers in which contribute to the scene. Then there is the marketing argument - seeing the wind move trees and grass is cool - and we get often compared to e.g. Outerra in terms of scenes, so why not counter with some cool effects of our own? Reads well on a 'new features' list of 3.0... In practical terms, as you indicated, wind motion isn't excessively expensive - usually it's down to a few trigonometric function and some basic arithmetics, all of which runs very fast as compared to, say, getting a single noise frequency or computing an environment-map reflection. So while it's not immediately relevant for flight, I still think it has some reasonable gain for pain ratio, especially since we can implement it optional by checkbox. However bear in mind that the same constants would be used for both oaks and conifers, which I'd expect to move different amounts. You're right - same with the motion of grass and shrub... It's quite hard to come up with closeup motion that looks well on both corn and in the desert. We could pass stiffness constants as uniforms if we really like, but I think this would be over the top... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Stuart, this tree movement code is wonderful - how could you possibly not implement this? I've been looking out of the window, timing the movement of trees in our forest, and I think the time constant should rather be 1.7-2.0 and the amplitude about 2.5 times as large - all of which makes it more pronounced. Then I cooked myself a nice tropical storm and went in low level in rain over treetops - very very nice. I think I'll be putting this in at high quality and see if I can't get some wind movement of the hires noise to match the impression... // [top vert only] [time dependent movement] [seed so trees close together move together] position.x = position.x + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindN; position.y = position.y + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindE; Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. Since I see it reliably, I could have a try how I can make it go away - I think I understand how the tree shader works well enough... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Fri, Apr 26, 2013 at 7:28 AM, Renk Thorsten wrote: this tree movement code is wonderful - how could you possibly not implement this? Glad you like it. It got stuck under a bunch of other stuff and forgotten about more than anything else. However, one reason I didn't spend more time on it was that it didn't seem particularly useful from a sim perspective. If found that to see the effect at reason (30kt) winds you either need to be sitting on the ground or at quite low altitude when your attention is elsewhere. Also, the only time I recall seeing trees moving when flying myself was during a circuit to land at the end of a cross-country flight when the wind had picked up a lot and we wanted to get on the ground ASAP. On this particular leg I was doing comms/nav so had a bit of time to look around. The pilot had the bar in a death-grip and was concentrating very hard on keeping us right-side up, and I'm pretty sure he didn't notice any tree movements :) That said, I'm very happy for this to be added. it is quite a neat effect. I've been looking out of the window, timing the movement of trees in our forest, and I think the time constant should rather be 1.7-2.0 and the amplitude about 2.5 times as large - all of which makes it more pronounced. Then I cooked myself a nice tropical storm and went in low level in rain over treetops - very very nice. The constants were just guesses based on an evenings work with no direct observation of reality. However bear in mind that the same constants would be used for both oaks and conifers, which I'd expect to move different amounts. I think I'll be putting this in at high quality and see if I can't get some wind movement of the hires noise to match the impression... I look forward to it. Since I see it reliably, I could have a try how I can make it go away - I think I understand how the tree shader works well enough... Someone contacted me off-list to mention that this is a fairly well known problem and that shrinking the UV mapping slightly (which I'll need to do in the C-code) and ensuring a nice transparent border around all the trees is the normal way to address this. So, I don't think there's anything you or Vivian need to do here. I just need to spend an hour or so adjusting all the textures. I'll also write some better documentation on creating tree textures so scenery modelers can created them right first time. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Curt, There is a proposal to go to higher resolution trees in the near future - Thomas Albrecht has said he will be working on that in the coming year: http://www.flightgear.org/forums/viewtopic.php?f=5 http://www.flightgear.org/forums/viewtopic.php?f=5t=19265start=15#p179241 t=19265start=15#p179241 It might be opportune to rationalise our tree texture structures to take that into account. Vivian From: Curtis Olson [mailto:curtol...@flightgear.org] Sent: 26 April 2013 01:27 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues Vivian, Your description makes sense in conjunction with a mipmapping issue. Think about how mipmapping works. The default mipmap generation algorithm creates the 1/2 size image by averaging each 2x2 block of pixels in the higher level down to 1 pixel in the next level. Then repeat, generating the 1/4 size image from the 1/2 size image. You can see that at smaller image sizes, each pixel will draw information from a wide block of pixels out of the original so there can be a lot of bleeding across. This also impacts alpha levels so transparency is another one that doesn't usually mipmap as you'd expect/wish. Note to people who hadn't noticed this before -- the requirement that texture sizes be powers of two allows the mipmapping level creating scheme to be well defined, and if your texture dimensions aren't an even power of two, they are probably getting scaled to the next size down under the hood when they are loaded by OSG. I'm not sure what to do about the tree problem though -- it might help to divide up the internal image into power of 2 chunks, go 4 trees across the texture rather than 5 (just for example.) That might split down further before producing artifacts if we aren't already doing that. (?) I've heard graphics guru's speak of using other algorithms to generate the mip map levels, or even manually creating them. In some cases I think you need to consider this sort of thing even though it's a pain and blows up the size of the distributed texture if we need to also include the pregenerated mipmap levels. Curt. On Thu, Apr 25, 2013 at 5:50 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Stuart On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I would give you some screenshots - but that's broken here. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http
Re: [Flightgear-devel] Tree issues
On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
When I've seen the bits of pixels on the very edges of the transparent tree areas it has sure looked like a texture wrapping issue to me. This is a flag you can turn on/off at least at the low level of opengl and I'm sure OSG would expose this. Basically the bits at the very top of the tree probably line up nicely with the bits at the bottom. You want this when you are tiling textures and mipmapping together to avoid seeing the seams, but with billboard textures you probably want to turn this off, and it especially stands out with transparent textures. Regards, Curt. On Thu, Apr 25, 2013 at 3:29 PM, Stuart Buchanan stuar...@gmail.com wrote: On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Curt, On Thu, Apr 25, 2013 at 9:42 PM, Curtis Olson wrote: When I've seen the bits of pixels on the very edges of the transparent tree areas it has sure looked like a texture wrapping issue to me. This is a flag you can turn on/off at least at the low level of opengl and I'm sure OSG would expose this. I think you might be thinking of the UV clamping function? Unfortunately the UV coordinates are something like (0,0), (0.128, 0.0), (0.128, 0.25), (0.0, 0.25) and it's that top edge at y=0.25 which is the problem. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I would give you some screenshots - but that's broken here. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Vivian, Your description makes sense in conjunction with a mipmapping issue. Think about how mipmapping works. The default mipmap generation algorithm creates the 1/2 size image by averaging each 2x2 block of pixels in the higher level down to 1 pixel in the next level. Then repeat, generating the 1/4 size image from the 1/2 size image. You can see that at smaller image sizes, each pixel will draw information from a wide block of pixels out of the original so there can be a lot of bleeding across. This also impacts alpha levels so transparency is another one that doesn't usually mipmap as you'd expect/wish. Note to people who hadn't noticed this before -- the requirement that texture sizes be powers of two allows the mipmapping level creating scheme to be well defined, and if your texture dimensions aren't an even power of two, they are probably getting scaled to the next size down under the hood when they are loaded by OSG. I'm not sure what to do about the tree problem though -- it might help to divide up the internal image into power of 2 chunks, go 4 trees across the texture rather than 5 (just for example.) That might split down further before producing artifacts if we aren't already doing that. (?) I've heard graphics guru's speak of using other algorithms to generate the mip map levels, or even manually creating them. In some cases I think you need to consider this sort of thing even though it's a pain and blows up the size of the distributed texture if we need to also include the pregenerated mipmap levels. Curt. On Thu, Apr 25, 2013 at 5:50 PM, Vivian Meazza vivian.mea...@lineone.netwrote: Stuart On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I would give you some screenshots - but that's broken here. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt!
Re: [Flightgear-devel] Tree issues
On Tue, Apr 23, 2013 at 12:38 PM, Renk Thorsten wrote: Oh, do you still have that somewhere? I would love to play with this implemented in an optional high-quality tree shader - I could probably also add some grass movement by translating the grain texture or the hires noise with time into the wind direction... Fortunately I still have the vertex shader stashed away, but I've lost the effect file. I added additional uniforms to tree.vert: uniform float osg_SimulationTime, WindE, WindN; WindE and WindN are almost certainly /environment/wind-from-[east|north]-fps I think osg_SimulationTime is built in. The actual code to do the translations is this shear code, placed between the rotation and placement in the correct location: // Rotation of the generic quad to specific one for the tree. position.xy = vec2(dot(position.xy, vec2(cr, sr)), dot(position.xy, vec2(-sr, cr))); // Shear by wind. Note that this only applies to the top vertices // [top vert only] [time dependent movement] [seed so trees close together move together] position.x = position.x + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindN; position.y = position.y + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindE; // Move to correct location (stored in gl_Color) position = position + gl_Color.xyz; -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On 23 Apr 2013, at 07:22, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Stuart, is it possible to pass somehow the info what trees are deciduous? I've done some testing, and I can selectively pick 'green' hue in the shader and color-rotate these pixels to autumn colors, but this is not sensitive enough to key on the difference between leaf and needle - if we had that, we could have autumn colors in addition. Yes. If we put the deciduous trees at the beginning of the texture strip I can pass through information on the fraction of trees that are deciduous as a uniform and you can compare the x texture coordinate against that. At most a couple of lines of c code. Then fall and windy could be combined with particles (?) to simulate wind blown leaves and dynamically painting the foliage part of the texture with alpha to make leaves fall off on windy weather..? ;) Kinda special case and maybe not worth the effort but might be quite awesome jaw-dropper on the right moment.. ;-) Yes, let's forget about spending all the framerate for flight and do realistic vegetation - trees and grass should also move in the wind :-) (I like the idea in principle because it's just mad enough to be charming...) Actually, I had this working very nicely a couple of months ago - using a sine function on time multiplied by wind factor to shift the top texture coordinates so the top of the trees move. I even had a nice larger scale effect to produce the sort of wave affect you see across the tree tops However to be visible at normal ranges (500m+) the wind had to be absolutely howling and shifting the tree tops many meters, so it really didn't seem worth the minor computational cost. -Stuart * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Actually, I had this working very nicely a couple of months ago - using a sine function on time multiplied by wind factor to shift the top texture coordinates so the top of the trees move. I even had a nice larger scale effect to produce the sort of wave affect you see across the tree tops However to be visible at normal ranges (500m+) the wind had to be absolutely howling and shifting the tree tops many meters, so it really didn't seem worth the minor computational cost. Oh, do you still have that somewhere? I would love to play with this implemented in an optional high-quality tree shader - I could probably also add some grass movement by translating the grain texture or the hires noise with time into the wind direction... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
