Hi Robert,
My team have traced to using hardware generation of mipmaps as the reason
why the compressed texture loads slower than uncompressed texture. We do not
know the exact reason and have reproduced the same behaviour across NVIDIA and
Intel-based GPU on both Linux and Windows system.
H Boon,
This is a driver/hardware specific issue rather than an OSG one. If you
want to understand this then it would be best to approach the NVidia or
Intel support forums.
Robert.
On 17 March 2014 02:22, Boon Wah boon...@gmail.com wrote:
Hi,
It appears that within texture.cpp in
Hi,
It appears that within texture.cpp in core OSG library, glTexImage2D is
faster than glCompressedTexImage2D by about 80 - 100%.
glTexImage2D is used when the texture data is uncompressed (e.g. RGB24) and
glCompressedTexImage2D is used when the texture data is compressed (e.g.
Hi Jimmy,
Performance of various OpenGL calls is very dependent upon the driver and
hardware you have, and in particular what formats they accelerate on the
GPU varies, if you don't use the fast paths for that driver/hardware
combination then you can see big performance drops as the operations
Hi,
I notice that glCompressedTexImage2D takes the longest time during texture
loading. Can I understand what does this function actually does?
I thought the texture decompression is handled by GPU, and loading to GPU
actually should be significantly fast. In my testing, uncompress
Hi,
I tried --compression flag and --compression-dxt1 flag in OSGDEM. However,
when I step through OSG when I view the IVE, I noticed that the texture
compression all defaults to SCTC-DX1. The size of the compiled textures are the
same.
Can anybody advise on how to select the ARB
Hi Jimmy,
I don't recall the options or whether compressed greyscale is possible with
VPB/osgdem as it's a while since I worked on the code. What may be the
best thing to do is simple disable compression, the option is probably
---no-compression.
Robert.
On 18 October 2013 14:59, Boon Wah
jimmy82 wrote:
Hi,
Is there any way that I can choose a suitable texture format that
represents only 8-bit gray-scale texture? So far, I understand that the
internal representation of gray-scale and coloured texture are similar under
OpenGL compression schemes and S3TC.
All S3TC
Hi,
I am compiling a large satellite imaginary using OSGDEM.
As I want to reduce the size of the texture to a minimum, I worked only
with gray-scale 8-bit satellite imaginary.
Is there any way that I can choose a suitable texture format that
represents only 8-bit gray-scale
9 matches
Mail list logo