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 = logf((float)t)/log
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 textures
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 possibl
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
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 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
mipmaps
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 Christian,
On 10 January 2013 09:31, Christian Schulte 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 of floor, because in
>
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,
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 pl
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.
Christian
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 Schu
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 math.
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 de
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 i
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( ddsd.dwMipMa
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 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 wrote:
> Hi,
>
> I have a terrain model with 1024x1024 DXT1 textures. Using a min filter with
> LINEAR_MIPMAP_LINEAR the te
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" :
> Hi,
>
> I have a terrain model with 1024x1024 DXT1 textures. Using a min fi
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.
--
Re
20 matches
Mail list logo