Re: [osg-users] [osg-submissions] Texture compilation using PixelBufferObject
Hi Robert, Proposal: new member: BufferData::_numUsers initialized to BufferData::getReferenceCount when the GL buffer object is created and filled In Texture:apply, decrement the _numUsers member of the Image and release the GL buffer object if the sum of the _numUsers of all the BufferData contained if the GL buffer object is 0 Any thoughts ? Lionel On 14/12/2012 10:12, Robert Osfield wrote: Hi Lionel, Thanks for the explanation/code segment on the other thread. I now understand what is at issue, when an PBO is shared between osg::Texture/osg::Image the release is done by the first texture that applies it, rather than the last one to need it. I don't think the suggested fix of modifying the IncrementalCompileOperation is appropriate - it just hides the bug which is actually in the way that osg::Texture does the release based on the assumption that it's the only one using it. A proper solution will be to add some support into osg::BufferObject for registering when BufferData has been used and no longer required. Robert. ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Texture compilation using PixelBufferObject
Hi Lionel, On 14 December 2012 10:07, Lionel Lagarde lionel.laga...@oktal-se.frwrote: Hi Robert, Proposal: new member: BufferData::_numUsers initialized to BufferData::getReferenceCount when the GL buffer object is created and filled In Texture:apply, decrement the _numUsers member of the Image and release the GL buffer object if the sum of the _numUsers of all the BufferData contained if the GL buffer object is 0 Any thoughts ? Doesn't feel elegant to me. I wonder if we could unref the BufferData by removing it form the osg::Image and let it's ref count control it's destruction, and when it destructs it'll destruct the PixelBufferObject if it no longer has any references. This would be a bit similar to the way that the osg::Image is unref'd. Like this mechanism we'd need to make sure that the BufferData is applied to all the contexts that require it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Texture compilation using PixelBufferObject
Hi Robert, osg::Image inherits from osg::BufferData. The BufferData cannot be unreferenced separately. The behavior you describe is the what happen if unref image data after apply is true and copy data and release GL buffer object is false (like in my submission). Multi-context doesn't work if unref image data after apply is true because the image is referenced only once by the texture and not one per context. On 14/12/2012 11:20, Robert Osfield wrote: Hi Lionel, On 14 December 2012 10:07, Lionel Lagarde lionel.laga...@oktal-se.fr mailto:lionel.laga...@oktal-se.fr wrote: Hi Robert, Proposal: new member: BufferData::_numUsers initialized to BufferData::getReferenceCount when the GL buffer object is created and filled In Texture:apply, decrement the _numUsers member of the Image and release the GL buffer object if the sum of the _numUsers of all the BufferData contained if the GL buffer object is 0 Any thoughts ? Doesn't feel elegant to me. I wonder if we could unref the BufferData by removing it form the osg::Image and let it's ref count control it's destruction, and when it destructs it'll destruct the PixelBufferObject if it no longer has any references. This would be a bit similar to the way that the osg::Image is unref'd. Like this mechanism we'd need to make sure that the BufferData is applied to all the contexts that require it. Robert. ___ 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
Re: [osg-users] [osg-submissions] Texture compilation using PixelBufferObject
HI Lionel, On 14 December 2012 10:48, Lionel Lagarde lionel.laga...@oktal-se.frwrote: Hi Robert, osg::Image inherits from osg::BufferData. The BufferData cannot be unreferenced separately. Indeed, I knew this but didn't make the connection! :-) The behavior you describe is the what happen if unref image data after apply is true and copy data and release GL buffer object is false (like in my submission). Yes. I'm starting to think the BufferData level copy data and release GL buffer object is misguided and broken in it's current form and might be better off just removing it completely or doing a proper rethink and refactor of the support for this feature. Multi-context doesn't work if unref image data after apply is truebecause the image is referenced only once by the texture and not one per context. There is support in osg::Texture for making sure all the contexts have applied the image before the image gets unref'd. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg plugin path naming issue?
HI Preet, The OSG builds all debub libraries, including plugins with a 'd' postfix to avoid mixing of release and debug libraries. If you plugin directory doesn't contain the d versions of the plugins then it's likely because they haven't been built or haven't been installed in your plugin directory for some reason. I wouldn't recommend renaming the plugins as this can lead to crashes under Windows as the compiler is crap and unable to mix debug and release builds reliably. Robert. On 13 December 2012 19:34, Preet prismatic.proj...@gmail.com wrote: Hiya, OSG couldn't find a few plugins on an embedded target where I was manually installing the libraries. I noticed that osgDB was searching for plugins named with a 'd' at the end (I *am* using debug libs) but my actual plugins don't have a 'd' appended at the end of their name. For example, osgDB was looking for osgdb_freetyped.so, when the plugin itself was built as osgdb_freetype.so Everything works as expected when I rename the files (append a 'd' to all plugins) before putting them on the device. I don't move their relative paths or anything (so they stay in osgPlugins-x.x.x). Is this a bug or did I do something weird when building OSG? Preet ___ 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
Re: [osg-users] Render multiple osgText nodes with the same drawcall
HI Preet, osgText::Text rendering with a single character per Text will be inefficient for a cull, draw dispatch and draw GPU bottleneck reasons. It will probably be more efficient to create a scene graph from osg::Geometry/osg::Texture/osg::StateSet rather than using osgText. You could use the osgText::Font and associated Textures to help with the texturing side to the rendering. The osg::Geometry you create you could put as many quads in as you need. Robert. On 14 December 2012 00:39, Preet prismatic.proj...@gmail.com wrote: Hiya, I'm using OSG on a mobile target (OpenGL ES 2) and my scene runs really really slow. I'm trying to optimize it by reducing the number of draw calls. My scene has a bunch of labels that draw text along a path. Each label consists of several osgText nodes that are single characters in length, each with their own transform on top. So if a single label is OSG it will have three osgText nodes. I want to throw all of the label attributes (which I think is just vertex and tex coord arrays) into a single VBO, but I'm not really sure how I would do that (or even if I could). I'd appreciate any advice. Preet ___ 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
Re: [osg-users] [osg-submissions] Texture compilation using PixelBufferObject
Hi Robert, Yes. copy data and release GL buffer object mechanism cannot be used as it is. Unfortunately (fortunately), I'm in holidays for 3 weeks. I can make the related corrections but I will not be able to test them. I'll be back the 7 jan. Hope the world doesn't end during my holidays ... By Lionel On 14/12/2012 15:07, Robert Osfield wrote: HI Lionel, On 14 December 2012 10:48, Lionel Lagarde lionel.laga...@oktal-se.fr mailto:lionel.laga...@oktal-se.fr wrote: Hi Robert, osg::Image inherits from osg::BufferData. The BufferData cannot be unreferenced separately. Indeed, I knew this but didn't make the connection! :-) The behavior you describe is the what happen if unref image data after apply is true and copy data and release GL buffer object is false (like in my submission). Yes. I'm starting to think the BufferData level copy data and release GL buffer object is misguided and broken in it's current form and might be better off just removing it completely or doing a proper rethink and refactor of the support for this feature. Multi-context doesn't work if unref image data after apply is true because the image is referenced only once by the texture and not one per context. There is support in osg::Texture for making sure all the contexts have applied the image before the image gets unref'd. Robert. ___ 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] R: R: a couple of questions about svg plugin (OSG 3.0.1)
Unfortunately it crashed with any version of cairo library (gotten from
http://ftp.acc.umu.se/pub/gnome/binaries/win32), and any .svg file I tested.
I ended up looking deeper at documentation of cairo library.
Specifically, since the crash happened (as shown here below in yellow) when it
tries to free the memory allocated for a cairo_surface_t,
I looked at cairo.h, and found this comment:
* Memory management of #cairo_surface_t is done with
* cairo_surface_reference() and cairo_surface_destroy().
So, I tried to replace the call (at yellow line here below):
free(cairo_surface);
with a:
cairo_surface_destroy(cairo_surface);
I rebuilt osgdb_svg.dll, and now it seems to work. I can load any .svg file and
use as a texture with no crash.
But I still wonder if that replacement really deallocates the memory allocated
for the cairo surface.
Anyway, it seems quite strange to me that the svg plugin could work without
crashes for all of you who tried it (on Win32), without the hack that I had to
do,
since the hack is actually in osg and not in third party libraries.
So, again, I would appreciate if any of you who successfully built and used the
osg svg plugin as it was, i.e. without my replacement,
could let me know where he got the required libraries for svg.
BTW, I built OSG 3.0.1 in win32 debug, with VisualStudio 2010 on Win7.
Thanks,
Gianluca
Da: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Gianluca Natale
Inviato: giovedì 13 dicembre 2012 16:02
A: OpenSceneGraph Users
Oggetto: [osg-users] R: a couple of questions about svg plugin (OSG 3.0.1)
Thanks Robert,
I'll try with different versions of libraries and different .svg test files, to
see if the crash disappears.
Gianluca
Da:
osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield
Inviato: giovedì 13 dicembre 2012 15:51
A: OpenSceneGraph Users
Oggetto: Re: [osg-users] a couple of questions about svg plugin (OSG 3.0.1)
Hi Guanluca,
I've only used librsvg from the Ubunutu/debian repositories and haven't come
across problems before. Perhaps there is a version issue, or perhaps an issue
with librsvg handling the .svg you are passing on. As you are working under
Windows I think it may well be simply down to the libs and the OSG being built
with different options, this is a very common issue for Windows programmers and
comes with the territory am I afraid, it's another one of the reasons that I
haven't touched windows development for a decade.
As for rendering svg using the scene graph/OpenGL rather than rendering to a
CPU based image then texturing this, we'll it's possible but a for more complex
issue than just relying upon a 3rd party lib to the handle all the specifics of
vector graphics. NVidia do have a library that does vector graphics ontop of
OpenGL so this is probably the way one would tackle it.
Robert.
On 13 December 2012 12:11, Gianluca Natale
nat...@europe.altair.commailto:nat...@europe.altair.com wrote:
Hi all,
I have a couple of issues/questions about the osg plugin for svg file format.
1.
I got win32 prebuilt versions of the library librsvg, and all required
dependencies (glib, gdk-pixbuf, cairo, libcroco, fontconfig, libpng, freetype,
gettext-runtime, libxml2, expat, pango), from this website:
http://ftp.acc.umu.se/pub/gnome/binaries/win32.
And rebuilt the osgdb_svg.dll plugin (in OSG 3.0.1).
When I try to read an svg image in my application, I have a crash in the yellow
line in following function inside ReaderWriterSVG.cpp:
osg::Image* createImage(RsvgHandle *handle, unsigned int width,
unsigned int height) const
{
RsvgDimensionData dimensionData;
rsvg_handle_get_dimensions( handle, dimensionData);
// If image resollution 128, cairo produces some artifacts.
// I don't know why, but we check the size...
if (width 128) width = 128;
if (height 128) height = 128;
width = osg::Image::computeNearestPowerOfTwo(width);
height = osg::Image::computeNearestPowerOfTwo(height);
osg::Image *image = new osg::Image();
image-allocateImage(width, height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
image-setPixelFormat(GL_BGRA);
cairo_surface_t *cairo_surface =
cairo_image_surface_create_for_data(image-data(),
CAIRO_FORMAT_ARGB32, width, height,
image-getRowSizeInBytes());
cairo_t *cr = cairo_create(cairo_surface);
cairo_scale(cr,((float)width)/dimensionData.width,
((float)height)/dimensionData.height);
rsvg_handle_render_cairo(handle, cr);
cairo_destroy(cr);
free(cairo_surface);
image-flipVertical();
Re: [osg-users] R: R: a couple of questions about svg plugin (OSG 3.0.1)
On 12/14/2012 01:19 PM, Gianluca Natale wrote: Unfortunately it crashed with any version of cairo library (gotten from http://ftp.acc.umu.se/pub/gnome/binaries/win32), and any .svg file I tested. I ended up looking deeper at documentation of cairo library. Specifically, since the crash happened (as shown here below in yellow) when it tries to free the memory allocated for a cairo_surface_t, I looked at cairo.h, and found this comment: * Memory management of #cairo_surface_t is done with * cairo_surface_reference() and cairo_surface_destroy(). So, I tried to replace the call (at yellow line here below): free(cairo_surface); with a: cairo_surface_destroy(cairo_surface); I rebuilt osgdb_svg.dll, and now it seems to work. I can load any .svg file and use as a texture with no crash. But I still wonder if that replacement really deallocates the memory allocated for the cairo surface. Hi, Gianluca, This change has already been made in SVN (r12945, by Jason Beverage). The log indicates the change was made because it was causing a crash in Windows. From my experience in using cairo for several years, this is the correct way to destroy a cairo surface. Using free was a bug from the beginning, as cairo surfaces (like all cairo objects) are internally reference counted. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Cameras and lagging proj matrix
I think I have a pretty good idea of the cause. The CullVisitor gathers near far info during traversal but doesn't actually compute the final projection matrix until after the traversal completes. This means, obviously, that the projection matrix for the current frame hasn't been computed at the time the CullVisitor encounters my post-render Camera. Instead, the CullVisitor inserts last frame's projection matrix into the render graph, which is used for the box rendering. Then it completes traversal, computes the *correct* projection matrix, and uses this new matrix for the viewer root Camera's cylinder rendering. Thus, the two projection matrices are off just slightly, and the result is incorrect z interaction. But knowing this, I haven't been able to come up with a workaround. (Okay, well, short of editing the render graph after cull, which seems like I'd be asking for trouble.) So, still hoping for input from the community on how to make this work without visual artifacts. Thanks. -Paul On 12/14/2012 11:28 AM, Paul Martz wrote: Hi all -- I'm attempting to render with two Cameras, where one inherits the projection matrix of the other. But there appears to be some latency such that the subordinate Camera doesn't get the projection matrix until one frame late. You can reproduce the issue with the attached example and animation path. The example configures the viewer's root Camera to render to an FBO with color and depth textures attached. It renders a cylinder into these textures. A post-render Camera then splats the color texture into the window with a full screen quad. The problem occurs when a final post-render Camera draws the checkerboard box. It uses the depth texture an input to a fragment shader that performs a manual depth test. I have taken steps to ensure that this post-render Camera has RELATIVE_RF ref frame, and set it to disable near far computation, so that it will inherit the projection matrix of the viewer root Camera. This works quite well except for the slight lag, indicating that this post-render Camera doesn't get the correct projection matrix until about a frame too late. The problem is definitely related to the fact that the viewer root Camera is configured to auto-compute near far, because if I disable this and set a fixed projection matrix on the root Camera, the problem goes away (uncomment lines 49 and 50). Can anyone explain the one-frame lag with the projection matrix? I'll be digging into the code over the weekend to figure this out myself, but would appreciate any input while I dig... Thanks, -Paul ___ 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
Re: [osg-users] Multiple Cameras and lagging proj matrix
Paul, I had a similar problem (I think). I installed a custom callback on the RTT camera (CullSettings::setClampProjectionMatrixCallback). This callback would call the original implementation first, then store the results of the projection matrix clamp so that I could use it immediately. You can see the custom callback here: https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171 Each frame, I prime it with the current CullVisitor: https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384 And then immediately use the result to set a uniform: https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L403 Hope this helps. Glenn Waldron / @glennwaldron / osgEarth.org On Fri, Dec 14, 2012 at 3:12 PM, Paul Martz pma...@skew-matrix.com wrote: I think I have a pretty good idea of the cause. The CullVisitor gathers near far info during traversal but doesn't actually compute the final projection matrix until after the traversal completes. This means, obviously, that the projection matrix for the current frame hasn't been computed at the time the CullVisitor encounters my post-render Camera. Instead, the CullVisitor inserts last frame's projection matrix into the render graph, which is used for the box rendering. Then it completes traversal, computes the *correct* projection matrix, and uses this new matrix for the viewer root Camera's cylinder rendering. Thus, the two projection matrices are off just slightly, and the result is incorrect z interaction. But knowing this, I haven't been able to come up with a workaround. (Okay, well, short of editing the render graph after cull, which seems like I'd be asking for trouble.) So, still hoping for input from the community on how to make this work without visual artifacts. Thanks. -Paul On 12/14/2012 11:28 AM, Paul Martz wrote: Hi all -- I'm attempting to render with two Cameras, where one inherits the projection matrix of the other. But there appears to be some latency such that the subordinate Camera doesn't get the projection matrix until one frame late. You can reproduce the issue with the attached example and animation path. The example configures the viewer's root Camera to render to an FBO with color and depth textures attached. It renders a cylinder into these textures. A post-render Camera then splats the color texture into the window with a full screen quad. The problem occurs when a final post-render Camera draws the checkerboard box. It uses the depth texture an input to a fragment shader that performs a manual depth test. I have taken steps to ensure that this post-render Camera has RELATIVE_RF ref frame, and set it to disable near far computation, so that it will inherit the projection matrix of the viewer root Camera. This works quite well except for the slight lag, indicating that this post-render Camera doesn't get the correct projection matrix until about a frame too late. The problem is definitely related to the fact that the viewer root Camera is configured to auto-compute near far, because if I disable this and set a fixed projection matrix on the root Camera, the problem goes away (uncomment lines 49 and 50). Can anyone explain the one-frame lag with the projection matrix? I'll be digging into the code over the weekend to figure this out myself, but would appreciate any input while I dig... Thanks, -Paul __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://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] Questions about mip maps
Hi, I have a set of pre-computed procedurals textures, and my texture generation system can produce high-quality downsampled textures. So I would like to use them as mipmaps for my textures : - is it possible to allocate and load mipmaps from CPU, just like we load an osg::Image into an osg::Texture2D ? - is there any example of that ? - is it mandatory that each mipmap level is exactly half size of the previous ? - is it mandatory that texture size is a power of two ? how to deal with odd texture size ? (or odd n-th mipmap size) ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51590#51590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about mip maps
On 12/14/2012 06:08 PM, Aurelien Albert wrote: Hi, I have a set of pre-computed procedurals textures, and my texture generation system can produce high-quality downsampled textures. So I would like to use them as mipmaps for my textures : - is it possible to allocate and load mipmaps from CPU, just like we load an osg::Image into an osg::Texture2D ? Yes. As far as I know, the way to do it is to pass the entire set of images (with the mipmaps) to osg::Image::setData(), then call osg::Image::setMipmapLevels() with a vector indicating the byte offset to the start of each of the mipmaps. - is there any example of that ? The only example I know of off the top of my head is in the DDS plugin (search for the call to setMipmapLevels to see where). There are probably others, too. - is it mandatory that each mipmap level is exactly half size of the previous ? Not exactly, but each successive level should be an integer quotient of the previous level's size and two. They don't need to be powers of two either, as long as you're targeting relatively recent hardware. Essentially, you take the floor of size/2 to get the size of the next level. Say you start with a size of 999. The mip levels would then be 499, 249, 124, 62, 31, 15, 7, and 3. The textures also don't need to be square. The mip levels stop when any of the dimensions reaches 1, so you shouldn't create any mipmaps that are, for example, 4x1. Hope this helps! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about mip maps
On 12/14/2012 07:16 PM, Jason Daly wrote: The textures also don't need to be square. The mip levels stop when any of the dimensions reaches 1, so you shouldn't create any mipmaps that are, for example, 4x1. Actually, this isn't exactly correct. You should create mipmaps until you get to a size with a 1 pixel dimension, and then you should stop, so, for example, a 63x21 texture would have mipmaps of 31x10, 15x5, 7x2, and 2x1 (but not 1x1). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture internal and source format questions
Hello. Lets say i have a texture which stores the depthmap. 1) Is the following correct ? texture2d-setInternalFormat(GL_DEPTH_COMPONENT16); texture2d-setSourceFormat(GL_DEPTH_COMPONENT); texture2d-setSourceType(GL_UNSIGNED_SHORT); 2) Why do we need do initialize both internal format and source format if we are not going to use any image ? Thank you ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
