[Flightgear-devel] Random Buildings
Hi All, A while back I initiated a discussion about improving our random buildings, and got lots of very useful feedback and suggestions. The first part of this (masking of random object and vegetation placement to match the underlying terrain texture) has been in git for some time. I have finally got around to implementing the second part - generating (efficient) random buildings. Before and after screenshots: Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg After - http://www.nanjika.co.uk/flightgear/buildings.jpg At a functional level, there are three different size of buildings (small, medium, large), with slightly different constraints (small and medium buildings are never deeper than they are wide, small buildings may have pitched roofs). Various parameters can be set in the materials.xml file, such as the proportion of each building size, the texture file (which is shared across all buildings), and the range of sizes of each building. The actual buildings are then generated by FG itself directly as OSG primitives. Obviously, this would be pointless if frame-rates were hit to the same extent as they are with a similar number of normal models. The good news is that on my system there is _no_ fps drop from the random buildings. I get the same frame-rate whether or not the random buildings are generated or not. The same applies whether or not I'm running with Rembrandt. Of particular note - I get significantly better frame-rates with this rather than the urban shader. For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU - all the buildings at the leaf of the quadtree are part of the same geometry, so the GPU can churn through it very quickly without having to change state. There are still some bugs to be worked out before this can be pushed to git, but I'm hoping to get it checked in over the weekend. If someone is interested in spending some time creating a better default texture, please get in touch. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Thu, May 3, 2012 at 7:29 AM, Renk Thorsten wrote: Since the random buildings are now in the effect system, I've run a few tests with the lightfield shaders yesterday. The good news is: It works just fine. The bad news is: It eats performance like mad. For comparison: Without lightfield shading, I had a test case involving a large urban area (Las Vegas in this case) in which I had 30 fps given the weather without any buildings. Populating the city with random buildings at density 1.6 reduced me to 28 fps. Using the urban shader effect (quality 3 I think) instead gave me 25 fps. I think this is more or less what Stuart is seeing as well (?). On my system I get the following just SE of KSFO facing the city at ~155 degrees): - No buildings: 27fps - Random buildings (density 1.6 though it doesn't make any difference on my system): 27fps - Urban Shader (Quality 2): 22fps Skydome switched on (apologies if this != Lighfield): - Random buildings: 20fps - No buildings: 21fps (Note that I'm see a lot of variability when I start changing values in the Rendering Options menu and then reloading the tiles. On startup with Random Buildings switched on, I get 35fps) So, it looks like there's a lot of variability in performance impact depending on people's specific systems. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
The initial commit of the random buildings is now available in git. To enable this, you'll need to set /sim/rendiner/random-buildings=true. This is available through the Rendering Options dialog, and requires the scenery tile to be reloaded to take effect (via the Reload Scenery button on that dialog). A couple of notes: - At present, the building placements add significantly to the scenery generation time - particularly if you start increasing the building density (/sim/rending/building-density). I need to spend some time looking at alternative algorithms for this. - The buildings do not use the Effects system yet. An obvious enhancement would be to add a night-time texture with some emissive properties and use some effect to simulate night illumination of the buildings. - Placement works well against other buildings, landclass edges (though there are sometimes very small overlaps (~1m), but not against custom scenery. - I've modified Effects/urban.eff so that the existing urban shader is disabled when random buildings are enabled. Unfortunately I can't mask the buildings in such a way that they don't collide with the urban shader generated buildings, so they don't work well together. - The texture used for the buildings (Textures/buildings.png) is pretty simplistic. If someone has the time and interest in improving it, they are very welcome - textures aren't my forte. Feedback is welcome as always. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
Since the random buildings are now in the effect system, I've run a few tests with the lightfield shaders yesterday. The good news is: It works just fine. The bad news is: It eats performance like mad. For comparison: Without lightfield shading, I had a test case involving a large urban area (Las Vegas in this case) in which I had 30 fps given the weather without any buildings. Populating the city with random buildings at density 1.6 reduced me to 28 fps. Using the urban shader effect (quality 3 I think) instead gave me 25 fps. I think this is more or less what Stuart is seeing as well (?). With Lightfield shading on, Las Vegas in about the same test case without buildings comes with 20 fps. With random buildings, I'm down to 10 fps even for a density as low as 0.5 (urban shader isn't implemented in the scheme, so no number here). This indicates there's some scaling going on which I don't really understand. The additional amount of vertices thrown in by the buildings doesn't seem to be so large that the dramatic framerate loss could be explained. The two shading strategies seem to scale drastically different, and I have no real idea why. I don't think it's a problem with the random buildings, more something I don't really understand. Maybe I should try to come up with a distinct model shader, putting more work to the fragment part based on the theory that buildings are often more vertices than pixels? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Upcoming Random Buildings changes
Hi All, This is to give a heads up on some changes that I'm planning for Random Buildings for the V3.0 release, and to allow for comments/suggestions/ideas. In 2.12.0 the algorithm for the placement of random buildings is a rather scattergun approach. materials.xml sets a building density (amongst other building attributes) which is used to generate a number of random points on each triangle that makes up the scenery. These random points are checked against a mask to ensure they aren't being placed in the middle of roads, and then rotated to the correct orientation to match the texture (using the red channel of the mask). This broadly works, but the placement is fairly unrealistic: - The mask is quite broad, and some buildings quite large, so they can still stick out into the roads, and generally don't line right up against the street. - The spacing of buildings has to be quite conservative. So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the new world, but the end result should be better. There is an open question of how to handle random object placement, which also use the blue channel of the object mask: - For areas that don't use random buildings, I'm tempted just to leave it as-is for the moment, as it reduces the number of object masks that need to be re-created. - For areas with both random buildings and random objects I'm planning to make groups of objects to specific blue values. So, a blue value of 234 might equate to placing a silo or a farmhouse, while a blue value of 233 might place a church, or tower block. The mapping will be defined in the materials.xml file. Command, questions and offers of help to update some object masks are all welcome :) -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Tue, Apr 24, 2012 at 10:09 PM, Stuart Buchanan wrote: The initial commit of the random buildings is now available in git. One thing I forgot to mention: you need to be running with data/materials/default/materials.xml or data/materials/dds/materials.xml. The data/materials[-dds],xml are obselete and will be removed shortly. -Stuart Hi Stuart Maybe this is the point now to change something in scenery creation process? AFAIK towns are still (?) point features ... maybe this could be switched now to polygon features, using random buildings code later instead of this unique village models ? What do you think about towns and random buildings ? Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Thu, Apr 19, 2012 at 4:39 PM, rickbritto wrote: hello friends, Is possible to separate the random loading by types of buildings? Yes. The materials.xml file allows you to define different parameters for different landlclasses (e.g. Urban, Suburban, Commercial), and as mentioned above I'm adding parameters to control the ratio of the different building types. So a residential zone will have (say) 90% small buildings, and 10% medium, while an Urban zone will have 50% medium and 50% large. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random buildings improvements - phase 2
Hi All, I've just committed a change that adds emissive lighting to the random buildings: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg At present, this only works with rembrandt and the skydome switched off. You'll need generic shaders switched on. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wed, May 23, 2012 at 2:38 PM, Björn Kesten wrote: Would trimming down building variety help? Unfortunately not. Individual buildings aren't instantiations of a small number of objects, as the random vegetation is. Instead, a huge group of buildings are a single OSG object, which limits the OSG overhead and means they are very efficient to render. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote: This is to give a heads up on some changes that I'm planning for Random Buildings for the V3.0 release, and to allow for comments/suggestions/ideas. I've now got the new system broadly working on a private build: http://www.nanjika.co.uk/flightgear/buildings.jpg I've managed to minimize apparent tiling by randomly choosing between building sizes and random objects at each point (subject to dimension restrictions). I need to sort out the random objects which need to be rotated by 90 degrees (see the bottom left where an orange school building goes across the road). As expected, the downside is that creating the object masks takes quite a bit longer. It's taken me about 4 hours to generate the mask used here for the city1.png texture. Generating the buildings at runtime is also a bit slower so I expect to implement the PagedLoD next. -Stuart In 2.12.0 the algorithm for the placement of random buildings is a rather scattergun approach. materials.xml sets a building density (amongst other building attributes) which is used to generate a number of random points on each triangle that makes up the scenery. These random points are checked against a mask to ensure they aren't being placed in the middle of roads, and then rotated to the correct orientation to match the texture (using the red channel of the mask). This broadly works, but the placement is fairly unrealistic: - The mask is quite broad, and some buildings quite large, so they can still stick out into the roads, and generally don't line right up against the street. - The spacing of buildings has to be quite conservative. So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the new world, but the end result should be better. There is an open question of how to handle random object placement, which also use the blue channel of the object mask: - For areas that don't use random buildings, I'm tempted just to leave it as-is for the moment, as it reduces the number of object masks that need to be re-created. - For areas with both random buildings and random objects I'm planning to make groups of objects to specific blue values. So, a blue value of 234 might equate to placing a silo or a farmhouse, while a blue value of 233 might place a church, or tower block. The mapping will be defined in the materials.xml file. Command, questions and offers of help to update some object masks are all welcome :) -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 18, 2012 at 10:30 AM, James Turner wrote: Could you make the density controllable? If the hit is really 'almost zero', I think about double the density in your screenshot would look even better. Yes, the density is controllable in the same way as the random vegetation density (i.e. requires a scenery reload to take effect). However, one of the issues I'm hitting right now is that I have to avoid overlapping buildings by binning buildings that are too close to other buildings. As density increases you get more overlapping, and spend more time binning points, so scenery loading starts taking longer. One of the things I'm looking at before checking this in is making that process more efficient, as well as dealing with non-random objects. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
hello friends, Is possible to separate the random loading by types of buildings? as residential areas with houses,urban areas with Great Buildings,Commercial areas with buildings commercial stores. I separated some models I made in blocks, as shown below, and we could implement them in random loading hugs. Urban Zones http://img6.imageshack.us/img6/5604/urbanzone.png Residential Zones http://img163.imageshack.us/img163/4876/residentialzone.png Commercial Zones http://img137.imageshack.us/img137/886/commercialzone.png All City http://img685.imageshack.us/img685/6752/allcity1.png http://img801.imageshack.us/img801/1292/allcity2.png http://img705.imageshack.us/img705/6917/allcity3.png Enviado pelo @R7 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Mon, Apr 23, 2012 at 1:17 AM, HB-GRAL wrote: Just a small question because I’m currently looking to OSM street data and try to use it for scenery creation ... in your last screenshot of your improvements I still see buildings on streets (not the streets on urban textures, I mean the real roads coming originally from road line shapefiles). Will it be possible not to cover/overlap roads with random buildings, or is this planned anyway and I missed this point? Yes - this is part of the plan. I now have a solution for this, and also avoiding overlaps between buildings and the existing random objects. Unfortunately I don't yet have a solution for the custom objects from the scenery DB. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 10:23:12 Renk Thorsten wrote: Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. We might be generating too many buildings then? The greater Los Angeles area has between 13 and 16 million inhabitants (dependent on what you count). Assuming you haven't changed the visibility range from the startup default of ~16 km yet, checking with satellite images you should get about 1/12 of the greater LA urban area at startup, that means you generate 340k * 12 = 4 M houses in the greater LA area. The average number of people per household in the LA area was about 2.9 in 2006, so we have just populated Greater LA with ~12 million inhabitants - seems okay. Besides being totally off topic, you can't do that direct comparison. First off, our default scenery lacks a lot of detail in the urban area boundaries in that area thus marking a far larger area as being urban - a far larger area on which to generate buildings; second, the generated random buildings are a mixed set of residential and comercial/office buildings, so the math is a bit off there. Here's the catch: That's just assuming that the number of households per house is really 1 - but I think this assumption doesn't hold in dense urban areas, you can easily have 10 parties living in a larger building (even while I was living in Durham, NC we had 14 households in one building - and Durham NC had plenty of space to spare). Assuming for the sake of the argument that we might have on average 5 households per building in a dense urban area, we'd be overestimating the actual population by a factor 4.5. = use less, but somewhat larger buildings. Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. Cheers, * Thorsten Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 25, 2012 at 1:57 PM, James Turner wrote: Emilian suggested I check random vegetation (which generates many more quads), at LOWI with vegetation off/onthe difference is from 50 fps down to 30ish, and quad count goes from 100k to 200k - but nothing like what happens for buildings with draw / GPU time. Interesting to note that vegetation takes the vertex count from 500k to 6 *million*, without anything dying. So I think my card can handle the geometry submission. You need to be slightly careful here, as you're not comparing apples to apples. The random vegetation does very odd things with shaders to bypass the normal pipeline. I think there's a lot more actual structured data in the random buildings. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak fixes for random vegetation and buildings
Hi All, I've just pushed two fixes for possible memory leaks in random vegetation and buildings. One was noticed by valgrind, the other is speculative, to make use of osg::ref_ptrs where possible. At the same time, I've changed the random vegetation so that the normals are bound per-vertex rather than overall. Please let me know if you see any perf or memory impact. I'm hoping that this will reduce the memory occupancy over long flights. Note that the random buildings in particular still have a large memory footprint. These fixes do no address that. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wed, May 23, 2012 at 11:54 AM, Emilian Huminiuc wrote: Besides being totally off topic, you can't do that direct comparison. I don't think it's off-topic. The parameters I've used for generating random buildings are somewhat a guess based on the densly populated regions of the UK First off, our default scenery lacks a lot of detail in the urban area boundaries in that area thus marking a far larger area as being urban - a far larger area on which to generate buildings; second, the generated random buildings are a mixed set of residential and comercial/office buildings, so the math is a bit off there. This is all parameterizable and controlled from the materials.xml file. One can easily change materials.xml to generate more commercial/office buildings if that's the right way forward. At the moment, we generate mainly office/commercial/apartment blocks for Urban, and lower office blocks and houses in Suburban/Town. Here's the catch: That's just assuming that the number of households per house is really 1 - but I think this assumption doesn't hold in dense urban areas, you can easily have 10 parties living in a larger building (even while I was living in Durham, NC we had 14 households in one building - and Durham NC had plenty of space to spare). Assuming for the sake of the argument that we might have on average 5 households per building in a dense urban area, we'd be overestimating the actual population by a factor 4.5. = use less, but somewhat larger buildings. Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. So, are these areas defined as Urban, or Suburban/Town in our global scenery? -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
However, one of the issues I'm hitting right now is that I have to avoid overlapping buildings by binning buildings that are too close to other buildings. As density increases you get more overlapping, and spend more time binning points, so scenery loading starts taking longer. Create a grid with a (density-dependent) cell size up-front and roll a dice for every cell once if there's a building in or not - this avoids dealing with overlap issues. You might even save some random number generation... * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Wed, 2 May 2012 07:17:45 -0700 (PDT), Gene Buckle wrote: On Tue, 1 May 2012, Stuart Buchanan wrote: Hi All, I've just committed a change that adds emissive lighting to the random buildings: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg That looks fantastic Stuart! It'll be cool when you can fly over and catch someone playing Tetris on the side of one of those buildings. :D Damnit, now I need to find time to model the green building at MIT and write tetris in nasal! -- Jon Stockill li...@stockill.net -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Thu, May 3, 2012 at 7:29 AM, Renk Thorsten wrote: Since the random buildings are now in the effect system, I've run a few tests with the lightfield shaders yesterday. The good news is: It works just fine. With some help from Emilian, we've changed the buildings to make use of the mode-combined-deferred effect, to allow specular mapping (so windows are look more realistic) as well as multiple lightmaps. Unfortunately, it appears to no longer work when the lightfield shader is enabled - the buildings all lose their textures. I've had a look at the hierarchy of effects files, but can't see any obvious problem. Do you have any idea what might be going wrong? -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
Hi Tim, On Fri, Oct 11, 2013 at 12:55 PM, Tim Moore wrote: Cool stuff. Are those all individual models, or instanced geometry, or what? :) The vast majority are instanced geometries, though there are some random models interspersed. As mentioned previously, I'd like to move back to the previous implementation from (IIRC 2.8.0) where the buildings were collected into massive objects as it provides collision detection and more variety. On Fri, Oct 11, 2013 at 1:54 PM, geneb wrote: Is it possble to place buildings manually and have the random buildings fill around them without interference? Not yet, but that's a known bug that I would dearly like to fix. I'm hoping that the refactoring required to implement the PagedLOD will provide access to the data required. At present the static objects (e.g. manually placed buildings) are only ingested after the geometry and random objects have already been generated. With the PagedLOD approach the random objects will be generated only when the aircraft gets into range, so I'm hoping I can simply check against the bounding box of each static object. -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osm2city.py
Hi Tom, On Sun, May 12, 2013 at 9:35 PM, Thomas Albrecht wrote: Dear list, in particular Stuart, please let me 'officially' announce my project osm2city.py [1,2] here. This python script takes OSM floor plans and generates 3D buildings for use with flightgear. I'm planning to develop this into a procedural city generator which would take a street network and then reasonably places (random) buildings. The ultimate goal is (obviously) to improve FG's representation of cities. It's at a rather early stage, and for the moment I prefer python for quick prototyping. BUT, I know quite some C/C++, and compile from latest GIT sources regularly. In the future, I'm definately willing to move this into FG (in one form or another). Tom [1] http://wiki.flightgear.org/Osm2city.py [2] http://flightgear.org/forums/viewtopic.php?f=5t=19625 To echo what others have said - this looks fantastic, and a major step forward from the autogen buildings that we have at present. I look forward to it making my work redundant! Based on my experience with the random buildings I think that pre-generating the buildings as you are doing at present is a better approach than trying to do things at runtime. There simply isn't enough information available in the tile loader to run a complex algorithm at run-time, and even if we could, my experience has been that the perf impact is too great. For example, we generate random buildings on a per-triangle basis (which allows us to determine the position on a plane and avoid an expensive height query). They cannot overlap the edges of the current triangle, as we can't tell what the terrain is on the other side of the triangle edge. This means you can see odd streets leading to vertices in the terrain mesh. Very distracting when you start spotting them... As you mention on the wiki page, memory occupancy is a big issue. The original implementation of random buildings used OSG primitives to generate a geometry for an entire tile at once. IIRC that was around 10GB for the LA area, and I'd expect the more complex buildings you're generating to need significantly more. As the random buildings are pretty simple I was later able to shoehorn them into a shader approach and improve memory occupancy significantly, but I don't think that'll work with the complexity of buildings you have. Since then Matthias modified the tile loader with an LoD callback, so that model aren't all loaded at the same time as the tile - only when you get close to them. That should help a bit, and might make the memory cost palatable for large cities. I think it would be worth having a discussion with the scenery DB owners about this as part of the scenery DB, automatically generating buildings as OSM data improves and/or the scenery shapefiles are changed. -Stuart PS: There's a util in FG (fgelev IIRC) that provides a much easier way to probe terrain elevation than running a Nasal script in FG. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Improving random trees buildings
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! Thanks, -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] Random Buildings - memory consumption
On Wed, May 23, 2012 at 1:41 PM, Emilian Huminiuc wrote: All this ignores the fact that Stuart was actualy using the live weather hence we don't actualy know the visibility/ number of tiles loaded, that we don't know which way he was facing, the fact that in reality just 1/6 of the surface loaded at startup is dense urban area, while the rest is residential, and wide spaced commercial/business area, etc. I've just committed a change that adds a debug level log to output the total number of random buildings that have been created. You can switch the log on and grep it on Linux by running fgfs --log-level=debug --log-class=terrain 21 | grep Total random buildings -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Enabled random buildings in preferences.xml
Hi All, I'd like to propose having random buildings enabled in preferences.xml, so they are switched on by default. I think they improve the realism of our Urban, Suburban and Town sceneries significantly. I ran a poll on the forums to determine the fps impact of the random buildings (http://www.flightgear.org/forums/viewtopic.php?f=5t=16204). Out of 15 responses - 5 had no frame-rate impact - 5 had minimal impact (one or two fps) - 4 had noticeable impact, but considered it worthwhile - 1 had noticeable impact, and would have to consider enabling it on a flight-by-flight basis - 0 reported a major impact on frame-rate that would preclude switching it on. Here on the list, James (at least) has noticed really significant fps impact. There is a significant memory footprint, but this appears to be only an issue when using building densities 1. At present our default is for random vegetation and random objects to be switched on, both of which also have fps and memory impacts. I'd therefore like to suggest that we enable the random buildings by default as well. Does anyone have any objections, or want to second the proposal? -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Tue, Apr 24, 2012 at 9:19 AM, HB-GRALwrote: Maybe just another dumb question, but wouldn’t it be possible to dynamically create a generalized mask with .stg point coords from the custom objects? Yes, but the current architecture separates the .stg loading from the .btg loading in such a way that the .stg information is not available at the point I'm creating the random buildings. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hm... I'm getting good performance, but the rendering of the random buildings do not seem to go via model-default.eff - they respond to the normal visibility, but not to the terrain haze layer, so they remain visible when I turn on heavy ground fog. Is there a conceptual problem, or can this be fixed? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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] Discussion culture clashes
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote: It's a fact that the distances out to which we draw trees and buildings are considerably less than how far we potentially draw terrain (120 km max.) So these things are separated even now - we don't attempt to render random buildings in 80 km distance even if we render terrain. Nobody proposed to render buildings to the visibility range either. Buildings/trees are generated at tile load time currently, and remain resident in memory, for as long as the tile is loaded. If you don't se them on screen doens't mean they're not there. Emilian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Which would in fact not make them random buildings at all :-) May I propose to think about something more ambitious? One thing which bugs me is that we have now well-working de-tiling strategies for terrain, but not really for city textures and agriculture. Forest is effectively de-tiled by placing sufficiently many random trees on top - but we still get huge tiling artefacts for large city areas or fields. Deterministic 'random' building on top of that will make the tiling problem worse, because you get repeating patterns now in both texture and objects on top, which wasn't the case with the scattergun. I think one could at least partially solve this by subdividing the terrain into individual coordinate cells and give each city texture inside the cell a random orientation of the texture. The template would be the sparse dot noise function introduced in terrain-haze-ultra.frag , but instead of creating the dot position and radius randomly, the routine would just create a rotation angle randomly. I believe this would improve city and agriculture, but for this to really work, the 'random' buildings and trees would have to be shifted by the same function - probaby at placement time. Would it be technically hard to design the system in such a way that this could be introduced? I don't have a function ready yet, but it's something I wanted to give a try at some point with running a distinct shader for 'random' and 'civilized' terrain which needs different types of overlay. * Thorsten -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random object/vegetation terrain masking
Hi All, I've just committed to simgear/next and fgdata/master code to allow the placement and rotation of random objects and vegetation to be masked based on a bitmap. So we can now control the placement and rotation of random objects precisely to match the underlying terrain texture. So, for farmland, the farm buildings etc. will appear at the ends of roads rather than in the middle of fields*, and in urban areas random buildings will align with the streets** (which works well with the urban shader IMO). As an extra bonus, I've also added a property (/sim/rendering/vegetation-density) that controls the density of the random vegetation. So you can control how uninviting the forests are based on the abilities of your graphics card :) I've committed changes to materials.xml and materials-dds.xml to make use of this, but there's plenty of room for someone to spend time improving the masking if they wish. The masks are very easy to create: - the Red channel controls Rotation - the Blue channel controls Buildings - the Green channel controls vegetation. (You can also use values 255 on the B and G channel for probability placements) Comments welcome as always. -Stuart * This isn't compatible with the crop shader. I don't know if that is solvable or not. ** There's still a bit of work to be done on the urban masks, as some buildings are intruding onto the highways :) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Besides being totally off topic, you can't do that direct comparison. First off, our default scenery lacks a lot of detail in the urban area boundaries in that area thus marking a far larger area as being urban - a far larger area on which to generate buildings That'd makes my point actually stronger, no? if you overestimate the area, you overestimate population even worse :-) second, the generated random buildings are a mixed set of residential and comercial/office buildings, so the math is a bit off there. Is it indeed? (No, the math is of course not off - if anything the assumption that the number of households per house is five might be off, all else is basic arithmetics and actual numbers). The math is an order of magnitude estimate, not some exact computation. You want to hit the right order of magnitude, not get it within 20% accuracy. For the record, I see all the pitfalls of the approach right lined up (holiday homes, unoccupied homes currently for rent or sale, mobile home trailer parks, official buildings, commercial buildings,...). So you think that I'm off and the number of households per house in US cities is in fact unity? Doesn't fit my recollections of New York, San Francisco, Denver, ... admittedly I've never been to LA. It seems terribly difficult to get an actual number for the quantity, I haven't been able to google anything. Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. We're not talking a regionalized building placement concept here... we're doing an order of magnitude case study for our average US-themed city. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Enabled random buildings in preferences.xml
Stuart, ...There is a significant memory footprint, but this appears to be only an issue when using building densities 1. At present our default is for random vegetation and random objects to be switched on, both of which also have fps and memory impacts. I'd therefore like to suggest that we enable the random buildings by default as well. Does anyone have any objections, or want to second the proposal? Your work does really look great, especially at areas like San Fran, LA and other big cities. It improves really much the graphics! Framerates are better than expected, and it shows some eyecandy like reflecting windows. So I would agree to enabling it per default if, well if the memory foot print would be lower. Today I made a simple flight from KLAX to KSFO with the 777-200ER with scenery downloaded from TerraSync (TerraSync itself disabled), skydome-shader enabled, random buildings enabled (density =1), trees enabled (density =1), fair weather without (!) 3d-clouds and default materials.xml. After just mid distance I got the first error messages and the buildings went black. Coming again to city area everytime a tile had to be loaded the sim freezed for several seconds. I have 4GB RAM; and my GPU (Nvidea GTX640) has about 1 GB VRAM. I must admit I expected a better behavior. What I noticed, different to the trees, the distance of loading random building increases together with the visibility while the trees has a limited range. Would be something possible as well for random buildings? And if so, would it help in this issue? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Am 19.04.12 17:52, schrieb Stuart Buchanan: On Thu, Apr 19, 2012 at 4:39 PM, rickbritto wrote: hello friends, Is possible to separate the random loading by types of buildings? Yes. The materials.xml file allows you to define different parameters for different landlclasses (e.g. Urban, Suburban, Commercial), and as mentioned above I'm adding parameters to control the ratio of the different building types. So a residential zone will have (say) 90% small buildings, and 10% medium, while an Urban zone will have 50% medium and 50% large. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi Stuart Just a small question because I’m currently looking to OSM street data and try to use it for scenery creation ... in your last screenshot of your improvements I still see buildings on streets (not the streets on urban textures, I mean the real roads coming originally from road line shapefiles). Will it be possible not to cover/overlap roads with random buildings, or is this planned anyway and I missed this point? Cheers, Yves -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On 20 Sep 2013, at 11:04, Stuart Buchanan stuar...@gmail.com wrote: The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. That would be my hope too, BTW. Ideally we'd set a total memory use (or vertex count, which is a proxy metric for the same) for trees+buildings and setup the PagedLOD to keep things loading (really, generating) and unloading based on that target. Then it becomes a fairly clear memory-burn vs popping tradeoff which I think most people would accept as reasonable. You don't like the pops, you buy more [V]RAM :) Instancing would help the memory burn, but OSG makes it very complex, we need to bypass large chunks of the PrimitiveSet and Arrays APIs until they get a real API internally, possibly not until OSG 3.4 (This is on the assumption that even though the buildings are random, across a tile you could have quite a few which differ only in transform and some other shader uniforms, but have the same width/breadth/height/roof-pitch/number-of-floors, and hence could be drawn using the same instance data) Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabled random buildings in preferences.xml
I ran a poll on the forums to determine the fps impact of the random buildings Oops, forgot to vote. Will provide some of my test-results here then: Tested with the UFO, Rembrandt disabled, looking at downtown San Francisco (plenty of buildings in view). With KSFO being our default airport, users are very likely to see those large chunks of urban areas. See my forum profile for system specs. Building level, followed by the average fps: 0.00 : 140 0.25 : 130 0.50 : 115 0.75 : 80 1.00 : 65 2.00 : 40 It's neither linear nor exponental... Don't know what to advise now. It starts to look nice from 1.0 onwards, but halfing the framerates is quite something. Gijs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 25, 2012 at 1:35 PM, James Turner wrote: Observations - where did all the quads come from? Is my card going to a slow path to submit quads? The Quads came from all the random buildings you've just created (or have I misunderstood?) Each building consists of 9-12 quads, depending on whether it has a pitched roof or not. Perhaps I should be using a QUAD_STRIP instead. Don't know if that would make much difference though. - why do I have an extra 300 drawables with building on, and why aren't they fast? (and there seems to be one extra primitive set per drawable, fair enough...) The extra 300 Drawables are from the quadtree that is generated to a) make culling fast b) to provide a mixture of LOD so that buildings don't all appear in big blocks. That code is taken directly from the random vegetation, and I could look at reducing the size of the quad tree, at the expense of worse cull performance and/or less fade-in. (I must own up to not looking at the OSG stats before now I guess I can hack the code to builds tris instead of quads, and see if that matters. If it does I'm going to have fun updating *all* the code to only submit pure tris! The relevant code for the random buildings is in scene/tgdb/SGBuildingBin.cxx (IIRC), and would be pretty easy to hack into not very pretty triangles by simply commenting out the fourth vertice in each block, if you didn't mind living in an abstract house :) -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Thu, Aug 9, 2012 at 10:06 AM, Renk Thorsten wrote: Both options, random buildings and a realistic view range, are in my view extremely cool as long as you know what you are doing with them, and I don't really want to abandon either. But I suspect their combination (combined with other memory-hungry goodies) is not something we want to confront the casual user with. Do we have any ideas addressing these issues? Random buildings are switched off by default, but as you suggest, a warning in the GUI would be appropriate. I will do this. Unfortunately, the buildings are generated when the tiles are loaded, and it is this that causes the memory occupancy problems rather than visibility itself (subject to big view ranges causing the loading of more tiles). Aggressively limiting the maximum available visibility range might help, if it's causing more tiles to be loaded, but it is very dependent on the amount of Urban and Town terrain. For performance reasons, all the buildings within a tile are a single object. The memory capacity could be addressed by changing the implementation to something closer to the trees, where a (relatively) small number of buildings are instantiated at different locations. I don't know what this would do for performance though. I believe James and Matthias also had a plan to use some OpenGL/Shader technque to pass location information for instantiation, but I don't know the details. And other ideas? Or is this not an issue for the majority? I think it's a major issue, and one that I did not consider sufficiently in development. Sorry. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Thu, Aug 9, 2012 at 10:46 AM, Stuart Buchanan wrote: For performance reasons, all the buildings within a tile are a single object. The memory capacity could be addressed by changing the implementation to something closer to the trees, where a (relatively) small number of buildings are instantiated at different locations. I don't know what this would do for performance though. I've (finally) managed to get a prototype running using an instantiation of a shared geometry rather than a huge single object per tile. So far the results are promising. My standard test is at KSFO with the c172p, waiting until the intial set of tiles is loaded with standard weather conditions (e.g. no excessive visibility). With random buildings switched off FG uses ~1GB memory. With v2.8.0 random buildings, it's 2GB. With instantiated buildings at present it is 1.5GB. At KLAX, it's down even further, from 2.7GB to 1.6GB. I've not noticed any frame-rate impact. There's still quite a lot of work to do, but I hope to have this available before the next release. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 25, 2012 at 9:26 AM, Martin Spott wrote: Stuart Buchanan wrote: I don't believe the town model has been used for some time. It was supersede by the random object masking I introduced a while back. I think what John and Yves are talking about is the introduction of the various zone_maison models for each spot (therefore the term point-geometry) where just a single building is supposed to be placed: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blobdiff;f=materials.xml;h=0ccd5813d67dafeb144aa3869ca251570f4d8e5d;hp=aded880617f7f367c08df928abf2cde42a847dea;hb=b67df1d2c2a6a0e16cf5fd16f11eb5585fc27012;hpb=4fc9647ee594f3ae8db638a7186bd42db93437a9 which leads to pretty obscure effects in many places. Unfortunately Erik never bothered responding to this issue, therefore it's uncertain wether he'd silently agree or silently disagree to reverting the above commit. I've had a look at the relevant section of the re-organized material.xml file (data/Materials/base/town-buildings.xml), and the zone_maison models are no-longer present. I think I simply removed them when I added the terrain masking as they were no-longer required. If random objects/buildings are floating above the surface, then that's a bug in the random object/building code. The random buildings are specifically created with a basement extending 10m below the x-y plane so they can be placed on a slope without looking odd. Some of the random objects do not have such a basement, so may have one bottom edge overhanging on steep ground. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random Buildings - memory consumption
Hi All, Emilian and Vivian have pointed out a problem with the random buildings - they gobble memory. I'd like to get some advice on whether there's any solution, and also to ask someone with more C++ knowledge than myself to take a look at the code and check I'm not doing something stupid. The specific problem scenario is starting a KLAX (Los Angeles) which is in the middle of a massive urban area. Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. Each building consists of between 9 and 12 quads (we have a basement at the bottom to handle slopes, 4 walls, and a roof which may be pitched). In turn, each quad has 4 corners, each of which has a position (vec3), a normal (vec3) and a texture coordinate (vec2). So, the absolute minimum memory occupancy of the data for the random buildings is 340k * 10 * 4 * 8 = 108MB. On top of that will be some OSG overhead and the building texture itself. Once you start flying more tiles are loaded (presumably well before any old tiles are unloaded?) so memory occupancy rapidly increases. Flying east from KLAX is particularly bad. Using a higher building density makes the problem much worse, as you need 4X the number of buildings to get double the linear density. I ran out of memory on a 4GB system pretty quickly (and tile loading takes an age - something I need to look at again). So - Does anyone have any bright ideas on what I can do to reduce the base memory occupancy? One option might be to not generate the basement if the terrain is level. - Could a fresh pair of eyes take a look at the obj.cxx, mat.cxx and SGBuildingBin.[ch]xx code to see if I've missed something obvious. Thanks, -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Saturday 12 May 2012 21:49:46 Stuart Buchanan wrote: Unfortunately, it appears to no longer work when the lightfield shader is enabled - the buildings all lose their textures. I've had a look at the hierarchy of effects files, but can't see any obvious problem. Do you have any idea what might be going wrong? -Stuart I've pushed a fix for this one. Emilian-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Am 23.04.12 17:40, schrieb Stuart Buchanan: On Mon, Apr 23, 2012 at 1:17 AM, HB-GRAL wrote: Just a small question because I’m currently looking to OSM street data and try to use it for scenery creation ... in your last screenshot of your improvements I still see buildings on streets (not the streets on urban textures, I mean the real roads coming originally from road line shapefiles). Will it be possible not to cover/overlap roads with random buildings, or is this planned anyway and I missed this point? Yes - this is part of the plan. I now have a solution for this, and also avoiding overlaps between buildings and the existing random objects. Unfortunately I don't yet have a solution for the custom objects from the scenery DB. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Maybe just another dumb question, but wouldn’t it be possible to dynamically create a generalized mask with .stg point coords from the custom objects? -Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. We might be generating too many buildings then? The greater Los Angeles area has between 13 and 16 million inhabitants (dependent on what you count). Assuming you haven't changed the visibility range from the startup default of ~16 km yet, checking with satellite images you should get about 1/12 of the greater LA urban area at startup, that means you generate 340k * 12 = 4 M houses in the greater LA area. The average number of people per household in the LA area was about 2.9 in 2006, so we have just populated Greater LA with ~12 million inhabitants - seems okay. Here's the catch: That's just assuming that the number of households per house is really 1 - but I think this assumption doesn't hold in dense urban areas, you can easily have 10 parties living in a larger building (even while I was living in Durham, NC we had 14 households in one building - and Durham NC had plenty of space to spare). Assuming for the sake of the argument that we might have on average 5 households per building in a dense urban area, we'd be overestimating the actual population by a factor 4.5. = use less, but somewhat larger buildings. Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wed, May 23, 2012 at 11:23 AM, Renk Thorsten wrote: Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. We might be generating too many buildings then? The greater Los Angeles area has between 13 and 16 million inhabitants (dependent on what you count). Assuming you haven't changed the visibility range from the startup default of ~16 km yet, checking with satellite images you should get about 1/12 of the greater LA urban area at startup, that means you generate 340k * 12 = 4 M houses in the greater LA area. The average number of people per household in the LA area was about 2.9 in 2006, so we have just populated Greater LA with ~12 million inhabitants - seems okay. It was using METAR so I don't recall the actual visibility. The 340k number is the total number of buildings generated after sitting on the runway for 5 minutes. I don't know how many tiles are initially loaded, and therefore how much scenery is generated. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Fri, 11 Oct 2013, Stuart Buchanan wrote: On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote: This is to give a heads up on some changes that I'm planning for Random Buildings for the V3.0 release, and to allow for comments/suggestions/ideas. I've now got the new system broadly working on a private build: http://www.nanjika.co.uk/flightgear/buildings.jpg That looks realy nice Stuart! Good job! Is it possble to place buildings manually and have the random buildings fill around them without interference? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Thu, Sep 19, 2013 at 3:07 PM, Renk Thorsten wrote: Which would in fact not make them random buildings at all :-) It'll make them less random, certainly :) However, while the placement and size class (small, medium, large) will now be determined by the texture, there will be still be randomness for each building in terms of width, depth, number of floors and texture. I need to prototype this to understand whether that's sufficient to fool the eye or not. The other avenue I'm looking at is whether the texture scale is correct. IIRC the city1 texture is 1024x1024 and covers a 1kmx1km area. I need to measure some street widths, as I suspect that might be a bit small. It may be that we can increase the texture coverage without increasing the texture size, which would reduce the repetition. Or just decide that cities are important enough to be worth a larger texture. May I propose to think about something more ambitious? One thing which bugs me is that we have now well-working de-tiling strategies for terrain, but not really for city textures and agriculture. Forest is effectively de-tiled by placing sufficiently many random trees on top - but we still get huge tiling artefacts for large city areas or fields. Deterministic 'random' building on top of that will make the tiling problem worse, because you get repeating patterns now in both texture and objects on top, which wasn't the case with the scattergun. I think one could at least partially solve this by subdividing the terrain into individual coordinate cells and give each city texture inside the cell a random orientation of the texture. The template would be the sparse dot noise function introduced in terrain-haze-ultra.frag , but instead of creating the dot position and radius randomly, the routine would just create a rotation angle randomly. I believe this would improve city and agriculture, but for this to really work, the 'random' buildings and trees would have to be shifted by the same function - probaby at placement time. Would it be technically hard to design the system in such a way that this could be introduced? I don't have a function ready yet, but it's something I wanted to give a try at some point with running a distinct shader for 'random' and 'civilized' terrain which needs different types of overlay. At the moment, we use a shader instantiate the buildings and forests to the correct locations. That transformation could be made more complicated to allow for texture rotation. Where it would have more difficulty is in handling the random objects, which are masked as well and would need to be moved. It would also be a bit tricky to make the edges of each coordinate cell look. At the moment, the textures edges tile nicely. I guess we could mirror the translation in the C-code, but it feels a bit wrong. On Thu, Sep 19, 2013 at 5:05 PM, Adrian Musceac wrote: Stuart, this is totally unrelated, but what would be the price to pay to have collision with generated buildings, and Rembrandt shadows? Actually, this isn't completely unrelated... The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. Now, all I need to do is find the time to code all of this up!. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
-Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 25 April 2012 10:46 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Random Buildings One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). It has an alpha channel Removed in Git Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 12:10:16 Stuart Buchanan wrote: Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. So, are these areas defined as Urban, or Suburban/Town in our global scenery? -Stuart Just by looking at how the terrain is textured in FG, I can say they are defined as Urban. Emilian. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabled random buildings in preferences.xml
Out of interest, do you have it enabled by default now? I'm interested to know whether you consider the frame-rate hit acceptable for the extra eye-candy. I don't fly that often these days, most of my time is spent on launching the 747 and testing various things. Don't need nice looking scenery for that, so I've everything disabled by default :-) Just did another test, and the outcome is rather interesting I think. This time with the 747-400: 0.00 : 45 1.00 : 35 2.00 : 30 Looks as if the buildings have a high impact, until the framerates come within a certain range (around 25-30 fps). Setting the density to 3 isn't significantly different from the fps at 2... Are the buildings smart and do they base their looks/density on the framerates? Gijs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabled random buildings in preferences.xml
On Sat, Jun 9, 2012 at 9:53 PM, Gijs de Rooy wrote: Out of interest, do you have it enabled by default now? I'm interested to know whether you consider the frame-rate hit acceptable for the extra eye-candy. I don't fly that often these days, most of my time is spent on launching the 747 and testing various things. That sounds very familiar :) Just did another test, and the outcome is rather interesting I think. This time with the 747-400: 0.00 : 45 1.00 : 35 2.00 : 30 Looks as if the buildings have a high impact, until the framerates come within a certain range (around 25-30 fps). Setting the density to 3 isn't significantly different from the fps at 2... Are the buildings smart and do they base their looks/density on the framerates? The buildings certainly aren't smart, but 25-30fps is around the range that I get normally. It may be that your memory bus to the GPU can handle 25-30fps but not much more. Note also that the building density is not guaranteed. Building density is also constrained by building minimum distance, so density 2 does not represent twice the number of buildings in reality. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Stuart -Original Message- From: Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2012 10:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random Buildings On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote: For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. That's very suspicious. There are a small number of states/primitive sets being used (for LoD purposes). Even at density=1.0 in a large urban area there will be many thousands of additional vertices being drawn, so it's possible that is saturating your GPU. One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). Looks good here - minimal impact on frame rate. Well done Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Stuart -Original Message- From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2012 10:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random Buildings On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote: For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. That's very suspicious. There are a small number of states/primitive sets being used (for LoD purposes). Even at density=1.0 in a large urban area there will be many thousands of additional vertices being drawn, so it's possible that is saturating your GPU. One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). It has an alpha channel Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On 25 Apr 2012, at 14:22, Stuart Buchanan wrote: Perhaps I should be using a QUAD_STRIP instead. Don't know if that would make much difference though. Doubtful, I'd say, if they are already in a single primitive set. The extra 300 Drawables are from the quadtree that is generated to a) make culling fast b) to provide a mixture of LOD so that buildings don't all appear in big blocks. That code is taken directly from the random vegetation, and I could look at reducing the size of the quad tree, at the expense of worse cull performance and/or less fade-in. (I must own up to not looking at the OSG stats before now Okay, this seems way too many drawables to me. Recalling Robert's target of about 4000 drawables maximum per scene, which we regularly blow out of the water What's the gain of so many drawables vs one LOD node per tile? I'm firmly in the 'small, compact scene graph with massive leaves' camp, you see. If part of the tile is visible, great, submit the whole damn lot and I'm confident the card will cope :) You could quad tree down a couple of levels if you insist, but I'd be thinking no more than a 2 or 3. (And the same for random vegetation) In fact, could you make the quadtree depth a config option? With 0 as a permissible value? The relevant code for the random buildings is in scene/tgdb/SGBuildingBin.cxx (IIRC), and would be pretty easy to hack into not very pretty triangles by simply commenting out the fourth vertice in each block, if you didn't mind living in an abstract house :) Will give it a go. Cheers, James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Tue, 1 May 2012, Stuart Buchanan wrote: Hi All, I've just committed a change that adds emissive lighting to the random buildings: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg That looks fantastic Stuart! It'll be cool when you can fly over and catch someone playing Tetris on the side of one of those buildings. :D g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generating ground textures on the fly?
I've been playing with populating my home airport's area with buildings derived from OSM floorplan data. I think having many buildings in the correct place greatly improves realism over the current random buildings/sparse static models, especially when you know the area. However, now the buildings obviously don't match with ground textures or random trees. Any bright ideas how to achieve this? I know I could follow the photoscenery approach and pre-render special materials and masks for a couple of cities, but that just doesn't scale. I wonder how x-plane 10 does this? Could we generate the texture on the fly? Based on landclass and road data? I could see a number of advantages/disadvantages here as compared to our current, generic textures: + much better autogen scenery possible: many textured streets/railroads without additional scenery vertices + shared models with an individual piece of ground texture + get rid of sharp landclass borders + possibly improved resolution - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM) - probably totally incompatible with the current terragear toolchain I know C/C++ and would be happy to start tinkering with this part at some point. But I know next to nothing about OSG, OpenGL, and shaders. Graphics gurus: is there any better way to do this? Cheers, Tom -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory issues
Of late, I have increasingly been running into some segfaults which seem to have to do with peak memory usage (I don't think memory leaks are a major issue for what I've been seeing, since some segfauls happened quite early on, and especially when I try pushing my limits of graphical goodies). Memory also appears to be an issue for other users, judging by forum response. For me, running into swap space means basically either immediate or imminent crash. Sometimes I get a 30 seconds grace with framerates below 5 fps, sometimes Flightgear dies immediately. Apparently other binaries (the 64 bit Jenkins) seem to be a bit more tolerant - see for instance user experiences here: http://www.flightgear.org/forums/viewtopic.php?f=68t=17114 None of this is a problem on a fundamental level for me personally - I largely know my 'safe' limits for visibility (250 km for default scenery and bare terrain on short suborbital hops, 120 km for long-distance flights in bare default scenery, 60 km in bare custom scenery or default scenery with buildings, 40 km in custum scenery with buildings, subtract another 10% for trees...), so I check a range of options I know by experience to be safe before the flight and am not usually troubled by crashes unless I try something new. But I know this stuff because I do a lot of benchmark testing, am active on this list and have some understanding of the inner workings of Flightgear. But there's nothing to inform the casual user what he should do. In fact, by chance the combination of options we offer is quite dangerous. * before the new edition of random buildings came out, I've played a lot with opening up visibility at high altitude. Even for a ground visibility of less than 8 km, you'd get 120 km at airliner cruise altitude if 'realistic visibility' is checked and the visibility limit shifted to max. in Advanced Weather * at the same time, random buildings (even in a rather unpopulated area like the Alps and with a density around 0.8) account for half of my memory consumption (I tested 1.0 GB for loading a 40 km radius without buildings against 1.9 GB for loading the same scene with buildings). That's before trees and/or higher densities. Hitting a major urban area changes the picture drastically. The combination of the two means instant death at high altitude, even when all you do on the ground looks sane - you can see a nice collection of random buildings nearby, have a safe visibility range, good momory consumption - and once you are up, the tile manager starts loading a city 120 km away you don't even see yet and populates it with buildings, memory consumption explodes and you are dead. Both options, random buildings and a realistic view range, are in my view extremely cool as long as you know what you are doing with them, and I don't really want to abandon either. But I suspect their combination (combined with other memory-hungry goodies) is not something we want to confront the casual user with. Do we have any ideas addressing these issues? For instance, should I agressively limit the maximally available visibility range in Advanced Weather if random buildings and trees are selected? Is it technically feasible to let Flightgear probe the remaining physical memory and if we run into trouble initiate an agressive unloading of terrain, e.g. by forcing visibility down (since most memory-hungry stuff scales with the square of the visibility range, I think adjusting that is most effective)? I know this is not realistic, but I'd rather have sudden haze than sudden segfault? Should we code a few warnings into the GUI? And other ideas? Or is this not an issue for the majority? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On 24 Apr 2012, at 22:09, Stuart Buchanan wrote: Feedback is welcome as always. For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 25, 2012 at 10:33 AM, Renk Thorsten wrote: Hm... I'm getting good performance, but the rendering of the random buildings do not seem to go via model-default.eff - they respond to the normal visibility, but not to the terrain haze layer, so they remain visible when I turn on heavy ground fog. Is there a conceptual problem, or can this be fixed? You are correct - they aren't using model-default.eff or indeed any part of the Effects system right now (which is why they don't work properly with Rembrandt either). There's no conceptual problem - I just haven't worked out how to integrate the Effects properly yet. I'm sure it's a five minute job for someone who knows more about the Effects C++ code than I do. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On 25 Apr 2012, at 13:35, James Turner wrote: Other suggestions most welcome. Emilian suggested I check random vegetation (which generates many more quads), at LOWI with vegetation off/onthe difference is from 50 fps down to 30ish, and quad count goes from 100k to 200k - but nothing like what happens for buildings with draw / GPU time. Interesting to note that vegetation takes the vertex count from 500k to 6 *million*, without anything dying. So I think my card can handle the geometry submission. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Emilian suggested I check random vegetation (which generates many more quads), at LOWI with vegetation off/onthe difference is from 50 fps down to 30ish, and quad count goes from 100k to 200k - but nothing like what happens for buildings with draw / GPU time. Interesting to note that vegetation takes the vertex count from 500k to 6 *million*, without anything dying. So I think my card can handle the geometry submission. Did you try that with the LOWI custom scenery? I have the same card and run out of memory (opengl) if i use the trees and a heavy plane like the new 787-8 This never happens with the trees switched off. Oliver -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabled random buildings in preferences.xml
That error is not exclusive for the random buildings (at least with the win 32bit fgfs). Just try to fly over detailed scenery long enough. With trees enabled the problem shows up sooner. And if you use a heavy airplane like the 787-8 from Omega95, fgfs will run out of memory on startup if you have a detailed scenery. The current win fgfs 32bit makes it impossible to fly a distance without running in this error. Oliver Am 09.06.2012 23:29, schrieb Heiko Schulz: Stuart, I got following error message: Warning: detected OpenGL error 'out of memory' at after RenderBin::draw(..) Heiko -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Thu, Aug 9, 2012 at 10:46 AM, Stuart Buchanan wrote: On Thu, Aug 9, 2012 at 10:06 AM, Renk Thorsten wrote: Both options, random buildings and a realistic view range, are in my view extremely cool as long as you know what you are doing with them, and I don't really want to abandon either. But I suspect their combination (combined with other memory-hungry goodies) is not something we want to confront the casual user with. Do we have any ideas addressing these issues? Random buildings are switched off by default, but as you suggest, a warning in the GUI would be appropriate. I will do this. This has now been done - commit ef93e36 Could someone please cherry-pick this to the release branch. Thanks. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Fri, Dec 14, 2012 at 12:28 PM, Adrian Musceac wrote: Oh one more thing, The random buildings and trees definetly receive shadows, but they don't cast it. Is that the way it should be? Asking because I'm about to push the modifications to my simgear clone. The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. The random buildings I'm less certain about. The 2.8.0 version certainly both cast and receive shadows. I'm not sure I've tested shadows since I changed them to an instantiation model post 2.8.0. Sorry I can't be more definitive. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weekly CVS Changelog Summary: SimGear
On Sunday 13 January 2008 12:00:10 am Curtis L. Olson wrote: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-06_09:04:44 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/SGModelBin.hxx /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/SGTexturedTriangleBin.hxx /var/cvs/SimGear-0.3/source/simgear/scene/util/QuadTreeBuilder.cxx Random object support from Stuart Buchanan In addition to Stuart's changes, there's an independent quad tree builder class for constructing loose quad trees from scene graph nodes. Stuart also implemented changes to the random number generator suggested by Andy Ross. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-06_09:04:45 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/util/QuadTreeBuilder.hxx Random object support from Stuart Buchanan In addition to Stuart's changes, there's an independent quad tree builder class for constructing loose quad trees from scene graph nodes. Stuart also implemented changes to the random number generator suggested by Andy Ross. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-12_02:50:21 (fredb) /var/cvs/SimGear-0.3/source/simgear/scene/model/ModelRegistry.cxx Avoid spitting gazillion 'Cannot find image file ' message on the console while loading random objects 2f585eeea02e2c79d7b1d8c4963bae I assume that the random objects include buildings. Starting up at KSFO last night after updating my sources was a nice suprise. The area was populated with buildings looking more realistic and not as barren. The real suprise is that it does not appear to have impacted frame rates and I believe it might be running smoother with slightly better framerates. signature.asc Description: This is a digitally signed message part. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ 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] Random Buildings
Wow, this is beyond awesome! And even better than the buggy shader! I'd take a look at the texture(s) used and see what I can do. B. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 25, 2012 at 2:44 PM, James Turner wrote: On 25 Apr 2012, at 14:22, Stuart Buchanan wrote: The extra 300 Drawables are from the quadtree that is generated to a) make culling fast b) to provide a mixture of LOD so that buildings don't all appear in big blocks. That code is taken directly from the random vegetation, and I could look at reducing the size of the quad tree, at the expense of worse cull performance and/or less fade-in. (I must own up to not looking at the OSG stats before now Okay, this seems way too many drawables to me. Recalling Robert's target of about 4000 drawables maximum per scene, which we regularly blow out of the water What's the gain of so many drawables vs one LOD node per tile? One benefit is better culling. The other is that we can have buildings gradually appear rather than all springing into view at once when you get within the LoD range of the center of the time (where objects at the edge might be significantly closer) I'm firmly in the 'small, compact scene graph with massive leaves' camp, you see. If part of the tile is visible, great, submit the whole damn lot and I'm confident the card will cope :) You could quad tree down a couple of levels if you insist, but I'd be thinking no more than a 2 or 3. (And the same for random vegetation) In fact, could you make the quadtree depth a config option? With 0 as a permissible value? The relevant code for the random buildings is in scene/tgdb/SGBuildingBin.cxx (IIRC), and would be pretty easy to hack into not very pretty triangles by simply commenting out the fourth vertice in each block, if you didn't mind living in an abstract house :) Will give it a go. If you're going to be looking in the code anyway, the depth of the quad tree is set in some constants at the top of the SGBuildingBin.cxx file, and (IIRC) the LoD range is also set up there, so you could see if reducing the depth makes a difference. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Vivian: It surely isn't, but who cares, as long as it works. (It works very well in Enemy Engaged and still looks quite good, despite being from 1999 (original version).) B. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Would trimming down building variety help? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
In other words, object batching is imlemented and used. Good to know, thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif The only place models get the effect is if they go via Effects/model-default.eff if they're using their own effect file they are not in the scheme. In addition, neither the random buildings nor the random vegetation in the screenshot are currently implemented in the scheme - that makes it a bit hard to see if there's something going wrong in the screenshot, random buildings and static buildings should have different lighting to dome degree. Do they respond to fog (ground haze slider in Advanced Weather)? Also, what if you simply use Effects/model-default.eff as currently on master (shouldn't really be much of a difference)? I have observed once that models came out very dark, that was fixed by switching the shader on and off, apparently some glitch which I could never reproduce. Spending 3 minutes with Effects/model-default.eff in the merge request branch doesn't reveal anything odd. So, I'm a bit at a loss. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenerymodels loading and Perfomance issues
Hi, I just got an interesting Mail from one of the scenery managers, and he guesses that the animations inside the xmls are the problem. So just using ac's should increase perfomance. So here a test with the latest scenery in EDDP available on TeraSync:(Terrasync after fetching disabled) With xml: Using c172P 3d-panel; disabled 3d-clouds, disabled Random objects, disabled shaders, Framerate-Throttle 30fps: 26L: 31 fps Same positions looking to the village: 31fps 26R: 31 fps Same positions looking to the village: 31fps 08R: 26-27fps Same positions looking to the village: 26-28fps 08L: 30fps Same positions looking to the village: 29fps Quite good! Using Bo105 flying over the village disabled 3d-clouds, disabled Random objects, disabled shaders, Framerate-Throttle 30fps: 300ft AGL view direction 270degrees: 31fps 300ft AGL view direction 100 degrees (village south of the tower, the other village with buildings in sight): 17-25fps 100ft view direction 270degrees: AGL 27-30 fps 100ft AGL view direction 100 degrees (village south of the tower, the other village with buildings in sight): 25fps O.k. but on older computers or/and more buildings an problem - see Paris, and not the latest eye candies! Now without xml, just plain ac's. Only minor impact noticable when landing inside the village south of the tower, the other village with buildings in sight: 28- 30fps All others test cases are totally stable, no impacts noticable! I only changed the models inside the airport, and only the shared models of the village, all lines were too much. ( I still had to change several hundred lines ) Conclusion: So it seems that indeed are the animations which causes this big impact. Range animation seems pretty needless, but at least we want so see nightlighted Buildings, so what to do? I uploaded the modified .stg-files for EDDP, place it and backup the old ones in Objects/e010n50/e012n51 www.hoerbird.net/3154776.stg www.hoerbird.net/3154777.stg Hope this all might help Regards HHS -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Mon, Sep 3, 2012 at 11:58 PM, Stuart Buchanan wrote: I've (finally) managed to get a prototype running using an instantiation of a shared geometry rather than a huge single object per tile. So far the results are promising. My standard test is at KSFO with the c172p, waiting until the intial set of tiles is loaded with standard weather conditions (e.g. no excessive visibility). With random buildings switched off FG uses ~1GB memory. With v2.8.0 random buildings, it's 2GB. With instantiated buildings at present it is 1.5GB. At KLAX, it's down even further, from 2.7GB to 1.6GB. I've not noticed any frame-rate impact. There's still quite a lot of work to do, but I hope to have this available before the next release. This work is now checked into next/master. You'll need an updated simgear and data to see any effect. Basically, I've moved to using a scheme very similar to that of the trees, where there are a small number of buildings created, and then instantiated multiple times. The technique relies on a vertex shader, as the final position and rotation of the building are passed in on the gl_Color vector. This in turn has meant that I've been forced to create new version of various vertex shaders. It might be possible to clean that up by having a new parameter to existing shaders indicating that position/rotation information is in gl_Color, but I haven't investigated that option in detail. There are three known regressions from the previous implementation: - The reflection map appears to be broken, and is currently switched off. I suspect this might be because the binormal or tangent are not being calculated correctly. - The buidings do not cast shadows in Rembrandt, though other objects _do_ cast shadows on the buildings. I don't know the reason for this. - At high building densities and certain angles of view, one can see gaps in the building placement where the edges of the scenery triangles go. This is unfortunately inevitable, as we have less sizing information during placement. If anyone with shader/effects knowledge has the time to look at the first two of these problems, that would be wonderful. Feedback/comments appreciated as always. -Stuart PS: With a building density of 4 at KSFO I have 1.6GB peak occupancy. That compares to 3GB previously. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
So.if.someone.could.setup.a list of effect(combination)s that don't work, I can try to construct something. From my side: Lightfields currently support - of the detailed shader config dialog: water reflection (water slider) and snow/dust (currently on landmass slider), all other sliders are ignored - of other shader-generated stuff: 3d-clouds, Stuart's random buildings, random vegetation is unsupported * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random vegetation and Atmospheric light scattering (was Re: Shader menu structure)
On Sat, Jun 30, 2012 at 12:49 AM, Stuart Buchanan wrote: Hopefully I'll be able to do a similar fix for the random buildings before the release. This is now done as a first pass, with the proviso that the atmospheric scattering disables the emissive and reflective building characteristics at present. There should no-longer be any annoying scenery artefacts popping up out of the general haze. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Before and after screenshots: Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg After - http://www.nanjika.co.uk/flightgear/buildings.jpg Wow, this looks pretty good! Why are there buildings on the street though - isn't that a different landclass? Does this have to an US-style rectangular street grid, or can we come up with an algorithm to draw more European-style street patterns (I think an adaption of the Markov chains I've been using for the undulatus cloud patterns might do the trick)? And, the performance numbers confirm many discussions here - the batched geometry with no state changes is very efficient, it's nodes, transforms and state changes that are killing us. I don't know... might be lack of transparency and low vertex count as well. The buildings are more or less cubes, if there are 1000 visible it's ~8000 vertices, usually I see performance deteriorating when I go from ~400.000 vertices to 800.000 vertices, if you throw 10.000 more in or not is just lost in the variations in scenery vertex count. I thought a lot of the resource drain comes from models with an xml-wrapper. Well, I'm looking forward to this! Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 18, 2012 at 10:45 AM, Renk Thorsten wrote: Wow, this looks pretty good! Why are there buildings on the street though - isn't that a different landclass? That's a bug in the placement algorithm - the buildings shouldn't extend past the edges of the city landclass. I'm planning to fix that before checking it into git. Does this have to an US-style rectangular street grid, or can we come up with an algorithm to draw more European-style street patterns (I think an adaption of the Markov chains I've been using for the undulatus cloud patterns might do the trick)? The current city textures are US-style rectangular street grids. Placement and rotation of the buildings uses the terrain-masking, where a second texture is used as a mask for placement and rotation. If you have a more European city texture, it would take ~1hr to create a suitable mask (the difficult bit is mentally converting the rotation in degrees into a 0-256 colour value!). Note also that changes I made to the materials.xml loading a couple of months ago so that any condition tags on the material definition are evaluation at tile loading time, and the directory structure would make it very easy to apply such a texture/mask to just European cities. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hi, On Wednesday, April 18, 2012 10:25:55 Stuart Buchanan wrote: For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU - all the buildings at the leaf of the quadtree are part of the same geometry, so the GPU can churn through it very quickly without having to change state. That sounds like we are heading in the right direction. Thanks! Let me be somehow picky: You are talking about having the houses in the same geometry, that's already fine. The next thing to care for is that they are also in a minimum amount of osg::PrimitiveSet instances. That's about minimizing the amount of draw calls that happen underneath. The best thing would be to have one single *DrawElements instance doing the whole geometry in a single draw call. Greetings Mathias -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Discussion culture clashes
Actually, I think what he tried to suggest was, that the needs of visuals and the needs equipment like radar should not be mixed. For visuals we need the terrain and all the objects like trees and buildings which are hard on performance. It's a fact that the distances out to which we draw trees and buildings are considerably less than how far we potentially draw terrain (120 km max.) So these things are separated even now - we don't attempt to render random buildings in 80 km distance even if we render terrain. Nobody proposed to render buildings to the visibility range either. Also let me quote what James said immediately before: This is moving in the right direction for sure. I'd like to go a little further, and make the LOD setting a simple checkbox labelled 'reduce detail adaptively'. Then make the LOD ranges (for trees, clouds, AI models, whatever) internal properties, and crucially, enable OSG's LOD-bias feature. This effectively scales the 'visible distance' used to select LOD by a factor, and we can use a PID controller to adapt it based on target and actual frame-rate. (Of course I didn't try it for real yet). This ought to nicely adjust the LOD bias, and hence the final LOD, to keep a target rate (say 30 or 60fps). So this doesn't lead to any more gracious interpretation. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Fri, Sep 20, 2013 at 11:15 AM, Adrian Musceac wrote: I think one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and graphics load. It should be possible to take an object and generate multiple LOD's for it automatically, but I have almost no knowledge about 3D objects. Might be worth checking it out. While a good LoD system helps with graphics load, it doesn't help with overall memory load (unless it's a PagedLOD), which was the problem with the buildings. We have fairly good LoD solutions for both trees and buildings to help with the graphics loads. For example we display the large buildings are further range than the medium or small. Hopefully people never notice it because it's quite subtle. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
I am pretty confident (and hope to test, but it sounds like you might beat me to it) that for either the classical (non-Rembrandt) render, doing a depth-write *only* pass of the entire scene will be a net win. (Again assuming the fragment shader is the bottleneck). Since this will reduce overdraw to zero - solving both the 'cockpit covers terrain' optimization, but also where random trees or buildings do. (Which is presumably where your 30% gain comes from) I guess there's only trees, random buildings, cockpit and clouds which can cover substantial parts of the scene (all else is rare and exotic...). Trees I've accounted for, random buildings most likely cover urban landclass which has no overlay texturing and is hence pretty cheap to render if no urban effect is on (in which case you can't have buildings), so the expected gain is less. Clouds are a bit tricky if done directly because their rotations sit pretty heavy on the vertex shader, so doing a second pass might create a new vertex shader bottleneck (at least in one try it did, but I may have done something fishy there). Hence the idea to slip the obscuring rectangles in... The cockpit is the biggest potential gain, but due to the near camera - far camera thingy, I don't see how this can be done on the level of editing effect files - maybe a suitable edit of the camera group code can pull that off, but I have no idea where to start there. If you figure that one out, it'd be great. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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] Real-Time Radio Propagation
Hi Adrian, On Wed, Dec 12, 2012 at 10:12 PM, Adrian Musceac wrote: As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. I think the random objects _do_ need to be included so they can be included in collision calculations. On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the perfect approach. My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within reasonable range of the station? One might be able to create a bitmap storing the minimum signal altitude (i.e. the altitude below which there is no signal due to terrain), the maximum signal strength, the altitude that occurs, etc. and then use these as parameters into a straightforward function to determine the signal strength at the current altitude. One could then overlay the published approach volumes and thereby ensure that aircraft within the approach volume receive valid signal strength. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Hi Stuart, De: Stuart Buchanan On Wed, May 23, 2012 at 2:38 PM, Björn Kesten wrote: Would trimming down building variety help? Unfortunately not. Individual buildings aren't instantiations of a small number of objects, as the random vegetation is. Instead, a huge group of buildings are a single OSG object, which limits the OSG overhead and means they are very efficient to render. There is an OpenGL feature that is available in OSG : you can instantiate the same geometry multiple times. You prepare the geometry once and when adding the primitive set (IIRC) you specify an optional number of instances. The vertex shader is call the number of instance specified times with a predefined uniform gl_InstanceID set from 1 to n. Of course, as you don't want your geometry draw n times at the same place, you have to compute the placement of objects inside the vertex shader using gl_InstanceID. Either you compute placement with an algorithm inside the shader, or you provide a matrix array uniform that you can index with gl_InstanceID. see http://www.opengl.org/wiki/Vertex_Specification#Instancing for a less nebulous explanation ;) Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. The random buildings I'm less certain about. The 2.8.0 version certainly both cast and receive shadows. I'm not sure I've tested shadows since I changed them to an instantiation model post 2.8.0. Sorry I can't be more definitive. Ok, let me revert to next and test again. I don't normally enable Rembrandt since it's very slow on my machine, but when I did, I couldn't believe how much it can changed the scene and how nice it looked. So far, I think we agree trees shouldn't have the TERRAIN_BIT set, and random buildings are still up for debate, but random models should definetly set this bit. I will test the shadows again and report which bits are working in latest simgear and which are not. BTW, random models cast shadows, I saw that clearly. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG vs. trees and buildings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Megginson wrote: What are the issues with OSG around dynamic scenery (trees, non-static randomly-placed buildings, 3D clouds, etc.)? Is it just a matter of spending a few hours coding, or is there something in the OSG APIs that makes dynamically-generated scenery difficult? Trees and other random objects are not hard and will fall out of the work I'm doing on real OSG database paging. Our clouds are a different matter because their rendering is done using OpenGL features that require some reworking for OSG's framework. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8bY6eDhWHdXrDRURAr+VAJ9Va6O1dyTnjKJBBuxgJfyQSFhXKACgvGA2 py7uHKyOeSrWDVvG2mb8/HM= =Ky2c -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On 25 Apr 2012, at 12:35, Stuart Buchanan wrote: I must admit that I've only tested Edinburgh and San Francisco, which may simply not have as much Urban area as Berlin. I'll try Berlin when I get the chance, but could you see if the same problem occurs at EGPH and KSFO? Yep, second run was at EGPH Also, there is a significant slow-down in scenery loading. Is it possible that background scenery loading might be affecting your framerates (though I note that you've previously said that the increase is in GPU and Draw time). Right, I can see that too. The draw / GPU times increases proportionally as the tiles (re-)load with buildings. It points to the actual geometry being the limiting factor, which is very odd. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings improvements - phase 1
I've just checked in a change so the buildings now use the Effects system properly, which includes a global cache of the textures. This might help. Nice - have to try this. Btw - could you take a look at the ambient value of the material declaration? I have the feeling it is very low, I'm getting very black shadows for low sun, much more than for the typical static building. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. Ok, I've just tested this with current Git, and buildings except random models, as well as trees, don't cast shadows, but receive them. I do remember a time when buildings cast shadows too, I think. I'll try to research this further. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osm2city.py
Dear list, in particular Stuart, please let me 'officially' announce my project osm2city.py [1,2] here. This python script takes OSM floor plans and generates 3D buildings for use with flightgear. I'm planning to develop this into a procedural city generator which would take a street network and then reasonably places (random) buildings. The ultimate goal is (obviously) to improve FG's representation of cities. It's at a rather early stage, and for the moment I prefer python for quick prototyping. BUT, I know quite some C/C++, and compile from latest GIT sources regularly. In the future, I'm definately willing to move this into FG (in one form or another). Tom [1] http://wiki.flightgear.org/Osm2city.py [2] http://flightgear.org/forums/viewtopic.php?f=5t=19625 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wednesday, September 18, 2013 19:05:22 Stuart Buchanan wrote: I did take a look at the PagedLOD approach - Matthias' code made a great template to work from. -Stuart Stuart, this is totally unrelated, but what would be the price to pay to have collision with generated buildings, and Rembrandt shadows? Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random trees
Gérard wrote: Hello, Is it only me ? or is there a funny behaviour with the random objects ? I have found trees into the stadium :) http://pagesperso-orange.fr/GRTux/RandomTreesAndStadium.jpg No, it isn't just you :) The random objects, including trees, are placed randomly based on the terrain type of the scenery, as defined in materials.xml. IIRC there is no attempt to stop multiple objects being placed at the same location - just the random function - and each object type is considered independantly. Objects from the scenery objects databased are placed as defined in the .stg/.btg files. Again, there is no attempt by the random object code to avoid placing random objects at the same location. In general this isn't a problem - we don't use object densities high enough to see collisions regularly, and usually a larger object will completely obscure a smaller one. If we decide to increase the density of random objects significantly so that collisions become a problem, we'll probably need to change to a different scheme, particularly for towns and cities. One possibility is to use a bitmap to determine possible object locations. This can then be aligned with the texture, so our buildings align with the streets, trees appear on the edges of fields, cows in the middle etc. However, I have enough work on my plate before the 1.9 release to start thinking about that just now! -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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 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] Random Buildings
On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote: For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. That's very suspicious. There are a small number of states/primitive sets being used (for LoD purposes). Even at density=1.0 in a large urban area there will be many thousands of additional vertices being drawn, so it's possible that is saturating your GPU. One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random Buildings improvements - phase 1
Hi All, I've made a couple of updates to the random buildings to address some of the feedback received so far. 1) As suggested by Thorsten R. I've changed the placement algorithm from random to a grid-like arrangement. This should allow faster scenery generation, as it allows me to reduce the building coverage required in materials.xml to provide the same actual building density in the sim. 2) As the algorithm is more effective, /sim/rendering/building-density is now more effective. I've therefore reduced the maximum value in the rendering dialog to allow those wanting to use a value 1 more leeway in setting it via the rendering dialog. 3) I've reduce the number of Drawables generated by reducing the quad tree depth from 3 to 2, and reducing the number of LoD leaf nodes from 10 to 4. James Turner - I'd be very interested if this change improves your framerates. Next on my TODO list: Integration with the Effects system. Watch this space! -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
* R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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
