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.


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.
Flightgear-devel mailing list

Reply via email to