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
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
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
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
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,
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
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
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).
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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,
-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
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
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
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
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 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!
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
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
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
Hi All,
I've just committed a change that adds emissive lighting to the random
buildings:
http://www.nanjika.co.uk/flightgear/buildings-evening.jpg
At present, this only works with rembrandt and the skydome switched off.
You'll need generic shaders switched on.
-Stuart
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
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.
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
Hi All,
I've made a couple of updates to the random buildings to address some
of the feedback received so far.
1) As suggested by Thorsten R. I've changed the placement algorithm
from random to a grid-like arrangement. This should allow faster
scenery generation, as it allows me to reduce the
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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.
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
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
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.
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
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,
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
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)
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
Hi All,
A while back I initiated a discussion about improving our random
buildings, and got lots of very useful feedback and suggestions. The
first part of this (masking of random object and vegetation placement
to match the underlying terrain texture) has been in git for some
time.
I have
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
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
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.
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
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
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
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
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
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
99 matches
Mail list logo