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 (SGBui
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 cur
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
>
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 st
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,
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.cx
Emilian Huminiuc wrote:
> http://mapserver.flightgear.org/map/?lon=-118.18562&lat=33.91857&zoom=11&layers=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 se
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 b
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 m
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
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
w
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
> > parti
> 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
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
be
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 agre
> 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 poi
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
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 betw
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 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
> 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)
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
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
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
On Sat, May 5, 2012 at 8:07 AM, Gene Buckle 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 i
> 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
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/G
Geoff
> > 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,
-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 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,
> 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
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
-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 st
> 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 abs
On 05/03/2012 11:47 PM, Stuart Buchanan wrote:
> On my system I get the following just SE of KSFO facing the city at
> ~155 degrees):
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?
For
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 li
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 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 ti
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 eve
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 def
Wow!
Stu, do you have plans to "regionalize" the autogenerated buildings?
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 Asi
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 fantas
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 T
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
---
> 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 i
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
> 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
On Sat, Apr 28, 2012 at 9:28 PM, James Turner wrote:
> 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
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 (
> 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
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 bu
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 a
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.j
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
Exclusiv
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
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
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 di
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 visib
Heiko
> 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 w
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 a
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
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 significant
> 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 ve
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 tak
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 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 buildin
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, de
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 wha
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-buildin
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 ru
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 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.
Ver
> -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 (da
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:
>
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 m
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 h
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: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. T
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 enab
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 r
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 th
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
> variou
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
"p
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 th
> 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 t
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 dens
> 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],x
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 obse
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 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 w
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
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 "rea
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. Urba
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
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 rando
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
-
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 cal
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
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 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 f
1 - 100 of 105 matches
Mail list logo
