Hi Karl, I haven't heard of dds specific problems like this, it might just be co-incidence that it's happening to the dds route, or perhaps something is happening on the OSG or OpenGL driver side. Unfortunately there isn't much we can do directly, you'll need to try and isolate the issue yourself. Things to look at would be whether the dds files are correct on disk, whether corruption happens on loading - perhaps you could do a hash of some kind of the images and check these on load to make sure that the loading is correct. Also try cutting down the number of textures used. Also try different hardware/OpenGL drivers.
Robert. On 27 August 2012 16:55, Cary, Karl A. <[email protected]> wrote: > 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: [email protected] > [mailto:[email protected]] 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: [email protected] > [mailto:[email protected]] 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: [email protected] > [mailto:[email protected]] 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: [email protected] > [mailto:[email protected]] 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." <[email protected]>: >> 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: [email protected] >> [mailto:[email protected]] 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." <[email protected]>: >> >>> 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: [email protected] >>> [mailto:[email protected]] 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. <[email protected]> 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 >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >>> or >>> g >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >>> org >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> org _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
