[osg-users] osgManipulator Problem
Hi All: when i use the osgManipulator Model, I want to realize a new function with the osgManipulator Dragger::dispatch , but I find it not with virtual , so the function can not to rewrite, I hope the function can have the virtual attribute, so we can realize other function Thank you for help Liu zhi yu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Extend a Line
Hi, I am making a very simple flight simulator and have a plane location and a second chase plane location I do not want the chase plane to get too close to the target plane. I also do not want it to get too far away from the target plane. How do I extend a line in 3D space? If I can extend the points below I can always have the chase plane a fixed distance behind targetPos = 3, 3, 3 * trailPos = 6, 7, 3 Thank you for help to a simple question Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49758#49758 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawable & GLSL
On Tue, 2012-09-04 at 19:15 -0400, Jean-Sébastien Guay wrote:
> Hi Jeremy,
>
> In the past I've done similar low-level 2-pass rendering in a Drawable,
> by doing as Robert suggests. Apply one stateset, draw, apply another,
> draw again (same or different geometry).
>
> A Program is just state, so you need to draw something in between
> setting different Programs. Otherwise setting the first Program has no
> (visible) effect. I know it sounds obvious but I thought I'd just throw
> that out there so there's no ambiguity :-)
>
> Hope this helps,
Hey Paul. :)
It's not simply an issue of setting two similar state attributes in
sequence; the NV_path_rendering API is different enough in that for the
stroke you may want to use a shader and for the fill you may want to
reset the state and use whatever fixed state was available previously,
which is why I've had the issues. HOWEVER, I could just implement
everything as shaders anyways.
What I really seem to need is like a State::save(), State::restore()
kind of thing...
> J-S
>
>
> On 04/09/2012 1:23 PM, Jeremy Moles wrote:
> > On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
> >> Doesn't a Drawable's state get applied prior to the call to
> >> Drawable::drawImplementation()? If so, you could just put the _program in
> >> your
> >> Drawable's StateSet?
> > I'm working on a nodekit for NV_path_rendering, which takes an "as of
> > yet unseen" approach to rendering; new go OpenGL, at any rate. :)
> >
> > They call it the "Stencil then Cover" approach, and like most 2D vector
> > drawing libraries, there is a notion of both STROKING _and_ FILLING. In
> > order to support arbitrary shading on both the affected stroke fragments
> > and affected fill fragments, I need to be able to potentially set two
> > different shaders during a single drawable drawImplementation.
> >
> > Now, having said that--which I potentially should have mentioned in the
> > first email--does that change any advice you might have? :)
> >
> > (Thanks for the response, btw... good info.)
> >
> >> It's easy to verify that things are happening in the right order using a
> >> debugger with breakpoints set at your drawImplementation() and also at
> >> Program::apply().
> >>
> >> If it doesn't happen as I describe above, then I believe what you're doing
> >> below
> >> is the most robust, as that code would work with all other rendering in the
> >> scene graph, both shader and non-shader rendering.
> >>
> >> Honestly it's been too long since I played at this level. But I seem to
> >> recall
> >> that the difference between:
> >> _program->apply( state );
> >> and
> >> state->apply( _program.get() );
> >> is that the latter tracks the currently bound program, doesn't bother to
> >> apply
> >> it if it's already in use, and would probably allow you to remove the call
> >> to
> >> setLastAppliedProgramObject(0).
> >> -Paul
> >>
> >>
> >> On 9/4/2012 9:58 AM, Jeremy Moles wrote:
> >>> I am creating a custom Drawable that needs to push a Fragment Shader
> >>> into the current rendering state and then, after a single extension
> >>> call, subsequently remove this shader from the state.
> >>>
> >>> I have some code I noodled through to make this work, but I feel like
> >>> there is probably a better way. It goes something like this:
> >>>
> >>>
> >>>
> >>> drawImplementaion(RenderInfo& ri) {
> >>> State* state = ri.getState();
> >>> unsigned int contextID = state->getContextID();
> >>>
> >>> _program.apply(state);
> >>>
> >>> myExtensions->doMycall();
> >>>
> >>> GL2Extensions::Get(contextID, true)->glUseProgram(0);
> >>>
> >>> state->setLastAppliedProgramObject(0);
> >>> }
> >>>
> >>>
> >>>
> >>> Like I said above, this "works", but I feel like there is probably a
> >>> cleaner way to achieve what I want. Note that _program is a ref_ptr to a
> >>> properly create osg::Program object, since I certainly do NOT want to
> >>> recreate all the goodness it provides. :)
> >>>
> >>> Any API advice?
> >>>
> >>> ___
> >>> 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawable & GLSL
Hi Jeremy,
In the past I've done similar low-level 2-pass rendering in a Drawable,
by doing as Robert suggests. Apply one stateset, draw, apply another,
draw again (same or different geometry).
A Program is just state, so you need to draw something in between
setting different Programs. Otherwise setting the first Program has no
(visible) effect. I know it sounds obvious but I thought I'd just throw
that out there so there's no ambiguity :-)
Hope this helps,
J-S
On 04/09/2012 1:23 PM, Jeremy Moles wrote:
On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
Doesn't a Drawable's state get applied prior to the call to
Drawable::drawImplementation()? If so, you could just put the _program in your
Drawable's StateSet?
I'm working on a nodekit for NV_path_rendering, which takes an "as of
yet unseen" approach to rendering; new go OpenGL, at any rate. :)
They call it the "Stencil then Cover" approach, and like most 2D vector
drawing libraries, there is a notion of both STROKING _and_ FILLING. In
order to support arbitrary shading on both the affected stroke fragments
and affected fill fragments, I need to be able to potentially set two
different shaders during a single drawable drawImplementation.
Now, having said that--which I potentially should have mentioned in the
first email--does that change any advice you might have? :)
(Thanks for the response, btw... good info.)
It's easy to verify that things are happening in the right order using a
debugger with breakpoints set at your drawImplementation() and also at
Program::apply().
If it doesn't happen as I describe above, then I believe what you're doing below
is the most robust, as that code would work with all other rendering in the
scene graph, both shader and non-shader rendering.
Honestly it's been too long since I played at this level. But I seem to recall
that the difference between:
_program->apply( state );
and
state->apply( _program.get() );
is that the latter tracks the currently bound program, doesn't bother to apply
it if it's already in use, and would probably allow you to remove the call to
setLastAppliedProgramObject(0).
-Paul
On 9/4/2012 9:58 AM, Jeremy Moles wrote:
I am creating a custom Drawable that needs to push a Fragment Shader
into the current rendering state and then, after a single extension
call, subsequently remove this shader from the state.
I have some code I noodled through to make this work, but I feel like
there is probably a better way. It goes something like this:
drawImplementaion(RenderInfo& ri) {
State* state = ri.getState();
unsigned int contextID = state->getContextID();
_program.apply(state);
myExtensions->doMycall();
GL2Extensions::Get(contextID, true)->glUseProgram(0);
state->setLastAppliedProgramObject(0);
}
Like I said above, this "works", but I feel like there is probably a
cleaner way to achieve what I want. Note that _program is a ref_ptr to a
properly create osg::Program object, since I certainly do NOT want to
recreate all the goodness it provides. :)
Any API advice?
___
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
--
__
Jean-Sebastien Guay jean_...@videotron.ca
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] Program attribute cannot me removed
Hello. I have used this: stateset->setAttributeAndModes(new osg::Program()); and it worked. But why the other way didnt work ? thnx. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Program attribute cannot me removed
Hello. I face a problem with a program attribute. I enable the program using this: osg::StateSet* stateset = model_node->getOrCreateStateSet(); stateset->setAttributeAndModes( program, osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE ); and i disable it using: osg::StateSet* stateset = model_node->getOrCreateStateSet(); stateset->removeAttribute(osg::StateAttribute::PROGRAM); Before the return viewer.run() , enable and disable operations work fine. But after that, only enable works. I use 2 buttons to enable and disable program in run time. what do i do wrong ? thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawable & GLSL
Hi Jeremy,
It should be possible to do a
drawImplementation(..)
{
state.apply(stateSetOne);
// do stuff
state.apply(stateSetTwo);
// do more stuff
}
I'm not 100% sure what will happen with the progress of draw traversal
w.r.t how the drawable StateSet if any is applied and then later
assumed to be applied by other state calls. I think it will probably
work out OK though so try it, and if something breaks then considering
adding an extra state.apply(drawwablesStateSet) or a perhaps a state
dirty.
This is something we can workout if required though, try the simplest
thing first then if need be investigate more complicated routes...
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] QT and OSG on separate X screens
Hi, I'm trying to make QT app with osg on separate X screens under ubuntu 12.04 on nvidia 304 with qt 4.8.1. Compositeviewer with one view on first X and second view on second X works perfect. But I need to make render window in QT widget on first screen and fullscreen osg window on second screen. I tried various approaches given in examples but it doesn't work, because I've got deadlock problem when QT and OSG tried to makecurrent() method. Another alternative will be qtwidgets on first and second screens, but AFAIK qt doesn't allow to make this. Problem is that in qt 4.7.1 and with 295 drivers it works but now it doesn't. I tried single thread and multiply thread render but no result. The main problem is that I don't know how to debug this situation because hangouts can be after one minute or more. If someone have solution with this situation please give some hints. Thank you! Cheers, Roman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49749#49749 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lines being culled
Hi Robert, Thank you, that did the trick. The latest ATI drivers didn't work with display lists either. So it seems NVidia is still superior with OpenGL compared to ATI, as always... Regards, Andreas On 2012-09-04 17:01, Robert Osfield wrote: Hi Andreas, On 4 September 2012 15:56, Andreas Ekstrand wrote: Ah...I tried on a different computer and it works fine there. Could it be that freaking ATI card again...will try updated drivers I tried with your animation path and can't recreate the problem on my Kubuntu 12.04/NVidia 560Ti system. I would suspect a driver issue. One thing you could try is disabling the use of display lists in the results2.osg to see if that effects things - you can do this by just setting the useDisplayList TRUE entry in the .osg to FALSE. 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] Custom Drawable & GLSL
On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
> Doesn't a Drawable's state get applied prior to the call to
> Drawable::drawImplementation()? If so, you could just put the _program in
> your
> Drawable's StateSet?
I'm working on a nodekit for NV_path_rendering, which takes an "as of
yet unseen" approach to rendering; new go OpenGL, at any rate. :)
They call it the "Stencil then Cover" approach, and like most 2D vector
drawing libraries, there is a notion of both STROKING _and_ FILLING. In
order to support arbitrary shading on both the affected stroke fragments
and affected fill fragments, I need to be able to potentially set two
different shaders during a single drawable drawImplementation.
Now, having said that--which I potentially should have mentioned in the
first email--does that change any advice you might have? :)
(Thanks for the response, btw... good info.)
> It's easy to verify that things are happening in the right order using a
> debugger with breakpoints set at your drawImplementation() and also at
> Program::apply().
>
> If it doesn't happen as I describe above, then I believe what you're doing
> below
> is the most robust, as that code would work with all other rendering in the
> scene graph, both shader and non-shader rendering.
>
> Honestly it's been too long since I played at this level. But I seem to
> recall
> that the difference between:
> _program->apply( state );
> and
> state->apply( _program.get() );
> is that the latter tracks the currently bound program, doesn't bother to
> apply
> it if it's already in use, and would probably allow you to remove the call to
> setLastAppliedProgramObject(0).
> -Paul
>
>
> On 9/4/2012 9:58 AM, Jeremy Moles wrote:
> > I am creating a custom Drawable that needs to push a Fragment Shader
> > into the current rendering state and then, after a single extension
> > call, subsequently remove this shader from the state.
> >
> > I have some code I noodled through to make this work, but I feel like
> > there is probably a better way. It goes something like this:
> >
> >
> >
> > drawImplementaion(RenderInfo& ri) {
> > State* state = ri.getState();
> > unsigned int contextID = state->getContextID();
> >
> > _program.apply(state);
> >
> > myExtensions->doMycall();
> >
> > GL2Extensions::Get(contextID, true)->glUseProgram(0);
> >
> > state->setLastAppliedProgramObject(0);
> > }
> >
> >
> >
> > Like I said above, this "works", but I feel like there is probably a
> > cleaner way to achieve what I want. Note that _program is a ref_ptr to a
> > properly create osg::Program object, since I certainly do NOT want to
> > recreate all the goodness it provides. :)
> >
> > Any API advice?
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawable & GLSL
Doesn't a Drawable's state get applied prior to the call to
Drawable::drawImplementation()? If so, you could just put the _program in your
Drawable's StateSet?
It's easy to verify that things are happening in the right order using a
debugger with breakpoints set at your drawImplementation() and also at
Program::apply().
If it doesn't happen as I describe above, then I believe what you're doing below
is the most robust, as that code would work with all other rendering in the
scene graph, both shader and non-shader rendering.
Honestly it's been too long since I played at this level. But I seem to recall
that the difference between:
_program->apply( state );
and
state->apply( _program.get() );
is that the latter tracks the currently bound program, doesn't bother to apply
it if it's already in use, and would probably allow you to remove the call to
setLastAppliedProgramObject(0).
-Paul
On 9/4/2012 9:58 AM, Jeremy Moles wrote:
I am creating a custom Drawable that needs to push a Fragment Shader
into the current rendering state and then, after a single extension
call, subsequently remove this shader from the state.
I have some code I noodled through to make this work, but I feel like
there is probably a better way. It goes something like this:
drawImplementaion(RenderInfo& ri) {
State* state = ri.getState();
unsigned int contextID = state->getContextID();
_program.apply(state);
myExtensions->doMycall();
GL2Extensions::Get(contextID, true)->glUseProgram(0);
state->setLastAppliedProgramObject(0);
}
Like I said above, this "works", but I feel like there is probably a
cleaner way to achieve what I want. Note that _program is a ref_ptr to a
properly create osg::Program object, since I certainly do NOT want to
recreate all the goodness it provides. :)
Any API advice?
___
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] Custom Drawable & GLSL
I am creating a custom Drawable that needs to push a Fragment Shader
into the current rendering state and then, after a single extension
call, subsequently remove this shader from the state.
I have some code I noodled through to make this work, but I feel like
there is probably a better way. It goes something like this:
drawImplementaion(RenderInfo& ri) {
State* state = ri.getState();
unsigned int contextID = state->getContextID();
_program.apply(state);
myExtensions->doMycall();
GL2Extensions::Get(contextID, true)->glUseProgram(0);
state->setLastAppliedProgramObject(0);
}
Like I said above, this "works", but I feel like there is probably a
cleaner way to achieve what I want. Note that _program is a ref_ptr to a
properly create osg::Program object, since I certainly do NOT want to
recreate all the goodness it provides. :)
Any API advice?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Loading 32bit floating point grayscale texture with ImageIO (Mac OSX)
Hi, I can load floating-point greyscale diffs via the imageio-plugin, but they end all as RGBA/unsigned byte osg::Images. There's definitely some code-paths missing :) cheers, Stephan Am 04.09.12 16:12, schrieb Matthias Thöny: > Hi, > > I am wondering if someone ever tried to load 32bit floating point grayscale > .tiff images under Mac OSX with ImageIO. This seems not working at all. This > is a specific problem for grayscale textures. > > I tried to change the code in the ImageIO ReaderWriter class but obviously I > am doing something wrong. As far as documented it should be working: > > http://developer.apple.com/library/ios/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_context/dq_context.html#//apple_ref/doc/uid/TP30001066-CH203-SW9 > (search for Supported Pixel Formats) > > but the CGBitmapContextCreate tells you that this is not a valid combination > if you use: > > Gray 32 bpp, 32 bpc, kCGImageAlphaNone|kCGBitmapFloatComponents OS X > > Is there anybody who tried that before? > > Thank you! > > Cheers, > Matthias > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=49738#49738 > > > > > > ___ > 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] Lines being culled
Hi Andreas, On 4 September 2012 15:56, Andreas Ekstrand wrote: > Ah...I tried on a different computer and it works fine there. Could it be > that freaking ATI card again...will try updated drivers I tried with your animation path and can't recreate the problem on my Kubuntu 12.04/NVidia 560Ti system. I would suspect a driver issue. One thing you could try is disabling the use of display lists in the results2.osg to see if that effects things - you can do this by just setting the useDisplayList TRUE entry in the .osg to FALSE. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Split screen
Hi Peterakos, Have a look at the osgcompositeviewer example. Robert. On 4 September 2012 15:54, Peterakos wrote: > Hello. > > Is there any way to split the screen in 2 (vertical) ? > I would like to use 2 different cameras at the same time. > > thnx. > > ___ > 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] Lines being culled
Ah...I tried on a different computer and it works fine there. Could it be that freaking ATI card again...will try updated drivers /Andreas On 2012-09-04 16:43, Andreas Ekstrand wrote: Hi Robert, Sure, here is the animation path. I zoom in and out a couple of times in the end of the path to show where it disappears. I wonder if it might be related to my ATI graphics card and its drivers...well, let's see if you can reproduce it first. /Andreas On 2012-09-04 16:38, Robert Osfield wrote: Hi Andreas, I tried to recreate the problem with your model but haven't seen it yet. Could you record a camera path that demonstrates the issue and then post this so that we can test exactly the same thing as you. In osgviewer you can press 'z' to start recording the camera path then 'Z' to finish and replay the path. The file saved will be saved_animation.path, and to replace this in osgviewer you'd use: osgviewer result2.osg -p saved_animation.path Robert. On 4 September 2012 15:30, Andreas Ekstrand wrote: Hi, I have a problem with lines being culled. Running osgviewer on the attached osg file and zooming in on e.g. the top right corner of the geometry, consisting of lines representing normals, will result in a sudden culling of all the lines. I have tried disabling culling altogether, made sure backface culling is off and all sorts of precautions regarding depth test etc. (see the state set in the osg file) but I can't get it to stay in view when zooming in. What might be the cause of this? Has someone else experienced this? Can someone reproduce the problem? I use OSG 3.0.1. Regards, Andreas ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Split screen
Hello. Is there any way to split the screen in 2 (vertical) ? I would like to use 2 different cameras at the same time. thnx. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lines being culled
Hi Robert, Sure, here is the animation path. I zoom in and out a couple of times in the end of the path to show where it disappears. I wonder if it might be related to my ATI graphics card and its drivers...well, let's see if you can reproduce it first. /Andreas On 2012-09-04 16:38, Robert Osfield wrote: Hi Andreas, I tried to recreate the problem with your model but haven't seen it yet. Could you record a camera path that demonstrates the issue and then post this so that we can test exactly the same thing as you. In osgviewer you can press 'z' to start recording the camera path then 'Z' to finish and replay the path. The file saved will be saved_animation.path, and to replace this in osgviewer you'd use: osgviewer result2.osg -p saved_animation.path Robert. On 4 September 2012 15:30, Andreas Ekstrand wrote: Hi, I have a problem with lines being culled. Running osgviewer on the attached osg file and zooming in on e.g. the top right corner of the geometry, consisting of lines representing normals, will result in a sudden culling of all the lines. I have tried disabling culling altogether, made sure backface culling is off and all sorts of precautions regarding depth test etc. (see the state set in the osg file) but I can't get it to stay in view when zooming in. What might be the cause of this? Has someone else experienced this? Can someone reproduce the problem? I use OSG 3.0.1. Regards, Andreas ___ 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 0.000696070968497482 2148.97998046875 -1419.13293457031 156.382507324219 0.707106781186548 0 0 0.707106781186548 0.0699708689542101 2148.97998046875 -1419.13293457031 156.382507324219 0.707106781186548 0 0 0.707106781186548 0.139919413865792 2148.97998046875 -1419.13293457031 156.382507324219 0.707106781186548 0 0 0.707106781186548 0.199948398524417 2148.97998046875 -1419.13293457031 156.382507324219 0.707106781186548 0 0 0.707106781186548 0.270015883007378 2147.92557089404 -1419.01785670261 176.286059630242 0.703018200962319 8.26866960287859e-005 -0.000518097671577871 0.711171662718234 0.340036889565523 2145.62630033926 -1417.81958296193 223.621133729184 0.693197721765575 0.00032767138869332 -0.00174209757726281 0.720745292226393 0.399983165476051 2139.68783059861 -1407.42989543114 356.827997543489 0.664783110348327 0.000986130269286395 -0.00515699955770691 0.747017971067804 0.469952570558613 2136.12052832725 -1375.94880909789 539.855753714363 0.623628049361039 0.00291741787136331 -0.00962974233510827 0.781656454451486 0.539956376624898 2137.95133471062 -1339.70648820578 673.846479995252 0.591676193089214 0.00520059105325313 -0.012484252420843 0.806062267958031 0.599903018503338 2143.80523738044 -1284.79968371538 823.974014436394 0.553669758548842 0.00840057258550974 -0.0153392365213396 0.832552663001954 0.649976944021548 2147.35798211914 -1258.23869081301 884.088460264419 0.53768953663796 0.0098773571098232 -0.0163583689278756 0.842926333538466 0.719940859585432 2152.16792285005 -1225.3873611706 950.931880385933 0.519335571988979 0.0116546432028997 -0.0173939204121277 0.854313867668897 0.789953448881602 2155.2109048953 -1213.88359891992 972.718130886722 0.513203601722027 0.0125128895515685 -0.0174027541265714 0.857999204500458 0.850045745988992 2157.62227731718 -1206.58540685262 986.149904959701 0.509382939612347 0.0131448986966753 -0.0172850708793774 0.860265923302111 0.900685823866963 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 0.970117988054807 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.04028794355311 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.10022507026584 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.17028267361518 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.240051528282 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.30008527052348 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.35009076004216 2157.91668874775 -1204.73472914603 989.513711490872 0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852 1.40040915212554 2173.69867546522 -1202.07465143341 994.171151291092 0.508423027740886 0.0132441929692083 -0.01733270
Re: [osg-users] Lines being culled
Hi Andreas, I tried to recreate the problem with your model but haven't seen it yet. Could you record a camera path that demonstrates the issue and then post this so that we can test exactly the same thing as you. In osgviewer you can press 'z' to start recording the camera path then 'Z' to finish and replay the path. The file saved will be saved_animation.path, and to replace this in osgviewer you'd use: osgviewer result2.osg -p saved_animation.path Robert. On 4 September 2012 15:30, Andreas Ekstrand wrote: > Hi, > > I have a problem with lines being culled. Running osgviewer on the attached > osg file and zooming in on e.g. the top right corner of the geometry, > consisting of lines representing normals, will result in a sudden culling of > all the lines. I have tried disabling culling altogether, made sure backface > culling is off and all sorts of precautions regarding depth test etc. (see > the state set in the osg file) but I can't get it to stay in view when > zooming in. > > What might be the cause of this? Has someone else experienced this? Can > someone reproduce the problem? I use OSG 3.0.1. > > Regards, > Andreas > > > ___ > 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] [osgPlugins] Loading 32bit floating point grayscale texture with ImageIO (Mac OSX)
Hi, I am wondering if someone ever tried to load 32bit floating point grayscale .tiff images under Mac OSX with ImageIO. This seems not working at all. This is a specific problem for grayscale textures. I tried to change the code in the ImageIO ReaderWriter class but obviously I am doing something wrong. As far as documented it should be working: http://developer.apple.com/library/ios/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_context/dq_context.html#//apple_ref/doc/uid/TP30001066-CH203-SW9 (search for Supported Pixel Formats) but the CGBitmapContextCreate tells you that this is not a valid combination if you use: Gray 32 bpp, 32 bpc, kCGImageAlphaNone|kCGBitmapFloatComponents OS X Is there anybody who tried that before? Thank you! Cheers, Matthias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49738#49738 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Brainstorming: osgQML
To everyone using OSG and Qt, I watched the following demo of someone presenting QML on Raspberry Pi: http://www.youtube.com/watch?v=0j-Wakm5B84 ... and an interesting idea popped up in my mind: What about creating an osgQML plugin that can provide texture data through osg::ImageStream? Wouldn't that be cool? Unfortunately, I'm knee deep in other project, but I thought that there could be others on this list who might get at kick out of this idea. Best regards, John -- This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackerManipulator
Hi, one related question ... does it make sense to call setNode() somewhere in my NodeTrackerManipulator (with the node following node) so that the home position is computed wrt that node or is it better to call setHomePosition() explicitly? Moreover, when the home position would be used? Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49736#49736 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Speed of first frame rendering
Hi Boon Wah, On 4 September 2012 02:11, Boon Wah wrote: > Just a final question here, is there any way currently to parse a node > within GPU itself and store all the node data directly on GPU. Will this be > planned for future OSG releases? The OSG does a pre compile traversal of the whole scene graph during the first frame, but this only applies to scene graph so far assigned. You can force another compile traversal by using osgViewer::Renderer::setCompileOnNextDraw(true); The Renderer is assigned to the Camera in the viewer. > GPU memory sizes are getting increasingly large, and it will be > beneficial if we could do all these on GPU itself, rather than using CPU > memory space. The OSG does all rendering on the GPU and stores data on the GPU when so instructed by scene graph usage i.e. texture objects, vertex buffer objects etc. The OSG also has a feature in Texture that enables the automatic release of the osg::Image once the image is download to OpenGL. There are limits on just how much you can sensibly do on the GPU, and you can't download data directly from disk to the GPU so you always have to go through main memory, so it's really just an issue of how you manage that memory. The OSG is professional grade scene graph and will already being doing what that what the majority what the vis-sim industry need from a scene graph, so I'd recommend you don't too ahead of yourself with grand plans of what might be. I'd recommend you just take the time to learn about what the OSG can do and how it does it, the new OSG books will help you in this endeavour. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
