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] osm2city.py
On Mon, May 13, 2013 at 9:29 PM, Thomas Albrecht wrote: If I had a limited number of complex (as in 8 vertices per model) shared models, and place a total of 5 instances in a scene, could this be made to occupy significantly less RAM than 5 individual models? In theory yes - that's what the SHARED verb on the .stg file is for. The idea was to only have one model loaded, and then place it multiple times in the scenegraph. However, IIRC there was an issue with memory management in OSG which meant that when a tile containing SHARED entries was unloaded, it caused FG to churn for a while updating various pointer counters. I don't think this was ever resolved, so currently each SHARED instance is loaded individually. While this approach would reduce RAM usage, it would be at the expense of frame-rate, as the 5 models would still each require OSG state change. Sadly, nothing is for free :(. -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
[Flightgear-devel] Crash in latest FGFS even with default options (no .fgfsrc or any call parameters)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello James, hello Thomas, as you may know I'm running latest master of SG/FG and OSG (3.1.7 now) and I got a crash on bootstrap with no .fgfsrc and no call parameters: http://pastie.org/7916877 I kindly ask you to investigate this bug because I have found you both in git log. :) Best regards, Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlGVFW4ACgkQty+BhcbHvXhnhgCgjypF0m4nU4cM3kAZrR7dgXFC IFoAn0WhW9x5NZgNE9XvK9xXRD6FDxrc =v9oh -END PGP SIGNATURE- -- 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] Crash in latest FGFS even with default options (no .fgfsrc or any call parameters)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Roland, Am 2013-05-16 19:20, schrieb Roland Haeder: as you may know I'm running latest master of SG/FG and OSG (3.1.7 now) and I got a crash on bootstrap with no .fgfsrc and no call parameters: http://pastie.org/7916877 I kindly ask you to investigate this bug because I have found you both in git log. :) Can you identify the last working commits? I have pushed something which should fix the problem, although I do not really know how it can happen in the first place. The reason for the crash is that you somehow receive a key event (for you left alt key) without a graphics context set. I have now also installed the latest (svn) OpenSceneGraph but was not able to reproduce this problem. What exact OS are you using? Tom - -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org - Student of Computer Science @ Graz University of Technology - --- Austria -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGVTBEACgkQpBPMEK46x5frEgCfaWQCtxB9CdtKZhpDx41WHJOk 4roAoIzG1TACiTVpOm42e167t5E1WYHn =p3Uc -END PGP SIGNATURE- -- 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] Linux nightly builds
Are these the current ones... Strange problem is I think its outta sync with deb http://ppa.launchpad.net/saiarcot895/flightgear-edge/ubuntu raring main deb-src http://ppa.launchpad.net/saiarcot895/flightgear-edge/ubuntu raring main and I get.. mash@z:~$ /usr/games/fgfs --aircraft=777-200ER --fg-root=/usr/share/games/flightgear Base package check failed: Version 2.10.0 found at: /usr/share/games/flightgear Version 2.11.0 is required. Please upgrade/downgrade base package and set the path to your fgdata with --fg-root=path_to_your_fgdata Pete On Thu, Apr 18, 2013 at 12:57 AM, Saikrishna Arcot saiarcot...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm working in a local version of Jenkins to set up a nightly build for Linux Ubuntu and allow them to be uploaded to a PPA, so that non-developers can test the nightly builds. Since Launchpad doesn't allow pre-built debs, I'm planning on doing a test build to make sure it compiles in the first place and then uploading the source code to Launchpad for it to compile. Eventually, I'm hoping that the official releases can be prepared and uploaded to Launchpad from Jenkins itself. - -- Saikrishna Arcot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRbzbfAAoJEDg9nXyl50AFaEEP/RAqcJPDajBjMYGqxuy0hmbc WozarvSYyK/3C0FicOGVmHECkTPcmqV0a74HOQWMOHvQuhU7P3Ku+2ILl/J1WFrJ tbAwjzOEdnCmxa+IgDMwpM2yzeTnDZiQfrUYbAKhopsE/+s8XkyiLgIJ99fy4sTW q62kMEyW2FklhSWQm6uW6vs42xITOxeW0W1XoG95+qYh/XTUEtqxoBSktiMQMbGK x0/eqHoMDK7zOTWm/1Hf2pxOOm69f63hHg5PZRi4UlpYtCNxhMJuI2qNX2Jlk9+7 4qeWvyHXWp/SDtlSvcSd+o0XnEPaLcJGdBg6wjGN3DLYOeraB33EKWmuuV4crC5S OMWk+nzgFckOw717uaPdP0UxB116k+EJ8DfADE09/borTv+WS3ZXwgjBMNIGnMc3 S8TcSU8Z4pIn5a5fo3DZtaf8Wf+2Om5GW13cpSg0LeEoghE31mtIvH6RV3Cu710x YW9RglbUgeIKeWt5CFp/iEKwfFEzAY6W2eaAuuJzJxjpaAltsBzroUzej6lWXSeg doVEw+PrYt4Ej46TIIXxt2SZV2J8NFAvleZJYJvprQpvqAOZwzBc57i3ti0V13Sp /V3p6KO0LyNjrxnZBjJgbhGWKh9qjxOKYhcrkEW60yOHj+/rrNq961oW390Sd3uq OpUb0zWBz5UMRshdEq+k =qKP/ -END PGP SIGNATURE- -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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
