On Saturday 30 April 2011 15:05:58 Heiko Schulz wrote:
> Hello,
> 
> > Hmm, that depends. If those textures should be displayed
> > all the time (like a
> > livery), then yeah, I agree, one big texture is better than
> > many smaller ones,
> > also depending on your texturing needs. On the other hand,
> > if you're not
> > displaying half the texture most of the time, I think
> > that's wasted VRAM, that
> > could be freed for another texture of the same size. This
> > might seem just a
> > bit of wasted memory, but when you have 10-15 different
> > buildings with such
> > textures things start to add up, and you'd be using as much
> > memory as for
> > 20-30 different buildings, and where you have a detailed
> > village you could have
> > two or more.
> > 
> > Just my o.o2RON on the matter :P
> > Emilian
> 
> Yes, interesting thought, I understand. But I always thought that the
> process of loading and unloading textures settles down the perfomance and
> that'y why it is better to have them only loaded once and keep them in
> VRAM.
> 
> But maybe this only true when you not use any .dds-textures. I guess with
> .dds-textures  it would make sense to have them then seperated.
> 
> Cheers
> Heiko

Performance is one thing, VRAM available is another. When you reach the VRAM 
limit you get in trouble and suffer a major performance hit. (See the 
.dds&clouds threads here, the major cloud redrawing visible on some machines 
due to VRAM getting exhausted). With twice as big textures, you get to that 
limit twice as fast, thus you can display only ~half the models until you hit 
the limit.  

.dds textures help in different ways(less VRAM used for the same pixel size, 
faster loading due to embedded mipmaps, thus reducing the stutering noticed 
when one new texture gets loaded, etc..), but the same reasoning above can be 
applied to them, too.

Emilian

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to