Re: [osg-users] [HELP] Cull time in stats?

[Jimmy Lin]

Hi,

Thanks alot, J-C!

Cheers,
Jimmy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16064#16064





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [HELP] Cull time in stats?

[Jean-Sébastien Guay]

Hi Jimmy,


What will be a good-sized chunks? The bigger the better?


You need to experiment on the video cards you will be using, but in 
general, as I said before in this thread, thousands per vertex array 
(perhaps tens of thousands).



My scene are contains numbers of models which consist of multiple parts.
Although each part will always be in the same position relative to each others, 
 I can't really merge them to one osg::Geometry. Because they need to be able 
to change colour independently on run time.


If your colors are being specified per vertex, then you can change the 
colors of a certain set of vertices without affecting the others. Or, 
you can have multiple geometry objects sharing the same vertex array but 
having distinct color arrays, as I see you've thought of below. It's not 
the same since OSG will still have to switch arrays for colors, but it 
will be less work than what you're doing now.


Or just set the colors using textures and swap the textures when you 
need to change colors.


It's more work for you to code it up, but if you're hitting bottlenecks 
then it's probably more important to you that you improve the frame 
rate, so getting your data into a format that OSG, OpenGL and your video 
card can process more easily will pay off.



Now I am thinking about to create one huge static vertices array which will be 
used by all the geometry in the scene with correct indexing. Do you think this 
approach will help? or it might make the matter worse?


It will differ from card to card, but generally one huge array is not 
the answer, it's more about grouping so there are 10 or 20 thousand 
vertices per array. You need to experiment with the granularity. You 
could easily make a test program where you would make a vertex array of 
some large number N of vertices, then two of N/2 each, then four of N/4 
each and so on to experiment. Make the test reasonably close to your 
actual situation, but set it up so that granularity is parameterized 
(number of vertices per array, number of geometries per group, number of 
transforms above the groups, etc.)


The osgUtil::Optimizer has visitors that can help you do some of the 
necessary operations automatically, or can show you working code to do 
it which you can then copy and modify. For example, the 
FLATTEN_STATIC_TRANSFORMS setting will remove static transform nodes, 
the MERGE_GEODES setting will put several geometry objects under a 
single geode instead of multiple geodes, and the MERGE_GEOMETRY setting 
will merge several geometry objects into a single one (merging arrays 
together). See "osgconv --help-env" for more settings, and the 
osgUtil::Optimizer header for pointers into the classes that do the work.


Geez, I'm feel like I'm writing a novel here. I'll see if I can put this 
up on the wiki so I don't have to type all this up again in the future. :-)


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [HELP] Cull time in stats?

[Jimmy Lin]

Hi,

Thanks for clear things up for me, it does help alot.


> To reduce the draw 
> time, you need to group geometry so that data is uploaded to the card in 
> good-sized chunks.


What will be a good-sized chunks? The bigger the better?

My scene are contains numbers of models which consist of multiple parts.
Although each part will always be in the same position relative to each others, 
 I can't really merge them to one osg::Geometry. Because they need to be able 
to change colour independently on run time.

I just changed my code to share stateset, and it does help quit a bit.

Now I am thinking about to create one huge static vertices array which will be 
used by all the geometry in the scene with correct indexing. Do you think this 
approach will help? or it might make the matter worse?

Thanks again for your help!

Cheers,
Jimmy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16062#16062





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderGen and GL3

[Jean-Sébastien Guay]

Hi Paul,

I think we want to allow for apps that don't 
specify vertices from host code, and forcing the app to call 
Geometry::setVertexPointer in such a case would obfuscate the code. If 
an app wants to use only generic vertex attributes, OSG needs to change 
to allow this.


Sure, but it can allow it while the default usage will be to use 
setVertexPointer (or some other nomenclature that caters more to 
flexible vertex formats) to simplify code for users that just want to do 
rendering quick and easy.


This type of usage (Geometry without a vertex pointer) introduces a new 
issue, which I alluded to in my BOF presentation: How does OSG cull if 
the Geometry has no vertices, and therefore no bounding box? 
setInitialBounds could be a solution, disabling culling on the Geometry 
is another option.


I think if the user is creating vertices in a geometry shader or some 
other way that doesn't include any vertices on the CPU, then the user 
should think of some way of specifying their own tight bounds so that 
OSG can cull that geometry efficiently. There is already a 
ComputeBoundsCallback the user can use for that, in addition to 
setInitialBounds (if the bounds never change) and disabling culling, as 
you said. I think that's just a case where the user knows more than OSG 
does, so the user needs to take control and tell OSG what he/she wants.


Once again, graphics programming without a safety net.

On one hand, I have clients with large OSG-based apps, and the last 
thing they want is some kind of disruptive change in OSG. To serve them, 
I think we really do need to continue to support the old FFP state in GL3.


Yep.

On the other hand, there's a reason why OpenGL ditched the old FFP 
feature set: Apps that use *all* the features simultaneously are rare, 
and testing these features was an O(n^n) problem. Eliminating the 
features allows for equivalent functionality in much simpler 
app-specific shaders. If OSG tries to move forward with the old FFP 
feature set, we will be attempting to do what hardware vendors like ATI 
and NVIDIA have given up on. As more features are added to OSG, the 
problem will only get worse.


Yep.

