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:
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
Hi Tim,
On Fri, Oct 11, 2013 at 12:55 PM, Tim Moore wrote:
Cool stuff. Are those all individual models, or instanced geometry, or what?
:)
The vast majority are instanced geometries, though there are some random
models interspersed.
As mentioned previously, I'd like to move back to the
On Thu, Sep 19, 2013 at 3:07 PM, Renk Thorsten wrote:
Which would in fact not make them random buildings at all :-)
It'll make them less random, certainly :)
However, while the placement and size class (small, medium, large)
will now be determined by the texture, there will be still be
On Friday, September 20, 2013 13:04:32 Stuart Buchanan wrote:
If I implement a PagedLOD approach, it might reduce the memory
footprint sufficiently that we could switch back to the OSG
primitives.
I think one of the problems is that most of our objects have no concept of
different LOD's.
On Fri, Sep 20, 2013 at 11:15 AM, Adrian Musceac wrote:
I think one of the problems is that most of our objects have no concept of
different LOD's. If we had objects with say 3 LOD, it would ease memory and
graphics load. It should be possible to take an object and generate multiple
LOD's for
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
So, in V3.0 I plan to change this. Instead of using a scatter-gun
approach to placement and a mask, random building location will be
read directly from the mask, defined by a single pixel. The color
(actually blue value from 0-255) will define the size of building
(small medium, large),
On Wednesday, September 18, 2013 18:45:09 James Turner wrote:
(BTW Adrian proposed something which achieves a similar end result back in
February, the problem with his approach is it doesn't work via the OSG
paging mechanism, and hence I don't think we should pursue it - ultimately
we need to
On Wednesday, September 18, 2013 19:05:22 Stuart Buchanan wrote:
I did take a look at the PagedLOD approach - Matthias' code made a great
template to work from.
-Stuart
Stuart, this is totally unrelated, but what would be the price to pay to have
collision with generated buildings, and
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 Wed, Sep 18, 2013 at 4:45 PM, James Turner wrote:
It would really help memory use if we could defer tree/object/building
generation until the tile is close to the viewer. Right now you generate
lots of LOD nodes so we don't pay the rendering cost for distant tiles, but
we're still paying a
On 18 Sep 2013, at 17:05, Stuart Buchanan stuar...@gmail.com wrote:
I did take a look at the PagedLOD approach - Matthias' code made a great
template to work from.
Yes, that is exactly the model I would follow, and I am sure Mathias can be
asked for additional hints on the best way to
13 matches
Mail list logo
