[osg-users] Fwd: SKYBOX ?

Jeremy Moles jeremy at emperorlinux.com
Wed Sep 3 11:27:45 PDT 2008


On Wed, 2008-09-03 at 13:17 -0400, Jean-Sébastien Guay wrote: 
> Hello Nao,
> 
> > Would you have some advice about this, please?
> 
> Please don't send e-mail to someone directly when you post questions on 
> a mailing list. If I didn't reply, there are a couple possible reasons, 
> which may be that I didn't get to it yet, or that I don't have anything 
> to add (which is the case here). In any case, it's kind of like assuming 
> that your question takes precedence over whatever else I may be doing, 
> which is a bit rude. Like most people on the mailing list, I have paid 
> work to do, and answering messages on the list is done on the off-time 
> (while something compiles, or whatever).
> 
> > Now, when I try to use a 2048x2048 jpeg image for the texture, I get
> > this message (after viewer.run()):
> > 
> >  Scaling image 'skybox-1.jpg' from (2048,2048) to (512,512)
> > 
> > And indeed the image seems rescaled to 512x512.  It does not have the
> > quality of 2048x2048 image.
> > 
> > Is there a way to use the 2048x2048 image without rescaing?  What
> > component is enforcing this 512x512 restriction?

These values are determined by your OpenGL driver. The osg::Image class
queries these values and ensures that all images adhere to this (see
osg::Texture::getExtensions(...)) and the method ::maxTextureSize.

In your defense, however, I'm not able to actually get any test code for
Extensions working at all. Some of the examples create Extensions
objects (osgvertexprogram, osgmultitexture), but they never return a
valid pointer--at least for me.

> I have no idea why OSG would scale an image from 2048x2048 to 512x512. 
> As far as I know, OSG should only auto-resize an image if its dimensions 
> are not powers of two, and 2048 is a power of two...
> 
> You could place a breakpoint where the message originates (search for 
> "Scaling image" in the OSG sources, and place a breakpoint there) and 
> then run your application, and when the breakpoint is reached, examine 
> the call stack to see where the resize originates from.
> 
> Sorry I can't help more.
> 
> J-S




More information about the osg-users mailing list