(We already have such feature mixing issues in OSG. Ever try to use 
osgText with osgShadow? Both nodekits think they own texture unit 0... 
I've intended to make the texture unit a configurable option for some 
time now, but haven't gotten to it.)


Well in the past, I've placed text objects outside the 
osgShadow::ShadowedScene, or put osgText::Text under a Geode that has 
only such objects and set an empty program on that Geode. Now that last 
one isn't really an option anymore, but to accomodate GL3 osgText::Text 
will probably have to have its own shader anyways, so that should work...


But I'm sidestepping your point, which is valid. It's an n^n problem, 
because what if I want text to cast a shadow? What if I want text that 
casts a shadow under the ocean? (I recently had trouble mixing osgOcean 
and osgShadow in the same way, so I can extrapolate).


That's a problem in general with shaders. Even if we make OSG use shader 
fragments, how will we test that all fragments can interact well with 
all other fragments? It's only really at runtime (and visually to boot) 
that we'll know - we'd need to test all combinations and see if there 
are rendering problems. If there are subtle shading problems when we add 
a certain fragment, we might not even notice.


I'm currently very interested in researching ways to write apps that use 
OSG today in such a way that they avoid OSG functionality that is 
currently implemented on GL 1/2. The idea being, if you write your app 
this way, then any future changes to OSG aimed at supporting GL3 will be 
inconsequential.


It's an interesting thought, but it may end up being a lot of work 
(maybe even as much as writing the app in straight GL3) if OSG ends up 
supporting GL3 in a manner that's transparent (compared to OSG/GL2). 
That's why I'd like Robert to enter this discussion so that we can 
figure out a clear direction for OSG sooner rather than later - it will 
remove much speculation and allow us to future-proof our code in a way 
we're sure won't be wasted time.


Still, your visitor is interesting, extending it would be good, and 
testing it by having OSG create a GL3 context (perhaps even GL3.1 so 
that it errors out when using deprecated functionality) would be even 
better.


I agree, interesting discussion.

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [HELP] Cull time in stats?

[Jean-Sébastien Guay]

Hi Jimmy,


Regarding of having a flat scene graph. Does it matter if the whole scene will 
always be seen? Would it still improve the performance if I balance the scene 
graph more?


In the case where the whole scene will always be seen (think about it 
carefully, though, because I think these cases should be rare in 
practice) then balancing the graph will not help, but removing groups 
and transforms will. That is to say, if all your objects will always be 
visible, then in order to reduce the cull time you need to reduce the 
number of objects to traverse to get to the geometry. To reduce the draw 
time, you need to group geometry so that data is uploaded to the card in 
good-sized chunks.


So for example, if two objects will always be in the same position 
relative to one another, place both in the same osg::Geometry, 
transforming the vertices of the second one to be where the transform 
would have placed it relative to the first.


Say object 0 has vertex array V0 and object 1 has vertex array V1, and 
suppose that object 0 is at world position T0 and object 1 is at 
position T1, then you can build a vertex array V2 containing the 
vertices of both objects like this:


V2 = (V0, V1 + (T1 - T0))

(suppose the addition above will apply the same translation to all 
vertices in V1) and then position the composite object at position T0.


You can extend this if you have groups of many objects that will always 
be in the same relative position from each other, of course. For example 
if a city has buildings and all the buildings are static in world space, 
then place them all in the world coordinate frame with no transforms or 
groups. They can still be in different geometry objects if they have a 
sufficient number of vertices (thousands). If not, then group several of 
them in the same geometry object and use a texture atlas to texture them 
all with the same texture file.


Similar scene graph optimization tips have been discussed in the past on 
the list. The archives should contain even more tips. I don't know if 
there is a wiki page on openscenegraph.org that collects such tips, but 
if there isn't we should create one...


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgPPU: ssartest subtle difference

[Art Tevs]

Hi Anders,

the results you see are correct. The technique implemented here is a very 
simple, faked SSAO. Hence, you do not have to expect much. It is here, just to 
show, that everythign is possible. Users are encouraged to implement examples 
on their own.

If I will get enough time, maybe I could try to improve the SSAO example. 
However, I think, this won't happen in the near future :)

cheers,
art



Anders Backman wrote:
> Hi, downloaded latest (svn) osg and osgPPU and ran the ssaotest.I'm not sure 
> my laptop cope with this, but the result is far from what I expected:
> 
> 
> Left is osgviewer temple.ive and right is osgppu_ssao
> http://img3.imageshack.us/img3/2299/ssartest.jpg 
> (http://img3.imageshack.us/img3/2299/ssartest.jpg)
> 
> 
>  (http://img3.imageshack.us/img3/2299/ssartest.jpg)Only difference is the 
> background color :-) and a slight shadow frame around the model.
> What am I missing here?
> I have a Nvidia 9300 which usually work just find with most of the GL shaders 
> so far, so Im not expecting anything there.
> 
> 
> /Anders
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16059#16059





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderGen and GL3

[Paul Martz]

Jean-Sébastien Guay wrote:
I bet
it wouldn't be too hard to add apply(osg::Camera& camera) that
would set view and projection matrix uniforms, as well as
apply(osg::Transform& transform) for the current local-to-world
matrix (and perhaps uniforms for model*view, model*view*projection for
convenience).
  

Good thought. I've been mulling ways to set local2world, view, normal,
and projection matrices in a manner non-intrusive to app code.
Unfortunately I need to table this while I work on some other stuff,
but hopefully I'll resume this work in the near future.
Well I
think for the basic functionality (vertex positions, normals, vertex
colors, texcoords and the normal matrices) an app should not have to
change other than modifying its shaders to use new names. OSG is after
all a rendering library, so I think we can assume most apps will use
this functionality as a bare minimum.
  

Agreed, OSG is a rendering library. So is OpenGL, but OpenGL 3 allows
apps to not specify vertices on the host, and instead
procedurally generate clip coordinate positions as output of the vertex
shader. In contrast, the current Geometry::drawImplementation is a
no-op if the vertex pointer is not set. I think we want to allow for
apps that don't specify vertices from host code, and forcing the app to
call Geometry::setVertexPointer in such a case would obfuscate the
code. If an app wants to use only generic vertex attributes, OSG needs
to change to allow this.

This type of usage (Geometry without a vertex pointer) introduces a new
issue, which I alluded to in my BOF presentation: How does OSG cull if
the Geometry has no vertices, and therefore no bounding box?
setInitialBounds could be a solution, disabling culling on the Geometry
is another option.
After
that we can decide whether we want to keep the current wrapping of
fixed-pipeline state (for example osg::Fog) and have it set uniforms
when needed.
I flip back and forth on this.

On one hand, I have clients with large OSG-based apps, and the last
thing they want is some kind of disruptive change in OSG. To serve
them, I think we really do need to continue to support the old FFP
state in GL3.

On the other hand, there's a reason why OpenGL ditched the old FFP
feature set: Apps that use all the features simultaneously are
rare, and testing these features was an O(n^n) problem. Eliminating the
features allows for equivalent functionality in much simpler
app-specific shaders. If OSG tries to move forward with the old FFP
feature set, we will be attempting to do what hardware vendors like ATI
and NVIDIA have given up on. As more features are added to OSG, the
problem will only get worse.

(We already have such feature mixing issues in OSG. Ever try to use
osgText with osgShadow? Both nodekits think they own texture unit 0...
I've intended to make the texture unit a configurable option for some
time now, but haven't gotten to it.)

It seems like a "d*mned if we do, d*mned if we don't" kind of problem.
But certainly one worth discussing.
So I
think we have to answer a basic question before we do any actual work:
Do we want OSG to be like it was before, and basically become a GL2
layer over GL3? That would make it easier to use than straight GL3 for
beginners, I think, but it would make OpenGL programming less hands-on
than straight GL3. Of course, if we do it right we can still expose all
the GL3 code paths through a thin layer like was done for GL2, so
people who wanted to use all the freedom and generality of GL3 could
still do so. But OSG would become a good solution for people who wanted
an easier way of doing graphics programming than the "programming
without a safety net" model that GL3 offers. I personally think this is
a great opportunity for OSG to position itself as a great solution that
offers all the power of OpenGL 3 but with a gentler learning curve.
  

Excellent points, and well-said. This really is the question. And as I
said above, there is existing code that is counting on the old FFP
interface continuing to be supported in OSG.

I'm currently very interested in researching ways to write apps that
use OSG today in such a way that they avoid OSG functionality that is
currently implemented on GL 1/2. The idea being, if you write your app
this way, then any future changes to OSG aimed at supporting GL3 will
be inconsequential.

Good discussion.
   -Paul




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [HELP] Cull time in stats?

[Jimmy Lin]

Hi,

Regarding of having a flat scene graph. Does it matter if the whole scene will 
always be seen? Would it still improve the performance if I balance the scene 
graph more?

Thanks for the advice, I will try them.

Cheers,
Jimmy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16057#16057





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] PolytopeIntersector "distance" and Transform

[Andrew Cunningham]

Hi Peter,

Did you ever work up a fix for this?
... 

Thank you!

Cheers,
Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16056#16056





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [HELP] Cull time in stats?

[Jean-Sébastien Guay]

Hi Jimmy,


I would like to know what is the Cull time in the osg stats (the blue bar) 
means.
I notice it changes together with draw time when I zoom in/out of my scene.


Cull time is both the time to do the actual culling, and the time it 
takes to traverse the scene graph and build the draw list (flat list of 
all drawables and state that need to be drawn in the frame).


This list is then traversed in the draw stage, which is the draw bar (a 
better name for this is the "draw dispatch" - draw commands are sent to 
OpenGL). The GPU time is the actual time taken to do the drawing.



I tried to disable the camera cull by setting NO_CULLING for the camera, but it 
didn't remove the cull time at all. It looks like the Cull time in the stats is 
some sort of culling which is done after the camera cull, probably is the 
CullVisitor.
Is there a way to skip this culling process?
I am trying to improve my app's performance at the moment.
I know I can use DrawThreadPerContext instead of SingleThread. and also reuse 
my StateSet/StateAttribute to improve a bit. But both of them require major 
code change on my app.
And most of time the whole scene should be rendered in my app anyway, so there 
is not much point to do culling, and if it can be disabled, I think it will 
increase my performance a lot.


As I said above, the CullVisitor doesn't only do culling. And the 
culling it does is not very costly. Doing setCullingActive(false) does 
work, and if it doesn't give better results, it proves that culling is 
not your problem.


The large cull time indicates that traversing the graph is taking a lot 
of time. This is most likely caused by having a very flat scene graph. 
If most of the time you add objects to the root of the graph, then this 
might be your problem. Making your graph more spatially distributed 
(i.e. groups that are close together put as children of a common group), 
and also perhaps merging objects that will always be seen together (i.e. 
removing group nodes) will probably help. You have way too many groups 
compared to drawables.


Your draw time is also very high. As you said, sharing state and sharing 
arrays (vertex, normal, color, texcoord arrays) will help a lot. You 
seem to have about 27 vertices per drawable (77303/2815) which is very 
little. You should group many such drawables as one drawable, or if this 
is not possible, put the vertices for many drawables in a single vertex 
array, and make the drawables share the array, with the appropriate 
PrimitiveSets to draw the right part of the shared vertex array. 
Generally graphics cards work best when several thousand vertices are 
sent in a batch, so this will most probably help a lot with your draw time.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderGen and GL3

[Jean-Sébastien Guay]

Hi Paul,

Hi J-S -- Good discussion. Thanks for responding to my OSG BOF pleas to 
start discussing GL3 in osg-users. :-)


Heh, I think this kind of discussion is long overdue... OpenGL 3.0 has 
been out for a year after all. :-)


