Re: [osg-users] Rapidly updating texture data
Hi Jason and David, On Wed, Mar 3, 2010 at 10:09 PM, Jason Daly jd...@ist.ucf.edu wrote: Yeah, Performer wasn't written for OpenGL 2.0. OSG wasn't originally either, which is why it defaults to resizing all images. The resize hint was added for OpenGL 2.0 (actually for the ARB_texture_non_power_of_two extension) so the resize could be avoided if the hardware supported it. You could argue that it should default to not resize if the hardware supports it (i.e.: if the extension is present in the driver's extension string), but drivers have been known to lie in the past :-) For clarification, the OSG does enable the use of non power of two textures by default because with the introduction of OpenGL 2.0 drivers would implement non power of two textures as required by the spec, but do so in software for some hardware + texture filter combinations and in hardware in others, knowing whether hardware acceleration is present isn't possible which is very frustrating for a SDK/app developer, but alas that's something we just have to live with. Performance with the OSG doing the scaling of a non power of two texture to a power of two and still have rendering done in hardware results in far better performance than dropping the driver down to software paths for rendering due to use of non power of two textures, so the choice to assume the worst w.r.t driver/hardware support of non power of two texture has proven to be the best compromise. If you do know that non power of two textures are properly supported then you can enable this by setting texture-setResizeNonPowerOfTwoHint(false); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
J.P. Delport wrote: Hi Ben, I'm not sure if you are still scaling the image... If you are using Texture2D you can call texture-setResizeNonPowerOfTwoHint(false); on them to do not scale before uploading. Modern GPU are quite OK with non power of two textures. You can also use TextureRectangle instead of Texture2D. Sounds interesting! I assume that using TextureRectangle does not auto-resize the image file like Texture2D does? If so, that would solve one of my pet peeves in my life! Not to mention a consequence of letting users add graphic map images in my project – since I don’t expect them to understand the powers of two problem. That would save me some future grief! D Glenn! D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25123#25123 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
David Glenn wrote: Sounds interesting! I assume that using TextureRectangle does not auto-resize the image file like Texture2D does? Both Texture2D and TextureRectangle can work with non-power of two textures, if your graphics hardware supports it. Every OpenGL 2.0-compatible graphics card should handle this without a problem. The main difference with TextureRectangle is that it uses non-normalized texture coordinates, so if you have a 640x480 image, your texture coordinates on your geometry must range from 0-639 and 0-479 to show the whole image. The simplest thing to do is to call setResizeNonPowerOfTwoHint(false) on your Texture2D object, and all should be well. If so, that would solve one of my pet peeves in my life! Not to mention a consequence of letting users add graphic map images in my project – since I don’t expect them to understand the powers of two problem. That would save me some future grief! Yeah, the power of two restriction was removed with the release of OpenGL 2.0. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Yep, now I can use the full camera resolution of 1024x768. I knew OpenGL 2.x could handle non-power of two textures ... didn't realize it was possible to circumvent the resize. Thanks much Jason. Kudos! On 3/3/10, Jason Daly jd...@ist.ucf.edu wrote: Both Texture2D and TextureRectangle can work with non-power of two textures, if your graphics hardware supports it. Every OpenGL 2.0-compatible graphics card should handle this without a problem. The simplest thing to do is to call setResizeNonPowerOfTwoHint(false) on your Texture2D object, and all should be well. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Jason Daly wrote: David Glenn wrote: Both Texture2D and TextureRectangle can work with non-power of two textures, if your graphics hardware supports it. Every OpenGL 2.0-compatible graphics card should handle this without a problem. The main difference with TextureRectangle is that it uses non-normalized texture coordinates, so if you have a 640x480 image, your texture coordinates on your geometry must range from 0-639 and 0-479 to show the whole image. The simplest thing to do is to call setResizeNonPowerOfTwoHint(false) on your Texture2D object, and all should be well. Funny thing J, for what it's worth, the Performer code still gives me the Magic Number Error if I feed it any texture that is wrong and I know I'm using OpenGL 2.0. So I thought in that case it was a performer thing. Well I’m talking about 5+ year old code at best, that was hacked from something that was designed to run on an old SGI box. God knows what I'm going to get out of it! D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25148#25148 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
David Glenn wrote: Funny thing J, for what it's worth, the Performer code still gives me the Magic Number Error if I feed it any texture that is wrong and I know I'm using OpenGL 2.0. So I thought in that case it was a performer thing. Well I’m talking about 5+ year old code at best, that was hacked from something that was designed to run on an old SGI box. God knows what I'm going to get out of it! Yeah, Performer wasn't written for OpenGL 2.0. OSG wasn't originally either, which is why it defaults to resizing all images. The resize hint was added for OpenGL 2.0 (actually for the ARB_texture_non_power_of_two extension) so the resize could be avoided if the hardware supported it. You could argue that it should default to not resize if the hardware supports it (i.e.: if the extension is present in the driver's extension string), but drivers have been known to lie in the past :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Oh my goodness ... did something really stupid. I was taking the camera image which is a non-power-of-2 (1024x768). It had to be scaled down to 1024x512. Doh! It's working quite well now. On 3/2/10, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, I rechecked our code and we are using setImage without problem for 5 simult 1360x1024 cameras each at 20Hz. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Ben Cain wrote: Oh my goodness ... did something really stupid. I was taking the camera image which is a non-power-of-2 (1024x768). It had to be scaled down to 1024x512. Doh! It's working quite well now. On 3/2/10, J.P. Delport wrote: ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Don't feel too bad! I've been at this for nearly 15 years now and I still make that mistake sometimes! Me, it as like a brain fart or a Magic Number Error Moment! :? D Glenn! D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25084#25084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Hi Ben, Ben Cain wrote: Oh my goodness ... did something really stupid. I was taking the camera image which is a non-power-of-2 (1024x768). It had to be scaled down to 1024x512. I'm not sure if you are still scaling the image... If you are using Texture2D you can call texture-setResizeNonPowerOfTwoHint(false); on them to do not scale before uploading. Modern GPU are quite OK with non power of two textures. You can also use TextureRectangle instead of Texture2D. Doh! It's working quite well now. Glad you got it working. rgds jp On 3/2/10, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, I rechecked our code and we are using setImage without problem for 5 simult 1360x1024 cameras each at 20Hz. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Thanks J.P. You say that I can call myim-dirty() or myim-setImage(), but wouldn't calling myim-setImage() cause a slow update? That's what I seem to be experiencing. I need to update based on the sensor around 30Hz. The imagery data (from sensor) is in system memory ... just trying to get a view that shows it without dropping so many frames. Thanks again, Ben On Fri, Feb 26, 2010 at 12:23 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, we also pump data from cameras into the GPU. To enable PBOs is simple: // make image osg::ref_ptrosg::Image myim = new osg::Image(); // attach pbo myim-setPixelBufferObject(new osg::PixelBufferObject(myim.get())); // point im to data, avoid copying (mod format here for your app) myim-setImage(ImageFormat_[i].getWidth(), ImageFormat_[i].getHeight(), 1, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE, my_data_pointer, osg::Image::NO_DELETE); // assign to texture mytexture-setImage(myim.get()); Now, when the data update, just call myim-dirty() and all should update. You can also call setImage again. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Hi Ben, Ben Cain wrote: Thanks J.P. You say that I can call myim-dirty() or myim-setImage(), but wouldn't calling myim-setImage() cause a slow update? That's what I seem to be experiencing. I need to update based on the sensor around 30Hz. I rechecked our code and we are using setImage without problem for 5 simult 1360x1024 cameras each at 20Hz. The texture needs to get uploaded to the GPU in some way. When PBO is attached it seems to be fast enough. What hardware and OS are you using? What is the bus to the GPU? Uploads to GPU on PCIe should be 1GB/s+. The imagery data (from sensor) is in system memory ... just trying to get a view that shows it without dropping so many frames. We also have this case and we just try to not copy anything around in system memory, so just point the Image directly at the data. We also use a ring buffer for acquisition. Only other thing I can think of is to make sure that you are not changing pixel formats during the upload. This might switch to software code in the driver. rgds jp Thanks again, Ben On Fri, Feb 26, 2010 at 12:23 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, we also pump data from cameras into the GPU. To enable PBOs is simple: // make image osg::ref_ptrosg::Image myim = new osg::Image(); // attach pbo myim-setPixelBufferObject(new osg::PixelBufferObject(myim.get())); // point im to data, avoid copying (mod format here for your app) myim-setImage(ImageFormat_[i].getWidth(), ImageFormat_[i].getHeight(), 1, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE, my_data_pointer, osg::Image::NO_DELETE); // assign to texture mytexture-setImage(myim.get()); Now, when the data update, just call myim-dirty() and all should update. You can also call setImage again. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Ben Cain wrote: Hello, Is there a way to repeatedly/efficiently update an OSG texture's data ... for example imagery data that is being updating in system memory (e.g. from a sensor capture device). I've tried updating an OSG texture using texture2D-setImage(data) ... but it is very slow. Again, the image data is already in memory. You might try using PBOs (pixel buffer objects). I think the osgscreencapture example shows them in action. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Thanks Jason. I've used FBOs before for render-to-texture. I'll take a look at PBOs. On Thu, Feb 25, 2010 at 3:05 PM, Jason Daly jd...@ist.ucf.edu wrote: You might try using PBOs (pixel buffer objects). I think the osgscreencapture example shows them in action. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Ben Cain wrote: Thanks Jason. I've used FBOs before for render-to-texture. I'll take a look at PBOs. No problem. There's also the osg::ImageStream class. It's subclassed in the ffmpeg plugin and used in the osgmovie example for streaming movies to texture. If you've got an image stream from a hardware device that you're trying to use for texturing, then you might want to take advantage of that structure, since it's already there. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Hi Ben, we also pump data from cameras into the GPU. To enable PBOs is simple: // make image osg::ref_ptrosg::Image myim = new osg::Image(); // attach pbo myim-setPixelBufferObject(new osg::PixelBufferObject(myim.get())); // point im to data, avoid copying (mod format here for your app) myim-setImage(ImageFormat_[i].getWidth(), ImageFormat_[i].getHeight(), 1, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE, my_data_pointer, osg::Image::NO_DELETE); // assign to texture mytexture-setImage(myim.get()); Now, when the data update, just call myim-dirty() and all should update. You can also call setImage again. jp Ben Cain wrote: Thanks Jason. I've used FBOs before for render-to-texture. I'll take a look at PBOs. On Thu, Feb 25, 2010 at 3:05 PM, Jason Daly jd...@ist.ucf.edu wrote: You might try using PBOs (pixel buffer objects). I think the osgscreencapture example shows them in action. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
