Re: [Flightgear-devel] Improving random trees buildings
Happy new year! Vivian, On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote: The hangs are caused by mipmap generation on the fly by OSG? The hangs are caused by mipmap generation by the driver which happens on forst use of a texture. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. Which is in this case sad I think. If it's easy to fit both needs I think we should. You do not experience any hangs? None that I have seen so far Ok. I have also seen one of the machines at the flightgear booth at the fsweekend which did not show any problems. But Thorstens huge machine really hangs in an unaccaptable way. I would really never tolerate this as a user ... What is the motivation for you to use dds files? It's a better way of storing cubemaps for reflections or other layered images. The built in mipmap OSG algorithm is a bit slow - using dds works around this (for some systems) Ok, granted. Use it for that. What do you gain by not using the usual image files? Dds textures remain in video memory, so we get improved performance when switching textures. We expect that at least some people will see smoother performance when loading scenery textures. I haven't been able to measure any gain, but there are some have reported that they see a subjective improvement. No, this really should not be a difference. Probably this is what I refer to as these hangs. But the reason is not that dds is in video memory and other textures are not. These *are really all* in video memory. There is no difference between dds and png. The driver decides where to put which buffer objects so that it is accessible to the gpu. And depending on the memory pressure on GPU's memory of the whole system driver the driver might page something out or not. So, once you really reach these huge GPU boards memory limits you might see that using compression you start paging less. But our working set is way below. The real reason appears to me like being the initial mipmap computation when allocating a texture in the driver. And an other post of Erik in this thread tells me that we should try to provide a mipmapping method that already runs in the database loader thread so that on initial allocation in the driver the mipmaps are already present. Also according Eriks comment, compression on the fly on the upload path in the driver seems to work without delay. So, for drivers that announce the compresin extension we can still tell the driver to store the textures compressed on the gpu to minimize gpu memory paging. So, still, since it is technically incorrect to provide these s3 patent precompressed textures to a driver that does not announce the apropriate extension and since we are not allowed to code something that deompresses this, I think we should avoid using this compression for all the provided models/textures. I think of a warning that is issued from the image loader in flightgear that detects when these precompressed textures are seen. So even people using drivers that just offer this extension have a chance to see that the provided textures will not work for others. The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu. Seems to work here - I have tried --prop:sim/rendering/texture-compression=dxt5 I hope that is the right syntax - no warning from fg anyway. I don't see any problems with running the F16 using that. I might be entirely wrong of course. Yes, that is thought like that. But since you do not see the hangs in any configuration you can just sit down and watch us testing :) Thanks anyway! Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Am Freitag, den 30.12.2011, 00:09 +0100 schrieb Csaba Halász: I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). As far as i know, FXT1 a texture compression from 3DFX was invented to have a patent free alternative to S3TC. But the Wikipedia article claims, that some parts of FXT1 might infringe the S3TC patent. But this isn't the only problem, the main problem is that it is marginally supported by 3d drivers. Which results in the problem that it is practically not usable. But there is an OpenGL Extension for it. See: http://en.wikipedia.org/wiki/FXT1 and http://www.opengl.org/registry/specs/3DFX/texture_compression_FXT1.txt But i want to ask. What hinders us to ship all FlightGear textures as compressed *.dds Files and provide a software tool to uncompress them before FlightGear is launched for users, that don't have a videocard with 3d drivers that support S3TC? Then flightgear should be able to select the appropriate texture files on the fly. Best Regards, Oliver C. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Fri, 2011-12-30 at 00:07 +, Vivian Meazza wrote: The F16 is just excellent here. I get a slight pause on first switching from an internal to external view, but I expect that is the texture loading for the first time. Thereafter it is as near instantaneous as you could wish. Likewise livery changes. Couple of small bugs - a USAF insignia seem to get left behind on the lower wing surface when changing liveries and some errors: Property systems/hook/tailhook-cmd-norm is already defined. Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Some of the textures aren't properly aligned on the RNlAF-J015-demo livery Overall an excellent experience! However, this is perhaps not a totally fair test: I'm running Windows XP on a 128GB SSD, with a Core2 Quad and nVidia GTX 260, so I would expect quick switching etc. Yes but I assume this is with the recent DDS textures. They were put in git because it does seem toe solve the problem. Now we have to figure out what exactly makes them behave better over PNG/rgb textures. Thanks for the bug reports. I also noticed this yesterday when fiddling with the textures :) Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
-Original Message- From: Mathias Fröhlich [mailto:mathias.froehl...@gmx.net] Sent: 29 December 2011 20:04 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Improving random trees buildings Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. Yes - the new textures do contain pre-compressed data. Emilian is the driving force behind the new .dds terrain textures, and some of the features he has used cannot (as I understand it) be back-ported to png textures. So yes, there would be merit in making the dds terrain textures the default, but since we were aware of at least some of the problems this might cause we made it a switchable option. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. The hangs are caused by mipmap generation on the fly by OSG? Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. I would expect that. Of course, dds should improve the situation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. That isn't the only solution - it is not difficult to provide an F16 with png texures and one with dds, allowing the user to select which one is most suitable. Not ideal, but a workaround I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change
Re: [Flightgear-devel] Improving random trees buildings
Stuart On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote: I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg As an update on this, I've now written some code to apply the same technique to the random objects and rotations, so the green channel determines the random vegetation density, the blue channel determines random object (i.e. building) density, and the red channel indicates the rotation. Using the DDS textures, the effects can be quite convincing: http://www.nanjika.co.uk/flightgear/object_mask.jpg Note that these are all random objects - none of the buildings or trees were placed manually. The rotations aren't perfectly aligned with the textures, but it's fairly close. Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Creating the masks is a bit of work, and not something one would want to do if the textures are likely to change. No, there is no intention to replace the materials.xml file with the materials-dds.xml file, at least while there are those systems that cannot use .dds. Equally, we cannot, for obvious reasons, backport all of the new stuff in dds format to png, so over time the two files will drift further apart. There are significant gains in performance and appearance by using dds, so it's worth running both formats in parallel. The current phase of work is largely complete; I think Emilian has some tidying up to do. Apologies for the tardy reply: I replaced one of my HDD with a SSD on Christmas Day - it worked well for 3 hours or so then it all fell apart. The hardware is fine - but I'm still rebuilding all the software from scratch. I expect to have it all back by the end of the weekend. (OK, I'm an optimist.) Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote: Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Hmm, regarding dds. I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that. And in fact this will not happen to the open source drivers before something about 2020 because of patent issues. Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Le 29/12/2011 14:16, Mathias Fröhlich a écrit : Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. this is the same here with fglrx driver, so not a particular driver issue, but may be the mipmap generation? for me as a multiplayer pilot, dds (with pregenerated mipmap) is the way to go, as it provide me (with a luckily dds compliant driver) a better flightgear experience with dds textures (materials and planes): smoother flight, mp planes converted load faster, no more age to pass on external view for the first time or change livery. [...] jano -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Vivian, There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote: Mathias I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. At least the bug where switching from internal view to external view cause a big 'pause' for the F-16. It also effects livery switching for the F-16. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stefan On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. I hear your pain - but as I said - you don't have to use materials-dds.xml - it's not the not the default. Neither do you have to use any shaders - they are switchable. If you still can't run Flightgear - well you know the solution - upgrade your system. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. Stefan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 14:16 +0100, Mathias Fröhlich wrote: Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Good Idea, I will try that. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 12:40 +0100, Mathias Fröhlich wrote: I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. Yes, the dds textures could provide pregenerated mipmaps. I guess that our dds files really do so. Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Thanks Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. You do not experience any hangs? What is the motivation for you to use dds files? What do you gain by not using the usual image files? The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu. Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___
Re: [Flightgear-devel] Improving random trees buildings
2011/12/29 Mathias Fröhlich mathias.froehl...@gmx.net: And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. I agree fully with Mathias on this issue, even though I am using the binary fglrx at the moment. I check the open source one from time to time, however, to see if it has improved enough for my purposes. Incidentally, AMD's favorable open source policy was the reason I switched from nVidia. I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). -- Csaba/Jester -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Erik, On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote: Mathias I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. At least the bug where switching from internal view to external view cause a big 'pause' for the F-16. It also effects livery switching for the F-16. The F16 is just excellent here. I get a slight pause on firest switching from an internal to external view, but I expect that is the testure loading for the first time. Thereafter it is as near instantaneous as you could wish. Likewise livery changes. Couple of small bugs - a USAF insignia seem to get left behind on the lower wing surface when changing liveries and some errors: Property systems/hook/tailhook-cmd-norm is already defined. Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Some of the textures aren't properly aligned on the RNlAF-J015-demo livery Overall an excellent experience! However, this is perhaps not a totally fair test: I'm running Windows XP on a 128GB SSD, with a Core2 Quad and nVidia GTX 260, so I would expect quick switching etc. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Hi, On Tuesday, December 27, 2011 10:49:07 Erik Hofman wrote: Actually for the F-16 I did not switch because of compression but because livery switching is almost instant while the previous textures is took about 10 seconds to switch from internal view to external for the first time. That's too long. Hmm, if precompressed textures help here, may be nvidias driver has problems compressing textures on the fly? Can you try to short circuit SGSceneFeatures::setTextureCompression() to see if this helps for the long hangs? If so we could make the use of thexture compression customizable? I would be very pleased to use another texture format that has the same effect though. Well, I am not sure what is better then. Use precompressed textures that cannot be read from one driver or uncompressed ones having these unacceptable hangs. Both is not acceptable IMO. Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Tue, 2011-12-27 at 09:53 +0100, Mathias Fröhlich wrote: Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... Actually for the F-16 I did not switch because of compression but because livery switching is almost instant while the previous textures is took about 10 seconds to switch from internal view to external for the first time. I would be very pleased to use another texture format that has the same effect though. Erik -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Hi, On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote: Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Hmm, regarding dds. I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that. And in fact this will not happen to the open source drivers before something about 2020 because of patent issues. Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... Thanks Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote: I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg As an update on this, I've now written some code to apply the same technique to the random objects and rotations, so the green channel determines the random vegetation density, the blue channel determines random object (i.e. building) density, and the red channel indicates the rotation. Using the DDS textures, the effects can be quite convincing: http://www.nanjika.co.uk/flightgear/object_mask.jpg Note that these are all random objects - none of the buildings or trees were placed manually. The rotations aren't perfectly aligned with the textures, but it's fairly close. Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Creating the masks is a bit of work, and not something one would want to do if the textures are likely to change. -Stuart -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Am Montag, den 05.12.2011, 11:02 + schrieb Martin Spott: kreuzritter2000 wrote: When we're talking about MSFS and terrain i also want to mention, that their regular grid allowed them to use textures that allowed a seamless crossover on their borders. So with the right textures choosen, the textures matched on the borders. Ah, well, but, as I understand, this would in summary require dozends of different textures just to meet the requirements of simple variations at corner areas, like: Yes, that's the case. FS2004 is shipped with a dozends of textures. But i don't see a big problem with this, because more different textures also allow more variety. Only from a high attitude, a user might see a repitive pattern. | B | A |-- BB | C | A -|-- BB It's exactly like in the game TetraVex. http://en.wikipedia.org/wiki/TetraVex Screenshot example: http://en.wikipedia.org/wiki/File:Tetravex.png One square is one texture, and same numbers mean, that the textures match on their borders. But this doesn't mean that the left texture (let's say number 9) looks the same like the right texture (let's say number 9 too), the're not mirrored, they look different on the 9 fields, but they do match at the borders. From my prspective this approach isn't flexible enough. AFAIK this technique works only with regular grids. Best Regards, Oliver C. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Am Montag, den 05.12.2011, 16:16 + schrieb lists: On Sun, 4 Dec 2011 22:14:18 +, Stuart Buchanan wrote: Rather than using the same texture, we can simply have a separate texture for object type and rotation. It's simple enough to place objects along a linear feature (like a road): http://www.stockill.net/Junk/newscenery/fgfs-screen-008.png (It's some older scenery which didn't actually include the road, but you get the idea). I'd rather we didn't spend too much time adding features to textures which will clash with real data. It won't clash if we get rid of urban textures in the long term. In my opinion the best visual quality can be reached if we give every generic and none generic 3d object a couple of ground textures that match like in the tetravex game screenshot example (see other e-mail) with all the other generic 3d object textures by selecting the right one. The good thing about this approach would be, that you could really go into detail and you would have a natual visual representation where everything harmonizes. Though, this approach would need a lot of processing power. I took a slightly different approach - a different material for the rough: http://www.stockill.net/Junk/newscenery/fgfs-screen-023.png http://www.stockill.net/Junk/newscenery/fgfs-screen-024.png http://www.stockill.net/Junk/newscenery/fgfs-screen-029.png It works for parks too: http://www.stockill.net/Junk/newscenery/fgfs-screen-020.png Your approach might met real data, but it looks unnatural. If we ever want to have a natural looking visual quality, then this can be only reached by an approach with matching textures on todays hardware. You're approach might look natural in 200 years, when we have the right hardware and petabytes of real data for it, but not now and not in 20 years. That's the problem i see here. Best Regards, Oliver C. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Am Sonntag, den 04.12.2011, 22:14 + schrieb Stuart Buchanan: On Sun, Dec 4, 2011 at 1:08 PM, kreuzritter2000wrote: We could do the same, but i don't know, if this works with an irregular grid, flighgear uses. This is a very interesting idea indeed. I hadn't realized that is how they had done it in MSFS. Rather than using the same texture, we can simply have a separate texture for object type and rotation. I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg This looks great! When we're talking about MSFS and terrain i also want to mention, that their regular grid allowed them to use textures that allowed a seamless crossover on their borders. So with the right textures choosen, the textures matched on the borders. This solution might be rather difficult or is impossible with an irregular grid, but the borders at the textures and their not seamless crossover are one show stopper that makes the visual qualitiy in FlightGear not as that good as it could be. I wonder how X-Plane solved that, they're using an irregular grid too, but the texture borders look rather seamless which makes the visual quality very realistic. http://www.x-plane.com/wp/wp-content/gallery/more-v10-landscapes/kc-10_13.jpg Best Regards, Oliver C. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Mon, 2011-12-05 at 10:55 +0100, kreuzritter2000 wrote: I wonder how X-Plane solved that, they're using an irregular grid too, but the texture borders look rather seamless which makes the visual quality very realistic. http://www.x-plane.com/wp/wp-content/gallery/more-v10-landscapes/kc-10_13.jpg To me it looks like there is a (small) strip of vertices between adjacent areas. This strip uses interpolation and multi-texturing to get a transition area. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
kreuzritter2000 wrote: When we're talking about MSFS and terrain i also want to mention, that their regular grid allowed them to use textures that allowed a seamless crossover on their borders. So with the right textures choosen, the textures matched on the borders. Ah, well, but, as I understand, this would in summary require dozends of different textures just to meet the requirements of simple variations at corner areas, like: | B | A |-- BB | C | A -|-- BB From my prspective this approach isn't flexible enough. http://www.x-plane.com/wp/wp-content/gallery/more-v10-landscapes/kc-10_13.jpg I think they're just multi-texturing the transition area between two adjacent land cover classes - which isn't _that_ simple either, because you'll have to define carefully which land cover type pairings may feature a transition area and which ones don't. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Sun, 4 Dec 2011 22:14:18 +, Stuart Buchanan wrote: Rather than using the same texture, we can simply have a separate texture for object type and rotation. It's simple enough to place objects along a linear feature (like a road): http://www.stockill.net/Junk/newscenery/fgfs-screen-008.png (It's some older scenery which didn't actually include the road, but you get the idea). I'd rather we didn't spend too much time adding features to textures which will clash with real data. I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg (For those interested, the golf course is Gullane, outside of Edinburgh from some scenery I've been generating recently using gshhs for the coastline as the CLC shapefiles) I took a slightly different approach - a different material for the rough: http://www.stockill.net/Junk/newscenery/fgfs-screen-023.png http://www.stockill.net/Junk/newscenery/fgfs-screen-024.png http://www.stockill.net/Junk/newscenery/fgfs-screen-029.png It works for parks too: http://www.stockill.net/Junk/newscenery/fgfs-screen-020.png If there are any crazy people who've mapped golf courses in more detail (bunkers, green, etc) then we could add even more detail - anyone want to model a golf cart - with walk mode you could have a quick round before a flight ;-) -- Jon Stockill li...@stockill.net -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
I think X-Plane is using texture splatting. Please read this blog post from Ben Supnik (X-Plane scenery developer) that I read a few years ago: http://www.x-plane.com/blog/2008/12/dealing-with-repetition/ It deals not exactly with the smooth transition problem, but this technique could be applied to FlightGear terrain, too. for more information on texture splatting: http://en.wikipedia.org/wiki/Texture_splatting cheers, Robert -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Am Mittwoch, den 30.11.2011, 14:07 + schrieb Stuart Buchanan: Hi All, Having seen some recent screenshots from X-Plane 10, I've been thinking about ways to improve our random scenery, in particular buildings. At present, we have random building scattered over the scenery, based on .ac models, plus the Urban shader. The former are limited in that performance suffers significantly as density increases, and there is little control over their placement. At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. And Vadym Kukhtin wrote: Can you use low-bit gray (or index) mask, to indicate not only placed or not, but also rotate angle? Then it will be possible to align buildings along main streets. AFAIK Microsoft used the textures itself to put information where to put an 3d object on them. They used a special color key, AFAIK it was white. And on all these white points an 3d object was placed. But i don't know if the use of a regular polygon grid played a role too. It may be possible, that the regular grid allowed a fast and easy way to place the objects on the textures according to the color key information that was in the texture. We could do the same, but i don't know, if this works with an irregular grid, flighgear uses. We could specify a special color key to put an object on a texture. Because the Texture is in RGB color, this key could be for example 255, 255, 255. If we add a lot more color keys, for example color key regions like 251-255, 251-255, 251-255 we could also put additional information like the rotating angle in the color key or the type of the object. For example: 255, 255, 255 could stand for an angle of 0 degrees. 254, 255, 255 for 45 degrees 255, 254, 255 for 90 degrees 255, 255, 254 for 135 degrees 254, 254, 255 for 180 degrees 254, 255, 254 for 225 degrees 255, 254, 254 for 270 degress 254, 254, 254 for 314 degrees Using values from 253 to 255 allows additional information like object type or street lights etc. This is only one point on the texture, using groups of points allow a lot more information. For example we could use one point to place the information about rotating angle and position of the object and another point directly next to the first one for object type informations. A special rule like the upper left point of a group of color key points in a texture is always the one that holds the position and angle clarifies which point of a group of special color key points is to be taken for the position and angle. If the 3d object is big enough, which should be the case in the most cases, the user won't see these points on the textures when flying over them. It should be easy to use at least a group of 1-4 points for object informations. Of course we have to make sure that these color keys won't be used as a color of the texture. And the textures need to be edited by hand first to place the object information into them. But i don't see a big problem with that. A 24 bit RGB allows enough color informations for a texture, so we could easily use some special color keys to place object informations into them. The only problem could be texture compression and the fact, that the grid is irregular. I don't know if it is possible to place a 3d object on an texture according to its color value of one point in a texture. Best Regards, Oliver C. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On 30 Nov 2011, at 14:07, Stuart Buchanan wrote: I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. It may be that my system is unique in that one is cheap and the other expensive, and this is all pointless! Definitely sounds good to me, a few comments on the details though, based on some similar ideas I once looked at, and playing with 'massing models' in Google Earth: - I don't think you need to worry about a cuboid per floor - only define some (irregular) trapezoids for the floor plans, and simply extrude them to a height - with suitable random generation of the heights. - partly due to my limited vertex shader knowledge, I was considering doing this with simple meshes (and a single texture for a given region of buildings) - if the geometry is truly fixed, it should sit in a VBO very efficiently, and with no alpha blending or similar, I'd be surprised if the geometry is the bottle-neck. (I was imagining a mesh per scenery tile, for example) - if you want to get really fancy, you could set building heights based on the area of the land-cover polygon; small or suburban area = wider spacing, lower heights, huge urban polygon = taller boxes, narrower spacing James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
2011/11/30 Stuart Buchanan stuar...@gmail.com: At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. Can you use low-bit gray (or index) mask, to indicate not only placed or not, but also rotate angle? Then it will be possible to align buildings along main streets. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. Thats will be awesome. -- --- WBR, Vadym. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, Dec 1, 2011 at 8:07 AM, James Turner wrote: - I don't think you need to worry about a cuboid per floor - only define some (irregular) trapezoids for the floor plans, and simply extrude them to a height - with suitable random generation of the heights. I was thinking I'd need a cuboid per floor so I can use textures efficiently. I'm thinking of a texture file that contains a number of horizontal texture strips, each representing a floors-worth of walls for a different building. I think I need a cuboid per floor so they can repeat on the x-axis but use the same texture strip for each floor. Otherwise I need a separate texture file for each different building type, which I understand is particularly inefficient. - partly due to my limited vertex shader knowledge, I was considering doing this with simple meshes (and a single texture for a given region of buildings) - if the geometry is truly fixed, it should sit in a VBO very efficiently, and with no alpha blending or similar, I'd be surprised if the geometry is the bottle-neck. (I was imagining a mesh per scenery tile, for example) That's an interesting idea. I was planning something more complicated, with each building being considered separately purely because I could re-use a lot of the code/knowledge I already had from the trees. A single mesh per tile might be a bit much (I think there's a limit on the number of vertices per object?), but certainly a mesh per triangle should work and might in fact be simpler to implement. - if you want to get really fancy, you could set building heights based on the area of the land-cover polygon; small or suburban area = wider spacing, lower heights, huge urban polygon = taller boxes, narrower spacing That's my intention. I'm anticipating defining sets of buildings with heights, widths, textures and spacings on a per-material basis, comparable to the existing random vegetation. On Thu, Dec 1, 2011 at 8:46 AM, Vadym Kukhtin wrote: At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. Can you use low-bit gray (or index) mask, to indicate not only placed or not, but also rotate angle? Then it will be possible to align buildings along main streets. Excellent idea! -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stuart Hi All, Having seen some recent screenshots from X-Plane 10, I've been thinking about ways to improve our random scenery, in particular buildings. At present, we have random building scattered over the scenery, based on .ac models, plus the Urban shader. The former are limited in that performance suffers significantly as density increases, and there is little control over their placement. The Urban shader provides an good impression of a complex city-scape, but the sides of the buildings are rather gray, and the visuals suffer at low viewing angles. It also has a significant performance impact. I'm wondering whether there is any mileage in using a variant on the scheme we use for random vegetation to create a cityscape. As you may be aware, the random vetegation uses a small number of geomerties instantiated all over the terrain, and uses a vertex shader (which is much cheaper than a fragment or geometry shader) to provide height, width and texture information. Of course, there's no point at all in doing this unless it provides better performance than the urban shader. The Default materials.xml tree density is 4000m^2, or a tree per 63mx63m square (ish). The trees themselves have similar geometric complexity to a cuboid (same number of vertices), but buildings don't generally have any alpha blending requirements. So to a first level of approximation, we should be able to populate the urban area with textured cubeoids at the same density as the trees for a similar cost performance-wise. To provide more interesting buildings, I'm anticipating using a cuboid per floor, plus a modified cuboid for the roof, so probably ~ 4x the complexity of trees geometrically for a 3 storey building. Obviously there would be XML controls in materials.xml (or a linked XML file) for the length, width, number of floors, textures, and roof. At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. It may be that my system is unique in that one is cheap and the other expensive, and this is all pointless! Sounds a good idea - I hate the random objects - they are always the wrong style/size and in the wrong place. Just do it - we'll make it switchable at runtime. Users can make up their own minds (or as it has been said of users: what they are pleased to call their minds). Looking forward to testing it, Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
