Alright to add what I have found thus far. We went back and reconverted the images using an option when we saved to flip the images vertically. By doing this I don't have to do anything in the code. The only difference between loading jpgs and ddss now is the extension at the end of the filename. I ran my code 100 times with jpgs and it always worked fine. When I ran it 100 times with ddss, it averaged to every other run one of the textures would be screwed up. The other runs all of them were fine.
-----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Alright, so I am calling flipVertical() and setOrigin(osg::Image::TOP_LEFT) on the image before setting it in the Texture2D. In my current example I am loading 4 textures. As jpgs they always work fine. As dds, sometimes all 4 show up, and sometimes a different one will not show up. And it is a different one each time. Any clues? -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Ok, think I found the problem. DDS, being designed for DirectX, defines (0,0) as top left whereas OpenGL defines it as bottom left. So all I should need to do is flip it. On to do that.... -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 8:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, "Cary, Karl A." <karl.a.c...@saic.com>: > Will I need to do anything in osg to make sure it uses the pre-generated > mipmaps stored in the DDS file and not recreate new ones? Working on saving > the textures out as dds now. > > -----Original Message----- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Sergey Polischuk > Sent: Monday, August 27, 2012 2:23 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Texture Questions > > Hi > > You can use compressed textures in dds format, as they support dxtc texture > compression. You can create those with ati compressonator tool, nvidia > texture tools, or in photoshop using nvidia plugin. For rgb images you'll get > 6x compression ratio. Also, you can save textures in dds format with > pre-generated mipmaps, if you need those. > > Cheers. > > 24.08.2012, 21:13, "Cary, Karl A." <karl.a.c...@saic.com>: > >> I do have the ability to pre-process. The question is, what file >> formats support openGL compression and how do I take them from jpeg >> to >> these formats? As for mipmapping, you mentioned that it can be done CPU >> side. >> How do I initiate this? Since the texture load is happening in a >> separate thread, I can afford CPU time to do this rather than >> pushing >> more on to the GPU. I can test out to see if it is worthwhile. >> >> -----Original Message----- >> From: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of >> Robert Osfield >> Sent: Friday, August 24, 2012 11:40 AM >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] Texture Questions >> >> Hi Karl, >> >> On 24 August 2012 14:40, Cary, Karl A. <karl.a.c...@saic.com> wrote: >>> I have an application that loads several 2048x2048 textures in a >>> separate thread before passing off to the main to be applied to >>> the >>> geometry. I am trying to do anything and everything I can to >>> improve >>> performance on them as the number of textures will increase from >>> several to quite a lot. So I am looking at every option I can and >>> have >>> run in to several questions that I was hoping to get some advice on. >>> I >>> am creating osg::Texture2D and loading them with an osg::Image >>> read >>> in >> from a jpg file. >> >> Excatly how many textures are you talking about? >> >> Will of the texture reside in memory and be rendered at the same time? >> >> Do you have an flexibility w.r.t pre-processing the image data into >> other file formats? >> >> What pixel format do the textures have? RGB? >>> 1) Is mipmapping enabled by default? Or do I need to call >>> allocateMipmapLevels? >> By default the osg::Texture* will use trilinear mipmapping, if the >> osg::Image doesn't contain the mipmaps then it'll either generate >> them >> on demand in the rendering thread either done by the GL driver or >> GPU >> using OpenGL extensions for generating mipmaps, or on the CPU using >> GLU functions when the driver doesn't support the generate mipmap >> extensions. >> >> You can switch the mipmapping off by just setting the >> texture->setFilter(Texture::MIN_FILTER, Texture::LINEAR); >>> 2) If it is enabled, how many levels are created by default? >> osg::Texture* will automatically work out how many levels are >> required >> based on the dimensions of the texture. >>> 3) Would changing the internal format mode to one of the >> compression >>> formats actually perform the compression or does that need to be >>> done >>> manually? >> If the source imagery is not in an OpenGL compressed format then the >> driver will do the compression for you, however this is an expensive >> operation so generally not one you'd during rendering, rather OpenGL >> compression is something you'd want to do in pre-processing step. >>> 4) If I do need to do the compression, how can I do it >>> without >> applying >>> it to geometry in my separate thread? I have only seen it done via >>> the >>> CompressTexturesVisitor applied to a node (as in osgconv), would I >>> have to make some empty node and apply the texture to it to do this? >> To compress in a background thread you can use the OSG's now support >> for compressing textures using NVTT (there is plugin for this when >> you >> compile the OSG when the NVTT SDK is available). You'll need >> OSG-3.x >> for this. >>> 5) Is there any way to send a texture down to the graphics >>> card >> prior >>> to applying it to geometry? >> You can pre-compile objects using the IncrementalCompileOperator, >> however, this is still done as part of the rendering thread so >> depending upon your requirements might not make a difference. >>> 6) Any other efficiency things I should be looking at? >> Pre-processing data so that it's pre-mipmapped and using OpenGL >> compressed texture is the best way if you want to maximize >> performance >> throughput of textures as this reduces how much work the CPU and GPU >> need to do to download and use the data. OpenGL compression is less >> aggressive than compression supported by conventional image formats >> so >> the files on disk will be bigger. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> or >> g >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
