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 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
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
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
Hi All,
This is to give a heads up on some changes that I'm planning for
Random Buildings for the V3.0 release, and to allow for
comments/suggestions/ideas.
In 2.12.0 the algorithm for the placement of random buildings is a
rather scattergun approach. materials.xml sets a building density
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
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,
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
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
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote:
This is to give a heads up on some changes that I'm planning for
Random Buildings for the V3.0 release, and to allow for
comments/suggestions/ideas.
I've now got the new system broadly working on a private build:
http://www.nanjika.co.uk
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
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
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
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, 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
Hi All,
I've just pushed two fixes for possible memory leaks in random
vegetation and buildings.
One was noticed by valgrind, the other is speculative, to make use of
osg::ref_ptrs where
possible.
At the same time, I've changed the random vegetation so that the
normals are bound
per-vertex
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
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
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 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
to the previous implementation
from (IIRC 2.8.0) where the buildings were collected into massive objects as
it provides collision detection and more variety.
On Fri, Oct 11, 2013 at 1:54 PM, geneb wrote:
Is it possble to place buildings manually and have the random buildings
fill around them without
this into a procedural city generator
which would take a street network and then reasonably places (random)
buildings. The ultimate goal is (obviously) to improve FG's representation of
cities.
It's at a rather early stage, and for the moment I prefer python for quick
prototyping. BUT, I know
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on .ac models, plus the Urban shader.
The former are limited
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
Hi All,
I'd like to propose having random buildings enabled in
preferences.xml, so they are switched on by default. I think they
improve the realism of our Urban, Suburban and Town sceneries significantly.
I ran a poll on the forums to determine the fps impact of the random
buildings (http
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
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
2011/11/30 Stuart Buchanan stuar...@gmail.com:
At the same time, I'm anticipating aligning the buildings with the
texture, and probably using a second texture as a mask to indicate
where buildings may, or may not, be placed.
Can you use low-bit gray (or index) mask, to indicate not only
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote:
It's a fact that the distances out to which we draw trees and buildings are
considerably less than how far we potentially draw terrain (120 km max.) So
these things are separated even now - we don't attempt to render random
), and the red channel the rotation.
So instead of a material designer blocking out a large area for random
buildings to be placed within, they will define the specific location
for each random building.
Which would in fact not make them random buildings at all :-)
May I propose to think about
, for farmland,
the farm buildings etc. will
appear at the ends of roads rather than in the middle of fields*, and
in urban areas random buildings will align with the streets** (which
works well with the urban shader
IMO).
As an extra bonus, I've also added a property
(/sim/rendering/vegetation-density
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
that we enable the random buildings by
default as well.
Does anyone have any objections, or want to second the proposal?
Your work does really look great, especially at areas like San Fran, LA and
other big cities. It improves really much the graphics!
Framerates are better than expected
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
On 20 Sep 2013, at 11:04, Stuart Buchanan stuar...@gmail.com wrote:
The original random buildings implementation (2.8.0) use basic OSG
primitives, and so had collision detection and Rembrandt shadows for
free. In 2.10.0 this was changed to a shader-based instance
approach based on the tree
I ran a poll on the forums to determine the fps impact of the random
buildings
Oops, forgot to vote. Will provide some of my test-results here then:
Tested with the UFO, Rembrandt disabled, looking at downtown San Francisco
(plenty of buildings in view).
With KSFO being our default airport
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 Thu, Aug 9, 2012 at 10:06 AM, Renk Thorsten wrote:
Both options, random buildings and a realistic view range, are in my view
extremely cool as long as you know what you are doing with them, and I don't
really want to abandon either. But I suspect their combination (combined with
other
with the
c172p, waiting until the intial set of tiles is loaded with standard weather
conditions (e.g. no excessive visibility).
With random buildings switched off FG uses ~1GB memory. With v2.8.0
random buildings, it's 2GB. With instantiated buildings at present it is
1.5GB.
At KLAX, it's down even
/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
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
Stuart
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on .ac models, plus the Urban shader.
The former
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
(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
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 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 Fri, 11 Oct 2013, Stuart Buchanan wrote:
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote:
This is to give a heads up on some changes that I'm planning for
Random Buildings for the V3.0 release, and to allow for
comments/suggestions/ideas.
I've now got the new system broadly
On Thu, Sep 19, 2013 at 3:07 PM, Renk Thorsten wrote:
Which would in fact not make them random buildings at all :-)
It'll make them less random, certainly :)
However, while the placement and size class (small, medium, large)
will now be determined by the texture, there will be still
-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 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
scenery for that, so I've everything disabled by
default :-)
Just did another test, and the outcome is rather interesting I think. This time
with the 747-400:
0.00 : 45
1.00 : 35
2.00 : 30
Looks as if the buildings have a high impact, until the framerates come within
a certain range (around 25
and testing various things.
That sounds very familiar :)
Just did another test, and the outcome is rather interesting I think. This
time with the 747-400:
0.00 : 45
1.00 : 35
2.00 : 30
Looks as if the buildings have a high impact, until the framerates come
within a certain range (around 25-30
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
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
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
I've been playing with populating my home airport's area with buildings derived
from OSM floorplan data. I think having many buildings in the correct place
greatly improves realism over the current random buildings/sparse static
models, especially when you know the area.
However, now
should do. In fact, by chance
the combination of options we offer is quite dangerous.
* before the new edition of random buildings came out, I've played a lot with
opening up visibility at high altitude. Even for a ground visibility of less
than 8 km, you'd get 120 km at airliner cruise
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
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 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
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 error is not exclusive for the random buildings (at least with the
win 32bit fgfs).
Just try to fly over detailed scenery long enough. With trees enabled
the problem shows up sooner.
And if you use a heavy airplane like the 787-8 from Omega95, fgfs will
run out of memory on startup if you
On Thu, Aug 9, 2012 at 10:46 AM, Stuart Buchanan wrote:
On Thu, Aug 9, 2012 at 10:06 AM, Renk Thorsten wrote:
Both options, random buildings and a realistic view range, are in my view
extremely cool as long as you know what you are doing with them, and I don't
really want to abandon either
On Fri, Dec 14, 2012 at 12:28 PM, Adrian Musceac wrote:
Oh one more thing, The random buildings and trees definetly receive shadows,
but they don't cast it.
Is that the way it should be? Asking because I'm about to push the
modifications to my simgear clone.
The trees were definitely both
/simgear/scene/model/ModelRegistry.cxx
Avoid spitting gazillion 'Cannot find image file ' message on the
console while loading random objects
2f585eeea02e2c79d7b1d8c4963bae
I assume that the random objects include buildings. Starting up at KSFO last
night after updating my sources
.
Using the DDS textures, the effects can be quite convincing:
http://www.nanjika.co.uk/flightgear/object_mask.jpg
Note that these are all random objects - none of the buildings or trees were
placed manually.
The rotations aren't perfectly aligned with the textures, but it's fairly close.
Vivian
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
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
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
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
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
buildings nor the random vegetation in the
screenshot are currently implemented in the scheme - that makes it a bit hard
to see if there's something going wrong in the screenshot, random buildings and
static buildings should have different lighting to dome degree. Do they respond
to fog (ground haze
I was not referring to a frame rate issue, but FG running out of memory.
http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392
It is rare to see that happening using the current scenery, but here if I
select random buildings and objects with a high value for trees, I can
)
With xml:
Using c172P 3d-panel; disabled 3d-clouds, disabled Random objects, disabled
shaders, Framerate-Throttle 30fps:
26L: 31 fps
Same positions looking to the village: 31fps
26R: 31 fps
Same positions looking to the village: 31fps
08R: 26-27fps
Same positions looking to the village: 26-28fps
the intial set of tiles is loaded with standard weather
conditions (e.g. no excessive visibility).
With random buildings switched off FG uses ~1GB memory. With v2.8.0
random buildings, it's 2GB. With instantiated buildings at present it is
1.5GB.
At KLAX, it's down even further, from 2.7GB
are ignored
- of other shader-generated stuff: 3d-clouds, Stuart's random buildings, random
vegetation is unsupported
* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's
On Sat, Jun 30, 2012 at 12:49 AM, Stuart Buchanan wrote:
Hopefully I'll be able to do a similar fix for the random buildings
before the release.
This is now done as a first pass, with the proviso that the atmospheric
scattering disables the emissive and reflective building characteristics
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: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
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
draw trees and buildings are
considerably less than how far we potentially draw terrain (120 km max.) So
these things are separated even now - we don't attempt to render random
buildings in 80 km distance even if we render terrain. Nobody proposed to
render buildings to the visibility range
for it automatically, but I have almost no knowledge about 3D objects.
Might be worth checking it out.
While a good LoD system helps with graphics load, it doesn't help with overall
memory load (unless it's a PagedLOD), which was the problem with the buildings.
We have fairly good LoD solutions
this will
reduce overdraw to zero - solving both the 'cockpit covers terrain'
optimization, but also where random trees or buildings do. (Which is
presumably where your 30% gain comes from)
I guess there's only trees, random buildings, cockpit and clouds which can
cover substantial parts of the scene
defining sets of buildings with
heights, widths, textures and spacings on a per-material basis,
comparable to the existing random vegetation.
On Thu, Dec 1, 2011 at 8:46 AM, Vadym Kukhtin wrote:
At the same time, I'm anticipating aligning the buildings with the
texture, and probably using a second
which have a certain mask set (in our case, it's
SG_NODEMASK_TERRAIN_BIT)
Unfortunately, not only the terrain surface has this mask set, but also random
objects, random trees, and 'random' buildings. They all share this mask, so an
_get_elevation_ call will have to traverse through litterally
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
since.
The random buildings I'm less certain about. The 2.8.0 version
certainly both cast and
receive shadows. I'm not sure I've tested shadows since I changed
them to an instantiation
model post 2.8.0.
Sorry I can't be more definitive.
Ok, let me revert to next and test again. I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Megginson wrote:
What are the issues with OSG around dynamic scenery (trees, non-static
randomly-placed buildings, 3D clouds, etc.)? Is it just a matter of
spending a few hours coding, or is there something in the OSG APIs
that makes
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
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
since.
Ok, I've just tested this with current Git, and buildings except random
models, as well as trees, don't cast shadows, but receive them.
I do remember a time when buildings cast shadows too, I think.
I'll try to research this further.
Cheers,
Adrian
and then reasonably places (random) buildings. The
ultimate goal is (obviously) to improve FG's representation of cities.
It's at a rather early stage, and for the moment I prefer python for quick
prototyping. BUT, I know quite some C/C++, and compile from latest GIT sources
regularly
On Wednesday, September 18, 2013 19:05:22 Stuart Buchanan wrote:
I did take a look at the PagedLOD approach - Matthias' code made a great
template to work from.
-Stuart
Stuart, this is totally unrelated, but what would be the price to pay to have
collision with generated buildings
Gérard wrote:
Hello,
Is it only me ? or is there a funny behaviour with the random objects ?
I have found trees into the stadium :)
http://pagesperso-orange.fr/GRTux/RandomTreesAndStadium.jpg
No, it isn't just you :)
The random objects, including trees, are placed randomly based
indicates the
rotation.
Using the DDS textures, the effects can be quite convincing:
http://www.nanjika.co.uk/flightgear/object_mask.jpg
Note that these are all random objects - none of the buildings or trees
were
placed manually.
The rotations aren't perfectly aligned with the textures
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
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
submodels being microwave photons in that case)
Hehe, yes. Except that ours don't come back. And I'm not sure
if they collide with static/random buildings. They hardly do
with trees. Hmm ... cows?
m.
-
This SF.net email
I think X-Plane is using texture splatting.
Please read this blog post from Ben Supnik (X-Plane scenery developer) that
I read a few years ago:
http://www.x-plane.com/blog/2008/12/dealing-with-repetition/
It deals not exactly with the smooth transition problem, but this technique
could be applied
1 - 100 of 291 matches
Mail list logo
