Re: [osg-users] Image::readPixels (3.0.1)
Hi Andrew,
Thanks for the callback code. Having a look at how this uses
osg::Image and how readPixels() calls allocateImage() it looks to me
the problems stems from the the later call not passing in the _packing
value so this defaults to 0. Your suggested fix of passing in the
_packing value to allocateImage() addresses this.
Looking at the API of the allocateImage() and readPixels() I can't
help but feel that readPixels() should match allocateImage() in having
the packing passed in as well, so avoid the need for you to call
setPacking(4). I have made this change and checked it into svn/trunk.
This will leave the original default behaviour in place but allow
users like yourself to set a specific packing value.
Robert.
On 29 March 2012 01:20, Andrew Cunningham andr...@mac.com wrote:
Just imagine this scenario of a DrawCallBack
struct SnapImage : public osg::Camera::DrawCallback
{
SnapImage(unsigned int format):
_snapImage(false),_format(format)
{
_image = new osg::Image;
_image-setPacking(4);
}
~SnapImage(){};
virtual void operator () (osg::RenderInfo renderInfo) const
{
if (!_snapImage) return;
osg::notify(osg::NOTICE)Camera callbackstd::endl;
osg::Camera* camera = renderInfo.getCurrentCamera();
osg::Viewport* viewport = camera ? camera-getViewport() : 0;
if (viewport _image.valid())
{
_image-readPixels(int(viewport-x()),int(viewport-y()),int(viewport-width()),int(viewport-height()),
_format,
GL_UNSIGNED_BYTE);
osg::notify(osg::NOTICE)Taken screenshot.. std::endl;
}
_snapImage = false;
}
mutable bool _snapImage;
mutable unsigned int _format;
mutable osg::ref_ptrosg::Image _image;
};
This will likely crash when width is not a multiple of 4. I not calling
setPacking() after the image has been allocated.
I wanted a packing of 4 as this matches the packing of BMP
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46659#46659
___
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] osg3.1.1 : bindPBufferToTextureImplementation not implemented
Hi there I'm trying to switch my application from osg 3.0.1 to osg 3.1.1 (and even to head 3.1.2) and I suddenly have the following message appearing cyclically: GraphicsWindow::bindPBufferToTextureImplementation(..) not implemented. The Line is written in PixelBufferX11 obviously, but comparing it to osg3.0.1 I find that the same line is there, too, but since the error doesn't come there, there must have been a change somewhere that makes osg3.1.1 call this part of code? The render loop is stuck somehow, nothing is displayed. Anybody else having the same behaviour? What do I have to do? Robert? Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg3.1.1 : bindPBufferToTextureImplementation not implemented
Hi David, I haven't seen this error. Does this occur in any of the OSG examples, this would help others understand what might be going on. What hardware/drivers are you using? Robert. On 29 March 2012 09:36, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: Hi there I’m trying to switch my application from osg 3.0.1 to osg 3.1.1 (and even to head 3.1.2) and I suddenly have the following message appearing cyclically: GraphicsWindow::bindPBufferToTextureImplementation(..) not implemented. The Line is written in PixelBufferX11 obviously, but comparing it to osg3.0.1 I find that the same line is there, too, but since the error doesn’t come there, there must have been a change somewhere that makes osg3.1.1 call this part of code? The render loop is stuck somehow, nothing is displayed. Anybody else having the same behaviour? What do I have to do? Robert? Regards Daniel ___ 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] osg3.1.1 : bindPBufferToTextureImplementation not implemented
Hi Robert I mixed up the include file path. This happens quickly when switching between different osg versions... my fault. Regards Daniel -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Donnerstag, 29. März 2012 10:41 An: OpenSceneGraph Users Betreff: Re: [osg-users] osg3.1.1 : bindPBufferToTextureImplementation not implemented Hi David, I haven't seen this error. Does this occur in any of the OSG examples, this would help others understand what might be going on. What hardware/drivers are you using? Robert. On 29 March 2012 09:36, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: Hi there I'm trying to switch my application from osg 3.0.1 to osg 3.1.1 (and even to head 3.1.2) and I suddenly have the following message appearing cyclically: GraphicsWindow::bindPBufferToTextureImplementation(..) not implemented. The Line is written in PixelBufferX11 obviously, but comparing it to osg3.0.1 I find that the same line is there, too, but since the error doesn't come there, there must have been a change somewhere that makes osg3.1.1 call this part of code? The render loop is stuck somehow, nothing is displayed. Anybody else having the same behaviour? What do I have to do? Robert? Regards Daniel ___ 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] bug in osgShadow VDSM texture stages
Hi there I observed a strange behaviour with osg 3.1.2 shadows. You can reproduce it very simply with osgshadow example. Just run it with the following arguments: Osgshadow -4 -vdsm -unit 4 As soon as you select a shadowunit of 4 and above, no more shadows are displayed. In my project application, I use multitexturing and therefore the 4 lowest texture stages are occupied. Does anybody know how to circumvent this limitation ? Regards Daniel *** Daniel Schmid Swiss SIMTEC AG Frutigenstrasse 4 CH-3600 Thun Tel:+41 33 533 02 10 Fax: +41 33 533 02 01 Mail: daniel.sch...@swiss-simtec.chmailto:cdaniel.sch...@swiss-simtec.ch URL: http://www.swiss-simtec.chhttp://www.swiss-simtec.ch/ *** ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bug in osgShadow VDSM texture stages
Hi Daniel, On 29 March 2012 12:54, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: I observed a strange behaviour with osg 3.1.2 shadows. You can reproduce it very simply with osgshadow example. Just run it with the following arguments: Osgshadow -4 –vdsm –unit 4 As soon as you select a shadowunit of 4 and above, no more shadows are displayed. In my project application, I use multitexturing and therefore the 4 lowest texture stages are occupied. Does anybody know how to circumvent this limitation ? Curious... by default the ViewDependentShadowMap will be using the fixed function pipeline to do the rendering and the fixed function pipeline provides a crude black shadow which isn't suitable for final applications but does at least handle most fixed function pipeline combinations. I wonder if in this case the fixed function pipeline set of for doing the shadow map is tied to just the four texture units. Try writing your own shaders for your scene graph that do the shadow map texture look up in their fragment shaders, I would expect this to work fine as others have certainly used scenes with larger than 4 units when using shaders. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Any one has updated osgVrpn from Mike Weiblen to OSG-3.xx ?
I used it recently, but it was on 2.8.5. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Graph layout using osgCompute
Hi Sorel,
If I understand you right, you want to access an undefined number of linear
arrays (OpenGL vertex buffers) during a single CUDA-kernel.
Each thread should work exclusively on one of these arrays.
I never tried this myself. Unfortunatelly I think the answer is no.
Here is what I found:
The only way you could call a kernel with a varying number of pointers,
would be to hand over an array of pointers:
Code:
void myKernel( float4** myArrays, uint numArrays )
{
...
}
However, then you will run into the problem that you cannot setup this array of
pointers on the host side as reported here:
http://forums.nvidia.com/index.php?showtopic=87337
Hopefully, I this answer will help you.
Best regards,
Jens
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46677#46677
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Efficient usage of Tessellator
Hiya, I have a bunch of shapes that can be kind of complex that I want to draw in osg, and I only have their border points available. I can draw them fine if I use the tessellator util. What I'd like to know is what underlying primitives are sent to OpenGL when I do tessellation. For example, here's some code: osg::ref_ptrosg::Geometry geom = new osg::Geometry; geom-setVertexArray(vertices.get()); geom-addPrimitiveSet(new osg::DrawArrays(GL_POLYGON,0,numOuterPolyPoints)); geom-addPrimitiveSet(new osg::DrawArrays(GL_POLYGON,numOuterPolyPoints, numInnerPolyPoints)); osgUtil::Tessellator geomTess; geomTess.setTessellationType(osgUtil::Tessellator::TESS_TYPE_GEOMETRY); geomTess.retessellatePolygons(*geom); osg::ref_ptrosg::Geode nodeGeom = new osg::Geode; nodeArea-addDrawable(geom); myRootNode-addChild(nodeGeom); I've read that GL_POLYGON is slow, unavailable with OpenGL ES and even deprecated after 3.x. Does the Tessellator change the initial primitive type? Should I be doing the above code differently to maximize compatibility and/or performance (ie use a triangle primitive)? If so, how? Regards, Preet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text Class Sizing Issue!
Well, since it not a submission per say. Here is the sample source code that
John wanted me to so you all.
Enjoy! Comments welcome!!
...
Laters!
D Glenn
David Glenn
---
D Glenn 3D Computer Graphics amp; Media Systems.
www.dglenn.com
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46681#46681
// Suggested Revisions to osgText::Text class.
// John Markano 3/21/2012
//
// The code below includes suggested fixes for two problems in osgText::Text
// in the OpenSceneGraph 2.8.1 release:
// (1) Text in object coordinates may be rendered with the wrong size.
// If an application requests a font resolution that the font doesn't
// support, OpenSceneGraph uses the closest supported
// resolution. osgText::Text does not handle this situation properly.
// It uses the requested resolution in some calculations where the
// actual resolution is more appropriate.
// (2) Text in screen coordinates may not be scaled properly when a
// perspective projection is specified. In particular, the displayed text
// size may vary with the field of view when it should remain constant
// relative to the screen.
//
// A class TextImproved is defined below to correct these problems. This class
// inherits osgText::Text and replaces three virtual functions in the parent
// class:
// - computeLastCharacterOnLine (for the first issue above)
// - computeGlyphRepresentation (for the first issue above)
// - computePositions (for the second issue above)
//
// Each of these functions includes suggested changes to the original code.
// The original code is also left in place for comparison. The preprocessor
// variable USE_ORIGINAL_CODE can be set to a non-zero value to compile the
// original code instead of the improved code.
//
// An example program is also provided below to provide a before-and-after
// illustration of these changes. This example program splits the screen
// into four quadrants, where
// - The upper left quadrant contains black text generated by osgText::Text
// with screen coordinates specified. It changes size with the field of
// view, but its size should be fixed.
// - The upper right quadrant contains black text generated by the
// TextImproved class defined below. This text should, and does, appear
// with a constant height of around 100 pixels. (No reference scale is
// provided.)
// - The lower left quadrant contains red text generated by osgText::Text
// with object coordinates specified. It should be one unit tall, but
// its actual size varies depending on what the active font supports.
// In this example, it's less than half as tall as the requested size
// because the default font resolution of 32 is much higher than the
// supported (by DefaultFont) resolution of 12.
// - The lower right quadrant contains red text generated by the TextImproved
// class. It displays closer to the correct height of one unit.
//
// The example program allows the user to increase or decrease the field
// of view using keystrokes. Type '+' to increase the field of view, or '-'
// to decrease the field of view. The camera position is fixed, so this
// is the only available viewing parameter control.
//
// This code was developed and tested using Red Hat Enterprise Linux 5.5,
// Qt 4.5.2 and OpenSceneGraph 2.8.1.
//
// This fix uses an uppercase E to find the available font size. This is
// a kludge that is inappropriate for many fonts. A suggested
// improvement would be to add a function to osgText::Font (and the
// DefaultFont subclass) to return the supported font resolution that is
// closest to the requested resolution.
#include osg/Camera
#include osg/Geode
#include osg/Geometry
#include osg/GL
#include osg/Group
#include osg/Math
#include osg/Matrix
#include osg/Notify
#include osg/Vec3
#include osg/Vec3d
#include osgGA/GUIEventHandler
#include osgText/Text
#include osgViewer/Viewer
#define USE_ORIGINAL_CODE (0)
using namespace osg;
using namespace osgText;
class TextImproved : public osgText::Text
{
protected:
String::iterator computeLastCharacterOnLine(osg::Vec2 cursor, String::iterator
first,String::iterator last)
{
Font* activefont = getActiveFont();
if (!activefont) return last;
#if USE_ORIGINAL_CODE
float hr = _characterHeight/getFontHeight();
#else
// Use an upper case E to determine which font size is available
// near the requested font resolution.
// Then compute a scale factor to scale the font to the requested
// character height. Include a factor of 0.7 to allow lower
// case characters to drop below the base of capital letters.
Font::Glyph* glyphGenericUpper = activefont-getGlyph(_fontSize, 'E');
float hr = 0.7 * (glyphGenericUpper
? _characterHeight/glyphGenericUpper-t()
: _characterHeight/getFontHeight());
#endif
float wr = hr/_characterAspectRatio;
bool kerning = true;
unsigned int
Re: [osg-users] Problem using osgconv to write OpenFlight
Hi Brad -- The client that contracted with me to develop the OpenFlight exporter specifically requested that the exporter support the same feature set as the importer. Since the importer doesn't load image files, likewise the exporter doesn't export image files. I'm not saying that's a good decision, I'm just giving you the background. :-) If you want to add this capability, you should probably use an export option to enable it, with the default being to not write the image data to files. As far as where to add this in the code, the exporter is a NodeVisitor. You should probably add a map of textures so that shared textures don't get written multiple times. -Paul On 1/20/2012 5:07 PM, Brad Colbert wrote: Hi folks, I found a work around. First, if I convert the IVE to OSG with the option osgconv -O OutputTextureFiles it will write out the .dds files. Then, I convert the IVE to FLT, which picks up those .dds files. A bit of a kludge but was wondering where I should look to make the proper changes to the OpenFlight writer to output the textures? -B -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Colbert Sent: Friday, January 20, 2012 3:56 PM To: 'osg-us...@openscenegraph.org' Subject: [osg-users] Problem using osgconv to write OpenFlight Hi folks, I'm suspecting that something is wrong with my DDS plugin but thought I would ask to see if it's something more fundamental. I'm trying to convert a .ive file to an OpenFlight file. I get the (.flt) file and the texture attribute files (.attr) but no texture files (.dds). Any ideas why? Thanks, Brad P.S. OpenSceneGraph Library 3.0.1 --- Brad Colbert Renaissance Sciences Corporation (480) 374-5073 ___ 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] Any one has updated osgVrpn from Mike Weiblen to OSG-3.xx ?
I imagine svn trunk HEAD is the latest, and if it hasn't been ported yet, then no one has done it. Mike Weiblen, Chris, and I all stay in fairly frequent contact (we all live in the same geographic region), and hasn't mentioned any recent development to osgVRPN or osgToy. -Paul On 3/29/2012 9:31 AM, Chris Hanson wrote: I used it recently, but it was on 2.8.5. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wish: convert osgGA::GUIEventAdapter to QKeySequence
So, I really wish the unmodified key was passed through. I have found more issues such as: * Ctrl+Shift+6 comes through as Ctrl Shift being pressed, but getKey() returns decimal 30 (a record separator). * Ctrl+Shift+0 (zero) - I see the Ctrl Shift key down, but nothing after that. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46687#46687 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Any one has updated osgVrpn from Mike Weiblen to OSG-3.xx ?
Ok thanks. I will use it with 2.8.x as I just need to do a short test with an intersense tracker... Pierre. 2012/3/29 Paul Martz pma...@skew-matrix.com I imagine svn trunk HEAD is the latest, and if it hasn't been ported yet, then no one has done it. Mike Weiblen, Chris, and I all stay in fairly frequent contact (we all live in the same geographic region), and hasn't mentioned any recent development to osgVRPN or osgToy. -Paul On 3/29/2012 9:31 AM, Chris Hanson wrote: I used it recently, but it was on 2.8.5. __**_ 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
Re: [osg-users] [build] OpenGLES2.0 build error
Hi Jordi, Thanks for the example. I couldn't figure out the CMake stuff, so I had to build my own XCode project, but it worked! So it seems like my OSG build now supports GLES2. !! Now on to porting my existing iOS projects to use this new rendering pipeline... fun. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46689#46689 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem using OSG GLSL uniforms and vertex attributes
Hello,
I'm re-implementing some shader code and I've run into a problem I've not had
before. That is, I'm switching on osg uniforms and vertex attributes for
shaders (testing GLSL 140), as it's laid out in the osgVertexAttributes
example, but it seems to only partly work.
Here's the shader code:
Vertex:
Code:
#version 140
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ModelViewProjectionMatrix;
in vec3 osg_Normal;
in vec4 osg_Vertex;
out vec3 normal;
void main()
{
normal = normalize(osg_NormalMatrix * osg_Normal);
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex; //ftransform();
}
Fragment:
Code:
#version 140
vec4 color1;
vec4 color2;
vec4 color3;
vec4 color4;
in vec3 normal;
out vec4 glFragColor;
void main()
{
color1 = vec4( 1.0, 0.5, 0.5, 1.0 );
color2 = vec4( 0.5, 0.2, 0.2, 1.0 );
color3 = vec4( 0.2, 0.1, 0.1, 1.0 );
color4 = vec4( 0.1, 0.05, 0.05, 1.0 );
vec4 light0 = vec4(0.0, 0.0, 0.0, 1.0);
float intensity = dot(vec3(light0), normal);
if (intensity 0.95) glFragColor = color1;
else if (intensity 0.5) glFragColor = color2;
else if (intensity 0.25) glFragColor = color3;
else glFragColor = color4;
}
Error log:
Code:
glLinkProgram FAILED
Program infoLog:
Vertex info
0(3) : warning C7555: 'attribute' is deprecated, use 'in/out' insetead
0(6) : error C1038: declaration of osg_ModelViewProjectionMatrix conflicts
with previous declaration at 0(2)
0(8) : error C1038: declaration of osg_Vertex conflicts with previous
declaration at 0(3)
I've used GLSL 140+ successfully in the past (OSG 2.8.x / 2.9.x), though I
don't have that code any longer. The error log makes no sense, suggesting I'm
declaring osg_ModelViewProjectionMatrix and osg_Vertex twice, with meaningless
line references. Interestingly, the osg_NormalMatrix and osg_Normal
declarations generate no errors.
Just to ensure it wasn't something I was doing, I modded osgVertexAttributes to
automatically load a model and apply the same GLSL 140 code - shader gen was
disabled. I didn't change any of the NodeVisitor code. Strangely enough, I
received a very similar error log for the vertex shader.
The GLSL 140 code was modded from the original 120 in the beginner's guide.
Prior to enabling the osg uniforms and vertex attributes, I tested the version
120 code and it worked just fine.
Maybe I missed a CMake option when I built my 3.0.1 binaries?
Thanks,
Joel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46690#46690
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
