Robert Osfield wrote:
Hi Laurens,
On Tue, Nov 3, 2009 at 5:08 PM, Laurens Voerman <[email protected]> wrote:
in order to save (texture)memory I am using a pagedLOD tree to lower the
texture resolution in the distance. In order to save disk space (and
simplify database creation) I modified the dds reader to read a
mmToSkip=n
readerwriteroption, which creates an osgImage from the n-th mipmap.
This works very nice, but there is a drawback: the cache is not aware of
the
options, so also attached is a ".mip" pseudoloader which sets the option,
disables the cache and reads the file.
I am not sure about the setup with the mip pseudoloader workaround for
the
cache, suggestions for a better solution are welcome.
I find this submission a bit odd. Lowering the texture resolution at
a distance suggest to me that your database isn't built appropriately
- as the distance LOD levels should be reducing the texture size per
pixel in a consistent manner from near to far - the aim should be to
have roughly a texel per pixel.
Jup, my database has a pagedLOD tree keeping the textures used at about a
texel per pixel.
You also say that to save disk space your modified the dds reading to
skip mipmap levels. I don't quite understand how reading is related
to to disk space, as it'll only effect the CPU and GPU memory
consumption. Or is it that you are using this feature during database
creation?
The pagedLOD tree needs a new texture FILE for each lod level.
This submission avoids that by reading the lower mip stack from the master
image file.
The pseudo loader feels pretty odd too, a lot of code for a very
specific feature that I is only likely every to be used in very
specific applications. This does seem like a good candidate for
inclusion into the core OSG, and more something I'd leave up to users
to implement if need be, or for use to look at other means for
achieving this end. I don't understand how the cache plays in with
what you are trying to achieve.
The option makes the dds reader skip data, so i don't want that version
cached, as it is not complete.
Overall this submissions seems to be pushing specific art path tricks
onto the OSG that really belong in the client application.
True.
It is working perfectly fine as part of my application, and I hesitated
quite a long time before submitting, as I am not entirely sure about the mip
pseudoloader.
The mip pseudoloader is addressing a general problem, that the cache does
not take options into account. This is a problem for all options changing
the result of a read, as the result of the first read is returned from
cache, so the current options are ignored.
A more generic solutions for this problem would be to add the
readerWriterOptions to the cache.
Your thoughts on this please?
I think the modification to the dds reader is a useful submission even if
you reject the "mip" reader.
Cheers,
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