I have the start of a NodeVisitor that will change all Geometry classes 
to use generic vertex attributes, as well as switch DLs to buffer 
objects. See below. I can also set uniform matrix values for the view 
and projection matrices in the app main loop.


While this is certainly an incomplete solution, it does allow me to use 
GLSL 1.30 shaders without any deprecated functionality. I currently have 
a GL3-safe cow running, doing all the transforms, lighting, and texture 
coord generation in GLSL 1.30 shaders. (One major piece of missing 
functionality is support for any model transforms buried in the scene 
graph. But it's a start.)


That's a good start, though it assumes vertices and normals will always 
be present and will always go in positions 0 and 1 (that's why you're 
discussing attribute array names with Robert in another thread, I realize).


You could also place vertex colors in attribute position 2. You could 
probably also check if a texture is currently bound to unit 0+i and then 
set texcoords from unit 0+i to attrib position 3+i, etc.


I bet it wouldn't be too hard to add apply(osg::Camera& camera) that 
would set view and projection matrix uniforms, as well as 
apply(osg::Transform& transform) for the current local-to-world matrix 
(and perhaps uniforms for model*view, model*view*projection for 
convenience).


Then later we could even extend the visitor so that at each node, it 
accumulates and checks all state and sets uniforms for the 
StateAttributes we're interested in.


Ideally, OSG apps should not need to change at all to be compatible with 
GL3. However, at this point, it's too early to tell whether this will be 
the case or not. With that in mind, I feel that exploring ways for 
applications to use OSG in a GL3-safe way is a worthwhile endeavor, 
especially for new app development. If there are ways for apps to take 
responsibility for using vertex attribs and setting their own uniforms, 
we need to research this and make the methods known, so that new 
development can use these techniques and avoid any porting headaches 
that might otherwise arise in the future.


Well I think for the basic functionality (vertex positions, normals, 
vertex colors, texcoords and the normal matrices) an app should not have 
to change other than modifying its shaders to use new names. OSG is 
after all a rendering library, so I think we can assume most apps will 
use this functionality as a bare minimum.


After that we can decide whether we want to keep the current wrapping of 
fixed-pipeline state (for example osg::Fog) and have it set uniforms 
when needed (say int osg_Fog_Type --> FOG_LINEAR, FOG_EXP, FOG_EXP2 
which could be defines; float osg_Fog_start, float osg_Fog_end, float 
osg_Fog_density, vec4 osg_Fog_color for example), or if we want to do it 
some other way. I don't know in what way, but perhaps someone will think 
of some more elegant way.


Since GLSL allows you to define your own structs, perhaps we could do 
something similar to what GLSL 1.2 did, instead of the above. Something 
like:


  struct osg_FogParameters {// From glsl_quickref.pdf, s/gl_/osg_/
vec4  color;
float density;
float start;
float end;
float scale;
  };
  uniform osg_FogParameters osg_Fog;

  ...
  ...
  vec4 fogColor = osg_Fog.color;
  ...
  ...

But as I said above, perhaps someone will have a better idea, as this 
would just basically re-do all the features that GL3 removed...


So I think we have to answer a basic question before we do any actual 
work: Do we want OSG to be like it was before, and basically become a 
GL2 layer over GL3? That would make it easier to use than straight GL3 
for beginners, I think, but it would make OpenGL programming less 
hands-on than straight GL3. Of course, if we do it right we can still 
expose all the GL3 code paths through a thin layer like was done for 
GL2, so people who wanted to use all the freedom and generality of GL3 
could still do so. But OSG would become a good solution for people who 
wanted an easier way of doing graphics programming than the "programming 
without a safety net" model that GL3 offers. I personally think this is 
a great opportunity for OSG to position itself as a great solution that 
offers all the power of OpenGL 3 but with a gentler learning curve.


What do you think?

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] offscreen rendering

[Harash Sharma]

Hi Rabbi,

This is my first response, I myself am a newbi, so the more experienced may 
kindly correct.
You have not set the camera manipulator for the viewer class. Calling 
viewer.run() automatically creates a default trackball manipulator object and 
sets it as the manipulator. The same does not happen in this case. Just try 
setting the appropriate manipulator.

Bye 

Harash




From: Rabbi Robinson 
To: osg-users@lists.openscenegraph.org
Sent: Monday, August 10, 2009 11:55:24 PM
Subject: Re: [osg-users] offscreen rendering

Hi,

Here is what I got so far.

osgViewer::Viewer viewer;
//graphics context
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->x = 0;
traits->y = 0;
traits->width = image->s();
traits->height = image->t();
traits->red = 8;
traits->green = 8;
traits->blue = 8;
traits->alpha = 8;
traits->depth = 24;
traits->windowDecoration = false;
traits->pbuffer = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;

osg::ref_ptr pbuffer = 
osg::GraphicsContext::createGraphicsContext(traits.get());
if (pbuffer.valid())
{
osg::ref_ptr camera = viewer.getCamera();
camera->setGraphicsContext(pbuffer.get());
camera->setViewport(new osg::Viewport(0,0,image->s(),image->t()));
camera->setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
camera->setDrawBuffer(GL_BACK);
camera->setReadBuffer(GL_BACK);
viewer.realize();
}
else
{
std::cout << "Error cofiguring pbuffer\n";
exit(0);
}

//draw
viewer.setSceneData(geode);
viewer.frame();

It crashes at viewer.frame(), complaining some resource already in use.



Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16051#16051





___
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] osgPPU: ssartest subtle difference

[Anders Backman]

Hi, downloaded latest (svn) osg and osgPPU and ran the ssaotest.I'm not sure
my laptop cope with this, but the result is far from what I expected:

Left is osgviewer temple.ive and right is osgppu_ssao

http://img3.imageshack.us/img3/2299/ssartest.jpg

Only difference is the
background color :-) and a slight shadow frame around the model.
What am I missing here?
I have a Nvidia 9300 which usually work just find with most of the GL
shaders so far, so Im not expecting anything there.

/Anders
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] offscreen rendering

[Rabbi Robinson]

Hi,

Here is what I got so far.

osgViewer::Viewer viewer;
//graphics context
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->x = 0;
traits->y = 0;
traits->width = image->s();
traits->height = image->t();
traits->red = 8;
traits->green = 8;
traits->blue = 8;
traits->alpha = 8;
traits->depth = 24;
traits->windowDecoration = false;
traits->pbuffer = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;

osg::ref_ptr pbuffer = 
osg::GraphicsContext::createGraphicsContext(traits.get());
if (pbuffer.valid())
{
osg::ref_ptr camera = viewer.getCamera();
camera->setGraphicsContext(pbuffer.get());
camera->setViewport(new 
osg::Viewport(0,0,image->s(),image->t()));
camera->setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
camera->setDrawBuffer(GL_BACK);
camera->setReadBuffer(GL_BACK);
viewer.realize();
}
else
{
std::cout << "Error cofiguring pbuffer\n";
exit(0);
}

