Hi Stuart,
If there's anything you need to do in fgfs-construct to orient these
textures, let me know.
I'm reworking it now to texture the vector data, so I'll have texture
coordinates matching road direction.
But I'm assuming by aligning the buildings with roads, you mean the roads
in the urban / suburban texture,
not the vector data
I'm going to try to experiment with a buffer area around freeways that may
give a better impression as they traverse urban areas.
Pete
On Thu, Dec 1, 2011 at 4:51 AM, James Turner <zakal...@mac.com> wrote:
>
> 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
>
------------------------------------------------------------------------------
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
