Re: [osg-users] heip
Please state your country to call the police. It's a joke xD for what do you need help? 2011/9/28 liu_junli liu_ju...@yeah.net ** -- liu_junli ___ 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] [osgOcean] Culling and intersects with ocean and model...
Hi Michael, Nice looking simulator you've got there, it's great to see osgOcean in the wild. K. On 28 September 2011 01:28, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Michael, This process would be made much easier if ocean surface only created a new stateset if a previous one didn't exist. Is there a reason for recreating it? No reason other than laziness. If any attribute that's being stored in the stateset gets changed, rather than just changing that attribute (and potentially others that depend on it, and so on) and thus scattering the code that creates the state set in many different methods, we just dirty the state set which causes it to be recreated and repopulated in the next frame. You're welcome to do it differently if you want and submit the change. In fact it would really be nice if you could merge your technique into osgOcean's own code and submit the change. I'm sure many people would appreciate such functionality, if you have the time to do it. J-S -- __** Jean-Sebastien Guay jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/ __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting up FBO in drawable
Hi everyone,
I'm trying to setup an pure OpenGL FBO with render to texture target in an
OSG drawable. But I just can't figure out how to do that properly (eg. how
to isolate those pure openGL calls from the rest of the OSG scene).
in my drawa implementation I just have:
virtual void drawImplementation(osg::RenderInfo info) const
{
OSG_NOTICE Drawing PingPongDrawable...;
osg::State* state = info.getState();
const unsigned int contextID = state-getContextID();
if(!_initialized !init(contextID,*state)) {
OSG_WARN Failed FBO setup!;
return;
}
state-checkGLErrors(end of PingPongDrawable drawing.);
}
So i'm really just calling an init function once to jus try to *create* an
FBO... I didn't even start using it..., the code of the init function is as
follow:
bool init(unsigned int contextID, osg::State state) const {
const FBOExtensions* fbo_ext =
FBOExtensions::instance(contextID,true);
const osg::Texture2DArray::Extensions* t2darray_ext =
osg::Texture2DArray::getExtensions(contextID,true);
// Push attribs to avoid collisions with existing OSG scene ?
glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT | GL_TEXTURE_BIT |
GL_ENABLE_BIT);
state.checkGLErrors(Before PPD init.);
// Prepare the target texture for the FBO:
state.setActiveTextureUnit(1);
state.checkGLErrors(Activating texture slot 1);
int FFT_SIZE=256;
GLuint fftaTex = 0;
glGenTextures(1, fftaTex);
glBindTexture(GL_TEXTURE_2D_ARRAY_EXT, fftaTex);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MAX_ANISOTROPY_EXT,
16);
t2darray_ext-glTexImage3D(GL_TEXTURE_2D_ARRAY_EXT, 0, GL_RGBA16F_ARB,
FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
fbo_ext-glGenerateMipmap(GL_TEXTURE_2D_ARRAY_EXT);
state.checkGLErrors(preparing target texture);
// Initialize the FBO
fbo_ext-glGenFramebuffers(1, _fftFbo);
state.checkGLErrors(Generating FBO);
fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, _fftFbo);
state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
fbo_ext-glFramebufferTexture(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
state.checkGLErrors(FramebufferTexture setup);
#endif
GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-getDefaultFboId() : 0;
fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, fboId);
if(fbo_ext-glCheckFramebufferStatus(GL_FRAMEBUFFER_EXT) !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
OSG_WARN Error while setting up Pingpong FBO.;
}
state.checkGLErrors(end of Framebuffer settings);
glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );
glPopAttrib();
_initialized = true;
return true;
}
Adding such a drawable in my scene, i don't have any problem as long as
ATTACH_TEXTURE is *undefined*. But when I define this, I still don't have
any error reported by the drawable itself (all the checkGLErrors I
inserted). But then getcontinous list of
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..) messages :-(
= Any idea what I'm doing wrong here ? How can I enforce the isolation
between those openGL calls and what's left from the OSG scene ? after all,
since this init function is called only once, there should not be any
continous warning report if it didn't have a side effect outside of this
drawable encapsulation...
Thanks for you help !! I really feel desperated now... :'(
Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up FBO in drawable
Hi,
I can't help you with your specific drawable question, but what would
you like to achieve? In the osggameoflife example there is an example of
ping-pong using multiple cameras and switches. You can also swap output
textures if they are exactly the same using a callback. See here for
inspiration:
http://code.google.com/p/flitr/source/browse/trunk/examples/keep_history_pass/keep_history_pass.cpp
cheers
jp
On 28/09/2011 10:45, Emmanuel Roche wrote:
Hi everyone,
I'm trying to setup an pure OpenGL FBO with render to texture target in
an OSG drawable. But I just can't figure out how to do that properly
(eg. how to isolate those pure openGL calls from the rest of the OSG
scene).
in my drawa implementation I just have:
virtual void drawImplementation(osg::RenderInfo info) const
{
OSG_NOTICE Drawing PingPongDrawable...;
osg::State* state = info.getState();
const unsigned int contextID = state-getContextID();
if(!_initialized !init(contextID,*state)) {
OSG_WARN Failed FBO setup!;
return;
}
state-checkGLErrors(end of PingPongDrawable drawing.);
}
So i'm really just calling an init function once to jus try to
_create_ an FBO... I didn't even start using it..., the code of the init
function is as follow:
bool init(unsigned int contextID, osg::State state) const {
const FBOExtensions* fbo_ext =
FBOExtensions::instance(contextID,true);
const osg::Texture2DArray::Extensions* t2darray_ext =
osg::Texture2DArray::getExtensions(contextID,true);
// Push attribs to avoid collisions with existing OSG scene ?
glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT | GL_TEXTURE_BIT
| GL_ENABLE_BIT);
state.checkGLErrors(Before PPD init.);
// Prepare the target texture for the FBO:
state.setActiveTextureUnit(1);
state.checkGLErrors(Activating texture slot 1);
int FFT_SIZE=256;
GLuint fftaTex = 0;
glGenTextures(1, fftaTex);
glBindTexture(GL_TEXTURE_2D_ARRAY_EXT, fftaTex);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D_ARRAY_EXT,
GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
t2darray_ext-glTexImage3D(GL_TEXTURE_2D_ARRAY_EXT, 0,
GL_RGBA16F_ARB, FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
fbo_ext-glGenerateMipmap(GL_TEXTURE_2D_ARRAY_EXT);
state.checkGLErrors(preparing target texture);
// Initialize the FBO
fbo_ext-glGenFramebuffers(1, _fftFbo);
state.checkGLErrors(Generating FBO);
fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, _fftFbo);
state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
fbo_ext-glFramebufferTexture(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
state.checkGLErrors(FramebufferTexture setup);
#endif
GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-getDefaultFboId() : 0;
fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, fboId);
if(fbo_ext-glCheckFramebufferStatus(GL_FRAMEBUFFER_EXT) !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
OSG_WARN Error while setting up Pingpong FBO.;
}
state.checkGLErrors(end of Framebuffer settings);
glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );
glPopAttrib();
_initialized = true;
return true;
}
Adding such a drawable in my scene, i don't have any problem as long as
ATTACH_TEXTURE is *undefined*. But when I define this, I still don't
have any error reported by the drawable itself (all the checkGLErrors I
inserted). But then getcontinous list of
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..) messages :-(
= Any idea what I'm doing wrong here ? How can I enforce the
isolation between those openGL calls and what's left from the OSG scene
? after all, since this init function is called only once, there should
not be any continous warning report if it didn't have a side effect
outside of this drawable encapsulation...
Thanks for you help !! I really feel desperated now... :'(
Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] Setting up FBO in drawable
Thanks J.P,
but actually I know the gameoflife example almost by heart already and this
won't fit the bill: I need a real single pass ping pong rendering here if
I want to achieve good performances.
Cheers,
Manu.
2011/9/28 J.P. Delport jpdelp...@csir.co.za
Hi,
I can't help you with your specific drawable question, but what would you
like to achieve? In the osggameoflife example there is an example of
ping-pong using multiple cameras and switches. You can also swap output
textures if they are exactly the same using a callback. See here for
inspiration:
http://code.google.com/p/**flitr/source/browse/trunk/**
examples/keep_history_pass/**keep_history_pass.cpphttp://code.google.com/p/flitr/source/browse/trunk/examples/keep_history_pass/keep_history_pass.cpp
cheers
jp
On 28/09/2011 10:45, Emmanuel Roche wrote:
Hi everyone,
I'm trying to setup an pure OpenGL FBO with render to texture target in
an OSG drawable. But I just can't figure out how to do that properly
(eg. how to isolate those pure openGL calls from the rest of the OSG
scene).
in my drawa implementation I just have:
virtual void drawImplementation(osg::**RenderInfo info) const
{
OSG_NOTICE Drawing PingPongDrawable...;
osg::State* state = info.getState();
const unsigned int contextID = state-getContextID();
if(!_initialized !init(contextID,*state)) {
OSG_WARN Failed FBO setup!;
return;
}
state-checkGLErrors(end of PingPongDrawable drawing.);
}
So i'm really just calling an init function once to jus try to
_create_ an FBO... I didn't even start using it..., the code of the init
function is as follow:
bool init(unsigned int contextID, osg::State state) const {
const FBOExtensions* fbo_ext =
FBOExtensions::instance(**contextID,true);
const osg::Texture2DArray::**Extensions* t2darray_ext =
osg::Texture2DArray::**getExtensions(contextID,true);
// Push attribs to avoid collisions with existing OSG scene ?
glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT | GL_TEXTURE_BIT
| GL_ENABLE_BIT);
state.checkGLErrors(Before PPD init.);
// Prepare the target texture for the FBO:
state.setActiveTextureUnit(1);
state.checkGLErrors(**Activating texture slot 1);
int FFT_SIZE=256;
GLuint fftaTex = 0;
glGenTextures(1, fftaTex);
glBindTexture(GL_TEXTURE_2D_**ARRAY_EXT, fftaTex);
glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_WRAP_S,
GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_WRAP_T,
GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D_**ARRAY_EXT,
GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
t2darray_ext-glTexImage3D(GL_**TEXTURE_2D_ARRAY_EXT, 0,
GL_RGBA16F_ARB, FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
fbo_ext-glGenerateMipmap(GL_**TEXTURE_2D_ARRAY_EXT);
state.checkGLErrors(preparing target texture);
// Initialize the FBO
fbo_ext-glGenFramebuffers(1, _fftFbo);
state.checkGLErrors(**Generating FBO);
fbo_ext-glBindFramebuffer(GL_**FRAMEBUFFER_EXT, _fftFbo);
state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
fbo_ext-glFramebufferTexture(**GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
state.checkGLErrors(**FramebufferTexture setup);
#endif
GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-**getDefaultFboId() : 0;
fbo_ext-glBindFramebuffer(GL_**FRAMEBUFFER_EXT, fboId);
if(fbo_ext-**glCheckFramebufferStatus(GL_**FRAMEBUFFER_EXT) !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
OSG_WARN Error while setting up Pingpong FBO.;
}
state.checkGLErrors(end of Framebuffer settings);
glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );
glPopAttrib();
_initialized = true;
return true;
}
Adding such a drawable in my scene, i don't have any problem as long as
ATTACH_TEXTURE is *undefined*. But when I define this, I still don't
have any error reported by the drawable itself (all the checkGLErrors I
inserted). But then getcontinous list of
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..) messages :-(
= Any idea what I'm doing wrong here ? How can I enforce the
isolation between those openGL calls and what's left from the OSG scene
? after all, since this init function is called only once, there should
not be any continous warning report if it didn't have a side effect
outside of this drawable encapsulation...
Thanks for you help !! I really feel desperated now... :'(
Manu.
__**_
osg-users mailing list
osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
Re: [osg-users] Setting up FBO in drawable
Hi,
I see you mention fft in your code. Is this what you want to do? Do you
have a working fft with multiple OSG cameras? Is it too slow for you?
jp
On 28/09/2011 11:30, Emmanuel Roche wrote:
Thanks J.P,
but actually I know the gameoflife example almost by heart already and
this won't fit the bill: I need a real single pass ping pong rendering
here if I want to achieve good performances.
Cheers,
Manu.
2011/9/28 J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za
Hi,
I can't help you with your specific drawable question, but what
would you like to achieve? In the osggameoflife example there is an
example of ping-pong using multiple cameras and switches. You can
also swap output textures if they are exactly the same using a
callback. See here for inspiration:
http://code.google.com/p/__flitr/source/browse/trunk/__examples/keep_history_pass/__keep_history_pass.cpp
http://code.google.com/p/flitr/source/browse/trunk/examples/keep_history_pass/keep_history_pass.cpp
cheers
jp
On 28/09/2011 10:45, Emmanuel Roche wrote:
Hi everyone,
I'm trying to setup an pure OpenGL FBO with render to texture
target in
an OSG drawable. But I just can't figure out how to do that
properly
(eg. how to isolate those pure openGL calls from the rest of
the OSG
scene).
in my drawa implementation I just have:
virtual void drawImplementation(osg::__RenderInfo info) const
{
OSG_NOTICE Drawing PingPongDrawable...;
osg::State* state = info.getState();
const unsigned int contextID = state-getContextID();
if(!_initialized !init(contextID,*state)) {
OSG_WARN Failed FBO setup!;
return;
}
state-checkGLErrors(end of PingPongDrawable drawing.);
}
So i'm really just calling an init function once to jus try to
_create_ an FBO... I didn't even start using it..., the code of
the init
function is as follow:
bool init(unsigned int contextID, osg::State state) const {
const FBOExtensions* fbo_ext =
FBOExtensions::instance(__contextID,true);
const osg::Texture2DArray::__Extensions* t2darray_ext =
osg::Texture2DArray::__getExtensions(contextID,true);
// Push attribs to avoid collisions with existing OSG scene ?
glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT |
GL_TEXTURE_BIT
| GL_ENABLE_BIT);
state.checkGLErrors(Before PPD init.);
// Prepare the target texture for the FBO:
state.setActiveTextureUnit(1);
state.checkGLErrors(__Activating texture slot 1);
int FFT_SIZE=256;
GLuint fftaTex = 0;
glGenTextures(1, fftaTex);
glBindTexture(GL_TEXTURE_2D___ARRAY_EXT, fftaTex);
glTexParameteri(GL_TEXTURE_2D___ARRAY_EXT,
GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D___ARRAY_EXT,
GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D___ARRAY_EXT,
GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D___ARRAY_EXT,
GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D___ARRAY_EXT,
GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
t2darray_ext-glTexImage3D(GL___TEXTURE_2D_ARRAY_EXT, 0,
GL_RGBA16F_ARB, FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
fbo_ext-glGenerateMipmap(GL___TEXTURE_2D_ARRAY_EXT);
state.checkGLErrors(preparing target texture);
// Initialize the FBO
fbo_ext-glGenFramebuffers(1, _fftFbo);
state.checkGLErrors(__Generating FBO);
fbo_ext-glBindFramebuffer(GL___FRAMEBUFFER_EXT, _fftFbo);
state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
fbo_ext-glFramebufferTexture(__GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
state.checkGLErrors(__FramebufferTexture setup);
#endif
GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-__getDefaultFboId() : 0;
fbo_ext-glBindFramebuffer(GL___FRAMEBUFFER_EXT, fboId);
if(fbo_ext-__glCheckFramebufferStatus(GL___FRAMEBUFFER_EXT) !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
OSG_WARN Error while setting up Pingpong FBO.;
}
state.checkGLErrors(end of Framebuffer settings);
glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );
glPopAttrib();
_initialized = true;
return true;
}
Adding such a drawable in my scene, i don't have any problem as
long as
ATTACH_TEXTURE is
[osg-users] Problem with temporary graphics content. [leaking memory]
Hello guys,
I am working on a big project which uses OSG 3.0.0 and I have a very strange
problem. During the initialization of the application I create a temporary
graphics context in order to perform a series of actions (OGL extension support
check,3d texture creation etc). When I am done I call
osg::GraphicsContext::releaseContext() in order to release the temporary
context. Then I create my scene graph, I create my viewer, I set my scenegraph
data to the viewer and then I start calling Viewer::frame() function (I do not
use Viewer::start() because it is a Qt application).
Lets focus on the problem now. After all the initialization and while the
application runs, I check the memory usage from the windows task manager. If I
do not create this temporary graphics context during the initialization, the
memory usage of the application is about 100MB of memory. If I do create this
temporary graphics context the memory usage is almost 300MB of memory!
I had a closer look at the memory usage during the application initialization:
* Without the temporary graphics context the memory usage goes up to 270MB and
then suddenly drops to 90MB and then ends up at 100MB. (I guess this is because
it releases some vertex and texture data from the CPU memory after transferring
them to the GPU memory).
* With the temporary graphics context I do not have the 270MB-90MB drop.
During the initialization it climbs up to 300MB and stays there.
Then I realized that this won't happen if I create the temporary graphics
context AFTER calling the Viewer::frame() function once (aka AFTER creating my
main graphics context). Why is this happening? Are there some rules on when a
temporary graphics content should be created?
Here is my code for the temporary graphics content:
Code:
class TemporaryGraphicsContext
{
public:
TemporaryGraphicsContext(void):_id(-1)
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = traits-y = 0;
traits-width = traits-height = 1;
traits-windowDecoration = false;
traits-doubleBuffer = false;
traits-sharedContext = 0;
traits-pbuffer = false;
_gc = osg::GraphicsContext::createGraphicsContext(traits.get());
if (_gc.valid())
{
_gc-realize();
_gc-makeCurrent();
_id = _gc-createNewContextID();
}
}
~TemporaryGraphicsContext() {
_gc-releaseContext();
}
bool valid() const { return _gc.valid() _gc-isRealized(); }
inline int getID(void){ return _id; }
public:
osg::ref_ptrosg::GraphicsContext _gc;
int _id;
};
And here is how I use it:
Code:
{
TemporaryGraphicsContext tmpGC;
// Do stuff
}
// tmpGC goes up of scope and released automatically(check destructor)
Any ideas what is going on? Thank you for your time guys!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43064#43064
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with temporary graphics context. [leaking memory]
I just did a test and I think I have to change the following sentence: Then I realized that this won't happen if I create the temporary graphics context AFTER calling the Viewer::frame() function once (aka AFTER creating my main graphics context). to: Then I realized that this won't happen if I create the temporary graphics context AFTER compiling the OpenGL objects of my data once. But still I have no idea why this is happening. :( Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43065#43065 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up FBO in drawable
Yes J.P,
as far as I understand the code I'm trying to integrate into OSG, this step
will basically perform a FFT computation on the GPU.
The code I'm using as template is written in pure opengl: it is the Ocean
lighting implementation from Eric Brunetton (
http://evasion.inrialpes.fr/~Eric.Bruneton/). My goal is to integrate this
code with osgEarth and achieve realistic ocean rendering this way.
in the opengl implementation, he is basically doing this:
1. Setting up 2 texture2Darrays with 5 layers both
2. attaching those texture arrays as color buffer 0 and 1 on a FBO,
3. ping ponging the rendering between those two texture arrays with 2x8
passes in a single rendering cycle (= a single frame), this is done this
way:
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glUseProgram(fftx-program);
glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 : 3);
for (int i = 0; i 2; ++i) { //
glUniform1f(glGetUniformLocation(fftx-program, pass), float(i + 0.5)
/ PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glUseProgram(ffty-program);
glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 : 3);
for (int i = PASSES; i 2 * PASSES; ++i) {
glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
PASSES + 0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
= as you can see, a single FBO is used and the glDrawBuffer is called
multiple times to toggle the target on the fly.
The good news in this story is, I don't if you following my previous
discussion with Sergey, (thread called Changing DrawBuffer for FBO) but it
turns out the DrawBuffer stateAttribute I created is working just as
expected in fact
So this ping pong implementation is basically working, but the problem I
noticed comes from another point: the GLSL program used in the process.
in the openGL code, the two texture2D arrays are attached to the FBO this
way:
glGenFramebuffersEXT(1, fftFbo2);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
fftaTex, 0);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT,
fftbTex, 0);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
So, in my OSG implementation I turned that into (this is lua code):
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);
But, now I think the problem comes from how those bindings are
interpretated in both case:
- the GLSL program performing the rendering contains a geometry shader.
and this shader with emit a screen quad for each of the 5 layers in the
texture2Darray, then the fragment shader just use the gl_FragColor as target
and it seems that:
- with the pure OpenGL code, automagically, the texture2DArray layer that
is written it is the layer corresponding to the geometry layer currently
emitted...
- Whereas in the OSG code, the results are... well... it seems only the
first layer is attached... which would make sense this the second 0 after
result.ffts[x] means layer=0...
Hmmm, I realize this all might not be that clear, but that's really the best
I can do :-)
Any way, on the whole, I think the ping pong rendering system is OK
(understand here that, if I were to use single Texture2D instead of
Texture2DArray attachement, everything would be just fine). But the real
problem now comes from the fact I'm trying to write to multiple layers in a
single Texture2DArray using a geometry shader to select the proper
layer... which might just make sense in OSG for some reason ??
Any idea about all this ?
The good thing is, now I could still manually create 5 quads per ping
pong pass and define a uniform to select the proper source layer in the
texture2DArray sampler, while also attaching all the layers one by one to
the FBO (this would give me 2x5 attachments) and still using a DrawBuffer
stateAttribute to select the proper texture and layer to render to...
But again, this will be a big sub-optimal and using a geometry shader would
probably be more efficient, no ? So is it possible ?
Cheers,
Manu.
2011/9/28 J.P. Delport jpdelp...@csir.co.za
Hi,
I see you mention fft in your code. Is this what you want to do? Do you
have a working fft
Re: [osg-users] Setting up FBO in drawable
Hi !
I performed some additional tests on this issue and now I think I'm reaching
the bottom of it:
when I attach my Texture2DArray as:
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);
And then force the GLSL program to only handle and write the computed values
for layer 0, the final result is perfect (on layer 0 of the Texture2DArray).
Now, if I switch the indexes to handle the layer 1 with:
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,1,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,1,true);
And then force the GLSL program to write only that layer 1 data, then may
layer 1 on the second Texture2DArray is completely black and the layer 1 on
the first Texture2DArray seems unchanged (that first Texture2DArray is
initialized first with non zero data.
= So it seems nothing in written on my layers 1 on that second case.
No idea what could be wrong with those Texture2DArray targets ?
Cheers,
Manu.
2011/9/28 Emmanuel Roche roche.emman...@gmail.com
Yes J.P,
as far as I understand the code I'm trying to integrate into OSG, this step
will basically perform a FFT computation on the GPU.
The code I'm using as template is written in pure opengl: it is the Ocean
lighting implementation from Eric Brunetton (
http://evasion.inrialpes.fr/~Eric.Bruneton/). My goal is to integrate this
code with osgEarth and achieve realistic ocean rendering this way.
in the opengl implementation, he is basically doing this:
1. Setting up 2 texture2Darrays with 5 layers both
2. attaching those texture arrays as color buffer 0 and 1 on a FBO,
3. ping ponging the rendering between those two texture arrays with 2x8
passes in a single rendering cycle (= a single frame), this is done this
way:
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glUseProgram(fftx-program);
glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 :
3);
for (int i = 0; i 2; ++i) { //
glUniform1f(glGetUniformLocation(fftx-program, pass), float(i + 0.5)
/ PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glUseProgram(ffty-program);
glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 :
3);
for (int i = PASSES; i 2 * PASSES; ++i) {
glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
PASSES + 0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
= as you can see, a single FBO is used and the glDrawBuffer is called
multiple times to toggle the target on the fly.
The good news in this story is, I don't if you following my previous
discussion with Sergey, (thread called Changing DrawBuffer for FBO) but it
turns out the DrawBuffer stateAttribute I created is working just as
expected in fact
So this ping pong implementation is basically working, but the problem I
noticed comes from another point: the GLSL program used in the process.
in the openGL code, the two texture2D arrays are attached to the FBO this
way:
glGenFramebuffersEXT(1, fftFbo2);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
fftaTex, 0);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT,
fftbTex, 0);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
So, in my OSG implementation I turned that into (this is lua code):
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);
But, now I think the problem comes from how those bindings are
interpretated in both case:
- the GLSL program performing the rendering contains a geometry shader.
and this shader with emit a screen quad for each of the 5 layers in the
texture2Darray, then the fragment shader just use the gl_FragColor as target
and it seems that:
- with the pure OpenGL code, automagically, the texture2DArray layer that
is written it is the layer corresponding to the geometry layer currently
emitted...
- Whereas in the OSG code, the results are... well... it seems only the
first layer is attached... which would make sense this the second 0 after
[osg-users] RTT second pass
Hello again, In my project I need to setup a second render pass that performs the following: Render the scene from the original camera's view (as in the first RTT pass). Set the second camera to be pre-render with render-order increased. Render some volumes and apply a shader a those positions. With this I have some questions: 1. If the second camera is set up with setReferenceFrame(osg::Transform::RELATIVE_RF), will this be the exact view as in the first camera? 2. Can I reuse the depth buffer produced in the first rendering pass for depth-testing in the second pass via simply attaching it as depth-target and not writing to it? 3. My goal is to execute the shaders only at the positions in the view space where the volumes intersect some geometry, in order to calculate view-space lighting there. Unfortunally I get totally wrong view space coordinates with this (e.g. the light position calculated by gl_ModelViewMatrix * vec4(0,0,0,1) is somehow screwed) Is this the way to go? I have done 1) and 3) in plain OpenGL, but somehow I'm totally stuck with light-vector calculation in the second pass. And I somehow think that my camera setup is just wrong. So how do I setup a pass, where I draw from the exact view of the first RTT pass? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with shadows after use sketchupToOSG
Hi, I exported a model with sketchupToOSG and loaded it in an osg application. When I enable shadows (the default osgShadows techniques) the textures of the loaded models becomes wrong. If I disable shadows, everything works. Anybody ever had this problem? That's what I got: http://imageshack.us/photo/my-images/849/shadowafterexport.png/ That's what it should be: http://imageshack.us/photo/my-images/59/shouldbed.png/ -- *Renato Silveira * Ph. D. Student Informatics Institute - UFRGS Porto Alegre - RS - Brazil http://www.inf.ufrgs.br/~rsilveira ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up FBO in drawable
hmmm and God created:
*osg::Camera::FACE_CONTROLLED_**BY_GEOMETRY_SHADER*
and
*setImplicitBufferAttachmentMask(osg.Camera.ImplicitBufferAttachment.IMPLICIT_COLOR_BUFFER_ATTACHMENT,
osg.Camera.ImplicitBufferAttachment.IMPLICIT_COLOR_BUFFER_ATTACHMENT);*
It now works perfectly !! That's the most beautiful day in my life !
(well... almost :-) )
Thanks for your support guys!
Now I can finally proceed with this task.
Cheers,
Manu.
2011/9/28 Emmanuel Roche roche.emman...@gmail.com
Hi !
I performed some additional tests on this issue and now I think I'm
reaching the bottom of it:
when I attach my Texture2DArray as:
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);
And then force the GLSL program to only handle and write the computed
values for layer 0, the final result is perfect (on layer 0 of the
Texture2DArray).
Now, if I switch the indexes to handle the layer 1 with:
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,1,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,1,true);
And then force the GLSL program to write only that layer 1 data, then may
layer 1 on the second Texture2DArray is completely black and the layer 1 on
the first Texture2DArray seems unchanged (that first Texture2DArray is
initialized first with non zero data.
= So it seems nothing in written on my layers 1 on that second case.
No idea what could be wrong with those Texture2DArray targets ?
Cheers,
Manu.
2011/9/28 Emmanuel Roche roche.emman...@gmail.com
Yes J.P,
as far as I understand the code I'm trying to integrate into OSG, this
step will basically perform a FFT computation on the GPU.
The code I'm using as template is written in pure opengl: it is the Ocean
lighting implementation from Eric Brunetton (
http://evasion.inrialpes.fr/~Eric.Bruneton/). My goal is to integrate
this code with osgEarth and achieve realistic ocean rendering this way.
in the opengl implementation, he is basically doing this:
1. Setting up 2 texture2Darrays with 5 layers both
2. attaching those texture arrays as color buffer 0 and 1 on a FBO,
3. ping ponging the rendering between those two texture arrays with 2x8
passes in a single rendering cycle (= a single frame), this is done this
way:
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glUseProgram(fftx-program);
glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 :
3);
for (int i = 0; i 2; ++i) { //
glUniform1f(glGetUniformLocation(fftx-program, pass), float(i +
0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glUseProgram(ffty-program);
glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 :
3);
for (int i = PASSES; i 2 * PASSES; ++i) {
glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
PASSES + 0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
= as you can see, a single FBO is used and the glDrawBuffer is called
multiple times to toggle the target on the fly.
The good news in this story is, I don't if you following my previous
discussion with Sergey, (thread called Changing DrawBuffer for FBO) but it
turns out the DrawBuffer stateAttribute I created is working just as
expected in fact
So this ping pong implementation is basically working, but the problem I
noticed comes from another point: the GLSL program used in the process.
in the openGL code, the two texture2D arrays are attached to the FBO this
way:
glGenFramebuffersEXT(1, fftFbo2);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
fftaTex, 0);
glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT,
fftbTex, 0);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
So, in my OSG implementation I turned that into (this is lua code):
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);
cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);
But, now I think the problem comes from how those bindings are
interpretated in both case:
- the GLSL program performing the
[osg-users] Rendering From First Person
Hey guys, looking for some quick design advice before I start hacking something that I'd end up scrapping. I've written a pretty traditional FPS camera; game-like movement and strafing, sprinting, mouse viewing by warping the pointer to the center of the screen, axis inversion, etc. All the stuff you might find in a game like Call of Duty or similar. When this is all done, I'll probably submit the camera (its a child of osgGA::StandardManipulator) as a new FirstPersonManipulator... Now I'm looking to add some facilities for attaching objects to the scene relative to the viewing eye. For example: a weapon and a mesh representing the viewer's arms. My question is how do I render these objects? Should I treat them specially (for example, adding them in a post render camera) or should I simply position them properly to be rendered in the main frame? I'm looking for some gotchas from other people who have done something similar. Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering From First Person
Hi Jeremy, My question is how do I render these objects? Should I treat them specially (for example, adding them in a post render camera) or should I simply position them properly to be rendered in the main frame? I'm looking for some gotchas from other people who have done something similar. I'd render them as a separate camera, simply because they're very close to the eye and so might affect your depth range and precision pretty drastically. If you render them as a separate camera, you'll then have a main camera with a z range starting at over 1m (probably the ground will be the closest object most of the time) and a post-render camera with a very small near distance but a very close far distance too, so that's ideal. You can even keep automatic near-far calculation on for both, and it will likely work really well. Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Culling and intersects with ocean and model...
Skylark wrote: You're welcome to do it differently if you want and submit the change. In fact it would really be nice if you could merge your technique into osgOcean's own code and submit the change. I'm sure many people would appreciate such functionality, if you have the time to do it. Hi J-S, I'd be happy to contribute this back at some point but I have some concerns. - First, getting this working correctly is dependent on being able to apply the stencil to only the inside the ship since we want the water to still draw over the outside, but not the inside. From a generic perspective, it would probably be ok to just specify which geometry (or subgraphs with the stencil set) should not be allowed to have ocean drawn over it. - The second concern is that in order for the ocean to know it should not draw over any particular fragment, the stencil needs to have already been set before the ocean gets there. This means that the ocean needs to be told to draw at a later phase (higher render bin number than that for used for ships in this case). I'm guessing this may be undesirable for some/many applications. Thoughts? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43073#43073 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering From First Person
On 9/28/2011 9:22 AM, Jean-Sébastien Guay wrote: Hi Jeremy, My question is how do I render these objects? Should I treat them specially (for example, adding them in a post render camera) or should I simply position them properly to be rendered in the main frame? I'm looking for some gotchas from other people who have done something similar. I'd render them as a separate camera, simply because they're very close to the eye and so might affect your depth range and precision pretty drastically. If you render them as a separate camera, you'll then have a main camera with a z range starting at over 1m (probably the ground will be the closest object most of the time) and a post-render camera with a very small near distance but a very close far distance too, so that's ideal. You can even keep automatic near-far calculation on for both, and it will likely work really well. I agree with J-S. If you use ABSOLUTE_RF and an identity view matrix, you should be able to draw these scene elements directly in eye space (you're looking down the -z axis with +y up). In OSG parlance, it's effectively a HUD. In OpenGL, the pattern looks like: push the modelview matrix, set it to identity, draw, then pop. Whenever rendering calls for this OpenGL pattern, in OSG you should immediately think Camera. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using the osgQt Library
Hello, I'm working on a project for work and it entails integrating the Qt 4.7.3 and OSG 3.0.0 APIs and I have studied the osgviewerQt example and believe that I have a good understanding of how it works. I have determined that for my needs the CompositeViewer is the best option and the example previously mentioned can serve as a building block. But in my case I will need to create the viewWidget after entering the Qt main loop. I think that I found the means to do so via the osgQt namespace function setViewer(osgViewer::ViewerBase * Viewer) is my rationale sound or am I missing something? Also if anyone can explain the usage (possible cases) of the two remaining functions (initQtWindowSystem() , getOrCreateApplication() ) also any further advice in regards to the osgQt Library will be greatly appreciated. Thank you! Cheers, Scott -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43075#43075 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Open Flight characteristic not reflected in the current OSG
Hi all -- David and I have been discussing this offline, and we've arrived at a fix that will be posted shortly. Turns out the actual issue was that the vertex record flags field had the NO_COLOR bit set, but the OSG flt loader wasn't checking for that bit. If NO_COLOR is set, the color index should be ignored. The code to support the Face record was already set up to use the face color in this situation. For the fix, all we had to do was modify the Vertex record code to correctly check for NO_COLOR, then leave the vertex color invalid in that case. The Face record took care of the rest. -Paul On 9/27/2011 3:30 PM, David Glenn wrote: Paul Martz wrote: On 9/27/2011 10:55 AM, David Glenn wrote: Greetings All: Something I found that is interesting in Creator 3.4 (Open Flight) that is not reflected in OSG. In Creator Face Attributes, under the Drawing tab, If your set the Shade to Gouraud, you are shading at the vector level, hence you usually set the colors at the vector points. What I found interesting is that if you don't set a vector color (leave the index color set to -1), since it is undefended, in Creators view it defaults to the Face color (or Primary Color). Do you have a small reproducer model that could be added to the regression suite at osgfltexport.googlecode.com? This does not happen in the Open Flight plug-in in either 2.8.1 or the latest I've tested 3.0.1 . Can you describe what OSG does and how it's different from the expected behavior? -Paul I know this is not a documented feature, but maybe we need to cover this in the Open Flight Plug-in anyway so we are computable to that standard. It would be better than trying to explain to some of these modelers why they have to brake old habits when from their perspective, it only happens on OSG. ... Thank you! David Glenn - D Glenn 3D Computer Graphics Media Systems. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43046#43046 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Quick answers 1) Yes, Ill make a reproduction you can use, as soon as I can get some free time to make one and to test it to verify the results - just in case! 2) Any elements that appear colored in Creator 3.4 display, appear as white in OSG 2.8.1 and OSG 3.0.1 that I tested. I post something here when I send it there or have any problems. David Glenn - D Glenn 3D Computer Graphics Media Systems. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shaders and projective texturing
On 9/27/2011 7:21 PM, Brad Colbert wrote: I am closer! Looks like the other example I have is FFP not GLSL. Here's a working GLSL implementation (not OSG) that should be relatively easy to feed with OSG uniforms and such: http://www.ozone3d.net/tutorials/glsl_texturing_p08.php#part_8 -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer and ScreenCapture Handler
Stephan I've been looking at a similar problem and I believe that I may have a possible solution. if you look in the api documentation for the CompositeViewer there is method called osgViewer::View * getView(unsigned int index) using this you could specify which view you want to capture based on the index value. Cheers, Scott[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43079#43079 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shaders and projective texturing
Hi Chris, Thanks! I found that one too but it still doesn't help me figure out how to fix the coordinates so that my projected texture renders in the center of the projection frustum instead of the upper right quadrant. It's strange and I can't figure it out. -B -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: Wednesday, September 28, 2011 3:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] GLSL shaders and projective texturing On 9/27/2011 7:21 PM, Brad Colbert wrote: I am closer! Looks like the other example I have is FFP not GLSL. Here's a working GLSL implementation (not OSG) that should be relatively easy to feed with OSG uniforms and such: http://www.ozone3d.net/tutorials/glsl_texturing_p08.php#part_8 -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shaders and projective texturing
Brad, I once had the same issue; calcuating my texgen matrix like this worked: texGenMat = modelViewMat * projectionMat * osg::Matrix::translate(1, 1, 1) * osg::Matrix::scale(0.5, 0.5, 0.5); Glenn Waldron / Pelican Mapping / @glennwaldron On Wed, Sep 28, 2011 at 7:34 PM, Brad Colbert bcolb...@rscusa.com wrote: Hi Chris, Thanks! I found that one too but it still doesn't help me figure out how to fix the coordinates so that my projected texture renders in the center of the projection frustum instead of the upper right quadrant. It's strange and I can't figure it out. -B -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: Wednesday, September 28, 2011 3:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] GLSL shaders and projective texturing On 9/27/2011 7:21 PM, Brad Colbert wrote: I am closer! Looks like the other example I have is FFP not GLSL. Here's a working GLSL implementation (not OSG) that should be relatively easy to feed with OSG uniforms and such: http://www.ozone3d.net/tutorials/glsl_texturing_p08.php#part_8 -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users 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] osganimationhardware example osg 3.0.1
Hi Guys
I've been trying to run the osganimationhardware example for osg 3.0.1 on
windows7 32bit with Geforce GTX 560 and latest drivers 280.26 . In the past
I have had this running (not on this machine or osg version), I simply
downloaded the osgData collection with the nathan.osg and skinning.vert
shader file.
However now when I'm running it, anything that is skinned does not render. I
have altered the shader to just use the gl_Vertex position rather then the
weighted position and then the object renders (so verts are fine). I have
also used the boneWeight0 uniforms to colour the mesh and they seem to have
decent values.
The only thing that doesn't seem to have good values is
uniform mat4 matrixPalette[MAX_MATRIX];
When I checked the converted shader the value of MAX_MATRIX seems to be set
correctly, but if I used the first line of the first matrix as the colour
value, like
gl_FrontColor = matrixPalette[0][0];
It is always black,
Looking at the uniform attached to the geoms stateset I can see roughly the
following in the debugger
_uniformList = [2]((matrixPalette, ({_ptr=0x0d0bfb58 },
0)),(nbBonesPerVertex, ({_ptr=0x0d0bf3b8 }, 0)))
_ptr = 0x0d0bfb58 {_parents=[1](0x0d0bfed8 {_parents=[1](0x00df9bf8
{_name= _dataVariance=DYNAMIC _userDataContainer=0x })
_modeList=[0]() _attributeList=[1](((PROGRAM, 0), ({_ptr=0x0d0bc9c0 }, 0)))
...}) _type=FLOAT_MAT4 _numElements=3 ...}
osg::MixinVectorfloat =
{_impl=[48](1.000,0.,0.,0.,0.,1.000,0.,0.,0.,0.,1.000,0.,0.,0.,0.,1.000,0.8939,0.0046100151,0.,0.,-0.0046100151,0.8939,0
So if the colour is the first vec4 of the matrixPalette uniform it should
be 1.000,0.,0.,0., but it's just black.
Can anyone confirm the osganimationhardware example is currently working
with these assets
http://www.openscenegraph.org/projects/osg/wiki/Downloads/SampleDatasets
Any help would be awesome
Tom
PS
My config looks like this
#ifndef OSG_CONFIG
#define OSG_CONFIG 1
/* #undef OSG_NOTIFY_DISABLED */
/*#define OSG_USE_FLOAT_MATRIX
#define OSG_USE_FLOAT_PLANE
#define OSG_USE_FLOAT_BOUNDINGSPHERE
#define OSG_USE_FLOAT_BOUNDINGBOX*/
#define OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION
/* #undef OSG_USE_UTF8_FILENAME */
#define OSG_DISABLE_MSVC_WARNINGS
#define OSG_GL1_AVAILABLE
#define OSG_GL2_AVAILABLE
/* #undef OSG_GL3_AVAILABLE */
/* #undef OSG_GLES1_AVAILABLE */
/* #undef OSG_GLES2_AVAILABLE */
/* #undef OSG_GL_LIBRARY_STATIC */
#define OSG_GL_DISPLAYLISTS_AVAILABLE
#define OSG_GL_MATRICES_AVAILABLE
#define OSG_GL_VERTEX_FUNCS_AVAILABLE
#define OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE
#define OSG_GL_FIXED_FUNCTION_AVAILABLE
#endif
I mention it as originally I dived straight into trying it without any fixed
functionality essentially emulating gles2, but had this same issue. I've
then gone for the more standard build above, but the result is the same
(although now I see objects that aren't skinned) If I can get this working
again on desktop then I don't think getting it working on gles2 will be too
much hassle (unless I hit some shader variable length limit).
Also standard osgAnimationViewer works fine
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