//draw
viewer.setSceneData(geode);
viewer.frame();

It crashes at viewer.frame(), complaining some resource already in use.



Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16051#16051





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] offscreen rendering

[Rabbi Robinson]

Hi,
What is the example called? I see there are some examples for prerendering. 
That's not what I need. In my case, I only need to do off screen rendering once 
at the beginning of the application for all.

Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16050#16050





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Newb looking for tutorial

[Cory Riddell]

Hi David,

Check out Paul's excellent quick start guide:
  http://www.osgbooks.com/books/osg_qs.html

There's a free downloadable version or you can buy a printed copy.

Cory



David Goering wrote:
> Hey, I have been fooling arround with OpenSceneGraph and OSGART the last few 
> weeks, and have very much benefited from your help so far, so thank you ;)
> Anyhow, I have now successfully added the tracking and video plugin from 
> OSGART and it works nicely, now I was wondering if t here are any good 
> tutorials out there concerning OSG and handling model files.
> For example simple translation, transformation, scaling etc. of loaded model 
> files or adding another model to the scene with a fixed position from another 
> model, just the basics of OSG.
> I have searched arround and found a few things, but maybe some people have 
> some nice tuts that helped them out,
> thanks again,
> David
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=16031#16031
>
>
>
>
>
> ___
> 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] offscreen rendering

[Maxime BOUCHER]

 wrote:
> Hi,
> Can someone show me how to do offscreen rendering? 
> What I have so far is a shader that render the texture on the screen after 
> processing. I would like to render it offscreen and save it as a texture map.
> Any reference will also be appreciated
> 
> Thank you!
> 
> Cheers,
> Rabbi

Hi,

 There is an example about this in the examples folder.
Good luck.

Cheers,


Max

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16048#16048





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] offscreen rendering

[Rabbi Robinson]

Hi,
Can someone show me how to do offscreen rendering? 
What I have so far is a shader that render the texture on the screen after 
processing. I would like to render it offscreen and save it as a texture map.
Any reference will also be appreciated

Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16047#16047





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Vacation reply

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Can we boot this spammer, please?

Jan


bob_holc...@hotmail.com wrote:
> *   Heya,how are you doing recently ? I would like to introduce you a
> very good company which i knew.Their website is*  *www.buangels.com*
>    * .They can offer you all kinds of
> e
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKgFa+n11XseNj94gRAqNGAKDrRxM45biGTes5pOVn3FSSFNf20gCg6TDD
zEBJXQgDquAMMDYoMR0omng=
=UbeJ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderGen and GL3

[Paul Martz]

Hi J-S -- Good discussion. Thanks for responding to my OSG BOF pleas to
start discussing GL3 in osg-users. :-)

I have the start of a NodeVisitor that will change all Geometry classes
to use generic vertex attributes, as well as switch DLs to buffer
objects. See below. I can also set uniform matrix values for the view
and projection matrices in the app main loop.

