I think there are a couple more points to consider with .dds format:
a) you can pregenerate the lower mip-map levels using a higher quality
algorithm than the simple box-filter OSG provides when it generates them on
the fly. This can often lead to noticeably better looking models.
b) The compressed dds format can be loaded into the video card and the data
can be kept in a compressed format on the card itself, saving texture ram.
c) png is smaller on disk, that's probably it's only benefit ... but jpg
would be even smaller at reasonable compression levels. Load times are
longer, most likely because the system is forced to compute the mip-maps on
the fly when the texture is loaded.
One other comment. I *thought* at one point we could load a single xml
reference model with animations and stuff, and then insert it many times
into the scene graph where ever we wanted (and only one copy would actually
exist with appropriate ref counting so it wasn't deleted until the last one
is removed from the scene graph.) For some critical models we used to bump
up the ref count by one when we first loaded it so the model was never
removed.
Perhaps this ability went away when we converted to OSG, or maybe some
subtle nuance of that changed? For clouds it would make perfect sense to
load a library of individual cloud fragment models, and then insert a
reference to those individual models into the scene graph ... but that may
not be possible though the nasal model loading and positioning interface.
Regards,
Curt.
On Tue, Mar 22, 2011 at 12:50 PM, <[email protected]> wrote:
>
> Okay, to summarize what I take from the discussion and all the tests:
>
> 1) Texture types: png seems to be best for load-once, then-keep problems
> because it has the smallest filesize, but takes a lot of time to load. dds
> seems to work well for some problems, possibly those involving opaque
> textures - here loading times can be reduced at (un?)-reasonable cost of
> file size. For my particular problem involving transparent textures, rgb
> seems to work best, so I keep it. The decision what format to use is not a
> 'one fits all' but must be made according to situation.
>
> 2) Texture cache: It seems clear, both by experiment and by Lauri's
> investigation that such a thing doesn't exist for models loaded from
> Nasal, possibly also other situations. If we had it, it would speed part
> of my code by factors O(100). So I'd seriously like to have it...
>
> However, since I can't do it myself, the alternative is to live with 'each
> model reloads the texture'. In this case, splitting multi-model texture
> sheets into one sheet for each model would possibly gain a factor 3 in
> speed - which is much less than a factor 100, but much better than 1.
>
> Thus, I'd like to know if somebody would be working on a general texture
> cache system in the future - if not, then I split texture sheets, that's
> messy but at least a bit faster.
>
> 3) xml: Somehow, xml wrappers are extremely bad. However, due to the need
> to make clouds immaterial and give them a dedicated shader, it's not an
> option to load the bare ac file. If anyone comes up with a faster way of
> passing this information, then I'll gladly use it - but for the time being
> I guess I am stuck with xml wrappers even if that means reduced
> performance.
>
> Using multi-layered models might help here, as then there's only a single
> xml wrapper to be parsed for 2 or more texture sheets, so maybe a factor 2
> is possible here.
>
> So, all in all, one can come up with a number of ugly workarounds which
> would help a bit, although a texture cache for models loaded from Nasal
> would be the 'big thing' needed here.
>
> * Thorsten
>
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
