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