While this is certainly an incomplete solution, it does allow me to use
GLSL 1.30 shaders without any deprecated functionality. I currently
have a GL3-safe cow running, doing all the transforms, lighting, and
texture coord generation in GLSL 1.30 shaders. (One major piece of
missing functionality is support for any model transforms buried in the
scene graph. But it's a start.)

Ideally, OSG apps should not need to change at all to be compatible
with GL3. However, at this point, it's too early to tell whether this
will be the case or not. With that in mind, I feel that exploring ways
for applications to use OSG in a GL3-safe way is a worthwhile endeavor,
especially for new app development. If there are ways for apps to take
responsibility for using vertex attribs and setting their own uniforms,
we need to research this and make the methods known, so that new
development can use these techniques and avoid any porting headaches
that might otherwise arise in the future.


class MakeGeneric : public osg::NodeVisitor
{
public:
    MakeGeneric()
  : osg::NodeVisitor( osg::NodeVisitor::TRAVERSE_ALL_CHILDREN ) {}
    ~MakeGeneric() {}

    void apply( osg::Geode& geode )
    {
    unsigned int idx;
    for( idx=0; idx
    {
    osg::Drawable* draw = geode.getDrawable( idx );
    draw->setUseDisplayList( false );
    draw->setUseVertexBufferObjects( true );

    osg::Geometry* geom = draw->asGeometry();
    if( geom == NULL ) continue;

    geom->setVertexAttribData( 0,
    osg::Geometry::ArrayData( geom->getVertexArray(),
osg::Geometry::BIND_PER_VERTEX ) );
    geom->setVertexAttribData( 1,
    osg::Geometry::ArrayData( geom->getNormalArray(),
osg::Geometry::BIND_PER_VERTEX ) );
    }
    }

protected:
    const osg::Program& _prog;
};


Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Running the processor between pre-render and main render

[Art Tevs]

Hi Miika,

OK, i was able to run this. Yes, I can see the issue you are speaking about. 
And I think, I understand where the problem is...


> 
> To fix this problem, we can try to add firstProcessor as a child of 
> slaveCamera instead of root, as explained in my previous posts. However, this 
> somehow breaks stage 3, which refuses to render to a texture anymore.
> 

This is also a correct step. If you do so, then you get the correct rendering 
order of PPUs. So the slave camera is rendered first and the master camera 
afterwards. However, as you already pointed out, the frame buffer of the main 
camera is not bound anymore.

I think the problem is, that osgppu uses FBOs without cameras and hence forces 
osg to reset its states, incl. FBOs back, after rendering of PPUs. Now, using 
the scene graph you have in your example application we would get this 
structure:

mainCamera->FBO
|
root
|
+--- scene
|
+--- slaveCamera->FBO -- 1st Processor --- scene
|
+--- 2nd Processor


Although the traverser is rendering the objects in correct order, but it also 
always restores the previous states of the parent after the rendering a 
subgraph. For example if you render objects in the main camera and one of this 
objects uses FBO in its stateset, then after rendering of this object, the FBO 
will be restored back.
However, currently in OSG there is no restore mechanism to restore to the 
correct FBO. So it just restores to FBO 0. I already claimed about that problem 
around year or two ago, because I also wasn't able to solve that issue. I have 
discusse dabout that issue already on hte mailing list, however this was just 
about DrawBuffers.
I do not remember how that discussions ended, so maybe we ended up either in 
"not needed feature" or "do not know how to patch OSG to support this". The 
problem is, that one assumes that FBOs are only used for Cameras, therefor 
there is only a special treatment for that case.

The problem would arrive with any other type of graph, where a node set an FBO 
to something. Because the RenderStage traces which state changes there were 
done, it will also trace that FBO was changed. Hence it will change FBO to its 
global default, when the corresponding node is not rendered anymore. 

So in order to solve that issue, one has to patch OSG to support to restore FBO 
to its previous state and not just to something default. However this seems to 
be harder than its sounds. In deed, as I have stated already previously on the 
mailing list: Restoring to something "baseline specific" (default value) of an 
StateAttribute is not a right way to do it. In most cases this works well, 
however in complex cases it breaks down. 
Maybe I can try to write a patch to oslve it, however this require big changes 
of current scene graph implementation, so that it may introduce just much more 
bugs.

cheers,
art


P.S.

> 
> Anyway, this is my problem of course and I'm not demanding that anyone fix it 
> for me, but I think that having the ability to do this would be very 
> benefical for osgPPU in general. As I mentioned before, osgPPU would be 
> perfectly suited for things such as processing shadow maps or any number of 
> other advanced algorithms, aside for this one little detail.
> 

In deed, I have used PPU not only for post processing, but also for inbetween 
processing. Take a look into this video:
http://www.tevs.eu/project_sigasia08.html
from 3:30 you see a TV screen with some video running on it. This video texture 
was processed by osgPPU to look little bit blueish like in real TVs.
However none of my porjects realy depends on frame coherency, hence I haven't 
took a lot of effort to correct this issue :(

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16044#16044





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Using vertex attributes

[Paul Martz]

Good info, Robert, thanks.

Rather than disrupt the current Geometry implementation, I've been
considering deriving a new class from Drawable called "Geometry3",
which would be very much like the current Geometry class, but would be
GL3-safe. This would mean removing the setVertexPointer,
setNormalPointer, etc., methods, removing all the "slow path" indices
methods, buffer objects on by default, and support for the new
primitive types. I imagine such a class could greatly reduce the length
of the currently 800-line long Geometry::drawImplementation, so maybe
some performance boost there by reducing instruction cache misses, not
to mention simplifying the code.

Rather than a separate class, perhaps we could reimplement Geometry
using a factory design pattern for different rendering APIs, GL1/2,
GL3, GL ES 1.1, GL ES 2.0, etc.

I mention all this because it impacts how vertex attributes would or
would not change. If we were to go with a separate Geometry3 class
(factory pattern or not), we could add the variable name string support
only to the new class, and leave the extant Geometry class interface as
it stands.

All of this is dependent on your plans to move OSG to a plugin back-end
to support multiple APIs. I'm not sure of the design details, but I'd
like to start discussing them. Ideally, the move to support OpenGL 3
would be organized and coherent; if we all decide to tackle this port
with heterogeneous and incompatible mechanisms, it would produce less
than ideal results.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466




Robert Osfield wrote:

  Hi Paul,

On Mon, Aug 10, 2009 at 3:12 AM, Paul Martz wrote:
  
  
Is there no way for an app to associate vertex attrib data with a variable
name string (like Uniforms)? If not, why not? And would you be open to a
code submission that adds this functionality?

  
  
Yes, there is no currently way of associating vertex attrib data with
a variable name string.  This was a deliberate decision based on the
fact that you can't do a query of the name binding within a display
list and still get the correct binding, as the GLSL program can change
independent of the geometries display lists.  The bottom line is
variable name strings for vertex attributes are incompatible with
display lists, which hardwired indices work fine either way.

Fast forward to GL3 and display lists are no longer on the menu, and
one has to use name strings when assigned vertex attributes so both
have one barrier removed and the option to not use name strings
removed from the menu, so we have bite the bullet and go implement
them.  To this we'll probably need to add a string name into the
Geometry::ArrayData structure, and interface into osg::Geometry for
setting it, and internal implementation details for setting up the
binding during Geometry::drawImplementation(..)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgCompute] Problem building osgCompute / osgCuda

[Hansoo Kim]

omdown wrote:
> When I attempt to build osgCompute, I get the following error..  I Googled it 
> and I'm not sure what to do about it...
> 
> 
> Code:
> 
> $ cd osgCompute
> $ cmake . -DCMAKE_BUILD_TYPE=Release
> -- Configuring done
> CMake Error in examples/osgTexDemo/src/CMakeLists.txt:
>  Cannot find source file "S0_0.fsh". Tried extensions .c .C .c++ .cc 
> .cpp
>  .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
> 
> 
> -- Build files have been written to: /home/cdail/Download/osgCompute
> 
> 
> 
> 
> Am I doing something wrong?  I'm following the readme instructions...
> 
> Thanks in advance for any help anyone can offer,
> Chris[/code]



Please refer my latest reply.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=14746#14746





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgCompute] Problem building osgCompute / osgCuda

[Hansoo Kim]

omdown wrote:
> When I attempt to build osgCompute, I get the following error..  I Googled it 
> and I'm not sure what to do about it...
> 
> 
> Code:
> 
> $ cd osgCompute
> $ cmake . -DCMAKE_BUILD_TYPE=Release
> -- Configuring done
> CMake Error in examples/osgTexDemo/src/CMakeLists.txt:
>  Cannot find source file "S0_0.fsh". Tried extensions .c .C .c++ .cc 
> .cpp
>  .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
> 
> 
> -- Build files have been written to: /home/cdail/Download/osgCompute
> 
> 
> 
> 
> Am I doing something wrong?  I'm following the readme instructions...
> 
> Thanks in advance for any help anyone can offer,
> Chris[/code]



Add environment variable OSGCOMPUTE_FILE_PATH to the folder which contains the 
osgCompute data (e.g., c:\osgCompute-Data).


VR Lab, Konkuk University, South Korea

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=14797#14797





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT with FBO then copy Texture to image using PBO results in blank image.

[Steven Powers]

art wrote:
> Hi Steven,
> 
> 
> > 
> > I've tried assigning the attached texture (without running the callback) to 
> > a quad in the scene and it is still blank.
> > 
> 
> 
> If your RTT texture is black without any post processing, so maybe you forgot 
> to add any scene below your RTT camera in the scene graph? For example your 
> scene graph can look like this:
> 
> root
> |
> +--- rtt camera -- (scene)
> |
> +--- main camera -- (scene)
> 
> 
> Also check if your transformations of the rtt camera are correct. It happens 
> sometimes, that one just don't see anything in the RTT cameras, because rtt 
> camera is just looking in wrong direction.
> 
> Oh, also to copy your processed data into an image, there exists already 
> classes in osg, which can do this. See osg::PixelBufferObject or 
> osg::PixelBufferDataObject. Also for any processing of your textures, it is 
> easier to use osgPPU for that task ;)
> 
> cheers,
> art



unfortunately this is not the case. If I attach an osg::Image , rather than an 
osg::Texture, to the camera I will get the correct frame buffer output. Of 
course the work done by the third party software is done after the osg::Image 
is populated by OSG.

Any other ideas?

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16040#16040





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgShadow and nested RTT-cams

[Felix Heide]

Hi Wojciech,

Thank you very much ! I will try this !

Cheers,
Felix

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16039#16039





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Vacation reply

[bob_holcomb]

   Heya,how are you doing recently ? I would like to introduce you a very good company which i knew.Their website is  www.buangels.com   .They can offer you all kinds of electronical products which you need like laptops ,gps ,TV LCD,cell phones,ps3,MP3/4,motorcycles  etcPlease take some time to have a check ,there must be somethings you 'd like to purchase .Their contact  email:buang...@188.com ,MSN: buang...@hotmail.com .












Hope you have a good mood in shopping from their company !Regards___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Z-buffer transparency / Alpha

[Maxime BOUCHER]

Hi,


