Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Rui, Since the definition of the RequestQueue::size() actually exists in the .cpp the error looks to be a little misleading. Could the error simply be due to the RequestQueue not being declared with an OSGDB_EXPORT? Robert. On Thu, Jan 20, 2011 at 4:50 AM, Wang Rui wangra...@gmail.com wrote: Hi Robert, It builds well on my Windows XP and VisualStudio 8/9, both dynamic and static versions. But when compiling with MinGW (gcc version 3.4.5), there is a compile error: ... CMakeFiles\osgViewer.dir\StatsHandler.obj:StatsHandler.cpp:(.text$_ZNK5osgDB13DatabasePager24getDataToCompileListSizeEv[osgDB::DatabasePager::getDataToCompileListSize() const]+0x18): undefined reference to `osgDB::DatabasePager::RequestQueue::size()' ... The problem can be solved by making an inline version of the RequestQueue::size() method (as attached). Another way is to implement the getDataToCompileListSize() method in the cpp file rather than in the header. Which would you prefer? :-) Cheers, Wang Rui 2011/1/19 Robert Osfield robert.osfi...@gmail.com: Hi All, Could you please test the build of OpenSceneGraph svn/trunk and test it against your own applications. If you are successful and find problems post your findings on this thread so we can access how things are converging. All going well I'll tag 2.9.11 tomorrow. Thanks, 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg help documentation
2011/1/20 hongyang wang hywang1...@gmail.com: hello! I want to know ,How can I get osg help documentation? You could try the documention link on the openscenegraph.org front page. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan,
Thanks for your reply. I'm still having problems trying to make use of
texelFetchBuffer with your code.
Why texture pixel format are you using? I'm using an integer texture format.
Not sure if OSG's allocateImage method behaves ok in this case.
I am creating the texture the following way:
Code:
bbp::RTNeuron::TextureBuffer *tb = new bbp::RTNeuron::TextureBuffer();
tb-setInternalFormat(GL_RGBA8UI); // 4 bytes per pixel, R-G-B-A format as per
EXT_texture_integer formats specification
osg::Image *image = new osg::Image();
image-allocateImage(128*128, 1, 1, GL_RGBA_INTEGER, GL_UNSIGNED_BYTE, 1); //
note: width=(128*128), height=1
tb-setImage(0, image);
In my fragment shader, right now, here is what I'm doing for a quick test:
Code:
#version 150 compatibility
#extension GL_EXT_gpu_shader4 : enable
uniform samplerBuffer tex;
void main(void)
{
if (textureSizeBuffer(tex) == (128*128)) // size in pixels
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); // red (as I am expecting)
else
gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0); // green
}
The result is always green here, not red as I am expecting.
Is there anything I am doing wrong with your code?
Regards
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35795#35795
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cocoa + osg example
On 1/19/11, Andre Simoes andrersim...@gmail.com wrote: Hello for all. Does anybody already had the experience of using osg inside a COCOA application ? Is there any example that i study to understand how to use both together ? There used to be osgviewerCocoa in the examples section of the code. Also, this is quite a bit dated, but there is a WaveInterfernce demo I did which built on the above. http://playcontrol.net/ewing/jibberjabber/waveinterference_opengl_sha.html -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
fred_em wrote: Code: [...] tb-setInternalFormat(GL_RGBA8UI); // 4 bytes per pixel, R-G-B-A format as per EXT_texture_integer formats specification osg::Image *image = new osg::Image(); image-allocateImage(128*128, 1, 1, GL_RGBA_INTEGER, GL_UNSIGNED_BYTE, 1); // note: width=(128*128), height=1 tb-setImage(0, image); I am getting the same bogus result with the following standard pixel format (eg. not using EXT_texture_integer): Code: [...] tb-setInternalFormat(GL_RGBA8); // 4 bytes per pixel, regular RGBA normalized pixel format osg::Image *image = new osg::Image(); image-allocateImage(128*128, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, 1); tb-setImage(0, image); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35798#35798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visibility of point array
Hi, Oliver I can give you some general pointers or make basic example, but i'll have time for example not earlier than on weekend. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35803#35803 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Robert, I've tried adding an OSGDB_EXPORT macro to the RequestQueue struct but the error still appeared. I'm a little confused, too, and don't know if this is an MinGW compiler issue. I'm doing a complete rebuild now and will report the result later. Cheers, Wang Rui 2011/1/20 Robert Osfield robert.osfi...@gmail.com: Hi Rui, Since the definition of the RequestQueue::size() actually exists in the .cpp the error looks to be a little misleading. Could the error simply be due to the RequestQueue not being declared with an OSGDB_EXPORT? Robert. On Thu, Jan 20, 2011 at 4:50 AM, Wang Rui wangra...@gmail.com wrote: Hi Robert, It builds well on my Windows XP and VisualStudio 8/9, both dynamic and static versions. But when compiling with MinGW (gcc version 3.4.5), there is a compile error: ... CMakeFiles\osgViewer.dir\StatsHandler.obj:StatsHandler.cpp:(.text$_ZNK5osgDB13DatabasePager24getDataToCompileListSizeEv[osgDB::DatabasePager::getDataToCompileListSize() const]+0x18): undefined reference to `osgDB::DatabasePager::RequestQueue::size()' ... The problem can be solved by making an inline version of the RequestQueue::size() method (as attached). Another way is to implement the getDataToCompileListSize() method in the cpp file rather than in the header. Which would you prefer? :-) Cheers, Wang Rui 2011/1/19 Robert Osfield robert.osfi...@gmail.com: Hi All, Could you please test the build of OpenSceneGraph svn/trunk and test it against your own applications. If you are successful and find problems post your findings on this thread so we can access how things are converging. All going well I'll tag 2.9.11 tomorrow. Thanks, 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 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] Please test svn/trunk in prep for 2.9.11 dev release
Hi, Wang Rui writes: Hi Robert, I've tried adding an OSGDB_EXPORT macro to the RequestQueue struct but the error still appeared. I'm a little confused, too, and don't know if this is an MinGW compiler issue. I'm doing a complete rebuild now and will report the result later. Nevertheless, that works for me. Mingw version 4.4.4. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Alberto + Rui, Thanks for the testing. I've gone ahead and checked in the addition of the OSGDB_EXPORT to the nested protected classes in the DatabasePager. Thanks, Robert. On Thu, Jan 20, 2011 at 1:25 PM, Alberto Luaces alua...@udc.es wrote: Hi, Wang Rui writes: Hi Robert, I've tried adding an OSGDB_EXPORT macro to the RequestQueue struct but the error still appeared. I'm a little confused, too, and don't know if this is an MinGW compiler issue. I'm doing a complete rebuild now and will report the result later. Nevertheless, that works for me. Mingw version 4.4.4. -- Alberto ___ 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] Visibility of point array
Hi Sergey, ok, thanks, currently my approach is working ok, but I'm still looking for speed improvements, so your help is very appreciated. Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35808#35808 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Robert Osfield writes: Hi Alberto + Rui, Thanks for the testing. I've gone ahead and checked in the addition of the OSGDB_EXPORT to the nested protected classes in the DatabasePager. Thanks Robert. Updated rebuilt succesfully. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QOSGWidget and ViewQOSG resize behavior
Hello Jimmy, Firstly, I'd like to take this chance to say Hello to this community. Hello to you too! Welcome to osg-users! :-) For the meat of this topic: I have compiled the 2.9.10 OSG library from the svn source. In the comments for the osgviewerQtWidget example, it is clearly stated that the ViewQOSG and QOSGWidgets can not be resized in a Windows environment. First of all, that example is now deprecated as you'll see if you browse the current SVN trunk, see these change sets: http://www.openscenegraph.org/projects/osg/changeset/12025/OpenSceneGraph/trunk/examples http://www.openscenegraph.org/projects/osg/changeset/12026/OpenSceneGraph/trunk/examples So perhaps you would be better to start with the current Qt integration example, osgviewerQt (which was osgviewerQtContext before, and uses osgQt::GraphicsWindowQt). I don't have any more information about your specific problem, having not used these examples much myself. We have a Qt expert in house who did our own Qt integration not based on either of these. But I'm pretty sure others will be able to help you. Sorry I can't help more, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Fred
What texture pixel format are you using? I'm using an integer texture
format. Not sure if OSG's allocateImage method behaves ok in this
case.
I've only used setup code of this style:
image-setImage(size, 1, 1, GL_LUMINANCE32F_ARB, GL_LUMINANCE,
GL_FLOAT, data, osg::Image::NO_DELETE);
I don't know whether for other formats it may fail.
I am creating the texture the following way:
Code: bbp::RTNeuron::TextureBuffer *tb = new
bbp::RTNeuron::TextureBuffer(); tb-setInternalFormat(GL_RGBA8UI); //
4 bytes per pixel, R-G-B-A format as per EXT_texture_integer formats
specification osg::Image *image = new osg::Image();
image-allocateImage(128*128, 1, 1, GL_RGBA_INTEGER,
GL_UNSIGNED_BYTE, 1); // note: width=(128*128), height=1
tb-setImage(0, image);
If you use GL_RGBA_INTEGER then you must use isamplerBuffer or
uisamplerBuffer otherwise the results are undefined.
For a normalized value I don't know what were you expecting but it can't
be the same as with floating point or true integer formats.
The main differences between your code and mine are that I'm setting the
internal texture format explicitly and I'm using a plain array of data
instead RGB/RGBA formats.
Code: #version 150 compatibility #extension GL_EXT_gpu_shader4 :
enable
uniform samplerBuffer tex;
void main(void) { if (textureSizeBuffer(tex) == (128*128)) // size in
pixels gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); // red (as I am
expecting) else gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0); // green }
The result is always green here, not red as I am expecting.
I haven't used textureSizeBuffer before but from the docs I've read your
code should pretty much work. Is this wrong also with a normalized
texture format or a floating point format?
Cheers,
Juan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Robert, Everything is OK after updating mingw-gcc version to 4.5.0. :-) Cheers, Wang Rui 2011/1/20 Robert Osfield robert.osfi...@gmail.com: Hi Alberto + Rui, Thanks for the testing. I've gone ahead and checked in the addition of the OSGDB_EXPORT to the nested protected classes in the DatabasePager. Thanks, Robert. On Thu, Jan 20, 2011 at 1:25 PM, Alberto Luaces alua...@udc.es wrote: Hi, Wang Rui writes: Hi Robert, I've tried adding an OSGDB_EXPORT macro to the RequestQueue struct but the error still appeared. I'm a little confused, too, and don't know if this is an MinGW compiler issue. I'm doing a complete rebuild now and will report the result later. Nevertheless, that works for me. Mingw version 4.4.4. -- Alberto ___ 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
Re: [osg-users] osg help documentation
Or buy the new begginers guide book. https://www.packtpub.com/openscenegraph-3-0-beginners-guide/book -- A. On Thu, Jan 20, 2011 at 3:22 AM, Robert Osfield robert.osfi...@gmail.com wrote: 2011/1/20 hongyang wang hywang1...@gmail.com: hello! I want to know ,How can I get osg help documentation? You could try the documention link on the openscenegraph.org front page. 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] osg widget window rotate
Hi, I have been trying to implement a compass widget which the user can manipulate. I have been trying this with osg widget. When using addRotate to my widget's window the widget is clipped to the area it was previously in. How would i get around this problem? ... Thank you! Cheers, Gareth -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35814#35814 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Robert, Everything is OK with our application on MacOSX universal build (i386;x86_64). It includes the use of the ffmpeg plugin. Greets, Rafa. 2011/1/20 Wang Rui wangra...@gmail.com: Hi Robert, Everything is OK after updating mingw-gcc version to 4.5.0. :-) Cheers, Wang Rui 2011/1/20 Robert Osfield robert.osfi...@gmail.com: Hi Alberto + Rui, Thanks for the testing. I've gone ahead and checked in the addition of the OSGDB_EXPORT to the nested protected classes in the DatabasePager. Thanks, Robert. On Thu, Jan 20, 2011 at 1:25 PM, Alberto Luaces alua...@udc.es wrote: Hi, Wang Rui writes: Hi Robert, I've tried adding an OSGDB_EXPORT macro to the RequestQueue struct but the error still appeared. I'm a little confused, too, and don't know if this is an MinGW compiler issue. I'm doing a complete rebuild now and will report the result later. Nevertheless, that works for me. Mingw version 4.4.4. -- Alberto ___ 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 -- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es http://gvsig3d.blogspot.com Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transpose() and osg_NormalViewMatrix
On 1/19/2011 5:29 PM, Jean-Sébastien Guay wrote:
Hi Rob,
Of course, we don't need to
make osg::Matrix::transpose() part of the public API, if we don't want
to.
I personally think there's nothing *wrong* with having a transpose()
method, it's just that if the existing M*V would have fit your use
case then it would have avoided duplicating functionality and having 2
ways of doing things, which would potentially confuse new users.
Though you may argue that *not* having a transpose() method and
relying on the M*V might confuse them more, given that it's more
obscure and hard to understand at a glance and we need a wiki page to
explain its use.
So I would be open to adding transpose(), and while you're at it,
perhaps the doxygen comment for transpose() can mention that when
transforming normals and planes you can use M*V to avoid extra
operations involved in an explicit transpose, and the doxygen comment
for the M*V operator can also mention the particular cases where this
is useful and not to confuse it with the regular V*M operator...
Attached is a patch (against trunk) that contains my original changes:
- Add a transpose() function to Matrixf and Matrixd
- Add two new osg global glsl uniforms: osg_NormalViewMatrix and
osg_NormalViewMatrixInverse
as well as some doxygen comments that discuss the merits of using
transpose() vs. postMult() etc. The meat of the comments are on the
preMult() and postMult() functions with see also's on the relevant
operator*() functions.
Rob
Index: include/osg/Matrixd
===
--- include/osg/Matrixd (revision 12107)
+++ include/osg/Matrixd (working copy)
@@ -249,6 +249,15 @@
value_type angle2, const Vec3d axis2,
value_type angle3, const Vec3d axis3);
inline static Matrixd rotate( const Quat quat);
+/**
+ * Returns the transpose of 'matrix'. Although this function is
occasionally
+ * useful, it is often more efficient to use the Matrix classes
postMult (M*v)
+ * function to eliminate the need to transpose the matrix in the
first place.
+ * This is especially important to keep in mind when multiplying by
vectors and planes.
+ * For example, instead of using v * M(T), it would be more
efficient to simply use
+ * M * v.
+*/
+inline static Matrixd transpose( const Matrixd matrix );
inline static Matrixd inverse( const Matrixd matrix);
inline static Matrixd orthoNormal(const Matrixd matrix);
/** Create an orthographic projection matrix.
@@ -299,10 +308,21 @@
inline Vec3f operator* ( const Vec3f v ) const;
inline Vec3d operator* ( const Vec3d v ) const;
inline Vec4f preMult( const Vec4f v ) const;
+/** Transforms v by this matrix ( v * M ). This is the most commonly
used
+ * matrix multiply operation.
+*/
inline Vec4d preMult( const Vec4d v ) const;
inline Vec4f postMult( const Vec4f v ) const;
+/** Transforms v by the transpose of this matrix. Conceptually, this
can
+ * be thought of as either ( M * v ) or ( v * M(Transpose) ) and it
is
+ * computationally more efficient than actually computing the
transpose
+ * of the matrix.
+ */
inline Vec4d postMult( const Vec4d v ) const;
inline Vec4f operator* ( const Vec4f v ) const;
+/** A synonym for postMult()
+ * \sa postMult( const Vec4d )
+ */
inline Vec4d operator* ( const Vec4d v ) const;
#ifdef USE_DEPRECATED_API
@@ -511,6 +531,17 @@
return m;
}
+inline Matrixd Matrixd::transpose( const Matrixd matrix )
+{
+ Matrixd m;
+ for( int c = 0 ; c 4 ; c++ ) {
+for( int r = 0 ; r 4 ; r++ ) {
+ m(c,r) = matrix(r,c);
+}
+ }
+ return m;
+}
+
inline Matrixd Matrixd::inverse( const Matrixd matrix)
{
Matrixd m;
@@ -783,6 +814,9 @@
return m.preMult(v);
}
+/** A synonym for preMult()
+ * \sa Matrixd::preMult( const Vec4d )
+ */
inline Vec4d operator* (const Vec4d v, const Matrixd m )
{
return m.preMult(v);
Index: include/osg/Matrixf
===
--- include/osg/Matrixf (revision 12107)
+++ include/osg/Matrixf (working copy)
@@ -249,6 +249,15 @@
value_type angle2, const Vec3d axis2,
value_type angle3, const Vec3d axis3);
inline static Matrixf rotate( const Quat quat);
+/**
+ * Returns the transpose of 'matrix'. Although this function is
occasionally
+ * useful, it is often more efficient to use the Matrix classes
postMult (M*v)
+ * function to eliminate the need to transpose the matrix in the
first place.
+
Re: [osg-users] transpose() and osg_NormalViewMatrix
Hi Rob, Attached is a patch (against trunk)[...] The changes look good to me. Good work on the comments. You'll want to send the whole modified files to osg-submissions so Robert can review and check them in. Also I should have said that my opinion is not the deciding factor for whether the changes get integrated or not... Robert has final say of course. I was giving my opinion in the previous message and I realize it may have been construed as a final decision, sorry if I misled you. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg widget window rotate
On Thu, 2011-01-20 at 17:35 +0100, Gareth Penfold wrote: Hi, I have been trying to implement a compass widget which the user can manipulate. I have been trying this with osg widget. When using addRotate to my widget's window the widget is clipped to the area it was previously in. How would i get around this problem? By default, the clip area is the size of the window without rotation. This is called VisibilityMode in osgWidget terms. Set this to VM_ENTIRE and you'll be fine: w-setVisibilityMode(osgWidget::Window::VM_ENTIRE) ... Thank you! Cheers, Gareth -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35814#35814 ___ 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] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi, I'm writing a laser range finder simulator using the depth component of a scene. I'm linearising the range in a fragment shader using.. linearRange = (2.0*near) /(far+near-(nonLinearRange*(far-near))) I was hoping to display the foggy depth image by allowing the rtt camera to calculate the near/far planes and pass these values to the shader for use in the linearisation. I had hoped that this would mean that the calculated range should remain the same whether DO_NOT_COMPUTE_NEAR_FAR was set or not. I'm getting the near/far numbers from rttCamera-getProjectionMatrixAs Frustum and passing these to the shaders in a viewer-frame loop using Uniform-set(), but the linearised range is different dependent on DO_NOT_COMPUTE_NEAR_FAR. I can confirm that the near/far values change within the loop as the scene changes. Is it valid to pass data to a shader using Uniform-set() in a viewer-frame loop? Is my assumption that linearised range should be independent of DO_NOT_COMPUTE_NEAR_FAR if the near/planes are passed to the linearisation algorithm correct? Can anyone comment on the algorithm used (which seems to be generally accepted)? Ta. John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35796#35796 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Upgrade from 1.0.0 to 2.8.2
Hello all, I have a legacy app that I am trying to bring current. It previously used osg 1.0.0. I have upgraded to 2.8.2 and there was only 1 change I had to make to get it to compile against the new libraries. It had to do with return value being an object instead of a pointer. Anyway, now when the scene loads, I only get the blue background and none of the scene. I was hoping that someone here might have some idea of what things have changed and be able to point me in the right direction of where to look to get things working again. I should probably also mention that the application makes use of the Producer library from andesengineering dot com Thank you! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35783#35783 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How do I extract OSG data?
Hi, I'm an OSG newbie and after a few hours looking around online, I don't see how I can extract the data from my OSG files. How do I extract the data into, say, CSV files? Thank you very much! Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35782#35782 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Screen Resolution Being Overriden in Twinview
I am having an issue with screen resolution in Twinview. If I am in clone mode or non twinview, everything is fine. But when I am in twinview otherwise, the screen resolution changes even though I am not telling it to. It is essentially adding an invisible window decoration as that is the size it is changing by. My setup: I have 2 monitors, one is 1280x1024, the other is 1920x1200. I would like my application to show up on the 1280x1024 monitor and it does, just not at 1280x1024. When I create my graphics context, I do the following: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 0; traits-y = 0; traits-width = 1280; traits-height = 1024; traits-windowDecoration = false; traits-windowName = myApp; traits-doubleBuffer = true; traits-sharedContext = 0; osg::DisplaySettings* ds = osg::DisplaySettings::instance(); traits-sampleBuffers = ds-getMultiSamples; traits-samples = ds-getNumMultiSamples(); osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); At this point if I pause my program, the resolution is already wrong. It is starting at 0,0, but it is missing the far right and bottom, about the size of the window decoration border. If I then go through and get the window out of the osgViewer and do a window-setWindowRectangle(0,0,1280,1024), the screen goes full screen again. However any time I do anything at all to the viewer or wsi or window, or sets back to the other size. For example if I do a window-useCursor(true) call it resets. What am I doing wrong? I know it is not a driver issue as this was formerly a Performer app and it works just fine in there with the same system so it has to either be an issue in OSG (I doubt) or an error in how I am setting up the window. Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrade from 1.0.0 to 2.8.2
On 1/19/2011 4:51 PM, Mike Hatcher wrote: Hello all, I have a legacy app that I am trying to bring current. It previously used osg 1.0.0. I have upgraded to 2.8.2 and there was only 1 change I had to make to get it to compile against the new libraries. It had to do with return value being an object instead of a pointer. Anyway, now when the scene loads, I only get the blue background and none of the scene. I was hoping that someone here might have some idea of what things have changed and be able to point me in the right direction of where to look to get things working again. I should probably also mention that the application makes use of the Producer library from andesengineering dot com The differences from 1.0 to 2.8.2? Sure, let me just cover those in a couple lines... :-) Have you tried dumping your scene graph out as a .osg file and running it in plain osgviewer? Looking at it in a text editor to see what is amiss? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrade from 1.0.0 to 2.8.2
Thanks for the prompt reply! I probably should have mentioned what I had done. I did the steps described in the debugging FAQ. I turned off optimization (and on just to see) as well as turning the notifications to DEBUG and I did look at the output of it but there was nothing abnormal about it (or so it appeared.) I also did the dump to an .osg file and it is interesting. The dome and landscape shapes do appear but not with textures. It seems the textures are missing. I've tried moving the camera around all kinds of different orientations and eye points and can never see anything at all. However, when I run it in osgviewer, I get what I described above. When I run the osgviewer and the osg dump from the 1.0.0 version things do seem to appear correctly, almost just like they do when I run the app. I realize that there are probably many many more changes between those version than can be described in a few lines but here is the thing...it ported almost perfectly...almost too perfectly to the newer version so it is clear that there has been some level of (likely significant) effort at maintaining backward compatibility. I was just hoping for a pointer in the right direction...e.g. something along the lines of Well the camera code has remained largely unchanged but the coordinate system, references, units, etc...have completely changed so your camera is likely pointing off someplace where the geometry no longer exists or The way textures are done has been completely redesigned so probably none of your objects will get textured without bla bla bla... I realize some of that might be a stretch, but I thought I would ask anyway :) As I look at the coordinates of the camera and terrain and objects, and everything...they look right to me. Like I should be at least seeing something! Thank you! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35823#35823 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FYI, AMD launch first embedded APU processor
http://www.techeye.net/chips/amd-launch-first-embedded-apu-processor ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] Integration river rendering
Dear All, It has been a while since my last post on the osg mailing list but I'd like to confirm that I'm still following the progress on osgOcean. Some time ago I submitted an implementation for river rendering based on osgOcean. I am curious if there have been any additional thoughts on how to integrate this best with the existing ocean rendering. I understand if you have not had the free time to look into this but I would just like to confirm I'm still interested in any progress being made. Kind regards, Quintijn Hendrickx ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrade from 1.0.0 to 2.8.2
Well, you said you don't get any textures... But you also said you cranked up the notify level and everything looked OK. At level DEBUG, you should see the osgDB trying to locate your texture files, displaying the full path as it searches. Are those messages there? Is each file found correctly? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrade from 1.0.0 to 2.8.2
True, I was comparing the osgviewer and osg dumps taken in the different versions. The debug output shows all images, textures, models, and everything loading just fine. They are all found just fine and using readImageFile they are all read with all plugins appear to function correctly but using osgviewer they (textures only) don't appear to be rendered under 2.8.2 but at least sufaces are. However, the larger concern for me at the moment is that in the app, not osgviewer nothing at all appears...no wireframe, no surfaces, nothing but with osgviewer and the osg dump taken while actually running the app, surfaces are rendered. In 1.0.0 everything is there. On 2.8.2 it's all gone...except when using osgviewer and viewing the .osg dump. I think I can probably tackle the issue with textures once I can at least get something displayed on the screen but until then I'm at a total loss! Thank you! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35827#35827 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and QT example
Sounds quite interesting. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Benjamin Wasty Sent: Friday, January 21, 2011 3:13 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] OSG and QT example Hi, I worked on a Qt-widget integration for my university based on the Delta3D files posted earlier by David Guthrie. I made a few changes - mainly to make multi-threaded rendering really work. We'd be willing to make a submission if there's interest. My current version is attached - feedback would be welcome as this is the first time I worked with OSG. Below are some details and open issues: The class QtViewer inherits from osgViewer::Viewer and OSGAdapterWidget. It does some setup and calls frame() in its updateGL() method. Context sharing between Qt and OSG didn't work when OSG was running multi-threaded - in the end (after quite a few hours of debugging) I just 'switched' the two contexts in OSGAdapterWidget - the QGLWidget keeps its original one and the additional one created in threadedInitializeGL() is used by the OSG draw thread (OSGGraphicsWindowQt directs the makeCurrent/doneCurrent()-calls to that context). Improved mapping from Traits/osg::DisplaySettings to QGLFormat Removed QtGuiWindowSystemWrapper and GLWidgetFactory because we don't need them (but only commented out) No rendering when Widget is hidden (otherwise some access violation occurs) One remaining problem is that there is quite a lag when the main window is moved or resized, because Qt apparently doesn't have enough time to render fluently due to the blocking caused by vsync. Increasing the interval for the update timer helps, but reduces the framerate and in my opinion the now used 10ms are already too much. Should the frame()-call maybe moved to a separate thread like there: forum . openscenegraph . org / viewtopic.php?p=17387#17387 ? (2 posts before I can post URLs? I don't have time for that...) A quick test with that code didn't work, but I didn't pursue it further so far. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35820#35820 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi, On 20/01/11 13:54, John Simpson wrote: Hi, I'm writing a laser range finder simulator using the depth component of a scene. I'm linearising the range in a fragment shader using.. linearRange = (2.0*near) /(far+near-(nonLinearRange*(far-near))) I was hoping to display the foggy depth image by allowing the rtt camera to calculate the near/far planes and pass these values to the shader for use in the linearisation. I had hoped that this would mean that the calculated range should remain the same whether DO_NOT_COMPUTE_NEAR_FAR was set or not. I'm getting the near/far numbers from rttCamera-getProjectionMatrixAs Frustum and passing these to the shaders in a viewer-frame loop using Uniform-set(), but the linearised range is different dependent on DO_NOT_COMPUTE_NEAR_FAR. I'm not 100% sure when the projection matrix is set, you might have to split -frame() into update(), cull(), then get the matrix and set the uniform, then draw(). I can confirm that the near/far values change within the loop as the scene changes. But they might be one frame behind? Is it valid to pass data to a shader using Uniform-set() in a viewer-frame loop? Yes. Is my assumption that linearised range should be independent of DO_NOT_COMPUTE_NEAR_FAR if the near/planes are passed to the linearisation algorithm correct? I think so, provided the algorithm is correct. But what are you setting for near/far in the DO_NOT_COMPUTE_NEAR_FAR case? What is your nonLinearRange value? Is it dependent on camera field of view? Can anyone comment on the algorithm used (which seems to be generally accepted)? Not by heart, I'll have to search... rgds jp Ta. John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35796#35796 ___ 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] multiple tex gen modes in a single scene
Hi Robert, I am currently adding shadows to my scene (which is going well) but in doing so I have hit this issue. I already use an eye linear tex gen in my scene to render overlays (very similar code to the osgSim::OverlayNode). I don't think it would be possible for me to split the renderering accross two different RenderStages as the two tex gens are used from within the same shader to render my terrain (one for applying shadows and the other for applying overlays). I have had a look at the PositionalStateContainer class and I do not understand why the issue exists. The tex gens use different texture units and as such there matrices are stored and applied seperately. However the result I am seeing is one of the two always 'wins' and its matrix is applied to both tex gens. This is an issue I will need to resolve so I am hoping you could provide some more guidance as to what would be the best solution. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, 13 January 2011 6:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Paul, Eye linear glTexGen is positional state, i.e. it's value depends on the current modelview matrix, so has to be treated by the OSG like other positional state like glLight and glClipPlane. All positional state has to be positioned by a positional state node, and for glTexGen this is TexGenNode. During the cull traversal the OSG collects the positional state and binds the TexGen/Light/ClipPlane to modelview matrix at that point in traversal, this binding is done via the PositionalStateContainer, and there is one of these per RenderStage. During the draw traversal the positional state is then applied prior to the traversal of the RenderStage, and fixes each positional state in the appropriate place. While this technique doesn't properly fix the state as required, it does limit you to one position, per stage, you can't have two eye line tex gens/lights/clip planes applied on two separate subgraphs. Object linear TexGen isn't positional state so can be applied in the normal way and you have multiple of these per stage without problem. To have multiple Eye linear TexGen/TexGenNode's you'll need to break the scene up into multiple RenderStage and use the clear mask set to 0 on the subsequent stages so that each stage overlays correctly on the previous one. Other approaches are to write a custom TexGen that you push/pop a custom modelview matrix. I'm afraid both approaches are rather hacky. Robert. On Thu, Jan 13, 2011 at 2:28 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- Has anyone ever successfully used multiple TexGen modes (say, EYE_LINEAR and OBJECT_LINEAR) on different objects in the same scene? What is the recommended way to do this in OSG? The TexGenNode has a pointer to a TexGen, and the TexGen has the mode. I assume I should create two TexGens, one OBJECT_LINEAR and one EYE_LINEAR, and two TexGenNodes to reference them, and add the two TexGenNodes to the scene graph. Then, I assume I should attach the same two TexGens as StateAttributes to different Node's StateSets as needed. I am running into some issues with this. If it sounds like I'm doing everything right, I'll post a small example that fails, or dig into the OSG code. More than likely, I'm doing something wrong here, so I just wanted to ask what the intended usage is. Thanks, -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ 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 DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales
