Hi,
I have a question. Why while reading dds file, to set number of mipmaps it is
using function osg::Image::computeNumberOfMipmapLevels( s, t, r ) but not what
is written in dds file header ?
I think that dds file knows better how many mipmaps it has inside.
Thank you!
Cheers,
Lukasz
Hi,
I think it is used as cross-checking method. Indeed, if the calculated
number (using osg::Image) is less than the number of mipmaps specified
in the dds file, the calculated value is kept. On the other hand if the
theoretical number of possible mipmaps is higher than the number of
Hi,
But for example we have 512x512 dds texture compressed with DXT1 and in header
we have 4 mipmaps.
In this example is meaningless to compute number of mipmaps, because OpenGL
,with my knowledge, does not generate mipmaps for compressed textures. So
setting bigger number of mipmaps is wrong.
Hi,
I didn't either find such a program being able to give a wrong number of
mipmaps, I only said that it may exist... Maybe it is better if Wojciech
explains us why he made this calculations. If we can indeed don't make
it it is ok for me, but it does not change anything to the fact that the
On 01/11/2013 08:26 AM, Christian Schulte wrote:
Hi,
I think it is used as cross-checking method. Indeed, if the calculated
number (using osg::Image) is less than the number of mipmaps specified
in the dds file, the calculated value is kept. On the other hand if the
theoretical number of
On 01/11/2013 09:00 AM, Lukasz Izdebski wrote:
Hi,
But for example we have 512x512 dds texture compressed with DXT1 and in header
we have 4 mipmaps.
In this example is meaningless to compute number of mipmaps, because OpenGL
,with my knowledge, does not generate mipmaps for compressed
I was summoned so I respond. Version of DDS plugin before my additions was
using this code to compute number of mipmaps (see revision 10369 of
ReaderWriterDDS.cpp ):
//debugging messages
float power2_s = logf((float)s)/logf((float)2);
float power2_t =
Hi,
I just tried the compilation of my test code on Microsoft Visual C++,
and the problem does not appear so it seems gcc linked... I will try to
recompile OSG on my different platforms using cmath in osg/Math, hoping
we don't see any other bugs.
Will keep you informed later today.
Hi,
I can confirm that it is working correctly on MS Visual C++ 2005 and
2010. Platform is Win7
cheers
Sebastian
Hi,
I just tried the compilation of my test code on Microsoft Visual C++,
and the problem does not appear so it seems gcc linked... I will try
to recompile OSG on my different
Robert,
I just tried another solution, which works and is maybe, let's say, more
correct from a coding point of view. Indeed, we want to floor a division
of two floats, so we should logically use floorf instead of floor,
because in math.h floor is only double. That's also the reason we don't
Hi Christian,
On 10 January 2013 09:31, Christian Schulte christian.schu...@onera.fr wrote:
I just tried another solution, which works and is maybe, let's say, more
correct from a coding point of view. Indeed, we want to floor a division of
two floats, so we should logically use floorf instead
Hi all,
I have investigated a little deeper the problem... Indeed, on
Windows platform, the number of mipmaps returned by
osg::Image::computeNumberOfMipmapLevels( s, t, r ) is wrong, but
it is correct on Linux platforms for the same dds file...
Here
Hi Christian,
Does this mean there is a bug in the MS version of math.h and the
floor function it provides?
Previously we haven't used cmath as some platforms didn't support it
properly, I recall IRIX being a problem, but am not sure if it extends
further than this. IRIX support has long been
Hi Robert,
I think the problem is linked indeed to a MS math.h problem, but in my
opinion it is not linked directly to the floor function but could affect
even other functions. I don't know what would be the consequences on the
global OSG behaviour but I agree with you that replacing the
I was about to ask why we aren't just using the log2 function here, but
apparently Microsoft doesn't consider this C99-standard function to be
important (ie: it's not included in Microsoft's math.h).
Seems like cmath is indeed the best solution.
--J
On 01/09/2013 11:39 AM, Christian
Hi,
i probably have solution for this problem, i have found a bug in dds plugin
ReaderWriterDDS.cpp
Line 633
unsigned numMipmaps = osg::Image::computeNumberOfMipmapLevels( s, t, r );
when compute numMipmaps returns wrong number. this number is less then number
of mipmaps in dds file(
I am using a nVidia GeForce GTX 580. And since 10 minutes also the latest
driver.
The problem can be solved by converting to a dds with only 8 mipmaps or
less...
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50893#50893
Hi,
I have a terrain model with 1024x1024 DXT1 textures. Using a min filter with
LINEAR_MIPMAP_LINEAR the textures are gone, changing only this filter to LINEAR
everything is back again. The textures contain 1 main image and 10 mipmaps...
Any ideas?
Thanks Cheers,
Tim.
--
Hi
it seems like osg dds plugin cant (correctly) read your mipmaps from dds file.
You can use file without mipmaps or try to dive in and find exact reason for
this behaviour.
Cheers.
30.10.2012, 14:19, Tim Rambau tim.ram...@dlr.de:
Hi,
I have a terrain model with 1024x1024 DXT1 textures.
Hi Tim,
Try running your app on a system with a difference graphics
card/driver, there is a change the issue is a driver bug.
Robert.
On 30 October 2012 09:18, Tim Rambau tim.ram...@dlr.de wrote:
Hi,
I have a terrain model with 1024x1024 DXT1 textures. Using a min filter with
20 matches
Mail list logo