Ulrich Hertlein wrote:
> Hi Maxime,
> 
> On 7/08/09 12:02 PM, Maxime BOUCHER wrote:
> 
> > Ulrich Hertlein wrote:
> > 
> > > Hi Maxime, I'm extremely irritated by what you write and maybe I'm not 
> > > the only one.
> > > 
> > 
> > I am very sorry, please apologize. Maybe could you tell me why so that I 
> > won't do it
> > again.
> > 
> 
> No need to apologize.  (I meant 'irritated' as 'confused', not annoyed or 
> angry, just  in 
> case that's how you understood it; English can be fuzzy... :-}
> 

Well, thank you, I misunderstood you, but I also know I'm quite a noob compared 
to most of you, and I understand my noob's questions can be irritating.


Ulrich Hertlein wrote:
> 
> You have to keep in mind that the people on the mailing list have absolutely 
> no idea what 
> you're trying to achieve and what the problem is.  You alone have that 
> information so it 
> helps to give as much detail as possible when posting a question.
> 
> What are you trying to accomplish and how do you approach it?  What is your 
> shader doing?
> 

What I do:
 It is a projective texture mapping.
I put a prerending viewer in the scene given its orientation and position.
I attach to its DEPTH_BUFFER a depth image. I do a frame() on the prerender to 
fill the depth image.
 A color image is declared to check the prerender orientation if needed.

Code:

_root_stateset = _root->getOrCreateStateSet();

_depth = new Image();
_color = new Image();

_depth->allocateImage(_imWidthHeight->x(), _imWidthHeight->y(), 1, 
GL_DEPTH_COMPONENT, GL_FLOAT);
_color->allocateImage(_imWidthHeight->x(), _imWidthHeight->y(), 1, GL_RGBA, 
GL_UNSIGNED_BYTE);

_prerender->getCamera()->attach(Camera::DEPTH_BUFFER, _depth.get(), 0, 0);
_prerender->getCamera()->attach(Camera::COLOR_BUFFER, _color.get(), 0, 0);

_texdepth = new Texture2D(_depth.get());
_root_stateset->setTextureAttribute(_depth_unit, _texdepth.get());

_texcolor = new Texture2D(_color.get());
_root_stateset->setTextureAttribute(_color_unit, _texcolor.get());

_tex = new Texture2D(_img.get());
_root_stateset->setTextureAttribute(_tex_unit, _tex.get());




 Then I attach to the root node a shader and  run the rendering viewer.
The shader computes the projection of each fragment in the image space of the 
projective camera (i.e. the prerender).
 If the fragment is out of bound  then I texture it with it's original texture.
 If the fragment distance from the projective camera is different from the one 
stored in the Z-buffer  then I texture it with its original texture too.
 Else, I texture the fragment with its corresponding set of pixels 
(interpolation done by hardware) in the image to project.

It is quite clear in the code (and I don't post it in order to be debugged, 
just to be clearer).

Vertex shader:

Code:

varying vec4 coord;

void main()
{
coord = gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = ftransform();
}



Fragment shader:

Code:

uniform sampler2D tex;
//uniform sampler2D depthtex;
uniform sampler2DShadow depthtex;
uniform sampler2D originaltexture;
uniform sampler2D colortex;

uniform mat4 WorldToCam;
uniform mat4 CamToImage;
uniform mat4 correction;
uniform vec3 camposition;

uniform float znear;
uniform float zfar;
uniform float uptozbits;

uniform float imagewidth;
uniform float imageheight;

varying vec4 coord;
varying float intensity;

void normalizeW( inout vec4 vec )
{
vec = vec / vec.w;
return;
}

void normalizeZ( inout vec4 vec )
{
vec = vec / vec.z;
return;
}

float zbuffer_precision(float Z) //*** Used to compute the error of Z buffer
{
float b = znear * zfar / (znear-zfar);
float res = ( b / ( (b/Z) - 1.0/uptozbits ) ) - Z;
return abs(res);
}

void main()
{

vec4 camspace = WorldToCam * coord;
normalizeW(camspace);

if (camspace.z > 0.0)
{
gl_FragColor = texture2D(originaltexture, gl_TexCoord[0].st);
return;
}

float Z = -camspace.z;

vec4 imspace = CamToImage * correction * camspace;
normalizeZ(imspace);

if ( imspace.x < 0.0 | imspace.x > imagewidth | imspace.y < 0.0 | imspace.y > 
imageheight )
{ 
gl_FragColor = texture2D(originaltexture, gl_TexCoord[0].st);
return;
}

//float uncorrected_z = texture2D( depthtex, vec2(imspace.x/imagewidth, 
1-imspace.y/imageheight) );
float uncorrected_z = shadow2D( depthtex, vec3(imspace.x/imagewidth, 
1-imspace.y/imageheight, 1.0) ).r;

float corrected_z = znear*zfar / (zfar - uncorrected_z*(zfar-znear));

if (uncorrected_z < 0.0 | uncorrected_z > 1.0) //*** Error case
{
gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);
return;
}

if(false) //*** Used to display a kind of real distance
{
gl_FragColor = vec4(Z/15, Z/15, Z/15, 1.0);
return;
}

if(true) //*** Used to display distance stored in the Z-buffer
{
vec4 color = vec4(uncorrected_z, uncorrected_z, uncorrected_z, 1.0);
gl_FragColor = color;
return;
}

if (false) //*** Used to display the color image attached to the color_buffer
{
gl_FragColor = texture2D( colortex, vec2(imspace.x/imagewidth, 
1-imspace.y/imageheight) );
return;
}


float delta = zbuffer_p

Re: [osg-users] Infinite Grid in OSG

[Andrew Thompson]

Hi,

Well, that was simple


Code:

virtual osg::BoundingBox computeBound() const
{
   osg::BoundingBox bbox;

   // Compute the min/max X and Y values for the grid
   float miny = (m_posY-(m_vHeight/2*m_zoom));
   float maxy = (m_posY+(m_vHeight/2*m_zoom));
   float minx = (m_posX-(m_vWidth/2*m_zoom));
   float maxx = (m_posX+(m_vWidth/2*m_zoom));

   bbox.set(minx, miny, -0.1, maxx, maxy, 0.1);

   return bbox;
}




That fixed it, no more clipping. 

Thank you!
Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16036#16036





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Infinite Grid in OSG

[Simon Hammett]

The clipping you are seeing is probably due to osg's computation of
the near and far clipping planes.
You'll need to implement computeBound so osg knows about your object.
Have a look in ShapeDrawable.cpp

