Re: [osg-users] Disapplying of StateAttributes
Hello,
I don't follow completely your meaning but I guess if you have an array
with {GL_COLOR_ATTACHMENT0} and call glDrawBuffers(1, arr) (forgive the
syntax errors) you will Dis the DrawBuffer attribute. That means you
will need to have the array of attachments and it's length as Attribute
in the state, where the defaults are as I wrote before, and then when
the state pops, the difference will be noted and the default will apply.
Hope that helps,
Guy.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Art
Tevs
Sent: Tuesday, April 15, 2008 1:46 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Disapplying of StateAttributes
Hi Robert,
One can't remove state from OpenGL, its a state
machine, you only modify its
current state. The
Yes, I know.
OSG manages this by using
osg::State which maintains a
stack of StateSet that are currently applied, and
stacks for the individual
modes and attributes that are applied. When a
stateset is popped the
modes/attributes that were applied by the parent
StateSet are applied.
This means that the parent StateSet has to contain
some stateattribute which restores the applied state
in the previous state.
Ok, I need this behaviour for the following thing:
I am currently preparing a patch for the FBOs and
MRTs. Here I would like to move the glDrawBuffers call
from the RenderStage to the FBO, since I would like to
use FBOs without camera's, hence on its own. This
would be also more general approach, then this one,
which we currently have.
Now the problem is, that in FrameBufferObject::apply()
method I would like to set the draw buffers
accordingly. However, I have no idea how to restore
the opengl's state back?!?!?!
If there would be something like ::disapply() method,
I would be able to restore the drawbuffers by
resetting them to the value as they were before.
Since there is no such call, I have to set the
drawbuffers to some default value, for which there is
no real default value exists
So any ideas how to manage this?
These applies are all done lazily - so if the state
doesn't change then no
OpenGL class are made.
When non modes or attributes are left on the stack
once everything is popped
off then default modes are used, and default
constructed versions of the
attributes are applied to restore OpenGL state back
to defaults.
Robert.
On Tue, Apr 15, 2008 at 12:27 PM, Art Tevs
[EMAIL PROTECTED] wrote:
Hi Robert,
no the question wasn't how to remove
stateattribute
from osg, but how to reset/remove state from
opengl.
Imagine following situation:
A
/ \
BC
Node B set some attribute. Node C doesn't have
this
attribute, however since there seems no disapply
method, C would get this attribute too (of course
assuming B and C are rendered sequentially).
In the stateset-removeAttribute() there is a call
to
setAssociatedModes() which probably disables the
corresponding mode of the attribute. However, what
to
do if there is no mode associated with the
attribute?
How is this managed?
--- Robert Osfield [EMAIL PROTECTED]
schrieb:
Hi Art,
If you want to remove a mode or attribute you
simply
one of use:
stateset-removeMode(..);
stateset-removeAttribute(..);
stateset-removeTextureAttribute(unit,..);
This will make the StateSet inherit from above.
As for the default set, OpenGL defaults are
almost
always used, but not
quite always. The GL_DEPTH_TEST is on by
default in
the OSG. Defaults for
the attributes can be found in the default
constructed versions of those
attributes.
Robert.
On Tue, Apr 15, 2008 at 11:14 AM, Art Tevs
[EMAIL PROTECTED] wrote:
Hi folks,
imagine I have a StateAttribute which do set
the
OpenGL's pipeline in some state. Now this
attribute is
applied for a node and the corresponding
subgraph
or
only that node is rendered with this
attribute.
However there is no call to disapply this
attribute. I
mean how do I know which state the OpenGL's
pipeline
was before this attribute was applied to
restore
it.
OK, as far as I see from different
StateAttribute's
derivatives (FBO, Viewport, Texture, ...)
there is
some default function call to set the GL's
pipeline in
a predictable state (i.e. bind FBO or texture
with
id
0, set default viewport, ...).
However what if there is no real default state
to
which to return the GL's pipeline? How to
manage
this?
__
Gesendet von Yahoo! Mail.
Der Lieblings-Mailbox der Welt.
http://de.overview.mail.yahoo.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users
Re: [osg-users] Using Custom Mouse Cursor
Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Moles Sent: Tuesday, April 15, 2008 5:17 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Using Custom Mouse Cursor On Tue, 2008-04-15 at 18:04 +0200, Guy wrote: Hello, I have no suggestion to solve the problem, but if the functionality to set the default cursor will be added, it should support a 3D cursor too. That means, hiding the operating system cursor and moving 3D object on the screen space according to the mouse movements. By the way, isn't there some sort of that implementation in osgWidget? Well, I can't really comment on the 3D cursor, but I will certainly be adding normal cursor changing support to osgWidget. I haven't begun to investigate this yet, but I commonly refer to SDL on issues such as these, so I'm sure they have a lot of good example code on how such a thing can be accomplished--and thus, integrated into OSG, if it isn't already. Thanks, Guy. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Monday, April 14, 2008 11:18 PM To: osg users Subject: [osg-users] Using Custom Mouse Cursor Hi all, I'm attempting to use OSG embedded in a C# window like hesicong and Glenn Waldron have recently discussed on the osg-users mailing list. One issue that I'm running into is changing the Cursor property on my mouse form. a custom mouse cursor in my form. GraphicsWindowWin32 manages the current cursor as one of the ones defined in the GraphicsWindow::MouseCursor enumeration so I can't use a custom cursor (as far as I can tell). If I set the cursor manually using ::SetCursor, it gets override by GraphicsWindowWin32 because it calls ::SetCursor in response to every WM_SETCURSOR call and passes in _currentCursor. I've tried setting useCursor to false in the traits of the graphics context and calling ::SetCursor on my own, but this causes the cursor to flicker very badly because GraphicsWindowWin32 calls ::SetCursor(NULL) if use cursor is set to false. It seems like there needs to be an option to set a custom cursor by passing in an HCURSOR or a way to say don't manage the mouse cursor in the Traits class. Any suggestions? Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Custom Mouse Cursor
I don't want to dive into a huge discussion over this issue, I just think that even that one can get the result wanted in many ways, it is more comprehend to have similar conceptual functionality under similar if not the same APIs, and not scatter around many APIs/Toolkits. But I agree that the differences you mentioned about the implementation and performance of 3D/2D cursors are heavy weighted and therefore not merge to the same API (at least for the time being). Anyway, I'll peek at Present3D to get ideas. :-) Thanks, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 15, 2008 9:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Using Custom Mouse Cursor Hi Guy, On Tue, Apr 15, 2008 at 5:04 PM, Guy [EMAIL PROTECTED] wrote: I have no suggestion to solve the problem, but if the functionality to set the default cursor will be added, it should support a 3D cursor too. That means, hiding the operating system cursor and moving 3D object on the screen space according to the mouse I've implemented a disabling of the desktop cursor replacing it with 3D cursor (a textured quad) in Present3D, its not the neatest code in the world but it functions. 3D Cursors require quite a different type of coding than desktop cursors - they require objects to be placed in the scene graph and updated with the appropriate depth, and they also are subject to the frame rate of the client app, so if you app is only rendering at 30Hz or less the delay in the cursor is rather noticable, its not as responsive as a desktop cursor that I believe is typically implemented in hardware. Given these differences I'd suggest that a 3D cursor should have a different API to support it. It might be a suitable candidate for osgWidget, although perhaps elsewhere would be fine too. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dilemma with the usage of object Shaders in differend views ...
Ok, lets have some theoretical example, shall we... Suppose the scene is composed of: - 3 views. - 2 parameters which are view dependent, named Param1 and Param2. - 3 objects with different shader for each. Now, we must have some assumption: - You have access to the shaders code, and you are willing to manipulate it, but not in runtime or by the scene structure. - All the different shaders are referring to the view depended parameters Param1 and Param2, and that's what makes them View dependent. Now lets build the scene-graph: Root|View1| | | |View2| | | | | |View3-| | | Scene Root|--Object1 with shader1 |--Object2 with shader2 |--Object3 with shader3 Now in order to achieve what you want, you only need to add the uniforms for Param1 and Param2 for all the views and set them with different values. All the other uniform values for the shaders should be set in the StateSet of the objects. When OSG renders the scene, the uniform values are inherited and therefore the View dependent parameters will be different for each view, while the shader code for each object, and the uniforms for the shader other then the view dependent parameters will be the same in each view. Did I understand your problem correctly? Does the solution make sense to you? Good luck, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 10:01 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hmm... Don't you have access to the shaders code? Yes i've access to the shader code. Hmm... Don't you have access to the shaders code? Yes i've access to the shader code. If you do have, then change it and add the uniforms for the View setting parameters to all of them. If not how do you know that they need view depended parameters? :) I'm not sure what you mean, perhaps i must clearify what i will done. I'm writing a engine, where i could specifiy shaders via a special XML config. This conifg is loaded and bound dynamically to the object. So far no problem. Now it should be possible to use the composite Viewer, where i define differend point's of views to the same scene i.e. to create split screens. Now i've to use different camera view parameters on the same shader where a single uniform is defined. It's not quite usefull to create a new shader only for this split screen... The setting of the view dependend values must be done by the engine dynamically without manipulations for the shader, the shader shouldn't have any dependency to the engine ... Normally the engine should use a single view. However it should be possible i.e. for effect demos to create different views ... Best regards, Christian - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: 09.04.2008 10:29:23 Subject: Re: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hmm... Don't you have access to the shaders code? If you do have, then change it and add the uniforms for the View setting parameters to all of them. If not how do you know that they need view depended parameters? :) Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 9:18 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hello Guy, If you set different shader for each object, I would like some clarification about your original question. Yes this is that what i would have, sorry for my confused description. Do you want different shader per object but with some common features that are different for each view?? Normally the features should not different for each view, but they could be differend between the objects. However you may have the option to deactivate or reset post processing effects, but this is not the problem, while these shaders are only exists in the view context and not shared between the views. Only the object shaders are the problem, they are view independend bound to the scene graph object StateSets, but they use view dependend values, while the scene graph is shared between the views ... By this reason the object based effects are exactly the same in differend views, while the representation is influenced by the view values ... If so, keep the shader as they were (differently setted) on the objects in the single view. Ok, i'm agree. Add to all the shaders uniforms for the View properties, and set the uniforms values differently at each View node. Ok, but now i am back
Re: [osg-users] Sharing uniforms among statesets?; was: Shader question concerning GL_LIGHTING
Hello, I think you might have bumped into a problem that shouldn't have been there, but still the simple solution is to set a uniform per object you want to light or not. The same as if without shader you have per object you draw to glEnable/glDisable the light. Back to the problem, do you mean that if you have one pointer to uniform with light on and one pointer to uniform with light off, and you have several objects using the same pointer for the ON state, and other several objects using the same pointer for the OFF state, then if the objects won't be rendered as a groups of lit and unlit, the result won't be true? If so it does seems like a bug. Can you post the code so we can check it? I can't see how this is possible, the apply method of Uniform has no optimization of checking if it was called at the current frame... I thought of other possibility just now? Do you have ONE uniform you share among both lit and unlit object?? If you do so, then don't. Make two uniforms, one for the lit and one for the unlit objects and share each of them among the relevant group of objects. Hope it helps, tell us how you progress, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yefei He Sent: Wednesday, April 09, 2008 5:46 PM To: OSG Users Subject: [osg-users] Sharing uniforms among statesets?; was: Shader question concerning GL_LIGHTING Hi, Mike, Robert, folks, Thanks for the help from this list, I've decided to use a uniform to solve the problem of switching lighting mode between fragments. My idea is to add the program and a LightingOn uniform to the stateset of the root node of the scenegraph, and set its value to 0 wherever the stateset of a node has GL_LIGHTING off, and to 1 wherever GL_LIGHTING is on. However, on a closer thought, here comes a problem. For the GL_LIGHTING mode in the stateset of a node, I can set it to whatever value and it won't affect that in the stateset of a different node, and individual glEnable(GL_LIGHTING) and glDisable(GL_LIGHTING) will be called during the draw stage. But if I'm sharing a uniform, is it that during the draw stage only one call to glUniform() for that uniform will take place, and its value will be that of the last call to Uniform::Set() before the draw stage? How do I make multiple glUniform() calls to the same uniform take place during the draw stage alongside glEnable/glDisable(GL_LIGHTING)? I don't think it's correct to create a separate osg::Uniform for each node, which in the minimum will induce multiple glGetUniformLocation() calls? Can I use a callback? A draw callback? A second approach is to create two sets of shaders and two programs, one for non lit fragments, and another for lit fragments. Then I just set the appropriate program to the stateset of each node in the scenegraph. Will this work? I imagine there may be thousands of glUseProgram() calls during each draw. I don't know how big an impact it will be on the performance. Thanks! Yefei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] runCameraSetUp not called after attaching new images to the camera
Hello michael, The setUpCamera does not run since the camera has the previous RenderStage as a cached object for efficiency issues. If you change the attachment, you should set the camera cache to NULL, then when the rendering occurs, a new RenderStage will be created for the camera and the runCameraSetup will be called again. But... if you change the attachment every frame, I guess it will be very slow. If that's the case I'd would recommend you change locally your code for the camera and RenderStage to directly change the RenderStage attachments without creating it each frame. Good luck, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guerrero, Michael (CIV) Sent: Thursday, April 10, 2008 1:24 AM To: OpenSceneGraph Users Subject: [osg-users] runCameraSetUp not called after attaching new images to the camera Hi guys, I'm not sure if this is a bug or I'm not understanding something. The first time I attach images to a camera, the runCameraSetUp function will be called in RenderStage which sets up the fbo to harvest the data. I do the following: texCam-attach(osg::Camera::COLOR_BUFFER, mReferenceColorImage); texCam-attach(osg::Camera::DEPTH_BUFFER, mReferenceDepthImage); This works just fine. The problem is when I want to change the images that are attached. For instance I later have the following: texCam-attach(osg::Camera::COLOR_BUFFER, mSceneColorImage); texCam-attach(osg::Camera::DEPTH_BUFFER, mSceneDepthImage); After setting the attachments to new images, runCameraSetUp will never get called to set up the frame buffer object. Is there something I can do to make this happen? Thanks, Michael Guerrero ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia card textures memory
I currently don't have the hardware to deal with it, so it was more a theoretical question. Moreover, the second card doesn't have to be a graphics card, so PBO has no meaning for it. Anyway, since I know nothing about PBOs, I'll try to dig into it a little, and if they are easier to map to PCIE address, I'll share this knowledge. Same if one day I'll use multiple graphics card. Thanks again, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, April 07, 2008 6:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] nVidia card textures memory Hi Guy, I don't know of any extensions for mapping/copying memory from one card to another directly. NVidia will have such code in their drivers, but its something that is hidden from the OpenGL. However, there are still OpenGL features that can help out a little. First up Frame Buffer Objects are perfect for capturing images, the OSG has full support for FBO's and its pretty straight forward to use just by setting a single line in osg::Camera. See osgdistortion or osgprerender examples. Next up to copy the data from one card to another you'll need to do a read pixels, which ordinarily is pretty slow, so here it'd be best to use Pixel Buffer Objects , agaiin its something the OSG supports, but so far I've only ever used it for sending imagery to a graphics card. You will also need a second PBO to get the data to the second card. I'm afraid there isn't an OSG example showing how to do this part so you are one your own. If you get it all working then it'd be a nice OSG example to have is you fancy contributing the final solution back. Robert. On Mon, Apr 7, 2008 at 3:20 PM, Guy [EMAIL PROTECTED] wrote: Hello, First I know my question has nothing to do with OSG, but a lot of OSG users might come across this subject and any guidance would be most appreciated. The questions I ask regard the nVidia textures memory and how to access it. 1. I'd like to pass data from nVidia texture memory to other card, on the PCI-Express bus. Is it possible and how to get Texture memory address and to map it to PCIE address? Or if there is a possibility to make the card render to memory address which is already mapped to PCIE address? 2. I'd like to run some image processing code on the whole screen (no matter what applications are running on and what they display). For that matter, I need to get the screen image, run my algorithm and display the result full screen. The problems with that are: 2.1 After one frame that *I* draw, the next time I'll get the screen image it might include changes *I* have done to the data. 2.2 Getting the screen data is slow. So the more complicate way to do it is to make all the applications running, draw to an off-screen memory buffer, process that buffer and display it. Or plug-in image processing code, somewhere on the card, after the driver drawing call functions and before the data it presented on screen. My questions are: 1. Is it possible to access the display buffer data on the nVidia card just before it is displayed on screen? (plug-in my code) 2. Would setting the apps drawing to n'th nVidia virtual desktop to that trick? And then again, does the nVidia card has address of memory buffer for each n'th virtual desktop? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dilemma with the usage of object Shaders in differend views ...
Hello, I think attaching a shader to each view instead of to object X would be fine. If you want to use the callback I think you should create a pre-draw callback to the object, which I'm not sure possible. The update callbacks won't help you since it run on all the scene before the rendering and then only the last setting of the shader will be set, and it also might affect performance. So I still think attaching shaders to the views would do what you want. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 10:55 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hi folks, actually i am working on object shading with OSG (i.e. Dot3). All works fine with single views. Now i am using the osgViewer::Composite viewer and getting some dielemma with the usage of object based shaders in differend views based on the same scene graph. I.e.: I've a single scene node with an object X where i bind the shaders (at the object StateSet) for execution. In a single view no problem. If i use this scene in multiple views (i.e. A, B) i've the dilemma, that i've to use diffrend shader params on the same shader instance. In each rendering pass the params of the camera are differend from the point of view of the views, if the views are rendered. But the shader has no knowledge about this, it uses only a single uniform to hook bind param ... I've thought about the following sollutions: 1. Using for each view a single shader instance at the same object StateSet. Is this usefull? If the scene is complex i could get a huge count of shaders which have to be executed. Additionally i'm not sure, if the binding of the unused shaders produces render artifacts or perfomance issues... 2. Using a callback mechanism which switches this values at the shader before rendering How i could achieve this aim in best way? Has anyone a better solution? Best regards, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HDR with osg
Hello.
1x1 texture should be rendered and call the shaders. I did it once in
multipass program that ran some algorithm on the GPU.
Be sure that you use orthographic projection and the viewport to be 1x1:
camera-setProjectionMatrixAsOrtho2D(0,1,0,1);
camera-setViewport(0, 0, 1, 1);
Guy.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of J.P.
Delport
Sent: Tuesday, April 08, 2008 3:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] HDR with osg
Hi,
Roman Grigoriev wrote:
Hi guys!
I try to implement HDR. And I got some problem when I compute average
luminance
I have to render it to 1X1 texture and here is the main problem
When I setup viewport with setVewport(0,0,1,1) - I've got clearcolor
i.e. (1,0,0,0)
Is this for a 1x1 target, or for your 2x2 target? I guess your shader is
not executed at all. What are you doing in the vertex shader? I have not
tried 1x1 textures myself.
When I setup viewport with setVewport(0,0,2,2) - I've got average
luminance - but here I've got 2X2 texture but I need 1X1 texture
At some texture size (search gpgpu.org or experiment) it becomes faster
to copy the texture to CPU and do final calculation there.
What should I do?
Debug more :) See if your shader is executed for 1x1 case at all. Turn
on more OSG (see OSG_NOTIFY_LEVEL) messages to see if there are not
other problems, e.g. non-power of two texture resampling. Try texture
rectangles...
jp
Here is my source (luminance2 texture has size of 4X4)
osg::ref_ptrosg::Texture2D finalluminance = new osg::Texture2D;
finalluminance-setTextureSize( 2, 2);
finalluminance-setInternalFormat(GL_RGBA16F_ARB);
finalluminance-setSourceFormat(GL_RGBA);
finalluminance-setSourceType(GL_FLOAT);
finalluminance-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LIN
EAR);
finalluminance-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LIN
EAR);
finalluminance-setWrap(osg::Texture::WRAP_S,
osg::Texture::CLAMP);
finalluminance-setWrap(osg::Texture::WRAP_T,
osg::Texture::CLAMP);
osg::ref_ptrosg::Camera luminance3Camera = new osg::Camera;
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrosg::Geometry geom
=osg::createTexturedQuadGeometry(osg::Vec3(0,0,-1),osg::Vec3(1.0,0.0,-1.
0),osg::Vec3(0.0,1.0,-1.0));
geom-getOrCreateStateSet()-setMode(GL_LIGHTING,osg::StateAttribute::OF
F);
geode-addDrawable(geom.get());
luminance3Camera-setName(luminance3);
luminance3Camera-setClearColor(osg::Vec4f(1.0f,0.0f,0.0f,1.0f));
luminance3Camera-setProjectionMatrix(osg::Matrix::ortho2D(0,1,0,1));
luminance3Camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
luminance3Camera-setViewMatrix(osg::Matrix::identity());
luminance3Camera-setViewport(0,0,2,2);
luminance3Camera-setRenderOrder(osg::Camera::POST_RENDER,13);
luminance3Camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFE
R_OBJECT);
luminance3Camera-attach(osg::Camera::COLOR_BUFFER,finalluminance.get())
;
luminance3Camera-addChild(geode.get());
osg::ref_ptrosg::StateSet luminance3stateset
=luminance3Camera-getOrCreateStateSet();
luminance3stateset-setTextureAttributeAndModes(0,luminance2.get(),osg::
StateAttribute::ON);
luminance3stateset-setAttribute(clamp,
osg::StateAttribute::ON);
root-addChild(luminance3Camera.get());
osg::Program* luminance3prg = new
osg::Program;
luminance3stateset-setAttribute(luminance3prg);
luminance3prg-addShader(osg::Shader::readShaderFile(osg::Shader::VERTEX
,
osgDB::findDataFile(Shaders/downLumExp_vp.glsl)));
luminance3prg-addShader(osg::Shader::readShaderFile(osg::Shader::FRAGME
NT,
osgDB::findDataFile(Shaders/downLumExp.glsl)));
osg::Uniform* DownSampler = new
osg::Uniform(DownSampler,0);
luminance3stateset-addUniform(DownSampler);
here is downLumExp.glsl
/*FRAGMENT_SHADER*/
uniform sampler2D DownSampler;
const vec2 samples[16]={
-0.375, -0.375, -0.125, -0.375, 0.125, -0.375, 0.375, -0.375, -0.375,
-0.125, -0.125, -0.125, 0.125, -0.125, 0.375, -0.125, -0.375, 0.125,
-0.125, 0.125, 0.125, 0.125, 0.375, 0.125, -0.375, 0.375, -0.125,
0.375,
0.125, 0.375, 0.375, 0.375
};
void main(void)
{
float lum = 0.0;
float maximum = 0.0;
vec4 color;
vec2 sample;
for(int i = 0; i 16; i
Re: [osg-users] Two separated subgraphs, 2nd trial
Maybe you could send your whole file. The code you inlined here seem right. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 08, 2008 2:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Two separated subgraphs, 2nd trial Hi Oliver, On Tue, Apr 8, 2008 at 1:13 PM, Oliver Kutter [EMAIL PROTECTED] wrote: Hi, isn't there anybody, who can answer my question (see below)? I've just re-read you post and can't think of anything to say - as I really don't know what specifically is amiss. I'd guess others don't know either. Try providing a screen shot to tell us what looks wrong then we might be able to help you. Robert. regards Oliver Oliver Kutter schrieb: Hi guys, I have a question concerning the openscenegraph example osghud. I have a similar scene like this example except that I don't want to display hud text. Instead I want to render some small coordinate system axes like the ones in 3d studio max in the left bottom corner. I still use openscenegraph 1.2, but I think this is not important for my problem. Now my graph looks like this: I have a sceneview with a camera, a root node and the main scene as a child of the root node. Now I constructed my stuff like the osghud example: I added a new camera to the root node as a new subgraph and then I added my coordinates system axes model as a child to that camera so that the axes and the main scene are not connected. I set up the viewport of that camera (2nd viewport) to the left bottom corner with size (100,100) similar to 3d studio max. Finally, my axes are displayed in the 2nd viewport, but not in the main scene. That is correct so far. Now my problem is that not only the axes but also the main scene is displayed in the 2nd viewport. This shouldn't be like that because the main scene is not a child of the 2nd camera. What am I doing wrong? These are my parameters which I set to the camera: osg::ref_ptrosg::Node _axes = osgDB::readNodeFile(../data/osg/coordinate_axes.osg); _camera-setProjectionMatrix(osg::Matrix::perspective(50.0, 1, 0.1, 1.0)); _camera-setViewport(0,0,100,100); _camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); _camera-setRenderOrder(osg::CameraNode::POST_RENDER); _camera-setClearMask(GL_DEPTH_BUFFER_BIT); _camera-addChild(_axes.get()); _root-addChild(_camera.get()); best regards, Oliver ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Glenum pixelFormat
Here is what I've found in gl.h:
/* PixelFormat */
#define GL_COLOR_INDEX0x1900
#define GL_STENCIL_INDEX 0x1901
#define GL_DEPTH_COMPONENT0x1902
#define GL_RED0x1903
#define GL_GREEN 0x1904
#define GL_BLUE 0x1905
#define GL_ALPHA 0x1906
#define GL_RGB0x1907
#define GL_RGBA 0x1908
#define GL_LUMINANCE 0x1909
#define GL_LUMINANCE_ALPHA0x190A
/* texture */
#define GL_ALPHA4 0x803B
#define GL_ALPHA8 0x803C
#define GL_ALPHA120x803D
#define GL_ALPHA160x803E
#define GL_LUMINANCE4 0x803F
#define GL_LUMINANCE8 0x8040
#define GL_LUMINANCE120x8041
#define GL_LUMINANCE160x8042
#define GL_LUMINANCE4_ALPHA4 0x8043
#define GL_LUMINANCE6_ALPHA2 0x8044
#define GL_LUMINANCE8_ALPHA8 0x8045
#define GL_LUMINANCE12_ALPHA4 0x8046
#define GL_LUMINANCE12_ALPHA120x8047
#define GL_LUMINANCE16_ALPHA160x8048
#define GL_INTENSITY 0x8049
#define GL_INTENSITY4 0x804A
#define GL_INTENSITY8 0x804B
#define GL_INTENSITY120x804C
#define GL_INTENSITY160x804D
#define GL_R3_G3_B2 0x2A10
#define GL_RGB4 0x804F
#define GL_RGB5 0x8050
#define GL_RGB8 0x8051
#define GL_RGB10 0x8052
#define GL_RGB12 0x8053
#define GL_RGB16 0x8054
#define GL_RGBA2 0x8055
#define GL_RGBA4 0x8056
#define GL_RGB5_A10x8057
#define GL_RGBA8 0x8058
#define GL_RGB10_A2 0x8059
#define GL_RGBA12 0x805A
#define GL_RGBA16 0x805B
#define GL_TEXTURE_RED_SIZE 0x805C
#define GL_TEXTURE_GREEN_SIZE 0x805D
#define GL_TEXTURE_BLUE_SIZE 0x805E
#define GL_TEXTURE_ALPHA_SIZE 0x805F
#define GL_TEXTURE_LUMINANCE_SIZE 0x8060
#define GL_TEXTURE_INTENSITY_SIZE 0x8061
#define GL_PROXY_TEXTURE_1D 0x8063
#define GL_PROXY_TEXTURE_2D 0x8064
For internal texture format there are also definitions in osg/Texture
In osg/Image:
enum AllocationMode {
NO_DELETE,
USE_NEW_DELETE,
USE_MALLOC_FREE
};
Good luck,
Guy.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Bourdier
Sent: Tuesday, April 08, 2008 2:55 PM
To: osg
Subject: [osg-users] Glenum pixelFormat
Hi All,
I'm trying to make a osg::Image, but in allocateImage(...) and
setImage(...) I need :
Pixel format,
Internal texture format,
AllocationMode...
But I didn't find any possible values ?!
Where can I find it ?
thanks
Regards,
Vincent.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cessnafire particle setup
These files contain the fire and the smoke trail. Good luck, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerrick Bivins Sent: Tuesday, April 08, 2008 5:00 PM To: OpenSceneGraph Users Subject: [osg-users] cessnafire particle setup Hi , Does anyone happen to have the code (or settings) to recreate the fire/smoke shown in cessnafire? biv ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g fire.osg Description: fire.osg tail of fire.osg Description: tail of fire.osg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dilemma with the usage of object Shaders in differend views ...
Well, the shader doesn't know of the stateset of the object (textures attached) if you don't set it explicitly. Otherwise, the shader can be inherited and at ObjectX you can add a uniform for the sampler. You are right that all the objects will be rendered with the same shader. If you set different shader for each object, I would like some clarification about your original question. Do you want different shader per object but with some common features that are different for each view?? If so, keep the shader as they were (differently setted) on the objects in the single view. Add to all the shaders uniforms for the View properties, and set the uniforms values differently at each View node. Hope it helps, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Heine Sent: Tuesday, April 08, 2008 5:39 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hello Guy, I think attaching a shader to each view instead of to object X would be fine. I'm not sure if this may be the right thing. Correct me if I'm wrong but this causes in some other issues: 1. I lost the reference to the specifiv object states like Textures, Geometries etc. How does the shader should access this values by differend objects? 2. If i bind it to the view, each object is rendered with this shader. So i shouldn't have the ability to separate shaders and effects between objects ... If you want to use the callback I think you should create a pre-draw callback to the object, which I'm not sure possible. The update callbacks won't help you since it run on all the scene before the rendering and then only the last setting of the shader will be set, and it also might affect performance. So I still think attaching shaders to the views would do what you want. Ok, this is an argument i've to agree. But if If i overload the render method of the composite viewer i could implement callbacks (better update sequences) for each object before calling the parent rendering method, so this should be possible. But i am not sure about possible perfomance lacks ... Best regards, Chrsitian Guy wrote: Hello, I think attaching a shader to each view instead of to object X would be fine. If you want to use the callback I think you should create a pre-draw callback to the object, which I'm not sure possible. The update callbacks won't help you since it run on all the scene before the rendering and then only the last setting of the shader will be set, and it also might affect performance. So I still think attaching shaders to the views would do what you want. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 10:55 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Dilemma with the usage of object Shaders in differend views ... Hi folks, actually i am working on object shading with OSG (i.e. Dot3). All works fine with single views. Now i am using the osgViewer::Composite viewer and getting some dielemma with the usage of object based shaders in differend views based on the same scene graph. I.e.: I've a single scene node with an object X where i bind the shaders (at the object StateSet) for execution. In a single view no problem. If i use this scene in multiple views (i.e. A, B) i've the dilemma, that i've to use diffrend shader params on the same shader instance. In each rendering pass the params of the camera are differend from the point of view of the views, if the views are rendered. But the shader has no knowledge about this, it uses only a single uniform to hook bind param ... I've thought about the following sollutions: 1. Using for each view a single shader instance at the same object StateSet. Is this usefull? If the scene is complex i could get a huge count of shaders which have to be executed. Additionally i'm not sure, if the binding of the unused shaders produces render artifacts or perfomance issues... 2. Using a callback mechanism which switches this values at the shader before rendering How i could achieve this aim in best way? Has anyone a better solution? Best regards, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http
Re: [osg-users] Two separated subgraphs, 2nd trial
Yes, I've noticed too late... Sorry. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Kutter Sent: Tuesday, April 08, 2008 5:48 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Two separated subgraphs, 2nd trial Hi Guy, everything is fine, I found the error. I already mentioned in a previous email. thanks, Oliver Guy schrieb: Maybe you could send your whole file. The code you inlined here seem right. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 08, 2008 2:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Two separated subgraphs, 2nd trial Hi Oliver, On Tue, Apr 8, 2008 at 1:13 PM, Oliver Kutter [EMAIL PROTECTED] wrote: Hi, isn't there anybody, who can answer my question (see below)? I've just re-read you post and can't think of anything to say - as I really don't know what specifically is amiss. I'd guess others don't know either. Try providing a screen shot to tell us what looks wrong then we might be able to help you. Robert. regards Oliver Oliver Kutter schrieb: Hi guys, I have a question concerning the openscenegraph example osghud. I have a similar scene like this example except that I don't want to display hud text. Instead I want to render some small coordinate system axes like the ones in 3d studio max in the left bottom corner. I still use openscenegraph 1.2, but I think this is not important for my problem. Now my graph looks like this: I have a sceneview with a camera, a root node and the main scene as a child of the root node. Now I constructed my stuff like the osghud example: I added a new camera to the root node as a new subgraph and then I added my coordinates system axes model as a child to that camera so that the axes and the main scene are not connected. I set up the viewport of that camera (2nd viewport) to the left bottom corner with size (100,100) similar to 3d studio max. Finally, my axes are displayed in the 2nd viewport, but not in the main scene. That is correct so far. Now my problem is that not only the axes but also the main scene is displayed in the 2nd viewport. This shouldn't be like that because the main scene is not a child of the 2nd camera. What am I doing wrong? These are my parameters which I set to the camera: osg::ref_ptrosg::Node _axes = osgDB::readNodeFile(../data/osg/coordinate_axes.osg); _camera-setProjectionMatrix(osg::Matrix::perspective(50.0, 1, 0.1, 1.0)); _camera-setViewport(0,0,100,100); _camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); _camera-setRenderOrder(osg::CameraNode::POST_RENDER); _camera-setClearMask(GL_DEPTH_BUFFER_BIT); _camera-addChild(_axes.get()); _root-addChild(_camera.get()); best regards, Oliver ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] nVidia card textures memory
Hello, First I know my question has nothing to do with OSG, but a lot of OSG users might come across this subject and any guidance would be most appreciated. The questions I ask regard the nVidia textures memory and how to access it. 1. I'd like to pass data from nVidia texture memory to other card, on the PCI-Express bus. Is it possible and how to get Texture memory address and to map it to PCIE address? Or if there is a possibility to make the card render to memory address which is already mapped to PCIE address? 2. I'd like to run some image processing code on the whole screen (no matter what applications are running on and what they display). For that matter, I need to get the screen image, run my algorithm and display the result full screen. The problems with that are: 2.1 After one frame that *I* draw, the next time I'll get the screen image it might include changes *I* have done to the data. 2.2 Getting the screen data is slow. So the more complicate way to do it is to make all the applications running, draw to an off-screen memory buffer, process that buffer and display it. Or plug-in image processing code, somewhere on the card, after the driver drawing call functions and before the data it presented on screen. My questions are: 1. Is it possible to access the display buffer data on the nVidia card just before it is displayed on screen? (plug-in my code) 2. Would setting the apps drawing to n'th nVidia virtual desktop to that trick? And then again, does the nVidia card has address of memory buffer for each n'th virtual desktop? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia card textures memory
I've checked compiz. They use extension GLX_EXT_texture_from_pixmap that is implemented specially for X11 systems if I understood correctly. I'm developing on windows and could find in my brief search any analog windows extension. But besides that it looks pretty cool with some ideas I thought were my inventions, already implemented :) Thanks for the reference and if anyone knows extensions of the sort for windows I'll really appreciate it. Thanks again, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Monday, April 07, 2008 3:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] nVidia card textures memory Hi, Guy wrote: Hello, First I know my question has nothing to do with OSG, but a lot of OSG users might come across this subject and any guidance would be most appreciated. The questions I ask regard the nVidia textures memory and how to access it. 1. I'd like to pass data from nVidia texture memory to other card, on the PCI-Express bus. Is it possible and how to get Texture memory address and to map it to PCIE address? Or if there is a possibility to make the card render to memory address which is already mapped to PCIE address? 2. I'd like to run some image processing code on the whole screen (no matter what applications are running on and what they display). For that matter, I need to get the screen image, run my algorithm and display the result full screen. The problems with that are: 2.1 After one frame that *I* draw, the next time I'll get the screen image it might include changes *I* have done to the data. 2.2 Getting the screen data is slow. So the more complicate way to do it is to make all the applications running, draw to an off-screen memory buffer, process that buffer and display it. Or plug-in image processing code, somewhere on the card, after the driver drawing call functions and before the data it presented on screen. My questions are: 1. Is it possible to access the display buffer data on the nVidia card just before it is displayed on screen? (plug-in my code) Sorry, I have no idea. 2. Would setting the apps drawing to n'th nVidia virtual desktop to that trick? And then again, does the nVidia card has address of memory buffer for each n'th virtual desktop? Not sure about how the data flows, but this sounds a lot like what compiz does on Linux. Basically all apps draw to OpenGL textures and the results can be modified before it is displayed. Maybe if you look at how they do it you might get some ideas. Thanks, Guy. cheers jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia card textures memory
Thanks, I'll look into it. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Monday, April 07, 2008 3:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] nVidia card textures memory Hi, Guy wrote: Hello, First I know my question has nothing to do with OSG, but a lot of OSG users might come across this subject and any guidance would be most appreciated. The questions I ask regard the nVidia textures memory and how to access it. 1. I'd like to pass data from nVidia texture memory to other card, on the PCI-Express bus. Is it possible and how to get Texture memory address and to map it to PCIE address? Or if there is a possibility to make the card render to memory address which is already mapped to PCIE address? 2. I'd like to run some image processing code on the whole screen (no matter what applications are running on and what they display). For that matter, I need to get the screen image, run my algorithm and display the result full screen. The problems with that are: 2.1 After one frame that *I* draw, the next time I'll get the screen image it might include changes *I* have done to the data. 2.2 Getting the screen data is slow. So the more complicate way to do it is to make all the applications running, draw to an off-screen memory buffer, process that buffer and display it. Or plug-in image processing code, somewhere on the card, after the driver drawing call functions and before the data it presented on screen. My questions are: 1. Is it possible to access the display buffer data on the nVidia card just before it is displayed on screen? (plug-in my code) Sorry, I have no idea. 2. Would setting the apps drawing to n'th nVidia virtual desktop to that trick? And then again, does the nVidia card has address of memory buffer for each n'th virtual desktop? Not sure about how the data flows, but this sounds a lot like what compiz does on Linux. Basically all apps draw to OpenGL textures and the results can be modified before it is displayed. Maybe if you look at how they do it you might get some ideas. Thanks, Guy. cheers jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
Robert checked-in the support and example JP wrote for MRT several days ago, so I guess the last svn update should help you with that. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of zhangguilian Sent: Sunday, April 06, 2008 5:16 PM To: osg-users Subject: [osg-users] Multiple render targets Hi, As far as I know MRT is not supported in some ealier version of OSG, there is no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed for MRT. I don't know current vesion of OSG supprot it or not, if not ,is there any solutions available in the osg community today? I would greatly appreciate if you can give some examples. Thanks in advance, zhangguilian 2008-04-06 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Replacing a stateset.
Maybe the node that you changed it's StateSet but it did not really change inherit states from it's parents. There is some kind of priority mechanism in the stateset. StateAttribute:: OVERRIDE, PROTECTED, INHERIT. Mybe you can set your new stateattributes with the mode StateAttribute:: PROTECTED | StateAttribute::ON? Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alberto Luaces Sent: Thursday, April 03, 2008 9:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Replacing a stateset. El Miércoles 02 Abril 2008ES 20:07:53 Dorosky, Christopher G escribió: Do I need to do something to clean up the node if it already had a shared stateset? Statesets as the rest of Referenced objects are reference counted, so if the ref_ptr that holds its address is pointed to another Stateset, the count for the first is decremented. If that count reaches 0, the object is automatically destroyed. That is, you haven't to do anything ;) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, I think we have discussed this issue before. I also not familiar with the general framework use of SetState, I myself implemented solution similar to that of JS with the exception that I activated the glDrawBuffer extension in the apply method of the FBO. I also made another difference, I didn't use vector for the draw buffers, but counted the attachments of different color buffers, and only if those were greater than one, applied the drawBuffers extension. But I thought to myself, is it true to use it ONLY when FBO's are on? I'm not familiar enough with attachments when not using FBO (like PBuffer or maybe in the future there will be separate frame buffers for separate screens) and this returns the location of applying the extension back to the RanderStage as JS did. (That's why I was quiet until now :) ) Now, suppose I do understand a little about SetStates, this is not applicable here since if there is more than one color buffer attachment you must use the extension, and if not, there is no point in using the extension, so why let the user set the state? What I think should be done is instead of adding the setDrawBuffers(BuffersVec) method, in the RenderStage setUpCamera function one should count the attachments to different color buffers and decide whether to use the extension or not, and in the InnerDraw apply the extension according to the flag found in the setUpCamera. Besides that I think JS has done very nice work. Bravo. (or cheers or as we say in Israel Kifak-Hey) :) Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Tuesday, April 01, 2008 2:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art, Art Tevs wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. Yes, I've compiled osgPPU and ran the examples; cannot say that I fully understand the code yet :) However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? I think having the MRT selection going through FBO-class could be a good option. However, I do not know how to add the StateAttribute. We might need an enable/disable and setDrawbuffers, or can a StateAttribute take a vector? I do not know how to pass the vector of render targets using an attribute? - At the moment I have: Camera-setDrawBuffers(vec) - this sets the intention to use MRT and also passes the list of targets. RenderStage-runCameraSetup - this queries the camera for the buffers, and if there are any, creates a vector of GLenums. RenderStage-drawInner - The existence of the target vector is used to determine if MRT is enabled. glDrawBuffers is called using the vector. - I think what you propose is: Camera-setDrawBuffers(vec) RenderStage-runCameraSetup - since this creates the FBO anyway, it might as well pass the camera settings regarding MRT to the FBO. Maybe using _fbo-setDrawBuffers. RenderStage-drawInner - instead of checking the member _drawBuffers, query the FBO to determine if MRT should be enabled and also get the list of targets from the FBO. - This could work, and I can probably integrate it into the patch, but I'm not sure how you get your FBOs into renderstage at present. Also, how do you control the reading back of textures/images? At the moment the readback attachment map is also setup in camera. Would this also need to be moved? Cheers, Art rgds jp -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hello, In continue to what I said before, I don't believe it's possible to change the subgraphs MRT definitions, since all the subgraph under the camera renders to the camera attachments. So if the camera is using MRT, then all the subgraph is rendered MRT. The differences in the subgraphs could be the shaders using or not using the MRTs. That brings the issue that if shaders use MRT and we didn't set the attachments correctly, a problem will occur. So what I think should happen is that whether using StateSet attribute to declare the need for MRT by sub-graphs or by testing the Shaders, the camera should activate some visitor on it's sub-graph, find the draw buffers required, and then setup itself for the maximum need. But then the setting would be the same for the whole sub-graph. Does it makes sense? Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 01, 2008 3:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art J.P, I'm curious about the going for a custom StateAttribute for DrawBuffers. In terms of encapsulation osg::Camera isn't a bad place for it, as there is already lots of RTT support there already. If there are cases when you want to enable/disable different combinations of DrawBuffers within on RTT subgraph then the StateAttribute is certainly the way to go. I haven't yet player with MRT yet though so can't really give too much insight based on experience so am all ears. Robert. On Tue, Apr 1, 2008 at 1:08 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? Cheers, Art --- J.P. Delport [EMAIL PROTECTED] schrieb: Hi Wojtek, Wojciech Lewandowski wrote: I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. thanks for the testing, I'm glad other fbo code is still fine. We are using MRT for two projects here and it works on Windows and Linux, so 'it works for me (TM)'. I'll submit it. thanks jp Cheers, Wojtek -- 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.or g Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting the Image from a Texture2D used as a render target
Well, the simplest way to retrieve the image from the RTT texture is to attach an image to the color buffer of the camera. Of course this slows down the rendering loop if you read every image rendered. So it is possible to attach the image only before the frames you actually want. When changing the image attachments you should also set the camera's rendering cache to NULL (the cache is pointer to RenderStage), so on the next frame it will initialize the RenderStage with the new settings. The osgprerender shows how to attach image to color buffer. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guerrero, Michael (CIV) Sent: Wednesday, April 02, 2008 2:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Getting the Image from a Texture2D used as a render target After looking into this further, it seemed that using glGetTexImage would be able to copy from a texture used as a render target (FBO). I have tried this only to be left with a black texture that never gets filled in. I know that function works by grabbing whatever texture is currently bound and returning its data. Using osg, the way to do this seemed to be the following: osg::GraphicsContext *context = cam-getGraphicsContext(); osg::State *currentState = context-getState(); currentState-setActiveTextureUnit(0); currentState-applyTextureAttribute(0, mColorTexture); osg::ref_ptrosg::Image imageCapture = new osg::Image; imageCapture-readImageFromCurrentTexture(0, false); Unfortunately imageCapture is entirely filled with zeros. Anyone have some ideas or experience with this sort of thing? Thanks, Michael Guerrero From: Guerrero, Michael (CIV) Sent: Tuesday, April 01, 2008 2:23 PM To: OpenSceneGraph Users Subject: [osg-users] Getting the Image from a Texture2D used as a render target Hi, I'm trying to retrieve texture data that I have rendered from video memory back to main memory. I was initially hoping I could set up a render target as usual and then just call GetImage on the Texture2D but that doesn't work. Is there any easy way to do this? Thanks, Michael Guerrero ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance drop higherRAMusageafterswitchingfrom OSG 1.2 to latest SVN
Yes, you are right. Forget what I said... you can regard it as white noise. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alberto Luaces Sent: Wednesday, April 02, 2008 9:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Performance drop higherRAMusageafterswitchingfrom OSG 1.2 to latest SVN El Miércoles 02 Abril 2008ES 09:36:37 Guy escribió: Some small thing I'd like to say regarding that. Not all dynamic objects must have callbacks. One could change the objects attributes manually between calls to frames, not using the callback mechanism, especially if the rate of calls to frame() is significantly different from the update() requirements for that object. At least that what I think... So, if someone else thinks the same, it wouldn't be true to turn all non-callbacks owners to STATIC. I suppose that if this is the case, you are reponsible for tagging the object as DYNAMIC since you have the information at first hand. ___ 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] osgvertexprogram example
Hi, What language is the shader in osgvertexprogram? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi,
Since the change I suggest is very small from what JP has implemented I
don't submit files here just the differences:
I removed getDrawBuffers and setDrawBuffers from the Camera.cpp / h
In RenderStage the changes are as follows:
RanderStage //.h
Added vector of GLEnum named _drawBuffers.
RenderStage.cpp
In function runCameraSetUp, before the attachments loop (line 245)
_drawBuffers.clear();
In the loop, add at the start of the loop the few lines:
if(itr-first = COLOR_BUFFER0 itr-first =
COLOR_BUFFER7)
_drawBuffers.push_back(itr-first -
COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);
And removed the line JP added (about line 404)
// set up draw buffers if using multiple render targets
osg::Camera::DrawBufferVector cam_buffers =
_camera-getDrawBuffers();
_drawBuffers.clear();
for (osg::Camera::DrawBufferVector::iterator buf =
cam_buffers.begin();
buf != cam_buffers.end();
++buf)
{
_drawBuffers.push_back(GL_COLOR_ATTACHMENT0_EXT+(*buf -
osg::Camera::COLOR_BUFFER0));
}
Then in function drawInner, in the second line JP wrote:
bool using_multiple_render_targets = !(_drawBuffers.empty());
I changed it to
bool using_multiple_render_targets = (_drawBuffers.size() 1);
That's all the changes. So if JP can check it (I have a mess of OSG1.2
and OSG2.3 code) then you can decide what to submit.
Now after the follow up discussion of the matter, it still won't be a
complete solution. I think in the setUpCamera code, the render stage
should run custom visitor on the camera and it's sub-graphs that checks
for nodes requests for MRT, for the camera it would be the color
attachments, and for nodes, whatever data that could be implemented in
the StateAttribute, that later would mapped to Color Attachment, and
only after collecting all the requests and having all the attachments
that will be used, the RenderStage will set up the _drawBuffers as
implemented above.
This is more complicated to implement and since I'm not very good with
visitors I can only suggest a pseudo code to write in the renderstage
setUpCamera before the _drawBuffers initialization (about line 245)
something like this should happen:
RTTVisitor rttVS;
Camera-accept(rttVS);
_drawBuffers = rttVS.getDrawBuffers();
And remove the code that push_back stuff to the _drawBuffers.
Now the RTTVisitor apply methods should be something like
Apply(Camera cam)
{
Foreach attachment in AttachmentBuffers
If( COLOR_BUFFER0 = attachment = COLOR_BUFFER7)
_drawBuffers.pushback(attachment - COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);
cam.Traverse();
}
This is what should implemented and I'm not sure how
Apply(Node node)
{
Foreach attachment in Node.GetStateAtrributeMRTStuff
If( COLOR_BUFFER0 = attachment = COLOR_BUFFER7(
_drawBuffers.pushback(attachment - COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);}
node.Traverse();
}
What do you think? Will that give a full solution? I think that this way
even if the MRT code is down there somewhere at some node, the camera
will be set correctly, the fixed pipeline will render to COLOR_BUFFER0
and the specific node with the shader can render what it wants to what
buffer it wants.
Is that what Art ment?
Thanks,
Guy.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgvertexprogram example
Hmm.. in the example there is code, I meant what language is it? It's not GLSL. Is it Cg? I'm not familiar with shaders beside GLSL and I want to read that refraction shader in order to implement a different shader, and I want to know what language to learn. Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, April 02, 2008 10:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgvertexprogram example Hi Guy, On Wed, Apr 2, 2008 at 10:16 AM, Guy [EMAIL PROTECTED] wrote: What language is the shader in osgvertexprogram? It'll based on ARB_vertex_program so you can get the specs from OpenGL docs/extension registry. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgvertexprogram example
Ok, thanks. I'll check the specs as you suggested. Hope I'll find there information about that assembly language. Thanks again, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, April 02, 2008 3:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgvertexprogram example On Wed, Apr 2, 2008 at 3:32 PM, Guy [EMAIL PROTECTED] wrote: Hmm.. in the example there is code, I meant what language is it? It's not GLSL. Is it Cg? I'm not familiar with shaders beside GLSL and I want to read that refraction shader in order to implement a different shader, and I want to know what language to learn. ARB_vertex_program predates GLSL and Cg, its more akin to assembly than a high level language like GLSL or Cg. These days just use GLSL as per osgshaders. The osgvertexprogram predates GLSL software and hardware so isn't a great example unless you need to target old hardware that doesn't support GLSL. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
JP, Thanks for the clarification, I just thought that only when the visitor is implemented the user responsibility for matching the shaders to attachments should be by setting the StateAttribute and not the Camera since many users don't want to know about camera's but still wants to write MRT shaders. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 4:54 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Guy wrote: Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. There are no more manual settings in Camera in the latest version. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Attaching COLOR_BUFFER0 or greater now enables MRT, so no other setting that can get out of sync is needed anymore. If user does not want MRT, attach COLOR_BUFFER only. Matching shaders to attachments is still the user's responsibility. jp Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6
In my company it also improved the program performance by more than 20%. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-S?bastien Guay Sent: Wednesday, April 02, 2008 5:24 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6 Hi Milan, Judie, It's a shame when the IDE constrains your ability to use the best available version of a piece of software. In addition to what Paul and Jeremy said, I find it a shame for other reasons. VC6 was just a horrible compiler, with a horrible standard library implementation. Upgrading will give you much more than just being able to compile and use OSG 2.x, including using multiple cores for compilation, better optimization, better debugging, a *much* more standards-compliant STL/Standard C++ Library implementation, etc. 2 years is a long time in computing. Just look at how far OSG has come in 2 years, and try to predict where it will be 2 years from now. The more you put off following new versions of your tools, the harder the upgrade will be (but then again, it doesn't pay to be reckless with upgrades either, I'm just advocating a balanced approach). My own 0.02$. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgvertexprogram example
Oh, that's for sure, what I wanted is to be able to read the code to learn from it. Later I'll probably implement it with GLSL, unless the assembly code has a lot better performance... Does anyone have such statistics by any chance? In the osgvertexprogram, if I understood correctly, the shader uses the cube map texture to create the refraction effect. I want to do similar thing to create reflection of arbitrary object. I guess I could find on the net a lot of GLSL shaders that do reflection and refraction, but I thought I might learn the assembly language as well to learn from the examples under my hands. Thanks anyway, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, April 02, 2008 5:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgvertexprogram example Hi Guy, What I really recommend is that you use GLSL, unless there is really strong reason to use ARB_vertex_program I would avoid it as GLSL shaders as far more flexible and expose latest features of graphics cards which ARB_verex_program can't. Robert. On Wed, Apr 2, 2008 at 4:51 PM, Guy [EMAIL PROTECTED] wrote: Ok, thanks. I'll check the specs as you suggested. Hope I'll find there information about that assembly language. Thanks again, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, April 02, 2008 3:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgvertexprogram example On Wed, Apr 2, 2008 at 3:32 PM, Guy [EMAIL PROTECTED] wrote: Hmm.. in the example there is code, I meant what language is it? It's not GLSL. Is it Cg? I'm not familiar with shaders beside GLSL and I want to read that refraction shader in order to implement a different shader, and I want to know what language to learn. ARB_vertex_program predates GLSL and Cg, its more akin to assembly than a high level language like GLSL or Cg. These days just use GLSL as per osgshaders. The osgvertexprogram predates GLSL software and hardware so isn't a great example unless you need to target old hardware that doesn't support GLSL. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reflection
Hello all, I'm trying to implement reflection from object faces. I looked at the osgprerendercubemap example, and when I change the reflector to anything but the sphere, the reflection doesn't seem realistic. Is there anyway besides ray tracing to implement that? How does cube map work? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Course in Paris
Thanks for the info. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, March 26, 2008 5:38 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] The Course in Paris Hello Guy -- The Intermediate course NodeKit topic explains what is a NodeKit and gives some examples of NodeKits. osgText and osgShadow are used as examples during the lab. The course doesn't cover details of, for example, osgFX, osgParticle, etc. By the end of this section, you'll have a high-level idea of what you need to do to create your own NodeKit, if desired. An experienced OSG programmer should definitely know how to use an LOD node. However, specifics of the DatabasePager and PagedLOD nodes will be discussed in the Terrain course. OSG 1.2 experience should be sufficient. Differences between OSG v1.2 and current OSG are discussed in all the courses. Register online here: http://www.skew-matrix.com/trainingparis.html If you have other questions, feel free to ask. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Sent: Wednesday, March 26, 2008 3:52 AM To: OpenSceneGraph Users Subject: [osg-users] The Course in Paris Hello, I've two questions about the course: 1. In the intermediate lectures, there is a topic of nodekits. Is it possible to find more information what nodekits are they? 2. For the third day it says you should be an experienced OSG developer. Does it also means one should be experienced with Database pager and LOD? Is OSG1.2 experience is good enough? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] The Course in Paris
Hello, I've two questions about the course: 1. In the intermediate lectures, there is a topic of nodekits. Is it possible to find more information what nodekits are they? 2. For the third day it says you should be an experienced OSG developer. Does it also means one should be experienced with Database pager and LOD? Is OSG1.2 experience is good enough? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] skydome
Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, March 26, 2008 12:45 PM To: OpenSceneGraph Users Subject: Re: [osg-users] skydome Hi Guy, On Wed, Mar 26, 2008 at 10:20 AM, Guy [EMAIL PROTECTED] wrote: Is there a sample of using skydome with OSG? osghangglide example has a very basic skydome, osgvertexprogram has an example of a cube to do the same thing. More heavy duty skydome have a look at the osgEmphermis NodeKit that's out there in the wild. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::getCameraContainingPosition() returns weird results when using slave cameras
Hello, I'm not sure about the problem you are talking about, but just give a suggestion that might help. Maybe the slave camera cache its size, the cache does not update with the Viewport change, and then the intersection takes the data from the cache? You could try to clear the cache and see if the problem continues. And of course maybe it has nothing to do with it, and then I apologize for wasting your time. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-S?bastien Guay Sent: Monday, March 24, 2008 10:03 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer::View::getCameraContainingPosition() returns weird results when using slave cameras Hi Glenn, In a nutshell, I am using a single slave camera (in order to embed my OSG surface in a .NET control). If I resize the viewport after creation, computeIntersections() no longer returns correct results -- the Y value is incorrectly scaled. It only works correctly if I resize the window back to its original aspect ratio. Yes, that sounds like a different problem. In my case, I was not getting correct results from computeIntersections() whenever CompositeViewer was using a single view with slave cameras - no resizing at all involved, just using setUpViewAcrossAllScreens(). You'll have to dig further. I suggest you try starting with a breakpoint in Viewer/CompositeViewer::eventTraversal() (depending on the viewer type you use) and compare the behavior before and after resizing the viewport. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z buffer resolution
Thank you very much, I will try it asap. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, March 12, 2008 8:32 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Z buffer resolution Hi, Guy wrote: Hello all. I have a problem with the distance between the near and far plane. The distance between objects in the scene might be ten thousands of km (at least 3 km) and the objects sizes might be in several meters. I've noticed that when the distance between the near and far plane is about 15km and the object size is 2m the object disappears. Also sometimes it seems a clipping plane several meters in front of the camera emerges. Does anyone have the same problem? Any ideas how to overcome it? You could try any of these (and maybe more that I don't know of): * Disable small object culling, something like: m_SceneView-setCullingMode(m_SceneView-getCullingMode() ~osg::CullStack::SMALL_FEATURE_CULLING); * Make the near and far planes calculate based on primitives and force the ratio: m_SceneView-setNearFarRatio(0); // default is 0.0005f; m_SceneView-setComputeNearFarMode(osgUtil::CullVisitor::COMPUTE_NEAR_FA R_USING_PRIMITIVES); * Look at 'osgdepthpartition' example, there is a node in OSG specially made for this type of situation with large depth range. cheers jp Thanks, Guy. -- 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Z buffer resolution
Hello all. I have a problem with the distance between the near and far plane. The distance between objects in the scene might be ten thousands of km (at least 3 km) and the objects sizes might be in several meters. I've noticed that when the distance between the near and far plane is about 15km and the object size is 2m the object disappears. Also sometimes it seems a clipping plane several meters in front of the camera emerges. Does anyone have the same problem? Any ideas how to overcome it? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HUD with perspective
Yes, that can be cool Star Wars-like text effect!! The force is strong with this one... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arnaud houegbelo Sent: Tuesday, February 19, 2008 3:59 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] HUD with perspective Many Thanks for the funny answer :) I knwo that I must use setViewMatrix(), but I already tried to use it with a perpective matrix with no good result. But perhaps my parameter are wrong. But if you said that I can use the osghud.cpp exemple and apply a view matrix on the camera is going to be fine, I'm going to tried it. It could be useful to have a osghud code exemple with perpective. Best regards, Arnaud Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MRT
Hi all, When using MRT, are all the targets passed to the rest of the pipeline (blending, accumulation, stencil etc)? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Different frame ratio for different cameras?
Check the osgdistortion example and don't add the screen camera (the second camera) to the scene. That's more or less what you are looking for. If not, can you describe what did you do and what didn't work? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas pe?a Sent: Monday, February 18, 2008 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Different frame ratio for different cameras? Thanks for your answer, and sorry for my monolithic post. I will try to make them more readable. Now that I see that in order to control the frame rates I need to use an independent viewer for each simulated camera; - How can a set it to just render to a image and not display in the screen at all? I have tried to attach an image to the viewer's camera and set its render implementation to FRAME_BUFFER_OBJECT but obviously I am missing something as it didn't work. Thanks a lot, Nicolas. 2008/2/18, Robert Osfield [EMAIL PROTECTED]: Hi Nicolas, For future posts could you break you posts into several paragraphs so the various questions and points are easier to spot and follow, this will make it easier to read and answer without getting misunderstandings. I think the question are asking is how to do a viewer with different views running at different frame rates. CompositeViewer doesn't support this, all the Views are synchronized to have the same FrameStamp. This is done for practicability as relaxing things so that all views could have different frame rates would really complicate the code internally as well as the public interface. There are also issues like the fact that all cameras on a graphics window have to be update all at the same time thanks to the way that double buffering works, this put constraints on the views that share a single window needing to update at the same time, keeping the CompositeViewer so it only has one frame stamp, and one frame loop fits this constraint automatically as well as keeping the internals and API clean. If you want two views with separate windows running at a different frame rate with their own frame loops then you'll need use two separate viewers. Robert. On Feb 18, 2008 10:00 AM, nicolas peña [EMAIL PROTECTED] wrote: Hello, I work in a Spanish research group that mainly works on mobile robotics and I am going to use OSG 2.2 to build an application (simulator of multi-robot collaborative perception) that has a main view that the user interact with, and a dynamic number of secondary views (one camera each) that render to a file, usually much lower frame rate that the main view, to simulate virtual cameras whose images are the used to feed the algorithms of collaborative perception. I am quite new to OSG, and after learning a bit I think that may at way to achieve this is using a composite viewer with a view as the main one and adding others with their respective camera set to render to a off screen pixel buffer, images attached to these cameras and post draw callbacks that send a copy of these images where they are needed. Many questions have arisen, to start with is the approach of using a composite viewer wrong?, how can I achieve different frame rates with the different views?. I had the idea of modifying the renderingTraversals() method of the viewer base class in order to accept as a parameter a std::vectorint that contained the indexes of the desired cameras to render in the internal vector that holds all the cameras, but with the threading model that its in use (really nice actually) this is just not that simple. Can any one help me with ideas on how to achieve my goal? Thanks a lot in advance!. Nicolas, ___ 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] Loading an image file
I agree about the performance, but it could theoretically change with driver implementation, and it's always good to know other options... especially when cats are involved... :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-S?bastien Guay Sent: Monday, February 18, 2008 6:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Loading an image file Hello Guy, This method also creates geometry, I think those guys are trying to avoid geometry creation. I think the class osg::DrawPixels can do the trick, but I never tried it. It's a tradeoff. You can create geometry (ooh, one whole quad!) and then set it to absolute reference frame or use some other way to make it always face the camera. Drawing the image each frame using glDrawPixels can be a few orders of magnitude slower than a quad with a texture, as long as the texture does not change too often. Just to say there are lots of ways to skin a cat, and you can't choose the best one for your situation unless you know about them. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Adding nodes to the scene while the viewer is running
Robert, If it is possible to add objects while running, what is the purpose of the realize function? I thought it initialize not only the camera. Is it possible to add ANY object while running or there are some limitations to this? Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Per Rosengren Sent: Saturday, February 16, 2008 11:32 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Adding nodes to the scene while the viewer is running Thank you! A small typo in my code resulted in that my geodes didn't get any children. No wonder they weren't visible... Robert Osfield wrote: Hi Per, Is it simply that the new objects aren't in the current camera's view? Try moving the camera around the scene. Try pressing space bar to force the camera manipulator back to its home position. Robert. 2008/2/15 Per Rosengren [EMAIL PROTECTED]: I try to add Geoms to the scene of my running osgViewer::Viewer. If I print all children of Viewer::getCamera(), the new nodes are there, but they are not visible in the viewer. They are added to a Switch in the scene, and they are set to be visible. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framerate vs stats?
I've different problem with XP/nVIDIA 8800 GT. In debug code, when the stats are on while exiting the app sometimes there is a crash. I happens in most of the osg examples. The release code works. It also happens with old OSG1.2 code, and it didn't happen on nVIDIA 7950. I first thought it's the driver setting, after playing with I thought I got rid of the crashes, but I didn't. Then I suspected osgText, I thought it might use driver capabilities for text, but it doesn't, then I suspected the font, when I used the default font it seems to crash much less frequently. Finally I gave up. Any knowledge about this issue will be helpful. Thanks, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Friday, February 15, 2008 3:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Framerate vs stats? Hi again, Just out curiosity can anyone with two monitors check if this happens with his setup ? I made this test on XP/GeForce 7800 GTX and Vista/GeForce 8800. If I have two monitors active draw time degrades if only one monitor draw time is stable. Thanks in advance, Wojtek - Original Message - From: Wojciech Lewandowski mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Friday, February 15, 2008 2:42 PM Subject: Re: [osg-users] Framerate vs stats? Thanks Serge, I have to withdraw my claim. Your mail gave me something to think and I checked whether problem exists in single monitor mode. I turned off my second monitor in Display properties... and Tada! - problem vanished. Framerate is stable. This is not the first time I observe unusual OSG/OpenGL behaviour in multimonitor mode. I guess its the drivers again. Sometimes changing NVidia multimonitor/mutihreading settings help but most often it does not...;-( Thanks for helping to isolate this issue, Wojtek - Original Message - From: Serge Lages mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Friday, February 15, 2008 1:10 PM Subject: Re: [osg-users] Framerate vs stats? On Fri, Feb 15, 2008 at 12:57 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert, We noticed another issue. When statistics bars are on - framerate slowly degrades. This happens with osgviewer dumptruck.osg for example. When stats are on draw time slowly grows and framerate starts to decrease. Tested with latest svn (2.3.4), windows xp vista, OSG built with VS 2008. Regards, Wojtek Hi Wojtek, I've just tested it (latest SVN, WinXP but VS2005, NVidia 8600GTS), and there is no decrease here, my framerate stay at the same value (tested with vsync on and off). Have you noticed this problem with VS 2005 too ? -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framerate vs stats?
How could it be a driver bug if it's debug/release issue?!? Don't both versions use the same driver? Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-S?bastien Guay Sent: Friday, February 15, 2008 5:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Framerate vs stats? Hello Wojtek, We noticed another issue. When statistics bars are on - framerate slowly degrades. This happens with osgviewer dumptruck.osg for example. When stats are on draw time slowly grows and framerate starts to decrease. I've seen that, but only when compiled in debug mode... Check to see if you're in debug. Never do performance timing in debug mode :-) If you're in release, then I haven't seen this, might be a driver bug... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MRT
Hello all, I've read in the mailing list that some people made some patches to use MRT. I also did the same, instead of changing the RenderStage, I changed the FrameBufferObject apply function (does MRT possible without FBO??) Anyway, the textures I attach to get the right values, but the images I attach do not. In RenderStage, only the last image of the camera attachments is being copied with readPixels. So I patched the RenderStage too, going over all camera attachments and trying to read the images. But readPixels read from the frame buffer, so for those attachments I attached also a texture and applied the texture with the state of the renderstage, and then tried readFromCurrentTexture (with fixing the image class to read correctly when using float) but the images data was the same (the data on the frame buffer) even that the textures where different. Can anyone explain how to read the data to the images (or any other way to get the data from the MRT to the RAM)? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
