[osg-users] unable to save render-to-texture image
Hi,all I was trying to save a render-to-texture image file many ways, however, failed each time. when i attach texture to camera.it works fine. but i attach image to camera. it doesn't work right. I saved the image data to .jpg, .png, .bmp format . but when i double-click the saved image file, there's nothing but blank.and when i tried do the same thing in the osg example osgprerender, the problem was still that. i use osgDB::writeImageFile(*image, "d:\\data\\test.bmp"); why? Is there someone met this problem? How did you fix it? [code] osg::ref_ptr colorMap = new osg::Texture2D; colorMap->setTextureSize(width, height); colorMap->setInternalFormat(GL_RGBA); colorMap->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR); colorMap->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR); osg::ref_ptr depthMap = new osg::Texture2D; depthMap->setTextureSize(width,height); depthMap->setInternalFormat(GL_DEPTH_COMPONENT); depthMap->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR); depthMap->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR); osg::ref_ptr camera = new osg::Camera; camera->setClearColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); camera->setReferenceFrame(osg::Transform::RELATIVE_RF); camera->setProjectionMatrixAsFrustum(-proj_right, proj_right, -proj_top, proj_top, znear, zfar); //camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF); camera->setProjectionMatrix(osg::Matrixd::identity()); camera->setViewMatrixAsLookAt(bs.center()-osg::Vec3(0.0f,2.0f,0.0f)*bs.radius(),bs.center(),osg::Vec3(0.0f,0.0f,1.0f)); camera->setViewMatrix(osg::Matrixd::identity()); camera->setViewport(0, 0, width, height); camera->setRenderOrder(osg::Camera::PRE_RENDER); camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); camera->attach(osg::Camera::DEPTH_BUFFER, depthMap); camera->attach(osg::Camera::COLOR_BUFFER, colorMap); osg::ref_ptr image = new osg::Image; image->allocateImage(width, height, 1, GL_RGBA, GL_FLOAT); image->setInternalTextureFormat(GL_RGBA); camera->attach(osg::Camera::COLOR_BUFFER, image.get()); osg::ref_ptr geo = createCube(colorMap, depthMap); camera->addChild(modelNode.get()); osg::ref_ptr parent = new osg::Group; parent->addChild(geo.get()); parent->addChild(camera.get()); osgDB::writeImageFile(*image, "test.bmp"); //colorMap->setImage(0, image); return parent.get(); [/code] ... Thank you! Cheers, sun -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38548#38548 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render To Image Crash in RenderStage.cpp - trunk
You could use a pbuffer instead of a window. See the osgscreencapture
example's pbuffer options.
jp
On 16/04/11 00:46, Matthias Asselborn wrote:
Hi,
i want to render a loaded scene into an image.
i dont want to see any viewer windows.
I have tried to realize it with osg::Viewer, but after the call
viewer->frame a viewer window poped up.
Now ive tried it with osgUtils::SceneViewer
but after the draw call - the program crashes
whats wrong?
Code:
osg::ref_ptr shot = new osg::Image();
shot->allocateImage( 800, 600, 1, GL_RGB, GL_UNSIGNED_BYTE );
osg::ref_ptr subgraph = m_pNode.get();
osg::ref_ptr camera = new osg::Camera;
osg::ref_ptr oldcamera = m_pViewer->getCamera();
//Copy the settings from sceneView-camera to get exactly the view
//the user sees at the moment:
camera->setClearColor( oldcamera->getClearColor() );
camera->setClearMask( oldcamera->getClearMask() );
camera->setColorMask( oldcamera->getColorMask() );
camera->setTransformOrder( oldcamera->getTransformOrder() );
camera->setProjectionMatrix( oldcamera->getProjectionMatrix() );
camera->setViewMatrix( oldcamera->getViewMatrix() );
// set view
camera->setReferenceFrame( osg::Transform::ABSOLUTE_RF );
// set viewport
camera->setViewport( 0, 0, 800, 600 );
//set the camera to render before after the main camera.
camera->setRenderOrder( osg::Camera::POST_RENDER );
// tell the camera to use OpenGL frame buffer object where supported.
camera->setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT );
camera->attach( osg::Camera::COLOR_BUFFER, shot.get() );
// add subgraph to render
camera->addChild( subgraph.get() );
//camera->addChild(TheDocument->GetHUD().get() );
//Need to mage it part of the scene :
m_pViewer->setSceneData( camera.get() );
//Make it frame:
m_pViewer->update();
m_pViewer->cull();
m_pViewer->draw();
// in draw call the software crashes
osgDB::writeImageFile( *shot, "C:/tools/test.bmp" );
The crash appers in
RenderStage.cpp Line 1146 - trunk
Code:
if (_graphicsContext.valid()&& _graphicsContext != callingContext)
{
// show we release the context so that others can use it?? will do so
right
// now as an experiment.
callingContext->releaseContext();
Thank you!
Cheers,
Matthias
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38516#38516
___
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] unable to save render-to-texture image
Hi, On 18/04/11 08:26, sun qi wrote: Hi,all I was trying to save a render-to-texture image file many ways, however, failed each time. when i attach texture to camera.it works fine. but i attach image to camera. it doesn't work right. I saved the image data to .jpg, .png, .bmp format . but when i double-click the saved image file, there's nothing but blank.and when i tried do the same thing in the osg example osgprerender, the problem was still that. i use osgDB::writeImageFile(*image, "d:\\data\\test.bmp"); why? Is there someone met this problem? How did you fix it? [code] osg::ref_ptr colorMap = new osg::Texture2D; colorMap->setTextureSize(width, height); colorMap->setInternalFormat(GL_RGBA); colorMap->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR); colorMap->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR); osg::ref_ptr depthMap = new osg::Texture2D; depthMap->setTextureSize(width,height); depthMap->setInternalFormat(GL_DEPTH_COMPONENT); depthMap->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR); depthMap->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR); osg::ref_ptr camera = new osg::Camera; camera->setClearColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); camera->setReferenceFrame(osg::Transform::RELATIVE_RF); camera->setProjectionMatrixAsFrustum(-proj_right, proj_right, -proj_top, proj_top, znear, zfar); //camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF); camera->setProjectionMatrix(osg::Matrixd::identity()); camera->setViewMatrixAsLookAt(bs.center()-osg::Vec3(0.0f,2.0f,0.0f)*bs.radius(),bs.center(),osg::Vec3(0.0f,0.0f,1.0f)); camera->setViewMatrix(osg::Matrixd::identity()); camera->setViewport(0, 0, width, height); camera->setRenderOrder(osg::Camera::PRE_RENDER); camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); camera->attach(osg::Camera::DEPTH_BUFFER, depthMap); camera->attach(osg::Camera::COLOR_BUFFER, colorMap); osg::ref_ptr image = new osg::Image; image->allocateImage(width, height, 1, GL_RGBA, GL_FLOAT); Not many image writers support float output, try GL_UNSIGNED_CHAR instead of GL_FLOAT here. Also, try write the image out in the Camera callback. jp image->setInternalTextureFormat(GL_RGBA); camera->attach(osg::Camera::COLOR_BUFFER, image.get()); osg::ref_ptr geo = createCube(colorMap, depthMap); camera->addChild(modelNode.get()); osg::ref_ptr parent = new osg::Group; parent->addChild(geo.get()); parent->addChild(camera.get()); osgDB::writeImageFile(*image, "test.bmp"); //colorMap->setImage(0, image); return parent.get(); [/code] ... Thank you! Cheers, sun -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38548#38548 ___ 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] Issue with drawing polygons
Hi, Guarav This could be driver issue, try latest drivers or google :) Cheers, Sergey. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi JS, About other serializers (Collada, FBX...), I guess it would be nice using the OSG serialization (as you say), or a default/fallback one. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - "Jean-Sébastien Guay" a écrit : > Hi Sukender, > > > Actually I hoped someone would help us on the serialization subject! > And yes, I guess new serializers may help. > > I think so, I haven't used them that much but from the description > they > seem simple to use, and as long as the class you want to save is > serializable then when the osg::Object serializes itself it can > serialize all its metadata at the same time. > > > But what about formats supporting metas? It may be helpful to add > somewhere a callback/serializer/anything, which may be called by > plugins to convert from/to a string representation when not handled > natively. No? > > Ah, so you're talking about saving to formats other than .osgt/.osgb > right? > > In that case perhaps the same serializers can be used to serialize the > > metadata, and then put that in a string inside metadata of the other > format file. And then when reading you just check if one of the > metadata > in the file corresponds to some OSG-serialized data, and deserialize > it. > That could work. > > And if the format has additional data that OSG doesn't know about, but > > which the reader might want to store as metadata in the OSG nodes when > > reading the file (like the recent discussion about OpenFlight Surface > > Material Codes), the ReaderWriter can easily add metadata when reading > too. > > But I think perhaps loading/saving metadata to/from OSG-native formats > > would be enough for now... > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.dyndns-web.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
Re: [osg-users] ShaderGen and OpenGL ES2
HI Ankur,
osgUtil::ShaderGen was written for GL2 rather than GLES2, and we've
just quickly used this class as a fallback to provide some basic
fallback functionality, it's certainly not a ideal solution for GLES2
or able to cope with all fixed function state.
I'm not personally working on updating ShaderGen for GLES2, and I'm
not aware of others doing this work, but they may be. Feel free to
dive in an help improve ShaderGen's support for GLES2.
Robert.
On Fri, Apr 15, 2011 at 1:21 PM, Ankur Gandhi wrote:
> Hi Robert,
>
> I am using OSG 2.9.11 dev release. recently I have started working on OSG
> over GLES2. Although my OSG based code is working fine on OpenGL based
> system, i face similar issues that of Yun-Ta on GLES2. My test application is
> importing a plain 3ds max object onto screen along with light source. when i
> run the program, i get following output.
>
>
> libEGL warning: failed to create DRM screen
> libEGL warning: use software fallback
> GraphicsWindowX11::init() - eglInitialize() succeded eglMajorVersion=1
> iMinorVersion=4
> GraphicsWindowX11::init() - window created =1
> VERTEX glCompileShader "" FAILED
> VERTEX Shader "" infolog:
> 0:0(0): error: `osg_Normal' redeclared
> 0:19(34): error: `gl_LightSource' undeclared
> 0:19(46): error: type mismatch
>
> FRAGMENT glCompileShader "" FAILED
> FRAGMENT Shader "" infolog:
> 0:20(20): error: syntax error, unexpected NEW_IDENTIFIER, expecting ',' or ';'
>
> glLinkProgram "" FAILED
> Program "" infolog:
> linking with uncompiled shaderlinking with uncompiled shader
> Warning: detected OpenGL error 'invalid enumerant' at after
> RenderBin::draw(..)
> Warning: detected OpenGL error 'invalid enumerant' at end of SceneView::draw()
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
>
>
> I was just wondering if work on ShaderGen is going on in some other branch or
> something? or am i doing anything wrong here to run 3ds max object over GLES2?
>
> any help would be appreciated.
>
> Thanking you in anticipation.
>
> Regards,
> Ankur
>
>
>
> robertosfield wrote:
>> Hi Yun-Ta,
>>
>> ShaderGen assumes OpenGL 2 feature set, so items like the built in
>> gl_* uniforms and vertex attributes are used. osg::State does map
>> automatically a number of these uniforms for GLE2 but doing a search
>> and replace of them, this isn't exhaustive though.
>>
>> The work I'm just starting now on shader composition will make
>> ShaderGen completely redundant and will properly support GLES 2, GL3
>> and GL4, so the issues you are seeing should disappear completely.
>>
>> Robert.
>>
>> On Wed, Jun 30, 2010 at 6:08 PM, <> wrote:
>>
>> > Hi all,
>> >
>> > I am trying to test OSG (2.9.8) on N900 with OpenGL ES2.
>> > However, ShaderGen.cpp seems to be not fully compatible with OpenGL ES2
>> > standard.
>> >
>> > For instance, gl_LightSource is not defined in ES2 and precision
>> > attribute (mediump / highp / lowp) has been missing. The later one can
>> > be easily fixed while the first one using undefined variables is more
>> > difficult to work around.
>> >
>> > Here is the GLSL code generated from ShaderGen.cpp:
>> > Nokia-N900:/home/user/osg-data# /opt/osg/bin/osgviewer cessna.osg
>> > GraphicsWindowX11::init() - eglInitialize() succeded eglMajorVersion=1
>> > iMinorVersion=4
>> > GraphicsWindowX11::init() - window created =1
>> > State::convertShaderSourceToOsgBuiltIns()
>> > ++Before Converted source
>> > varying vec3 normalDir;
>> > varying vec3 lightDir;
>> > varying vec3 viewDir;
>> >
>> > void main()
>> > {
>> > gl_Position = ftransform();
>> > normalDir = gl_NormalMatrix * gl_Normal;
>> > vec3 dir = -vec3(gl_ModelViewMatrix * gl_Vertex);
>> > viewDir = dir;
>> > vec4 lpos = gl_LightSource[0].position;
>> > if (lpos.w == 0.0)
>> > lightDir = lpos.xyz;
>> > else
>> > lightDir = lpos.xyz + dir;
>> > }
>> >
>> >
>> > Converted source
>> > uniform mat3 osg_NormalMatrix;
>> > uniform mat4 osg_ModelViewProjectionMatrix;
>> > uniform mat4 osg_ModelViewMatrix;
>> > attribute vec4 osg_Vertex;
>> > attribute vec3 osg_Normal;
>> > varying vec3 normalDir;
>> > varying vec3 lightDir;
>> > varying vec3 viewDir;
>> >
>> > void main()
>> > {
>> > gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
>> > normalDir = osg_NormalMatrix * osg_Normal;
>> > vec3 dir = -vec3(osg_ModelViewMatrix * osg_Vertex);
>> > viewDir = dir;
>> > vec4 lpos = gl_LightSource[0].position;
>> > if (lpos.w == 0.0)
>> > lightDir = lpos.xyz;
>> > else
>> > lightDir = lpos.xyz + dir;
>> > }
>> >
>> >
[osg-users] Community news: Remo 3D v2.1
Hi all, Just wanted to let you know that I recently added the first community news item since 2009. :-) http://www.openscenegraph.org/projects/osg/blog/Remo3Dv2.1 It would be nice if that section was more active, always fun to know what happens with OSG-related projects and products. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and OpenGL ES 2.0
Hi Ankur, On Sat, Apr 16, 2011 at 10:40 AM, Ankur Gandhi wrote: > You are right. both are quire different. I ported OSG over OpenGL ES 2.0 and > everything is behaving in different way. I guess I almost need to rewrite my > OpenGL application. Also i think i need to go through ShaderGen to understand > how well the OpenGL application gets converted to GLSL language. The big difference with GLES2 is that there is no fixed function pipeline so you have to provide shaders yourself. This situtation is the same for the GL 3.x and beyond profiles where backwards compatability is dropped, so it's in't really a case of GL vs GLES2, rather it's GL1/GLES1 fixed function vs GL3/GL4/GLES2 shader based, with GL2 sitting on the fence - doing both fixed function and shaders. You can also used shaders entirely with GL2, and even your the CMake to build only the shader backends, and not implement the fixed function state, so replicate much of what it takes to program GLES2 entirely on a machine with only GL2 available. This approach also allows you to build final applications that will more easily port between desktop and GLES2 targets. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osgFX::SpecularHighlights
Hi, It works! Thank you! Cheers, Lv -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38558#38558 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osg-users[ Viewer as emmbeded and existing modelview and projection matrices
Hi All I'm currently working on added some osg functionality to an existing opengl es app. The application already applies all the relavent matrix and viewport information. I was wondering if there was a simple way to just draw my osg viewer but without applying any matrix or viewports to the current GL state? Cheers Tom ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-users[ Viewer as emmbeded and existing modelview and projection matrices
On 4/18/2011 8:19 AM, Thomas Hogarth wrote: > I'm currently working on added some osg functionality to an existing opengl > es app. The > application already applies all the relavent matrix and viewport information. > I was > wondering if there was a simple way to just draw my osg viewer but without > applying any > matrix or viewports to the current GL state? I don't know for sure, but I wonder could you simply use the setProjectionMatrix and setViewMatrix methods on your osgViewer's Camera, to load the identity matrix to both? You'd want to make sure your viewer didn't have any manipulators and things that could dynamically modify the matrices. > Cheers > Tom -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] I am back
hello community, I am back :) ... this time from macedonia .. have you missed me?? -- Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
You could use an implicit constructor, e.g.
template
class Value {
Value(T);
Value(const Value&);
};
class Value;
template
void addMeta(const std::string&, const Value& v) {
Value* localcopy = new Value(v);
}
so the function call:
addMeta("myMeta", 5);
is implicitly converted to:
addMeta(std::string("myMeta"), Value(5));
Two considerations:
- There is some copying involved, which might be undesirable for large
arrays. C++ 2011 move constructors are intended to solve this problem
in general, but it's unlikely that OSG compatibility requirements will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for Value must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new Value(v).
On a related note, my preference would be for the Value class to be
immutable so that you are required to set metadata values through the
API rather than poking Value objects directly. This is necessary if
you want to support alternate backing stores which don't use Value
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
> Hi Peter,
>
> Thanks... but what for the addMeta()?
> I mean it's okay having a addMeta(string, ValueBase *), but this will force
> you to write
> o->addMeta( "myMeta", new Value(5) );
> instead of simply
> o->addMeta( "myMeta", 5 );
> which could be nice. Any idea?
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-users[ Viewer as emmbeded and existing modelview and projection matrices
Hi Thomas, The OSG's cull traversal requires information about the viewport, projecton and view matrices, and the draw traversals use this data in the draw traversal, so you have to pass them in via the setting of appropriate OSG data structures like osg::Camera. Applying viewports, projection and modelview matrices is pretty lightweight so setting it multiple times in the draw traversal of your application won't be a performance issue. Robert. On Mon, Apr 18, 2011 at 3:19 PM, Thomas Hogarth wrote: > Hi All > I'm currently working on added some osg functionality to an existing opengl > es app. The application already applies all the relavent matrix and > viewport information. I was wondering if there was a simple way to just > draw my osg viewer but without applying any matrix or viewports to the > current GL state? > Cheers > Tom > ___ > 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] I am back
Hi Nick, I am back :) ... this time from macedonia .. have you missed me?? Welcome back! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-users[ Viewer as emmbeded and existing modelview and projection matrices
Hi Guys Thanks for the speedy replies, yes seems like using the same model view matrix for the osg camera and then ensuring I reapplied the originals the next time round. They were only getting applied on setup by the original app then being read back from OpenGL before being applied again so think it was actually copying my incorrect osg matrix. So now I have an osg model surrounded by raw OpenGL gui, nice. I've finally landed some contract work and convinced them that osg is root to take for quickly adding animated 3d models to their app. It's for the IOS platform so fingers crossed all goes well. Cheers Tom On 18 April 2011 16:22, Robert Osfield wrote: > Hi Thomas, > > The OSG's cull traversal requires information about the viewport, > projecton and view matrices, and the draw traversals use this data in > the draw traversal, so you have to pass them in via the setting of > appropriate OSG data structures like osg::Camera. Applying viewports, > projection and modelview matrices is pretty lightweight so setting it > multiple times in the draw traversal of your application won't be a > performance issue. > > Robert. > > On Mon, Apr 18, 2011 at 3:19 PM, Thomas Hogarth > wrote: > > Hi All > > I'm currently working on added some osg functionality to an existing > opengl > > es app. The application already applies all the relavent matrix and > > viewport information. I was wondering if there was a simple way to just > > draw my osg viewer but without applying any matrix or viewports to the > > current GL state? > > Cheers > > Tom > > ___ > > 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] clipping problem with PagedLODs
I created two new classes: ClipNodeReused inherited from ClipNode, and ClipPlaneReused from ClipPlane (basically just overriding apply(osg::State&)). These classes enable me to reuse the OpenGL clipping planes so that I can do more than the graphics hardware limit of 6-8 clipping planes. This has worked well. However, I recently discovered that some model files do not get clipped correctly. The only thing that I see is different about these files is that they contain PagedLODs. I am not sure of the details of LODs to know if some form of clipping (perhaps as part of some form of culling?) might be happening that is keeping my custom clipping from occurring. Have others been able to clip PagedLODs successfully? Any ideas what might be going wrong here? Thanks! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render To Image Crash in RenderStage.cpp - trunk
what can i do? ive always a crash? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38569#38569 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple lights in a scene
Hi Gordon, I hope those puns were intended, in any case, they brightened my day ;) I did search the archives and found one reference to the osgmanylights tutorial, but unfortunately it is no longer on the site that it was linked to, does anyone have a copy of that tutorial lying around in their archive? The old link was: http://www.fx.clemson.edu/~acnatha/devnull/osg/osgmanylights.tar.gz I was however able to successfully implement pixel-based lighting in a fragment shader with as many lights as desired (up to shader memory limits of course). I basically just defined my own uniform array of gl_LightSourceParameters in the shader program. The values of these custom lights are controlled with uniforms which, when wrapped up in a LightUniforms class provides an API identical to osg::Light. A LightShader class, derived from osg::Shader, provides an interface for setting the number of lights which basically just does a search and replace of a special string (i.e. NUM_LIGHTS) in the shader source and then forces a recompilation of the shader program. This all works fine. The problem comes however in positioning the lights. If I understand correctly, OSG uses a LightSource placed in the scenegraph to modify the position of its associated Light according according to its parent transformation(s). This gets done by the PositionalStateContainer which gets added to the RenderStage during cull traversal in CullVisitor::accept(LightSource) -> RenderStage::addPositionedAttribute(). I was thinking about a couple of solutions to this: 1. Derive my own classes from osg::Light and osg::LightSource. This is problematic for a number of reasons: - CullVisitor, being a Visitor class, cannot be expanded (without modifying its interface) to recognize new classes (one of the tradeoffs for the Visitor pattern). So it will not recognize my derived LightSource class, if I understand the Visitor pattern correctly. - Deriving from osg::Light, which calls fixed function opengl lighting calls, causes GLMode errors for light numbers >= GL_MAX_LIGHTS. 2. Do not derive my own classes osg::Light and osg::LightSource, but instead make my LightSource-type class subclass from osg::Group directly, override the traverse() method, extract the localtoWorld transform from the visitor object and and based on that set the position and spotdirection on the (non osg derived) Light. However, this has some other side effects: - we have a shadow class, based on osg::ShadowTechnique, which relies on the PositionalStateContainer mechanism described above to position the shadow projectors to coincide with the osg::Light. Not using the osg::Light will not trigger this mechanism. At the moment I'm leaning toward solution 2, but then that would force me to adapt the shadowing class (which I inherited and it isn't pretty). I would like to get solution 1 to work though, but I can't figure out a way to use the osg::Light/LightSource interface and prevent it from calling the opengl fixed function API. It would be nice if all the osg::Light methods were virtual, then I could just derive my LightUniforms based class from osg::Light. I did read in the OSG QSG, page 69: "OSG lets you use more light sources than the underlying OpenGL implementation supports, but this is beyond the scope of this book." Is there another resource whose scope this isn't beyond? Does this have to do with multiple RenderStages, which I suspect is in the osgmanylights example? Thanks, Chris On Tue, Nov 18, 2008 at 8:05 PM, Tomlinson, Gordon wrote: > Search the mailing list archive will find many illuminating answers to this > type of question > > Opengl only supports 8 active light sources thus OSG supports one 8 active > light sources > > Also search the Opengl sites for more enlightenment > > > Gordon > > __ > Gordon Tomlinson > > Product Manager 3D > Email : gtomlinson @ overwatch.textron.com > __ > (C): (+1) 571-265-2612 > (W): (+1) 703-437-7651 > > "Self defence is not a function of learning tricks > but is a function of how quickly and intensely one > can arouse one's instinct for survival" > - Master Tambo Tetsura > > > > > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of dasari > pavan kumar > Sent: Tuesday, November 18, 2008 12:50 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Multiple lights in a scene > > Hi, > I am relatively new to using Lights in openscenegraph. I would like to > have a single light replicated 100 times at different places (The situation > is something like this. I need to light all the rooms in an apartment. > however every light is of the same ambient and diffuse color). But the > lights are not being rendered in the scene. Can anyone help me with this > situation ? > > I have created a LightSource with ce
Re: [osg-users] Multiple lights in a scene
Hi Chris,
First of all, I have to commend you on all the work you've put into
doing this. You obviously put a lot of thought and research into your
problem, and explored multiple avenues before posting, which I have to
admire!
I've personally never needed more than the 8 light sources the fixed
pipeline gave me, so I've always used the built-in gl_LightSource[i]
structure and osg::LightSource+osg::Light to manage my lights. I have a
mechanism in place that lets me reuse light IDs when lights get turned
on or off (a light turned off frees its light ID, and a light turned on
will take the first available light ID), and this uses IDs 0-7, which
has been sufficient for me. Add to that the fact that OSG's built-in
shadow techniques support casting shadows from only one light, and I've
never really had a need (personally or from client requirements) to go
further. But that's not to say it won't happen.
What I'd say in response to your question is, I think you have a good
idea of what is the best solution to your problem (solution 1), but it
requires some small changes to OSG itself in order to be feasible. So
what prevents you from proposing these changes? Robert hasn't been
against making some methods virtual when needed in the past, and even
deeper changes will be possible when they're justified.
About the CullVisitor, I don't understand what you mean about not
recognizing new classes. First of all, sure, you could add new classes
to its interface, but even if not, you can always, in the
accept(osg::LightSource&) method, check with a dynamic_cast if the
lightSource is of your derived class:
virtual void accept(osg::LightSource& ls)
{
if (dynamic_cast(&ls) != 0)
{
// My light source subclass.
}
else
{
// Plain old osg::LightSource
}
}
But whatever you decide, I think you shouldn't rule out changes to the
core OSG. The fixed pipeline is out, and shaders are in, and if OSG
could be made to support its own osg_LightSource[i] uniforms, with
indices limited only by shader memory (while not ruling out the
possibility that the first 8 of those be mapped to the fixed pipeline
light sources if the fixed pipeline is available) then that would be
very nice indeed.
I'll just add one last note, another way to deal with many light sources
would be to do deferred shading, maybe you should look this up. It all
depends on what you're doing, but deferred shading has the advantage
that all complex lighting calculations (per pixel lighting, normal
mapping, etc.) happen in screen space only once per visible pixel,
instead of possibly happening many times per pixel and being overwritten
(because of z order).
Hope this helps, and I hope you'll be able to show us some really cool
stuff in the near future,
J-S
On 18/04/2011 10:09 PM, SkullCheck wrote:
Hi Gordon,
I hope those puns were intended, in any case, they brightened my day ;)
I did search the archives and found one reference to the osgmanylights
tutorial, but unfortunately it is no longer on the site that it was
linked to, does anyone have a copy of that tutorial lying around in
their archive? The old link was:
http://www.fx.clemson.edu/~acnatha/devnull/osg/osgmanylights.tar.gz
I was however able to successfully implement pixel-based lighting in a
fragment shader with as many lights as desired (up to shader memory
limits of course). I basically just defined my own uniform array of
gl_LightSourceParameters in the shader program. The values of these
custom lights are controlled with uniforms which, when wrapped up in a
LightUniforms class provides an API identical to osg::Light. A
LightShader class, derived from osg::Shader, provides an interface for
setting the number of lights which basically just does a search and
replace of a special string (i.e. NUM_LIGHTS) in the shader source and
then forces a recompilation of the shader program. This all works
fine.
The problem comes however in positioning the lights. If I understand
correctly, OSG uses a LightSource placed in the scenegraph to modify
the position of its associated Light according according to its parent
transformation(s). This gets done by the PositionalStateContainer
which gets added to the RenderStage during cull traversal in
CullVisitor::accept(LightSource) ->
RenderStage::addPositionedAttribute(). I was thinking about a couple
of solutions to this:
1. Derive my own classes from osg::Light and osg::LightSource. This is
problematic for a number of reasons:
- CullVisitor, being a Visitor class, cannot be expanded (without
modifying its interface) to recognize new classes (one of the
tradeoffs for the Visitor pattern). So it will not recognize my
derived LightSource class, if I understand the Visitor pattern
correctly.
- Deriving from osg::Light, which calls fixed function opengl lighting
calls, causes GLMode errors for light numbers>= GL_MAX_LIGHTS.
2. Do not derive my own classes osg::Light and osg::LightSource, but
instead make my LightSo
Re: [osg-users] Forked osgIntrospection to cppintrospection
Hello dear OSG users, Let's follow up on this thread, before I make another release of cppintrospection, in order to package it in Debian! (and other operating systems) 2011/3/15 Mike Wozniewski : > In the meantime, there hasn't been a stable tag made for osgIntrospection in > the svn. In order to build it, I usually end up deleting a bunch of wrappers > that don't compile. Furthermore, we don't need all of the osgWrappers. We > just need the core osgIntrospection classes (Type, MethodInfo, etc), as > required for reflection or our own classes that we have derived from OSG. > > * ie, we don't need osgWrappers, just introspection * Yes, we need a tag, so that I can package it for Debian GNU/Linux. We also need it to be packaged separately. > > At some point Robert mentioned that osgIntrospection could become a generic > C++ introspection, and this is the inspiration for 'cppintrospection'... > something that can be used independently of OSG. I like this idea. Less > bloat, and much faster to build for projects like ours. > > I think the name distinction is necessary, since legacy systems that have > versions of OSG < 2.9.9 will contain a library called libosgIntrospection, > that contains (is linked with) all of the osgWrappers. > For the name of the project, Mike Wozniewski and I think we need this project to be renamed cppintrospection to avoid a name clash with the former one, unless I am misled. We still use some old OSG that is packaged in Debian, and it contains a osgIntrospection library. Also, I really want to avoid working with Subversion, as Git is much more fun to work with. Those two issues are not really issues, after all. I would really like to collaborate with you, Wang Rui, and benefit from your future changes to this project. I don't plan to make any change to it, as I am only interested in seeing it packaged, especially for Debian GNU/Linux. For the CMake packaging, I would be totally up for having it aside from the GNU Autotools, but I don't know how to use it, and have no time for this. I know the GNU Autotools, and that's is it for now. So, if I move forward with renaming this library and releasing a 2.12.0 tag to package it for Debian, would you be willing to move along, Wang Rui, and contribute to it? Otherwise, I guess I will simply apply you changes as patches from "upstream" to the gentle "fork". What do you think? Best regards, -- Alexandre Quessy http://alexandre.quessy.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] addSlave messup main cameras stateset
hi in order to display a rectangle roi over the 3d scene i use the example
provided in osg hud. however before drawing the roi i press a toggle selection
button which gets the stateset of the main camera as given below
Code:
osg::StateSet *stateSet = osg_viewer->getCamera()->getOrCreateStateSet();
osg::Point *pointState =
(osg::Point*)stateSet->getAttribute(osg::StateAttribute::POINT);
The 2d rectangle is drawn by mouse drag using the handler function. In the
handler function the slave camera is created and added to the viewer as
addSlave.
Code:
case(osgGA::GUIEventAdapter::PUSH):
{
camera_slaveBBox = createBBoxCamera();
viewer->addSlave(camera_slaveBBox, false);
}
As the mouse the dragged the rectangle is drawn and all is good untill..On
pressing the toggle selection button again in the first code "stateSet" is now
returned NULL :(
Now if i comment
Code:
//commentviewer->addSlave(camera_slaveBBox, false)
then stateSet indeed has some value. whats is the problem?
[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38572#38572
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