2009/8/10 Andrew Thompson :
> Hi Chris,
>
> Thanks for the heads up, I was digging around and found the 
> drawImplementation method in Drawable myself so decided to give it a go. 
> However I've had less than spectacular results!
>
> My first test was to take the code from ShapeDrawable that draws a box. Here 
> it is for completeness sake
>
>
> Code:
>
>
> void drawImplementation(osg::RenderInfo & renderInfo) const
> {
>   // evaluate hints
>   bool createBody = true;
>   bool createTop = true;
>   bool createBottom = true;
>
>   float dx = 3;
>   float dy = 3;
>   float dz = 3;
>
>   glColor3ub(60,60,60);
>   glPushMatrix();
>
>   glTranslatef(10,10,10);
>
>   glBegin(GL_QUADS);
>
>   if (createBody) {
>      // -ve y plane
>      glNormal3f(0.0f,-1.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,-dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,-dy,dz);
>
>      // +ve y plane
>      glNormal3f(0.0f,1.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      // +ve x plane
>      glNormal3f(1.0f,0.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,-dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>
>      // -ve x plane
>      glNormal3f(-1.0f,0.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,-dy,dz);
>   }
>
>   if (createTop) {
>      // +ve z plane
>      glNormal3f(0.0f,0.0f,1.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,-dy,dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,-dy,dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>   }
>
>   if (createBottom) {
>      // -ve z plane
>      glNormal3f(0.0f,0.0f,-1.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,dy,-dz);
>   }
>
>   glEnd();
>   glPopMatrix();
> }
>
>
>
>
>
> This results in a gray box drawn at the location 10,10,10 of size 3,3,3.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpBefore.png ]
>
> However, if I add other objects to my scene, then the box renders incorrectly.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpAfter.png ]
>
> At this point the subgraph looks like this, the additional objects from the 
> position attitude transforms (labelled PAT) onwards are added when the cones 
> are in the scene.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/Subgraph.png ]
>
> Another example, what I actually want to do is draw a subdividing grid that 
> extends to the horizon. The code for this (at present) is included below
>
>
> Code:
>
> void drawImplementation(osg::RenderInfo & renderInfo) const
> {
>   currentState->applyMode(GL_LIGHTING, false);
>   glColor3ub(60,60,60);
>
>   //render floor grid
>   glLineWidth(1.0f);
>   glBegin(GL_LINES);
>
>   // Compute the Z location of the grid
>   int zg = (int)0;
>   int ystep = 100;
>   int xstep = 100;
>
>   // Compute the Y-Step depending on the current zoom factor
>   if(m_zoom < 1.5)
>      ystep = xstep = 10;
>   if(m_zoom < 0.8)
>      ystep = xstep = 5;
>   if(m_zoom < 0.4)
>      ystep = xstep = 2;
>   if(m_zoom < 0.2)
>      ystep = xstep = 1;
>
>   // Compute the min/max X and Y values for each line
>   float miny = (m_posY-(m_vHeight/2*m_zoom));
>   float maxy = (m_posY+(m_vHeight/2*m_zoom));
>   float minx = (m_posX-(m_vWidth/2*m_zoom));
>   float maxx = (m_posX+(m_vWidth/2*m_zoom));
>
>   // Draw lines in the Y direction
>   for(int yg = (int)(miny - ((int)miny%ystep)); yg <= (int)(maxy - 
> ((int)maxy%ystep)); yg+=ystep){
>      glColor3ub(60,60,60);
>      if(yg%10 == 0){
>         glEnd();
>         glColor3ub(100,100,100);
>         glLineWidth(2.0f);
>         glBegin(GL_LINES);
>      }
>      if(yg%100 == 0)
>         glColor3ub(180,180,180);
>      glVertex3f(minx, (GLfloat)yg, (GLfloat)zg);
>      glVertex3f(maxx, (GLfloat)yg, (GLfloat)zg);
>      if(yg%10 =

Re: [osg-users] Newb looking for tutorial

[Rahul Jain]

Hi David,

Did you check out this link 
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials.


cheers
RJ

David Goering wrote:

Hey, I have been fooling arround with OpenSceneGraph and OSGART the last few 
weeks, and have very much benefited from your help so far, so thank you ;)
Anyhow, I have now successfully added the tracking and video plugin from OSGART 
and it works nicely, now I was wondering if t here are any good tutorials out 
there concerning OSG and handling model files.
For example simple translation, transformation, scaling etc. of loaded model 
files or adding another model to the scene with a fixed position from another 
model, just the basics of OSG.
I have searched arround and found a few things, but maybe some people have some 
nice tuts that helped them out,
thanks again,
David

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16031#16031





___
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] Infinite Grid in OSG

[Andrew Thompson]

Hi Chris, 

Thanks for the heads up, I was digging around and found the drawImplementation 
method in Drawable myself so decided to give it a go. However I've had less 
than spectacular results!

My first test was to take the code from ShapeDrawable that draws a box. Here it 
is for completeness sake


Code:


void drawImplementation(osg::RenderInfo & renderInfo) const
{
   // evaluate hints
   bool createBody = true;
   bool createTop = true;
   bool createBottom = true;

   float dx = 3;
   float dy = 3;
   float dz = 3; 

   glColor3ub(60,60,60);
   glPushMatrix();

   glTranslatef(10,10,10);

   glBegin(GL_QUADS);

   if (createBody) {
  // -ve y plane
  glNormal3f(0.0f,-1.0f,0.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(-dx,-dy,dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(-dx,-dy,-dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(dx,-dy,-dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(dx,-dy,dz);

  // +ve y plane
  glNormal3f(0.0f,1.0f,0.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(dx,dy,dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(dx,dy,-dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(-dx,dy,-dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(-dx,dy,dz);

  // +ve x plane
  glNormal3f(1.0f,0.0f,0.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(dx,-dy,dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(dx,-dy,-dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(dx,dy,-dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(dx,dy,dz);

  // -ve x plane
  glNormal3f(-1.0f,0.0f,0.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(-dx,dy,dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(-dx,dy,-dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(-dx,-dy,-dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(-dx,-dy,dz);
   }

   if (createTop) {
  // +ve z plane
  glNormal3f(0.0f,0.0f,1.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(-dx,dy,dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(-dx,-dy,dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(dx,-dy,dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(dx,dy,dz);
   }

   if (createBottom) {
  // -ve z plane
  glNormal3f(0.0f,0.0f,-1.0f);

  glTexCoord2f(0.0f,1.0f);
  glVertex3f(dx,dy,-dz);

  glTexCoord2f(0.0f,0.0f);
  glVertex3f(dx,-dy,-dz);

  glTexCoord2f(1.0f,0.0f);
  glVertex3f(-dx,-dy,-dz);

  glTexCoord2f(1.0f,1.0f);
  glVertex3f(-dx,dy,-dz);
   }

   glEnd();
   glPopMatrix();
}





This results in a gray box drawn at the location 10,10,10 of size 3,3,3. 

[Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpBefore.png ]

However, if I add other objects to my scene, then the box renders incorrectly. 

[Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpAfter.png ]

At this point the subgraph looks like this, the additional objects from the 
position attitude transforms (labelled PAT) onwards are added when the cones 
are in the scene. 

[Image: http://i137.photobucket.com/albums/q217/andyb1979/Subgraph.png ]

Another example, what I actually want to do is draw a subdividing grid that 
extends to the horizon. The code for this (at present) is included below


Code:

void drawImplementation(osg::RenderInfo & renderInfo) const
{
   currentState->applyMode(GL_LIGHTING, false);
   glColor3ub(60,60,60);

   //render floor grid
   glLineWidth(1.0f);
   glBegin(GL_LINES);

   // Compute the Z location of the grid
   int zg = (int)0;
   int ystep = 100;
   int xstep = 100;

   // Compute the Y-Step depending on the current zoom factor
   if(m_zoom < 1.5)
  ystep = xstep = 10;
   if(m_zoom < 0.8)
  ystep = xstep = 5;
   if(m_zoom < 0.4)
  ystep = xstep = 2;
   if(m_zoom < 0.2)
  ystep = xstep = 1;

   // Compute the min/max X and Y values for each line
   float miny = (m_posY-(m_vHeight/2*m_zoom));
   float maxy = (m_posY+(m_vHeight/2*m_zoom));
   float minx = (m_posX-(m_vWidth/2*m_zoom));
   float maxx = (m_posX+(m_vWidth/2*m_zoom));

   // Draw lines in the Y direction
   for(int yg = (int)(miny - ((int)miny%ystep)); yg <= (int)(maxy - 
((int)maxy%ystep)); yg+=ystep){
  glColor3ub(60,60,60);
  if(yg%10 == 0){
 glEnd();
 glColor3ub(100,100,100);
 glLineWidth(2.0f);
 glBegin(GL_LINES);
  }
  if(yg%100 == 0)
 glColor3ub(180,180,180);
  glVertex3f(minx, (GLfloat)yg, (GLfloat)zg);
  glVertex3f(maxx, (GLfloat)yg, (GLfloat)zg);
  if(yg%10 == 0){
 glEnd();
 glLineWidth(1.0f);
 glBegin(GL_LINES);
  }
   }

   // Draw lines in the X direction
   for(int xg = (int)(minx - ((int)minx%xstep)); xg <= (int)(maxx - 
((int)maxx%xstep)); xg+=xstep){
  glColor3ub(60,60,60);
  if(xg%10 == 0){
 glEnd();
 glColor3ub(100,100,100);
 glLineWidth(2.0f);
 glBegin(GL_LINES);
  }
  if(xg%100 == 0)
 glColor3ub(180,18

[osg-users] Newb looking for tutorial

[David Goering]

Hey, I have been fooling arround with OpenSceneGraph and OSGART the last few 
weeks, and have very much benefited from your help so far, so thank you ;)
Anyhow, I have now successfully added the tracking and video plugin from OSGART 
and it works nicely, now I was wondering if t here are any good tutorials out 
there concerning OSG and handling model files.
For example simple translation, transformation, scaling etc. of loaded model 
files or adding another model to the scene with a fixed position from another 
model, just the basics of OSG.
I have searched arround and found a few things, but maybe some people have some 
nice tuts that helped them out,
thanks again,
David

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16031#16031





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] global bounding sphere with autotransformed objects

[Gianluca Natale]

Hi All.
I have this problem, with OSG 2.8.0.

 

In my scenegraph there is some object attached as a child of an
Autotransform matrix
(I need to keep its size constant on the screen, wherever is the camera).

I have also to fit the model in the screen, using the global bounding sphere
of the model.
I've seen that the bounding sphere is computed during the rendering
traversal.

And that the bounding sphere of "auto-transformed" objects changes as the
camera position
changes, while the bounding sphere of the other objects is constant. This is
what I expected, since
the size on the screen must be constant.



So, I thought that I can compute the global bounding sphere of my model by
multiple iterative redraws,

until the global bounding sphere at step n is almost the same as that at
step n-1.
And it works.

 

Is there a way to update the bounding sphere of autotransformed object
without redrawing?
I mean, I would need to show directly the model fit in the screen, without
showing the user all the single steps.
Or, at least, may I avoid the swap of back and front buffers at the end of
redraw? In this way I could
make the back and front buffers be swapped only at the end of fit.

 

Thanks in advance

Gianluca Natale

 

 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderGen and GL3

[Robert Osfield]

Hi Paul,

ShaderGen was written for GL2 and OSG-2.x, it doesn't provide a first
step at looking towards GL3, but in the context of OSG-2.x, look at it
as a first step.

Robert.

On Sat, Aug 8, 2009 at 9:39 PM, Paul Martz wrote:
> Hi all -- I've finally had a chance to review the ShaderGen code. If I
> understand correctly, this was added as a step towards eventual support for
> OpenGL 3. However, I'm surprised by the OpenGL 2 / GLSL 1.20 nature of the
> shader code, specifically the extensive dependency on built-in uniforms and
> predefined vertex attributes that were deprecated with OpenGL 3 / GLSL 1.30
> -- even use of ftransform().
>
> Was the author assuming the code would be ported to OpenGL 3 / GLSL 1.30 in
> the future? Or was the author assuming that the host would set up uniforms
> and vertex attributes with names identical to the old GLSL 1.20 uniform and
> vertex attribute names (that would be a mistake in my opinion, as uniforms
> and vertex attributes starting with "gl_" are reserved)? Or have a simply
> misunderstood the point of this code?
>
> Thanks.
> --
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> +1 303 859 9466
>
> ___
> 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] [osgPPU] Running the processor between pre-render and main render

[Miika Aittala]

Ok, here's a little example (code is attached). Sorry if it's a bit contrived, 
I couldn't think of anything simple but illustrative. Basically it renders a 
cylinder with the following stages:

1) Render the cylinder to a texture from slaveCamera
2) Process the texture from stage 1 with firstProcessor, inverting the colors
3) Render the cylinder to a texture from viewer->camera, this time using the 
result of stage 2 as a texture
4) Process the texture from stage 3 with secondProcessor, which makes the image 
look wavy

The problem is that instead of this ordering, we get 1-3-2-4, which means that 
the pre-render result is always from the previous frame. If you compile and run 
the program, you'll notice that this causes a green fringe at the edges of the 
cylinder when you make it move (because the background color of the texture is 
green). Here's an image of this whole thing:

http://a.imagehost.org/view/0333/osgppukuva

To fix this problem, we can try to add firstProcessor as a child of slaveCamera 
instead of root, as explained in my previous posts. However, this somehow 
breaks stage 3, which refuses to render to a texture anymore.

To see the original problem, run the program and move the object with the 
mouse. This should give the ugly green borders. Comment out the first line 
(#define) of the code to see how it breaks when we attempt to alter the 
rendering order.

Anyway, this is my problem of course and I'm not demanding that anyone fix it 
for me, but I think that having the ability to do this would be very benefical 
for osgPPU in general. As I mentioned before, osgPPU would be perfectly suited 
for things such as processing shadow maps or any number of other advanced 
algorithms, aside for this one little detail.


Thanks,

Miika

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16027#16027



#define ATTACH_PROCESSOR_TO_ROOT// If this is defined, do the typical 
attachment to scene root - comment out to attempt to fix the render order 
(which goes wrong)

#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 


int main()
{
// Set up the viewer
osgViewer::Viewer viewer;
unsigned int screenWidth;
unsigned int screenHeight;

osg::GraphicsContext::getWindowingSystemInterface()->getScreenResolution(osg::GraphicsContext::ScreenIdentifier(0),
 screenWidth, screenHeight);
unsigned int windowWidth = 640;
unsigned int windowHeight = 480;
viewer.setUpViewInWindow((screenWidth-windowWidth)/2, 
(screenHeight-windowHeight)/2, windowWidth, windowHeight);
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);

// Add root node with two groups: rttScene will be rendered by 
slaveCamera and processed, mainScene will be rendered by osgViewer's camera
osg::Group* root = new osg::Group();
osg::Group* rttScene = new osg::Group();
osg::Group* mainScene = new osg::Group();

// Add something to see, same to both scenes
osg::Geode* geode = new osg::Geode();
geode->addDrawable(new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(4.4f,0.0f,0.0f),1.0f,1.4f)));

rttScene->addChild(geode);
mainScene->addChild(geode);

root->addChild(mainScene);


// Create the texture to render to...
osg::Texture2D* slaveCameraTexture = new osg::Texture2D;
{
slaveCameraTexture->setTextureSize(640, 480);
slaveCameraTexture->setInternalFormat(GL_RGBA);

slaveCameraTexture->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);

slaveCameraTexture->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
}
// and the RTT camera
osg::Camera* slaveCamera = new osg::Camera();
{
slaveCamera->setClearMask(GL_COLOR_BUFFER_BIT | 
GL_DEPTH_BUFFER_BIT);
slaveCamera->setClearColor(osg::Vec4(1,0,1,1));
slaveCamera->setViewport(new osg::Viewport(0,0,640,480));
slaveCamera->setReferenceFrame(osg::Transform::RELATIVE_RF);
slaveCamera->setRenderOrder(osg::Camera::PRE_RENDER);
slaveCamera->attach(osg::Camera::COLOR_BUFFER0, 
slaveCameraTexture);

slaveCamera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);

root->addChild(slaveCamera);
slaveCamera->addChild(rttScene);
}

// Set up a simple osgPPU processor which inverts the input image's 
colors
osg::Texture* rttTexture;
osgPPU::Processor *firstProcessor = new osgPPU::Processor;
{
firstProcessor->setCamera(slaveCamera);

osgPPU::UnitCameraAttachmentBypass* unitCam = new 
osgPPU::UnitCameraAttachmentBypass();
  

Re: [osg-users] Using vertex attributes

[Robert Osfield]

Hi Paul,

On Mon, Aug 10, 2009 at 3:12 AM, Paul Martz wrote:
> Is there no way for an app to associate vertex attrib data with a variable
> name string (like Uniforms)? If not, why not? And would you be open to a
> code submission that adds this functionality?

Yes, there is no currently way of associating vertex attrib data with
a variable name string.  This was a deliberate decision based on the
fact that you can't do a query of the name binding within a display
list and still get the correct binding, as the GLSL program can change
independent of the geometries display lists.  The bottom line is
variable name strings for vertex attributes are incompatible with
display lists, which hardwired indices work fine either way.

Fast forward to GL3 and display lists are no longer on the menu, and
one has to use name strings when assigned vertex attributes so both
have one barrier removed and the option to not use name strings
removed from the menu, so we have bite the bullet and go implement
them.  To this we'll probably need to add a string name into the
Geometry::ArrayData structure, and interface into osg::Geometry for
setting it, and internal implementation details for setting up the
binding during Geometry::drawImplementation(..)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 2.8 release date?

[Robert Osfield]

On Sun, Aug 9, 2009 at 10:42 PM, Paul Martz wrote:
> Ha! :-) Wiki lets me log in now (thanks Jose-Luis), but I guess this is one
> of the special pages that general users can't edit. So it's still up to you,
> Robert. :-)

Now fixed to read 2009.  I also need to update the details to point to
the 2.8.2 release.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgShadow and nested RTT-cams

[Wojciech Lewandowski]

Hi Felix,

Felix Heide wrote:

no one has an idea ?
  
Unfortunately, I don't have much to offer as I have no access to OSG 
source currently. But my intuition tells me that your case was not 
widely tested. I think you may have better chances when you setup your 
RTT rendering as separate slave camera instead of nested in the graph 
cam. See  osg hud examples on how to setup RTT cam as osgViewer slave (I 
don't remeber exactly which one). Hope this helps


Wojtek Lewandowski

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org