Re: [Flightgear-devel] Random Buildings - memory consumption
On Sat, May 26, 2012 at 7:18 AM, Mathias Fröhlich wrote: Good morning, On Friday, May 25, 2012 19:48:32 Stuart Buchanan wrote: Thanks for taking a look. I think that the SGBuildingBin destructor will be called when I call the list clear() method on the SGBuldingBinList (SGBuildingBin.cxx line 654). That in turn calls clear() I have no current code update, since I am on travel, but I think that the SGBuldingBinList is a list of pointers. Then, on clear of that list, the pointees are not cleared. I think I've got that covered - I delete each of the pointers within the BOOST_FOREACH loop (SGBuildingBin.cxx line 651). -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
Good morning, On Friday, May 25, 2012 19:48:32 Stuart Buchanan wrote: Thanks for taking a look. I think that the SGBuildingBin destructor will be called when I call the list clear() method on the SGBuldingBinList (SGBuildingBin.cxx line 654). That in turn calls clear() I have no current code update, since I am on travel, but I think that the SGBuldingBinList is a list of pointers. Then, on clear of that list, the pointees are not cleared. Either store the objects itself in the list, which should copy a lot more in the way you do this, or use SGReferenced together with a list of SGSharedPtr values. Just to give two simple solutions. In both of which, the clear can be completely omitted, that happens anyway on the destructor of any stl container. on the BuildingList (SGBuildingBin.hxx line 105), which is a simple struct of basic types, so shouldn't need a destructor. That's right. Mathias -- 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 Thu, May 24, 2012 at 7:07 AM, Mathias Fröhlich wrote: I may be false since I really only spent *very* little time on that. But I believe you never free the content of the building bin list. That means the pointers stored in the list are gone, but the building bins - the pointees - are still alive. Hi Mathias, Thanks for taking a look. I think that the SGBuildingBin destructor will be called when I call the list clear() method on the SGBuldingBinList (SGBuildingBin.cxx line 654). That in turn calls clear() on the BuildingList (SGBuildingBin.hxx line 105), which is a simple struct of basic types, so shouldn't need a destructor. -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 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
Re: [Flightgear-devel] Random Buildings - memory consumption
Hi, On Wednesday, May 23, 2012 10:37:00 Stuart Buchanan wrote: 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. I may be false since I really only spent *very* little time on that. But I believe you never free the content of the building bin list. That means the pointers stored in the list are gone, but the building bins - the pointees - are still alive. Greetings Mathias -- 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
Hi,
I don't have any clue of the opengl and simgear based stuff, so I looked only
at the struct Building and how to optimize that.
In the attachment you can find 3 structs representing the data.
The original is yours.
'small' is a very small optimization that doesn't require you to map floats to
discrete values. The flags variable holds bool pitched and the building type. I
assumed floors not to be bigger than 65k, so I reduced it to 16 bit ;).
In 'aggressive' I replaced the floats which I think doesn't require the full 4
byte precision of a float. However the mapping from float-int int-float can
take much time depending on the translation function you use. If normal float
division/multiplication is too slow, you could write some functions to directly
accessing the float (shifting the fraction depending on the exponent)
(http://en.wikipedia.org/wiki/Single_precision ).
However just ideas on that struct. Sizes in bytes:
original: 44
small: 36
aggressive: 28
Regards,
scosu
On 23.05.2012 11:37, Stuart Buchanan wrote:
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
#include stdint.h
#include stdio.h
enum BuildingType {
SMALL = 0,
MEDIUM,
LARGE
};
struct building_original {
enum BuildingType type;
float position[3];
float width;
float depth;
float height;
int floors;
float rotation;
bool pitched;
float radius;
};
#define BUILDING_FLAGS_SMALL 0x01
#define BUILDING_FLAGS_MEDIUM 0x02
#define BUILDING_FLAGS_LARGE 0x04
#define BUILDING_FLAGS_PITCHED 0x08
struct building_small {
uint16_t flags;
uint16_t floors;
float position[3];
float width;
float depth;
float height;
float rotation;
float radius;
};
#pragma pack(push,1)
struct building_aggressive {
float position[3];
uint16_t width;
uint16_t depth;
uint16_t height;
uint16_t rotation;
uint16_t floors;
uint8_t alignment_no_data; // to get better access times for variable radius
uint8_t flags;
uint32_t radius;
};
#pragma pack(pop)
int main(void) {
printf(original: %lu\n, sizeof(struct building_original));
printf(small: %lu\n, sizeof(struct building_small));
printf(aggressive: %lu\n, sizeof(struct building_aggressive));
}
--
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
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 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 - 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 - 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] 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] 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
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 14:16:02 Emilian Huminiuc wrote: 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. And the mapserver seems to agree with that assumption: http://mapserver.flightgear.org/map/?lon=-118.18562lat=33.91857zoom=11layers=0B00TFFFTFFFTFFF 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 - memory consumption
On Wednesday 23 May 2012 11:20:28 Renk Thorsten wrote: 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 No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used to do the math to compare with reality. 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 - memory consumption
No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used to do the math to compare with reality. A more constructive argument would have been to present your own counter-estimate, rather than calling all irrelevant... I think it's actually interesting that we can do such order of magnitude consistency checks. * 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 Wednesday 23 May 2012 12:05:05 Renk Thorsten wrote: No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used to do the math to compare with reality. A more constructive argument would have been to present your own counter-estimate, rather than calling all irrelevant... I think it's actually interesting that we can do such order of magnitude consistency checks. * Thorsten Keeping your initial assumption of default visibility, you'd get at least 6 tiles loaded, that makes for ~600 sq miles, wich is ~1/8 of the LA Metropolitan Statistical area, 8*340k ~ 2.7 million buildings for a population of ~12.8 million, that gives about 4.75 persons / building. Assuming 1/3 of the buildings are actualy represented as commercial/office that gets us to ~7persons/building or around 2households/building, which would be about right if it were residential, but is of course wrong for the apartment buildings; that is not the algorithm that's at fault, that's the underlying representation of the terrain (which should have just the core of the bigger cities in the area mapped as urban, and te rest as residential/town) Disclaimer: 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. 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 - 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
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] 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] 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] Random Buildings - memory consumption
Emilian Huminiuc wrote: http://mapserver.flightgear.org/map/?lon=-118.18562lat=33.91857zoom=11layers=0B00TFFFTFFFTFFF Just as a reminder the colour legend is here: http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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 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 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] Random buildings improvements - phase 2
The guy with the i5@3.3/8G/GT450 (and taking 50ms/frame for full-noise rembrandt) has a crapton of hardware grunt -- no current commercial game is going to bring that machine to its knees -- we're just *slow*. X-Plane 10 would kill it dead as a post. :) 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
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Sat, May 5, 2012 at 8:07 AM, Gene Buckle ge...@deltasoft.com wrote: The guy with the i5@3.3/8G/GT450 (and taking 50ms/frame for full-noise rembrandt) has a crapton of hardware grunt -- no current commercial game is going to bring that machine to its knees -- we're just *slow*. X-Plane 10 would kill it dead as a post. :) So would FSX with the right settings and add-ons. In fact, flightsims are the biggest performance killers in town. Shooters just can't compare. 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 improvements - phase 2
For the purpose of making the tests more comparable, would not it be better to use a standard setting/script/options which would set FG to some defined state? In this case clearly no. I'm interested in the relative change matrix of framerates for two features being on or off, not in the absolute scale factor (which depends on things like screen resolution, whether the binary is debug mode or release mode, ...). Stuart's post contains all the information I want to know whereas a defined state would not contain that information. I'm simply not interested if some people have an overall faster computer, I know that. I'm interested in relative scaling properties. * 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 improvements - phase 2
-Original Message- From: Renk Thorsten Sent: Friday, May 04, 2012 1:31 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random buildings improvements - phase 2 For the purpose of making the tests more comparable, would not it be better to use a standard setting/script/options which would set FG to some defined state? In this case clearly no. I'm interested in the relative change matrix of framerates for two features being on or off, not in the absolute scale factor (which depends on things like screen resolution, whether the binary is debug mode or release mode, ...). Stuart's post contains all the information I want to know whereas a defined state would not contain that information. I'm simply not interested if some people have an overall faster computer, I know that. I'm interested in relative scaling properties. * Thorsten -- However it may be of general interest to find the relationship between computers and current FG performance. At the moment it seems to me that FG requirements are increasing faster than the performance of affordable computers. A few months ago I was getting over 60 fps with an Intel i5-2500k CPU @3.30GHz, 8Gb Ram, Nvidia GTS 450 combination. This is now down to 40 (no Rembrandt) and less than 20 (with Rembrandt). Alan -- 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 4 May 2012, at 14:21, Alan Teeder wrote: At the moment it seems to me that FG requirements are increasing faster than the performance of affordable computers. A few months ago I was getting over 60 fps with an Intel i5-2500k CPU @3.30GHz, 8Gb Ram, Nvidia GTS 450 combination. This is now down to 40 (no Rembrandt) and less than 20 (with Rembrandt). It would certainly be good for you to find what caused the non-Rembrandt slow-down, since the only thing that should possibly have happened in that time is shader changes - nothing in the C++ scene that should make such a large difference. 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
At the moment it seems to me that FG requirements are increasing faster than the performance of affordable computers. I can't confirm that. The 'bare' current binary (= all shaders off) runs even a bit faster for me than previous releases. I think one clearly needs to distinguish between requirements to run fgfs and requirements to put all shaders to maximum, run dense AI traffic in the background and have goodies like movable jetways. The requirements for all shaders to max. are clearly growing quite fast. I agree that for this question, a standardized benchmark would be useful. * 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 improvements - phase 2
I agree that for this question, a standardized benchmark would be useful. Hi, Not exactly 'standardized' but certainly agree the some comparative information is important, not only which video/resolution/OS/... These were all run as default, noon, full screen, 1440x900, c172p, motor idling, KSFO 10L, for about 5 minutes each... the last is SG/FG git about 17:00 hours UTC today... Various versions currently available - in Ubuntu 10.04 LTS - all compiled from git source... fg3 2008-09-01 - 46 fps fg4 2009-03-26 - 46 fps fg5 2009-04-18 - 47 fps - highest fg6 2009-06-26 - 46 fps no 2010 not archived, until... fg14 2011-04-26 - 43 fps fg15 2011-06-03 - 40 fps fg16 2011-11-01 - 40 fps fg17 2011-10-30 - 32 fps fg18 2011-11-15 - 27 fps fg19 2012-01-16 - 22 fps - lowest fg20 2012-05-01 - 32 fps fg20 2012-05-04 - 32 fps This is of course without rembrandt, and not specifically enabling/disabling ANYTHING, although perhaps internal default were changed... Of course I hope we can someday return to the fps I got for most of 2009 ;=)) but do understand new 'features', subsystems, etc - in short improvements in the 'real' experience - can cost fps, perhaps never to be recovered... HTH. Regards, Geoff. PS: Can someone remind me the --prop:/sim/??? to set from the command line to show frame rate - to avoid the need to View - Display Options to click it into existence - tks. Of course I would prefer it be enabled by default ;=)) -- 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
-Original Message- From: James Turner Sent: Friday, May 04, 2012 2:32 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random buildings improvements - phase 2 On 4 May 2012, at 14:21, Alan Teeder wrote: At the moment it seems to me that FG requirements are increasing faster than the performance of affordable computers. A few months ago I was getting over 60 fps with an Intel i5-2500k CPU @3.30GHz, 8Gb Ram, Nvidia GTS 450 combination. This is now down to 40 (no Rembrandt) and less than 20 (with Rembrandt). It would certainly be good for you to find what caused the non-Rembrandt slow-down, since the only thing that should possibly have happened in that time is shader changes - nothing in the C++ scene that should make such a large difference. James -- James You made me think (no funny jokes please). So I removed -enable-rembrandtfrom system.fgfsrc and got 60fps again. Therefore my post should have read 40 fps (no shadows), and less than 20 (with shadows) as that is what I did, stupidly thinking that the shadows button would turn Rembrandt off. Sorry for the misleading post, but I think that my comment about increasing power requirements still holds good. On the subject of shadows, I am seeing very clear black shadows when it is raining. I don´t recall ever seeing these in real life, even on rainbow days. Making raindrop shadows must eat up a lot of CPU/GPU wherever it is done. Thanks for waking up my brain . ;) Alan -- 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
I would be happy to set up an automated are we fast yet-style system for FG. It would be nice to have perhaps 10 minutes worth of (representative) test that the machine can just run against every commit. What hardware do people think is actually a sensible baseline? The guy with the i5@3.3/8G/GT450 (and taking 50ms/frame for full-noise rembrandt) has a crapton of hardware grunt -- no current commercial game is going to bring that machine to its knees -- we're just *slow*. -- Chris -- 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
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 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
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 Wed, May 2, 2012 at 4:18 PM, Björn Kesten wrote: Stu, do you have plans to regionalize the autogenerated buildings? This is already supported in the code, and just needs someone to spend some time creating textures and changing some XML. The buildings (including the texture to use) are defined in materials.xml, and you can assign different building sizes and distributions to different material types. You can already see that in the difference between Urban and Town/Suburban areas. We already have the ability to select a terrain material based on a condition statement, which is evaluated when the tile is loaded, so it is a very easy job to create a new material definition for a given region using a condition statement that checks /position/latitude-deg and /position/longitude-deg I've still to document the new lightmap texture parameter (it's called building-lightmap) but the rest of the parameters are documented in data/Docs/README.materials if you want to have a play. Thorsten Renk mentioned that he is looking at integrating Adrian's modified textures, possibly making some of them regionalized. I'm sure you could work with him on this by contributing some more realistic building definitions. Both the current building texture and the lightmap are really just proof of concepts. I'm not very talented as a texture artist, so there's plenty of scope for improving them. tigert on the IRC channel has already been looking at improving the textures, and i4dnf also mentioned he would be as well. -Stuart You can define the buildings on If so, one could lift the concept from MSFS. They assigned a letter-code to every global region (e.g. Germany and Scandinavia was K) and thus, you didn't have american wooden houses in Germany or cobblestone houses in Asia. This could be done with kind of a show up in region [A,C,D,H] tag for every model and a global regions definition file or similar. 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 -- 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
Good to know, thanks. Texture work is not important, since there's way more people who know their way around PS/GIMP than people who can code such autogen systems. :) -- 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 Wed, 2 May 2012, Jon Stockill wrote: 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! \o/ 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
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] Random Buildings improvements - phase 1
On Mon, Apr 30, 2012 at 11:56 AM, Renk Thorsten wrote: 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. From memory, I've set it to 0.3. It is configurable in the data/Effects/buidling.eff file under parameters/material/ambient if you want to have a look yourself. I'm happy to accept a change to the value - I haven't spent any time tuning it. -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 1
From memory, I've set it to 0.3. It is configurable in the data/Effects/buidling.eff file under parameters/material/ambient if you want to have a look yourself. I'm happy to accept a change to the value - I haven't spent any time tuning it. Okay, that explains it. I think it should be in the range 0.7-1 - our ambient light is about half of the diffuse light (0.5, 0.5, 0.5) vs (1,1,1) - if the material declares ambient to 0.3, you get shadows which are then 0.15 times the base color - which is way too dark as compared with how terrain or most of the models are shaded in indirect light. 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
Heiko wrote: With todays GIT it seems to me that the buttons in all dialogs are much smaller than before- optical illusion, or does someone else noticed it? I've noticed the same on every dialog, except advanced weather... 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 improvements - phase 1
On 28 Apr 2012, at 20:10, Stuart Buchanan wrote: 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. Sadly no (I already tried 3 to 2 and 10 to 2 - the number of drawables and primitive sets drops, but that's clearly not the bottleneck in this case). So I still go from 50fps to 33ish over EGPH with density = 1 not great (but flyable) One thing I did notice - you're creating a state set for each bin, based on texture. I think you want to globally cache those by texture (all the other parameters are fixed anyway, right?), so that OSG can see that all the prim-sets in different bins share a state set, and hence reduce state changes. 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
Hi Stuart, 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. Is there a reason it could be different than for the trees ? Look in TreeBin.cxx to see how it was done. This was my example to do light animations btw. 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] Random Buildings
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote: 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. Found at least part of the issue: BIND_PER_PRIMITIVE should be avoided - it forces OSG to use manual calls, at least for me. Changing the normal binding to vertex (at 4x the memory for the normal array) gets the performance back to 'sane'. There's still quite a big FPS hit (eg, 50 FPS down to 30FPS over the centre of Edinburgh), but it's not 'crazy-off-the-scale-slow'. I did a check, and fortunately nothing else in our code is using BIND_PER_PRIMITIVE. 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
Vivian: A combination of canopy features with individual features scattered around the edge? Just like in the Enemy Engaged series of helicopter sims? (See picture) http://www.nexgam.de/media/cache/nexgam/img/articles/8753/Enemy-Engaged-Comanche-vs-Hokum-1.jpg I say this would be a viable option for rendering patches of forest. If the canopy texture can be spiced up with e.g. a bump map, you'd get a fairly good looking, but still fast result. 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
Björn Vivian: A combination of canopy features with individual features scattered around the edge? Just like in the Enemy Engaged series of helicopter sims? (See picture) http://www.nexgam.de/media/cache/nexgam/img/articles/8753/Enemy- Engaged-Comanche-vs-Hokum-1.jpg I say this would be a viable option for rendering patches of forest. If the canopy texture can be spiced up with e.g. a bump map, you'd get a fairly good looking, but still fast result. Thats what I had in mind. Perhaps we could use individual trees (outliers) around the edges. It's not an original idea. 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
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
2012/4/26 Björn Kesten : Vivian: A combination of canopy features with individual features scattered around the edge? Just like in the Enemy Engaged series of helicopter sims? (See picture) http://www.nexgam.de/media/cache/nexgam/img/articles/8753/Enemy-Engaged-Comanche-vs-Hokum-1.jpg I say this would be a viable option for rendering patches of forest. If the canopy texture can be spiced up with e.g. a bump map, you'd get a fairly good looking, but still fast result. IIRC we already have this available, using a geometry shader at very high shader quality settings. I don't recall the landclass that uses it, but I do recall at one point seeing it in-use just off the side of KLVK in the past. Personally, I prefer the look of individual trees, and on my system the trees are less expensive than a geometry shader. -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
Hi, On Thursday, April 26, 2012 08:32:19 James Turner wrote: On 25 Apr 2012, at 14:56, Stuart Buchanan wrote: 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. Found at least part of the issue: BIND_PER_PRIMITIVE should be avoided - it forces OSG to use manual calls, at least for me. Changing the normal binding to vertex (at 4x the memory for the normal array) gets the performance back to 'sane'. There's still quite a big FPS hit (eg, 50 FPS down to 30FPS over the centre of Edinburgh), but it's not 'crazy-off-the-scale-slow'. I did a check, and fortunately nothing else in our code is using BIND_PER_PRIMITIVE. Yes, there is that 'fast path' and there is already a method at the geometry that tells you if it will run in the fast path or not. I believe the method is areFastPathsUsed or something like that. And it's a bit tricky to trigger the flags evaluation. But looking at the source helps. In the end its all about if there is a corresponding OpenGL draw call that can just work on the unchanged arrays. Nice work so far. From some distance it looks pretty good. Thanks Mathias -- 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
Yves: Towns are not point features. The vmap0 represents towns as points, but these particular points are parsed by terragear and turned into 1km by 1km polygons which are burned into the terrain. That gives the square appearance in the default scenery. Hi John Yes, Im aware of this behaviour of terragear and vmap0. But I also remember this town model, a european church-like building with some houses grouped, all with same elevation. This looked very ugly i.e. in mountain areas (half of the village in the hill, rest hovering over terrain). And without this models you see this squares, which is the most atypic form for a small housing scheme/settlement/village in most places of the world. When the random buildings can be used to represent a settlement in near future and with new generated scenery I thought maybe its time to change cs_town from point to polygon feature from the beginning of scenery creation/digitizing now, and also remove this point to square option of terragear completely. Without claiming to have complete overview myself, I dont know any natural landclass where such geometry make sense. When it is not possible to change cs_town definition to polygon I will vote for an additional landclass, even Im sure we should reduce the classes ... -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 Wed, Apr 25, 2012 at 9:03 AM, wrote: Yes, I’m aware of this behaviour of terragear and vmap0. But I also remember this town model, a european church-like building with some houses grouped, all with same elevation. This looked very ugly i.e. in mountain areas (half of the village in the hill, rest hovering over terrain). And without this models you see this squares, which is the most atypic form for a small housing scheme/settlement/village in most places of the world. 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. -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 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. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Random Buildings
On Wed, 2012-04-25 at 08:26 +, 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 don't mind if it gets reverted but I did respond and have stated I did not have time to either create new building models (which is highly needed anyhow) or revert it myself. Erik -- 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
Erik Hofman wrote: On Wed, 2012-04-25 at 08:26 +, Martin Spott wrote: 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 don't mind if it gets reverted but I did respond [...] Ah, looks like I've missed that one. Sorry, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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: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
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] 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
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
-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
On 25 Apr 2012, at 11:53, Vivian Meazza wrote: Removed in Git Alas this makes no difference. Performance drop is roughly linear in the building density, though I won't claim it's strictly linear. Given that this is an Ati 5770, I would be *extremely* surprised if I'm fill-rate limited. Very suspicious. 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 12:05 PM, James Turner wrote: Performance drop is roughly linear in the building density, though I won't claim it's strictly linear. Given that this is an Ati 5770, I would be *extremely* surprised if I'm fill-rate limited. Very suspicious. Have you tried areas other than Berlin? 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? 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). -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 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
On 25 Apr 2012, at 12:56, James Turner wrote: 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. http://files.goneabitbursar.com/fg/no-buildings.png http://files.goneabitbursar.com/fg/with-buildings-density-1.png Observations - where did all the quads come from? Is my card going to a slow path to submit quads? - 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...) (there's obviously been a change in camera #1 too, but I'm ignoring that, hopefully that's reasonable) 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! Other suggestions most welcome. 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 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
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] 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
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
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
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] Random Buildings
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote: 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) This doesn't fit my understanding (but I'm almost certainly wrong) I was under the impression: - culling at the primitive level is slow, so if any part of the bounding volume of the build drawable is visible, just send the whole lot, it's already in a VBO on the GPU anyway... - LOD would show the drawable/geode as soon as any corner is close enough to the viewer, not the centre Both of these things will cause more 'drawing', but with less time on cull and no issue with popping. And the drawing should be fast for all the reasons we already know. Of course, in this particular case the drawing is slow, but that seems a highly specific bug. Which I really hope I can find a work-around for. 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
Am 25.04.2012 13:35, schrieb Stuart Buchanan: Also, there is a significant slow-down in scenery loading. I can certainly confirm ;-). It's not just a longer delay for initial start-up (splash screen takes much longer to drop), it's also causing issues with scenery taking too long to be loaded at run-time, so the aircraft sometimes flies into a patch of void. It also seems to delay unloading of scenery tiles (noticeable when trying to shutdown). This reminds me of an issue we had a while ago, where we had a huge number of shared models (cattle and horses) scattered across the scenery. Something in OSG doesn't scale well with huge numbers - which only caused issues when trying to unload a scenery tile. Since loading and unloading is done in the same thread, this also caused the loader to almost stall. Not sure, if this could also be a factor here. At the time, the only solution we (mainly Tim) saw, was drastically reducing the number of shared models (cull the cattle... ;-) ). Another issue: the density range in the rendering dialog is 0-10. However, even with density 1.5 the buildings look pretty packed. For me, only a density of 0.17 is about usable (avoids the void scenery patch issue). This, however, is the lowest possible setting on the slider - and is very tricky to adjust (just try to configure such a low value, you'll see what I mean). Can we somehow change the slider to a lower range, e.g. 0-3? Not sure if higher values made any sense at all. Actually, I have the same issue with the vegetation density slider. Does the range 0-10 really make any sense to anyone? A lower range would make it much easier to configure usable values on the slider. 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
Hello, Well done! A great enhancement! Now towns and Cities looks like they should! Here on my system Framerates are really good, but yes scenery loading needs some time- until framerates are stable enough to use it needs a much longer time. A very big surprise to me was that all buildings are landable- great for all heli-pilots! O.k., textures could be improved- but I guess we have some graphic talents out there, which can help- at least I hope. This, however, is the lowest possible setting on the slider - and is very tricky to adjust (just try to configure such a low value, you'll see what I mean). With todays GIT it seems to me that the buttons in all dialogs are much smaller than before- optical illusion, or does someone else noticed it? Actually, I have the same issue with the vegetation density slider. Does the range 0-10 really make any sense to anyone? A lower range would make it much easier to configure usable values on the slider. Agree- 10 is unusuable, and would be even unrealistic dense, even for woods. So in the moment RandomBuildings works perfect to me- even at LOWI. (6 years old DualCore 2,6Ghz, 4GB Ram, Nvidea Geforce GTX460, win 32 xp) Thanks and Cheers 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 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
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
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
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
Yves: Towns are not point features. The vmap0 represents towns as points, but these particular points are parsed by terragear and turned into 1km by 1km polygons which are burned into the terrain. That gives the square appearance in the default scenery. In custom scenery, medium to low density urbanized is typically mapped to town. In any case in my opinion materials.xml should represent the cs_ layers on the mapserver in order to increase flexibility for scenery generation. Thanks John -- 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 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
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] 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 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
Re: [Flightgear-devel] Random Buildings
On 18 Apr 2012, at 10:25, Stuart Buchanan wrote: 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. Fantastic. 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. 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. James -- 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
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: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
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
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
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
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] Random Buildings
2012/4/18 Mathias Fröhlich wrote: 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. I think I've already got that covered. I'm using a single osg::PrimitiveSet, and a single list of QUADS/vertices/normals/colors/textureCoords at the leaf of each Quadtree. -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 17:21:56 Stuart Buchanan wrote: I think I've already got that covered. I'm using a single osg::PrimitiveSet, and a single list of QUADS/vertices/normals/colors/textureCoords at the leaf of each Quadtree. Great! Thanks! 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
