On 1 Dec 2011, at 09:31, Stuart Buchanan wrote:
> 
> I was thinking I'd need a cuboid per floor so I can use textures
> efficiently. I'm thinking of a texture file that contains a number of
> horizontal texture strips, each representing a floors-worth of walls
> for a different building. I think I need a cuboid per floor so they
> can repeat on the x-axis but use the same texture strip for each
> floor. Otherwise I need a separate texture file for each different
> building type, which I understand is particularly inefficient.

Hmm, can't you just use texture-repeat to achieve this? You definitely want to 
use a single texture (and hence, state-set) for all the buildings if possible.

> That's an interesting idea. I was planning something more complicated,
> with each building being considered separately purely because I could
> re-use a lot of the code/knowledge I already had from the trees. A
> single mesh per tile might be a bit much (I think there's a limit on
> the number of vertices per object?), but certainly a mesh per triangle
> should work and might in fact be simpler to implement.

The limit of vertices per buffer is pretty high, I would be surprised if that's 
the constraining factor. The key point is that GPUs are fast on large 
quantities of un-changing data, all with the same state-set - so the fewer the 
better. Ideally you'd have one state-set for all the 'buildings' meshes, and 
one mesh/drawable per tile, all sharing that state-set, and all marked as 
static in OSG land. This should be maximally friendly to the GPU, even for 
'enormous' vertex counts.

James


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to