[osg-users] Loading different texture in child drawable than in parent geode

[Cary, Karl A.]

I have a geode that loads a shader. It loads up a texture that is meant
to be a default texture. That geode then has many children drawables
under it. The plan is that each child will have a different texture
associated with it, but will otherwise be using the same shader and
StateSet as the parent geode. If the child does not have a texture
associated with it, it should use the one from the parent geode. If I
put the shader in the geode, all geometry is drawn correctly. But if I
try to load a different texture in the child drawable, the geode's
texture is used instead. Please help me figure out what I am missing.
I'm starting to go bleary eyed!

 

Here is the code that sets up the texture and shader in the geode (and
this works, the texture loaded here shows up):

 

stateSet = new osg::StateSet

texSampler = new osg::Uniform("texture", 0);

stateSet->addUniform(texSampler);

stateSet->setTextureAttributeAndModes(0, texture,
osg::StateAttribute::ON);

 

osg::ref_ptr program = new osg::Program;

 

osg::ref_ptr vertShader = new
osg::Shader(osg::Shader::VERTEX);

vertShader->loadShaderSourceFromFile("shaders/testVert.glsl");

program->addShader(vertShader);

osg::ref_ptr fragShader = new
osg::Shader(osg::Shader::FRAGMENT);

fragShader->loadShaderSourceFromFile("shaders/testFrag.glsl");

program->addShader(fragShader);

 

stateSet->setAttribute(program);

stateSet->setAttributesAndModes(program.get(), osg::StateAttribute::ON);

 

this->setStateSet(stateSet);

 

I then attempt to load a different texture in the drawable that is
attached to the above geode. Here is the code I am attempting to use:

 

stateSet = new osg::StateSet;

stateSet->setTextureAttributeAndModes(0, texture,
osg::StateAttribute::ON | osg::StateAttribute::PROTECTED);

this->setStateSet(stateSet);

 

I am obviously missing something. I tried switching which texture was on
the geode and the drawable just to make sure it wasn't a problem with
the texture itself. There was no issue in switching it.

 

Thank you  for looking at this.

 

Karl

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

Re: [osg-users] Animations, weights, and priority.

[Garthy Dee]

ParticlePeter wrote:
> 
> @ Garthy, I'll be using you're observations so far if this is fine with you.
> 


Not a problem at all, please do. I can't vouch for their accuracy though. The 
description is just my best guess from plugging in lots of different values for 
weight and priority, and observing the results.


ParticlePeter wrote:
> 
> I would like to ask you to keep on posting your observations in this thread. 
> 


Certainly, if I can add anything useful, I will do so.


Cedric Pinson wrote:
> 
> It Looks like we need a document explaining the behaviour of animation. 
> 


Such a thing would be very useful.

...

At the moment I have implemented a solution that works more-or-less how I need 
it to. Basically, I am running a priority zero 100% weight idle animation, and 
running all other animations on top of that with priority one and variable 
weight. For the animations that are causing problems in transition, I 
effectively disable blending for them by always using 0% or 100% weight. This 
lets me work around the problem I am having at least. I imagine I'll keep 
swinging back to this as a background task from time to time, hopfully gaining 
a better understanding of how things work as time goes by.

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





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

Re: [osg-users] Multiple Shaders

[Glenn Waldron]

Stephen,

You need some kind of shader composition. Personally, I prefer the
VirtualProgram approach taken in the osgvirtualprogram example. IIRC, Robert
did not consider this flexible enough to be a general-purpose shader comp
solution, so it's not in the core OSG. However it suited our needs quite
well so we adopted and extended it for use in the osgEarth project.

http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ShaderComposition

Glenn Waldron / Pelican Mapping / @glennwaldron


On Thu, Aug 4, 2011 at 10:19 AM, Stephen Haith  wrote:

> Very timely thread - I am looking at doing the same thing.
>
> How can you apply a shader effect to the entire scene, AND another effect
> to only a part of the tree?
>
> Thanks,
>
> Stephen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=41851#41851
>
>
>
>
>
> ___
> 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] NVidia 275-series Driver Bug

[John Ivar Haugland]

Thanks, I followed the suggestion from Michael Platings (
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg46081.html)
 to
add the lines

for (GLsizei j = 0; j < maxLen && name[j]; ++j)
{
if (!isalnum(name[j]) && name[j] != '_')
{
name[j] = '\0';
break;
}
}

after the line

_extensions->glGetActiveUniform( _glProgramHandle,
i, maxLen, 0, &size, &type, name );

in Program.cpp of the osg library.

Recompiled the osg library. This fixed it for me with Nvidia driver  280.19.
Perhaps the helper class is a better solution? I suggest a solution should
be sent to the osg-submission mailing list ( Glenn?,  Michael?)

John Ivar.

On Fri, Aug 5, 2011 at 2:51 PM, Glenn Waldron  wrote:

> I worked around this issue with an "ArrayUniform" helper class. The code is
> here:
>
> https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ShaderUtils (and
> .cpp)
>
> Glenn Waldron / Pelican Mapping / @glennwaldron
>
> 2011/8/5 Sergey Polischuk 
>
>> Hi, John
>>
>> For me it works on new drivers if i append "[0]" to uniform array name,
>> BUT it wont work on old driver anymore with this change. So for now in our
>> apps we have to use two uniforms for each uniform array, one original and
>> another with "[0]" appended so stuff actually works on both old and new
>> drivers...
>> Cheers,
>> Sergey.
>> 05.08.2011, 12:22, "John Ivar Haugland" :
>>
>> FYI, I just tested the new NVIDIA beta driver 280.19. Same problem as with
>> 275 series.
>> John Ivar
>>
>> On Wed, Jul 27, 2011 at 3:56 PM, Jeremy Moles wrote:
>>
>> On Wed, 2011-07-27 at 12:06 +0400, Sergey Polischuk wrote:
>> > Hi Jeremy
>> >
>> > You can try to append "[]" to array uniform name string when create
>> osg::Uniform, mb this helps.
>>
>> It won't because it seems that internally OSG changes:
>>
>>Color
>>
>> ...to...
>>
>>Color[0]
>>
>> ...even, on non-array Uniforms.
>>
>> If I edit Program.cpp and remove this behavior (that is, the appending
>> of the "[0]" to uniform names), it works again. This issue was also
>> discussed briefly here:
>>
>> http://forum.openscenegraph.org/viewtopic.php?t=1828
>>
>> Robert responded saying it was truly a bug with the driver, which may
>> still be the case. However, if I write a small, pure OpenGL application,
>> EITHER syntax works ("Color" or "Color[0]"). If it is a driver bug, it
>> is only one that is exercised by by some state leakage or similar...
>>
>> My fear is that this is going to remain an issue for NVidia drivers
>> going forwards, but we'll have to see... perhaps someone with more
>> authoritative knowledge can comment on why this could be happening.
>>
>>
>> > 27.07.2011, 09:51, "Jeremy Moles" :
>> > > On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:
>> > >
>> > >>  Hello folks! Anyone here using the 275 series of NVidia drivers?
>> > >>  (Doesn't matter what OS, the bug is on Linux and Windows for me...)
>> > >>
>> > >>  It appears that this driver doesn't understand GLSL arrays anymore.
>> At
>> > >>  least, not like it used to. Crazy, huh? Yeah, I thought so too.
>> > >>
>> > >>  I've attached a __VERY__ simple application demonstrating this. If
>> > >>  anyone has a sec (particularly Mike Wieblen), I'd be interested to
>> see
>> > >>  if they could compile it and perhaps shed some light on this
>> mystery. :)
>> > >>
>> > >>  I've been googling and checking the NVidia forums, but so far
>> nothing.
>> > >
>> > > There have been a few replies to this original thread, and I'm not
>> > > trying to beat a dead horse here, but I recently purchased a video
>> card
>> > > that is ONLY support by 275+ (in Linux). So I'm back to investigating
>> > > this issue.
>> > >
>> > > If I use GLSL arrays via OSG, as demonstrated in the example app, it
>> > > completely misbehaves. However, non-array uniforms are just fine.
>> > >
>> > > Interestingly, if I write a purse OpenGL application using GLSL
>> arrays,
>> > > that works just fine. Is it possible there's some kind of bug in OSG
>> > > that these newer drivers expose? I don't imagine they're going to
>> "fix"
>> > > this for OSG, so eventually people will have to upgrade to 275 and
>> > > beyond...
>> > >
>> > > I've been trying to track down the issue, but have had no luck so far.
>> > > I'll keep investigating, but if anyone has acquired any NEW
>> information
>> > > in the last month, that would be stellar. :)
>> > >
>> > >>  ___
>> > >>  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://lis

Re: [osg-users] Multiple Shaders

[Stephen Haith]

Very timely thread - I am looking at doing the same thing.

How can you apply a shader effect to the entire scene, AND another effect to 
only a part of the tree?

Thanks,

Stephen

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





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

Re: [osg-users] Render to Depth Texture GLES 2 IOS

[Thomas Hogarth]

I fixed it,

Well I found out what you have to do to make it work. You have to also
attach a color texture to the camera, else you get the incomplete attachment
error.

Hope it helps anyone else trying this

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

Re: [osg-users] Shadows on invisible objects

[Alessandro Terenzi]

Paul Martz wrote:
> 
> When I use depth map shadows, I use a fragment shader to sample the depth 
> texture. If I wanted to see only the shadow areas but not the lit areas, I'd 
> just add the appropriate conditional call to "discard".
> 


Thanks Paul, your suggestion is very helpful, anyway I wonder if there exists 
also a way to achieve the same result without relying on shaders...for example, 
in the past I used the ColorMask to create an 'invisible' object that was able 
to hide other objects (its shape and volume was reveiled if other objects moved 
behind it, even though it was not visible in the scene). You can also pick such 
kind of invisible objects, so, maybe, something similar can be done also with 
shadows.

Basically I'm looking for a way to reveil the shape/volume of an invisible 
object by means of shadows casted onto it, I know that this may make no sense 
from a physical point of view, but we're in the CG world where only imagination 
is the limit, aren't we?

Cheers.
Alessandro

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





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

Re: [osg-users] Shadows on invisible objects

[Chris 'Xenon' Hanson]

On 8/5/2011 11:03 AM, Alessandro Terenzi wrote:
> Hi,
> I want to make an object invisible but, nonetheless, I also want it to 
> receive shadows, any suggestion?

  Receive? That makes no sense. Its appearance can't be altered by a shadow if 
it has no
appearance.

-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/
  Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. 
Contracting.
"There is no Truth. There is only Perception. To Perceive is to Exist." - 
Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shadows on invisible objects

[Paul Martz]

On 8/5/2011 11:03 AM, Alessandro Terenzi wrote:

Hi,
I want to make an object invisible but, nonetheless, I also want it to receive 
shadows, any suggestion?

By the way, I'm using the ShadowMap technique to implement shadows.

Thanks.
Alessandro



When I use depth map shadows, I use a fragment shader to sample the depth 
texture. If I wanted to see only the shadow areas but not the lit areas, I'd 
just add the appropriate conditional call to "discard".


Hope that helps,

--
  -Paul Martz  Skew Matrix Software
   http://www.skew-matrix.com/

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

[osg-users] Shadows on invisible objects

[Alessandro Terenzi]

Hi,
I want to make an object invisible but, nonetheless, I also want it to receive 
shadows, any suggestion?

By the way, I'm using the ShadowMap technique to implement shadows.

Thanks.
Alessandro

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





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

Re: [osg-users] osg::Geometry and GL_PRIMITVE_RESTART

[Peter Wrobel]

Hi Sergey,

thank you for your code, I will study it. :-)

Thank you!

Cheers, ParticlePeter

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





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

Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

[Jeremy Moles]

On Fri, 2011-08-05 at 17:15 +0200, Cedric Pinson wrote:
> Hi,
> The alternative would be distance map. It works really well.

Yeah. I recently added a DistanceFieldFont object to osgPango, though it
still needs some tweaking--particularly with regards to when the glyph
is resized smaller than the texture; larger always looks great. :)

> Cedric
> 
> On Fri, 2011-08-05 at 08:48 -0400, Glenn Waldron wrote:
> > I was just thinking the same thing. :) Labels too.
> > 
> > Glenn Waldron / Pelican Mapping / @glennwaldron
> > 
> > 
> > On Fri, Aug 5, 2011 at 2:56 AM, J.P. Delport 
> > wrote:
> > Hi Jeremy,
> > 
> > if this could be combined with osgEarth it would be very cool
> > for overlays.
> > 
> > rgds
> > jp
> > 
> > 
> > 
> > On 04/08/2011 21:23, Jeremy Moles wrote:
> > NVidia recently added an extension to their 275+
> > series of drivers
> > called "GL_NV_path_rendering." This turns path
> > (sometimes called vector
> > graphics) rendering into first class drawables in
> > OpenGL. Honestly, it's
> > one of the coolest things I've seen in a while, and
> > naturally--given my
> > interest in OpenGL UIs--I began researching it and
> > putting together a
> > NodeKit for OSG.
> > 
> > You can find it (in its infancy) here:
> > 
> > http://osgnvpr.googlecode.com
> > 
> > Run the example thusly:
> > 
> ># osgnvprviewer
> ># osgnvprviewer --perspective
> > 
> > ..and notice how that no matter what the resolution,
> > scale, or
> > projection, the objects are rendered clear and crisp.
> > There is also
> > support for glyphs inside of GL_NV_path_rendering, so
> > I will very soon
> > be adding support for this style of text rendering
> > into osgPango (and
> > possible, osgText::TextNode).
> > 
> > I've only just begun exploring this, and I'm mainly
> > sending this e-mail
> > to see if there is any professional interest in seeing
> > this NodeKit
> > mature in a timely fashion. I don't know if this is
> > outside the
> > allowable etiquette of the lists, but in full
> > disclosure I'm looking to
> > fill some free time by seeking funding for development
> > of by those who
> > would not only use these features but could benefit
> > from being able to
> > influence their development and pace! If this is
> > inappropriate for the
> > lists, just let me know and I'll be sure and keep my
> > peddling to a
> > minimum from here on out. :)
> > 
> > At any rate, I'll continue to work on osgNVPR
> > regardless, alongside
> > devleopment of osgCairo/Pango/Widget and the recent
> > TextNode submission.
> > (Can you see a pattern here? All OSG interface
> > development tools...)
> > 
> > Some notes:
> > 
> >- NV_path_rendering introduces a new kind of
> > rendering "style" for its
> > path objects. This doesn't map 1:1 to any existing
> > usage of
> > osg::Drawable, though I am able to "hijack" the
> > compileGLObjects()
> > method to get what I need. :)
> > 
> >- BoundingBoxes are calculated with an
> > extension call, but in order to
> > use the extension I need a contextID (provided via
> > either a State object
> > or RenderInfo object). Unfortunately, these are
> > difficult to "get to" at
> > times, so CameraManipulators cannot properly determine
> > a home position
> > unless the Path has been compiled.
> > 
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> > 
> > 
> > -- 
> > This message is subject to the CSIR's copyright terms and
> > 

Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

[Jeremy Moles]

On Fri, 2011-08-05 at 10:11 -0500, Michael Weiblen wrote:
> heh, first osgVRPN, now osgNVPR  :-)
> 
> That said, this is quite an interesting extension.
> 
> -- mew

Hmm, perhaps osgNVPath would be better. :)

> On Thu, Aug 4, 2011 at 2:23 PM, Jeremy Moles  wrote:
> > NVidia recently added an extension to their 275+ series of drivers
> > called "GL_NV_path_rendering." This turns path (sometimes called vector
> > graphics) rendering into first class drawables in OpenGL. Honestly, it's
> > one of the coolest things I've seen in a while, and naturally--given my
> > interest in OpenGL UIs--I began researching it and putting together a
> > NodeKit for OSG.
> >
> > You can find it (in its infancy) here:
> >
> > http://osgnvpr.googlecode.com
> >
> > Run the example thusly:
> >
> ># osgnvprviewer
> ># osgnvprviewer --perspective
> >
> > ..and notice how that no matter what the resolution, scale, or
> > projection, the objects are rendered clear and crisp. There is also
> > support for glyphs inside of GL_NV_path_rendering, so I will very soon
> > be adding support for this style of text rendering into osgPango (and
> > possible, osgText::TextNode).
> >
> > I've only just begun exploring this, and I'm mainly sending this e-mail
> > to see if there is any professional interest in seeing this NodeKit
> > mature in a timely fashion. I don't know if this is outside the
> > allowable etiquette of the lists, but in full disclosure I'm looking to
> > fill some free time by seeking funding for development of by those who
> > would not only use these features but could benefit from being able to
> > influence their development and pace! If this is inappropriate for the
> > lists, just let me know and I'll be sure and keep my peddling to a
> > minimum from here on out. :)
> >
> > At any rate, I'll continue to work on osgNVPR regardless, alongside
> > devleopment of osgCairo/Pango/Widget and the recent TextNode submission.
> > (Can you see a pattern here? All OSG interface development tools...)
> >
> > Some notes:
> >
> >- NV_path_rendering introduces a new kind of rendering "style" for 
> > its
> > path objects. This doesn't map 1:1 to any existing usage of
> > osg::Drawable, though I am able to "hijack" the compileGLObjects()
> > method to get what I need. :)
> >
> >- BoundingBoxes are calculated with an extension call, but in order 
> > to
> > use the extension I need a contextID (provided via either a State object
> > or RenderInfo object). Unfortunately, these are difficult to "get to" at
> > times, so CameraManipulators cannot properly determine a home position
> > unless the Path has been compiled.
> >
> > ___
> > 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] Composite viewer Threading model

[Emmanuel Roche]

well well well,

I'm wondering if this could be related to one of the previous thread on this
list called: "OSG seems to have a problem scaling to multiple windows on
multiple graphics cards" :-(


I'm currently diving into the GraphicsContext operations code, but I doubt I
can find any clear evidence that: "this is just the way it is supposed to
work or not" so please, someone, correct me if I'm wrong here:

=> I assume that with a CompositeViewer, if I display multiple windows with
one graphics context (<= one osg::GraphicsWindow) per window, and one camera
per windows, then using a threading model  CullDrawThreadPerContext should
result in the Cull/draw phase to run concurrently and this should be visible
when displaying the stats...

... or maybe it just doesn't work like that ? :-) Maybe the draw cycles must
be sequential (just as the GPU cycles ?) but then what is the meaning for
those threading models ? any clear description anywhere ?

cheers,
Manu.



2011/8/5 Emmanuel Roche 

> Hi everyone,
>
> I'm currently trying to experiment with OSG multi-threading support in an
> application:
>
> I have the following setup:
>
> - One app with 2 or more OSG rendering windows displaying the same scene (+
> different overlays, so nto really the same "osg::Scene" actually)
> - I can choose to either use a shared openGL context or not for those 2 (or
> more) windows.
> - I run the app on a 2 screens computer with 1x Geforce GTX 480
> - The rendering is done using a CompositeViewer derived class with very
> minor changes.
>
> The problem/question is:
>
> => I tried all the possible threading models, displaying the osg stats each
> time: and there is just no change at all in the resulting
> performances/reported stats:
>
> => All the cull/draw cycles still seem to be performed sequentially.
>
> So I'm wondering : what could I be missing here ??
>
> Even when I don't use a shared context for instance: I would have expected
> a setting such as DrawThreadPerContext to mean per "OpenGL context" Am I
> wrong on that ??
>
> Any idea what I should check first to ensure everything is OK for
> multithreading to occur ??
>
> Please see the attached image for the current stats I get.
>
> thanks for your advises guys ! :-)
>
> Cheers!
> Manu.
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Render into texture from 2 Cameras

[Sergey Polischuk]

Hi, Martin

You should either use clear only on camera that render first half, or use 
scissor test (osg::Scissor and GL_SCISSOR_TEST) set to region of camera 
viewport on each camera to not clear other camera's render result.

Cheers,
Sergey.

05.08.2011, 18:51, "Martin Haffner" :
> Hi,
>
> I made an application with a camera that rendered into a texture and 
> everything worked.
> Now I want to render into the texture from 2 Cameras. I want cam1 to render 
> into the left side, and cam1 render into the right side into the texture.
> Basically this is my code:
>
> Code:
>
> cam1 = new osg::CameraNode;
> cam1->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
> cam1->setClearColor(clearColor);
> cam1->setViewport(0, 0, m_rttWidth / 2 ,m_rttHeight);
> cam1->setRenderOrder(osg::CameraNode::PRE_RENDER);
> cam1->setRenderTargetImplementation( osg::CameraNode::FRAME_BUFFER_OBJECT );
> cam1->setProjectionMatrixAsPerspective(60.0f, static_cast(m_rttWidth 
> /2) / m_rttHeight, 0.01f, farPlane);
> osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); cam1->setComputeNearFarMode( 
> Camera::DO_NOT_COMPUTE_NEAR_FAR );
> cam1->attach(osg::Camera::COLOR_BUFFER, m_rttScene.get(), 0, 0, false, 4, 0);
> cam1->addChild( sceneRootNode );
> m_CamerasNode->addChild( cam1.get() );
>
> //Cam2
> // The code for cam2 exactly the same, except this line:
> cam2->setViewport( m_rttWidth /2, 0, m_rttWidth /2 ,100 );
>
> The left half of the texture is correctly rendered, but the right side of the 
> texture (which should be rendered by cam2) is black!
>
> Anyone has an idea what could be wrong? Maybe something with the clear flags? 
> Or culling?
>
> Thank you!
>
> Cheers,
> Martin
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=41886#41886
>
> ___
> 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] ANN: osgNVPR (NVidia Path Rendering)

[Cedric Pinson]

Hi,
The alternative would be distance map. It works really well.

Cedric

On Fri, 2011-08-05 at 08:48 -0400, Glenn Waldron wrote:
> I was just thinking the same thing. :) Labels too.
> 
> Glenn Waldron / Pelican Mapping / @glennwaldron
> 
> 
> On Fri, Aug 5, 2011 at 2:56 AM, J.P. Delport 
> wrote:
> Hi Jeremy,
> 
> if this could be combined with osgEarth it would be very cool
> for overlays.
> 
> rgds
> jp
> 
> 
> 
> On 04/08/2011 21:23, Jeremy Moles wrote:
> NVidia recently added an extension to their 275+
> series of drivers
> called "GL_NV_path_rendering." This turns path
> (sometimes called vector
> graphics) rendering into first class drawables in
> OpenGL. Honestly, it's
> one of the coolest things I've seen in a while, and
> naturally--given my
> interest in OpenGL UIs--I began researching it and
> putting together a
> NodeKit for OSG.
> 
> You can find it (in its infancy) here:
> 
> http://osgnvpr.googlecode.com
> 
> Run the example thusly:
> 
># osgnvprviewer
># osgnvprviewer --perspective
> 
> ..and notice how that no matter what the resolution,
> scale, or
> projection, the objects are rendered clear and crisp.
> There is also
> support for glyphs inside of GL_NV_path_rendering, so
> I will very soon
> be adding support for this style of text rendering
> into osgPango (and
> possible, osgText::TextNode).
> 
> I've only just begun exploring this, and I'm mainly
> sending this e-mail
> to see if there is any professional interest in seeing
> this NodeKit
> mature in a timely fashion. I don't know if this is
> outside the
> allowable etiquette of the lists, but in full
> disclosure I'm looking to
> fill some free time by seeking funding for development
> of by those who
> would not only use these features but could benefit
> from being able to
> influence their development and pace! If this is
> inappropriate for the
> lists, just let me know and I'll be sure and keep my
> peddling to a
> minimum from here on out. :)
> 
> At any rate, I'll continue to work on osgNVPR
> regardless, alongside
> devleopment of osgCairo/Pango/Widget and the recent
> TextNode submission.
> (Can you see a pattern here? All OSG interface
> development tools...)
> 
> Some notes:
> 
>- NV_path_rendering introduces a new kind of
> rendering "style" for its
> path objects. This doesn't map 1:1 to any existing
> usage of
> osg::Drawable, though I am able to "hijack" the
> compileGLObjects()
> method to get what I need. :)
> 
>- BoundingBoxes are calculated with an
> extension call, but in order to
> use the extension I need a contextID (provided via
> either a State object
> or RenderInfo object). Unfortunately, these are
> difficult to "get to" at
> times, so CameraManipulators cannot properly determine
> a home position
> unless the Path has been compiled.
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> 
> 
> -- 
> This message is subject to the CSIR's copyright terms and
> conditions, e-mail legal notice, and implemented Open Document
> Format (ODF) standard. The full disclaimer details can be
> found at http://www.csir.co.za/disclaimer.html.
> 
> This message has been scanned for viruses and dangerous
> content by MailScanner, and is believed to be clean.
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.opens

Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

[Michael Weiblen]

heh, first osgVRPN, now osgNVPR  :-)

That said, this is quite an interesting extension.

-- mew



On Thu, Aug 4, 2011 at 2:23 PM, Jeremy Moles  wrote:
> NVidia recently added an extension to their 275+ series of drivers
> called "GL_NV_path_rendering." This turns path (sometimes called vector
> graphics) rendering into first class drawables in OpenGL. Honestly, it's
> one of the coolest things I've seen in a while, and naturally--given my
> interest in OpenGL UIs--I began researching it and putting together a
> NodeKit for OSG.
>
> You can find it (in its infancy) here:
>
> http://osgnvpr.googlecode.com
>
> Run the example thusly:
>
>        # osgnvprviewer
>        # osgnvprviewer --perspective
>
> ..and notice how that no matter what the resolution, scale, or
> projection, the objects are rendered clear and crisp. There is also
> support for glyphs inside of GL_NV_path_rendering, so I will very soon
> be adding support for this style of text rendering into osgPango (and
> possible, osgText::TextNode).
>
> I've only just begun exploring this, and I'm mainly sending this e-mail
> to see if there is any professional interest in seeing this NodeKit
> mature in a timely fashion. I don't know if this is outside the
> allowable etiquette of the lists, but in full disclosure I'm looking to
> fill some free time by seeking funding for development of by those who
> would not only use these features but could benefit from being able to
> influence their development and pace! If this is inappropriate for the
> lists, just let me know and I'll be sure and keep my peddling to a
> minimum from here on out. :)
>
> At any rate, I'll continue to work on osgNVPR regardless, alongside
> devleopment of osgCairo/Pango/Widget and the recent TextNode submission.
> (Can you see a pattern here? All OSG interface development tools...)
>
> Some notes:
>
>        - NV_path_rendering introduces a new kind of rendering "style" for its
> path objects. This doesn't map 1:1 to any existing usage of
> osg::Drawable, though I am able to "hijack" the compileGLObjects()
> method to get what I need. :)
>
>        - BoundingBoxes are calculated with an extension call, but in order to
> use the extension I need a contextID (provided via either a State object
> or RenderInfo object). Unfortunately, these are difficult to "get to" at
> times, so CameraManipulators cannot properly determine a home position
> unless the Path has been compiled.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Mike Weiblen -- Black Hawk, Colorado USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Render into texture from 2 Cameras

[Martin Haffner]

Hi,

I made an application with a camera that rendered into a texture and everything 
worked.
Now I want to render into the texture from 2 Cameras. I want cam1 to render 
into the left side, and cam1 render into the right side into the texture.
Basically this is my code:


Code:

cam1 = new osg::CameraNode;
cam1->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
cam1->setClearColor(clearColor);
cam1->setViewport(0, 0, m_rttWidth / 2 ,m_rttHeight);
cam1->setRenderOrder(osg::CameraNode::PRE_RENDER);
cam1->setRenderTargetImplementation( osg::CameraNode::FRAME_BUFFER_OBJECT );
cam1->setProjectionMatrixAsPerspective(60.0f, static_cast(m_rttWidth /2) 
/ m_rttHeight, 0.01f, farPlane);
osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); cam1->setComputeNearFarMode( 
Camera::DO_NOT_COMPUTE_NEAR_FAR );
cam1->attach(osg::Camera::COLOR_BUFFER, m_rttScene.get(), 0, 0, false, 4, 0);
cam1->addChild( sceneRootNode );
m_CamerasNode->addChild( cam1.get() );

//Cam2
// The code for cam2 exactly the same, except this line:
cam2->setViewport( m_rttWidth /2, 0, m_rttWidth /2 ,100 );




The left half of the texture is correctly rendered, but the right side of the 
texture (which should be rendered by cam2) is black!

Anyone has an idea what could be wrong? Maybe something with the clear flags? 
Or culling?

Thank you!

Cheers,
Martin

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





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

Re: [osg-users] osg::Geometry and GL_PRIMITVE_RESTART

[Sergey Polischuk]

example of drawElementsUShort with primitive restart

class DrawElementsUShortRestart: public osg::DrawElementsUShort
{
public:
DrawElementsUShortRestart(const osg::DrawElementsUShort&);
DrawElementsUShortRestart(GLenum mode=GL_TRIANGLE_STRIP):
osg::DrawElementsUShort(mode), _enabled(false), _index(USHRT_MAX)
{}
DrawElementsUShortRestart(std::vector);

DrawElementsUShortRestart(GLenum mode, unsigned int no, const GLushort* 
ptr, int numInstances=0) : 
DrawElementsUShort(mode,no,ptr,numInstances), _enabled(false), 
_index(USHRT_MAX)
{}
void draw(osg::State& state, bool useVertexBufferObjects) const;
void setRestartIndex(unsigned index)
{
_index = index;
}
int getRestartIndex()
{
if (_enabled) return -1;
return _index;
}
private:
void glPrimitiveRestartIndexNV(GLuint index, unsigned contextID) const
{
std::map::iterator itr = 
_map.find(contextID);
if (itr==_map.end())
{
PrimitiveRestartIndexNV ptr = 0;
osg::setGLExtensionFuncPtr(ptr,  
"glPrimitiveRestartIndexNV" );
if (!ptr) throw 
std::runtime_error("glPrimitiveRestartIndexNV is not supported or smth");
_map[contextID] = ptr;
ptr(index);
}
else
itr->second(index);
};
typedef void (APIENTRY * PrimitiveRestartIndexNV)(GLuint);
static std::map _map;
bool _enabled;
GLushort _index;
};



DrawElementsUShortRestart::DrawElementsUShortRestart(std::vector
 vec)
:DrawElementsUShort(GL_TRIANGLE_STRIP), _enabled(true), _index(USHRT_MAX-1)
{
for (unsigned i = 0; i< vec.size(); i++)
{
for (unsigned j = 0; j< vec[i]->getNumIndices(); j++)
{
addElement(vec[i]->getElement(j));
}
if (i < vec.size() - 1)
addElement(_index);
}
};


void DrawElementsUShortRestart::draw(osg::State& state, bool 
useVertexBufferObjects) const 
{
if (_enabled)
{
glEnableClientState(GL_PRIMITIVE_RESTART_NV);
glPrimitiveRestartIndexNV(_index, state.getContextID());
}
osg::DrawElementsUShort::draw(state, useVertexBufferObjects);
if (_enabled)
glDisableClientState(GL_PRIMITIVE_RESTART_NV);
};

std::map 
DrawElementsUShortRestart::_map;


//i used this visitor to "merge" short primitivesets with triangle strips into 
one large with primitive restart

class MakeDrawElementsRestartVisitor: public osg::NodeVisitor
{
public:

MakeDrawElementsRestartVisitor():osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
setNodeMaskOverride(~0x0);
}

using osg::NodeVisitor::apply;
void apply(osg::Geode& node)
{

std::cerr<<"node.getNumDrawables():"getNumPrimitiveSets():"getNumPrimitiveSets(); 
j++)
{
osg::PrimitiveSet* ps = 
geom->getPrimitiveSet(j);
osg::DrawElementsUShort* deus = 
dynamic_cast(ps);
if (!deus)
{
std::cerr<<"return on 
(!deus)"getMode() is 
not GL_TRIANGLE_STRIP"getNumPrimitiveSets());
geom->addPrimitiveSet(deusr);
std::cerr Hi,
>
> Would it be possible for you to share you're implementation ? For me it is 
> still not clear how to extend osg ( as you see on my question above ).
> I found this thread: 
> http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg46962.html
>
> Sergey ( @hybr, is this you ? ) has created a new extension class: class 
> MyExtensions: public osg::Referenced
> wher he adds all possible extensions. I just wonder if this is the right way, 
> or if one should not just be able to add the particular extension required to 
> add a custom Drawable and or StateAttribute.
>
> Its really hard to find any documentation on that part of osg. Community, it 
> would be very nice if somebody could create a simple explanatory example, 
> please.
>
> Thank you!
>
> Cheers, ParticlePeter
>
> 

Re: [osg-users] NVidia 275-series Driver Bug

[Glenn Waldron]

I worked around this issue with an "ArrayUniform" helper class. The code is
here:

https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ShaderUtils (and
.cpp)

Glenn Waldron / Pelican Mapping / @glennwaldron

2011/8/5 Sergey Polischuk 

> Hi, John
>
> For me it works on new drivers if i append "[0]" to uniform array name, BUT
> it wont work on old driver anymore with this change. So for now in our apps
> we have to use two uniforms for each uniform array, one original and another
> with "[0]" appended so stuff actually works on both old and new drivers...
> Cheers,
> Sergey.
> 05.08.2011, 12:22, "John Ivar Haugland" :
>
> FYI, I just tested the new NVIDIA beta driver 280.19. Same problem as with
> 275 series.
> John Ivar
>
> On Wed, Jul 27, 2011 at 3:56 PM, Jeremy Moles wrote:
>
> On Wed, 2011-07-27 at 12:06 +0400, Sergey Polischuk wrote:
> > Hi Jeremy
> >
> > You can try to append "[]" to array uniform name string when create
> osg::Uniform, mb this helps.
>
> It won't because it seems that internally OSG changes:
>
>Color
>
> ...to...
>
>Color[0]
>
> ...even, on non-array Uniforms.
>
> If I edit Program.cpp and remove this behavior (that is, the appending
> of the "[0]" to uniform names), it works again. This issue was also
> discussed briefly here:
>
> http://forum.openscenegraph.org/viewtopic.php?t=1828
>
> Robert responded saying it was truly a bug with the driver, which may
> still be the case. However, if I write a small, pure OpenGL application,
> EITHER syntax works ("Color" or "Color[0]"). If it is a driver bug, it
> is only one that is exercised by by some state leakage or similar...
>
> My fear is that this is going to remain an issue for NVidia drivers
> going forwards, but we'll have to see... perhaps someone with more
> authoritative knowledge can comment on why this could be happening.
>
>
> > 27.07.2011, 09:51, "Jeremy Moles" :
> > > On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:
> > >
> > >>  Hello folks! Anyone here using the 275 series of NVidia drivers?
> > >>  (Doesn't matter what OS, the bug is on Linux and Windows for me...)
> > >>
> > >>  It appears that this driver doesn't understand GLSL arrays anymore.
> At
> > >>  least, not like it used to. Crazy, huh? Yeah, I thought so too.
> > >>
> > >>  I've attached a __VERY__ simple application demonstrating this. If
> > >>  anyone has a sec (particularly Mike Wieblen), I'd be interested to
> see
> > >>  if they could compile it and perhaps shed some light on this mystery.
> :)
> > >>
> > >>  I've been googling and checking the NVidia forums, but so far
> nothing.
> > >
> > > There have been a few replies to this original thread, and I'm not
> > > trying to beat a dead horse here, but I recently purchased a video card
> > > that is ONLY support by 275+ (in Linux). So I'm back to investigating
> > > this issue.
> > >
> > > If I use GLSL arrays via OSG, as demonstrated in the example app, it
> > > completely misbehaves. However, non-array uniforms are just fine.
> > >
> > > Interestingly, if I write a purse OpenGL application using GLSL arrays,
> > > that works just fine. Is it possible there's some kind of bug in OSG
> > > that these newer drivers expose? I don't imagine they're going to "fix"
> > > this for OSG, so eventually people will have to upgrade to 275 and
> > > beyond...
> > >
> > > I've been trying to track down the issue, but have had no luck so far.
> > > I'll keep investigating, but if anyone has acquired any NEW information
> > > in the last month, that would be stellar. :)
> > >
> > >>  ___
> > >>  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 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] tight integration of virtual file system

[Jason Beverage]

Hi Terry,

osgEarth has a generic zip based plugin called ZipFS that is
implemented as an osgDB plugin and isn't dependent on osgEarth.  We
originally developed it to support using a zip file of imagery tiles
for a cache.

It allows you to load files like:
osgDB::readNodeFile("c:/data/models.zip/cow.osg");

I haven't used it for quite awhile but last I checked it was working
just fine.  You can get the osgearth source code from github at
https://github.com/gwaldron/osgearth

If anything it could be a start to what you're looking for.

Thanks,

Jason



On Sat, Jul 30, 2011 at 1:13 PM, Terry Welsh  wrote:
> I would like to be able to load from .zip files and also to be able to
> prioritize which paths or .zip files to load from using the standard
> OSG_FILE_PATH mechanism.  Has anyone done any work with integrating a
> virtual file system such that .zip files can be added as paths to
> OSG_FILE_PATH and osgDB::findDataFile and osgDB::readNodeFile can
> freely navigate these files?  I suspect this would require overriding
> way too many osgDB functions.  Is it even feasible?
>
> Just finished looking over the physfs tutorial (
> http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/VFS
> ).  It's very cool, but it doesn't appear to be as tightly integrated
> as what I want to do.
> --
> Terry Welsh
> mogumbo 'at' gmail.com
> www.reallyslick.com
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

[Glenn Waldron]

I was just thinking the same thing. :) Labels too.

Glenn Waldron / Pelican Mapping / @glennwaldron


On Fri, Aug 5, 2011 at 2:56 AM, J.P. Delport  wrote:

> Hi Jeremy,
>
> if this could be combined with osgEarth it would be very cool for overlays.
>
> rgds
> jp
>
>
> On 04/08/2011 21:23, Jeremy Moles wrote:
>
>> NVidia recently added an extension to their 275+ series of drivers
>> called "GL_NV_path_rendering." This turns path (sometimes called vector
>> graphics) rendering into first class drawables in OpenGL. Honestly, it's
>> one of the coolest things I've seen in a while, and naturally--given my
>> interest in OpenGL UIs--I began researching it and putting together a
>> NodeKit for OSG.
>>
>> You can find it (in its infancy) here:
>>
>> http://osgnvpr.googlecode.com
>>
>> Run the example thusly:
>>
>># osgnvprviewer
>># osgnvprviewer --perspective
>>
>> ..and notice how that no matter what the resolution, scale, or
>> projection, the objects are rendered clear and crisp. There is also
>> support for glyphs inside of GL_NV_path_rendering, so I will very soon
>> be adding support for this style of text rendering into osgPango (and
>> possible, osgText::TextNode).
>>
>> I've only just begun exploring this, and I'm mainly sending this e-mail
>> to see if there is any professional interest in seeing this NodeKit
>> mature in a timely fashion. I don't know if this is outside the
>> allowable etiquette of the lists, but in full disclosure I'm looking to
>> fill some free time by seeking funding for development of by those who
>> would not only use these features but could benefit from being able to
>> influence their development and pace! If this is inappropriate for the
>> lists, just let me know and I'll be sure and keep my peddling to a
>> minimum from here on out. :)
>>
>> At any rate, I'll continue to work on osgNVPR regardless, alongside
>> devleopment of osgCairo/Pango/Widget and the recent TextNode submission.
>> (Can you see a pattern here? All OSG interface development tools...)
>>
>> Some notes:
>>
>>- NV_path_rendering introduces a new kind of rendering "style" for
>> its
>> path objects. This doesn't map 1:1 to any existing usage of
>> osg::Drawable, though I am able to "hijack" the compileGLObjects()
>> method to get what I need. :)
>>
>>- BoundingBoxes are calculated with an extension call, but in order
>> to
>> use the extension I need a contextID (provided via either a State object
>> or RenderInfo object). Unfortunately, these are difficult to "get to" at
>> times, so CameraManipulators cannot properly determine a home position
>> unless the Path has been compiled.
>>
>> __**_
>> osg-users mailing list
>> osg-users@lists.**openscenegraph.org 
>> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
>> openscenegraph.org
>>
>>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at http://www.csir.co.za/**
> disclaimer.html .
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
> __**_
> osg-users mailing list
> osg-users@lists.**openscenegraph.org 
> 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] Animations, weights, and priority.

[Cedric Pinson]

I think think we could start on this page
http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation

And update it because I wrote it a long time ago

Cedric
On Fri, 2011-08-05 at 13:56 +0200, Peter Wrobel wrote:
> Hi,
> 
> I would like to participate. I'll be implementing skinning and working over 
> the animation module of the mentioned plug-in in about a month. At that time 
> I can work on a draft. 
> 
> @ Garthy, I'll be using you're observations so far if this is fine with you.
> @ Cedric, how should I get in touch with you at that time ?
> 
> 
> Thank you!
> 
> Cheers, ParticlePeter
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=41879#41879
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 

-- 
Cedric Pinson
Provide OpenGL, WebGL and OpenSceneGraph services
+33 659 598 614 - cedric.pin...@plopbyte.com
http://plopbyte.com - http://osgjs.org - http://showwebgl.com


signature.asc
Description: This is a digitally signed message part
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Animations, weights, and priority.

[Peter Wrobel]

Hi,

I would like to participate. I'll be implementing skinning and working over the 
animation module of the mentioned plug-in in about a month. At that time I can 
work on a draft. 

@ Garthy, I'll be using you're observations so far if this is fine with you.
@ Cedric, how should I get in touch with you at that time ?


Thank you!

Cheers, ParticlePeter

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





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

Re: [osg-users] osg::Geometry and GL_PRIMITVE_RESTART

[Peter Wrobel]

Hi,

Would it be possible for you to share you're implementation ? For me it is 
still not clear how to extend osg ( as you see on my question above ). 
I found this thread: 
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg46962.html

Sergey ( @hybr, is this you ? ) has created a new extension class: class 
MyExtensions: public osg::Referenced
wher he adds all possible extensions. I just wonder if this is the right way, 
or if one should not just be able to add the particular extension required to 
add a custom Drawable and or StateAttribute.

Its really hard to find any documentation on that part of osg. Community, it 
would be very nice if somebody could create a simple explanatory example, 
please.


Thank you!

Cheers, ParticlePeter

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





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

Re: [osg-users] osg::Geometry and GL_PRIMITVE_RESTART

[Sergey Polischuk]

Hi all

There are no direct support in osg for primitive restart extension.
I've tried using it in osg in custom drawable, but i've found that it was about 
3x times slower than either display lists with short tristrips or vbos with 
indexed triangle list on my hardware (295 gtx) so there isn't much reason to 
use them for me. If you going for primitive restart to get speed up you better 
test it first on your target hardware.

Cheers,
Sergey.

03.08.2011, 17:21, "Aurelien Albert" :
> Hi,
>
> I'm facing the same problem : I try to use
>
> Code:
> glPrimitiveRestartIndex(0x);
> glEnableClientState(GL_PRIMITIVE_RESTART);
>
> In my OSG 3.0 project.
>
> Is there any way to use these functions without a "big hack" of osg ?
>
> Thank you!
>
> Cheers,
> Aurelien
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=41823#41823
>
> ___
> 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] Alan Mecham is away August 5 -15.

[Alan R Mecham]

I will be out of the office starting  08/05/2011 and will not return until
08/15/2011.

I appologise for any inconvenances that this may cause, but I will get back
to you as soon as possible when I return. If you need someone for the Human
Performance and Simulation Lab, please contact David Gertman or Jacques
Hugo.

Best Regards
Alan Mecham___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] NVidia 275-series Driver Bug

[Sergey Polischuk]

Hi, John For me it works on new drivers if i append "[0]" to uniform array name, BUT it wont work on old driver anymore with this change. So for now in our apps we have to use two uniforms for each uniform array, one original and another with "[0]" appended so stuff actually works on both old and new drivers...Cheers,Sergey.05.08.2011, 12:22, "John Ivar Haugland" :FYI, I just tested the new NVIDIA beta driver 280.19. Same problem as with 275 series.John IvarOn Wed, Jul 27, 2011 at 3:56 PM, Jeremy Moles  wrote:On Wed, 2011-07-27 at 12:06 +0400, Sergey Polischuk wrote:> Hi Jeremy>> You can try to append "[]" to array uniform name string when create osg::Uniform, mb this helps.It won't because it seems that internally OSG changes:       Color...to...       Color[0]...even, on non-array Uniforms.If I edit Program.cpp and remove this behavior (that is, the appending of the "[0]" to uniform names), it works again. This issue was alsodiscussed briefly here:http://forum.openscenegraph.org/viewtopic.php?t=1828 Robert responded saying it was truly a bug with the driver, which maystill be the case. However, if I write a small, pure OpenGL application,EITHER syntax works ("Color" or "Color[0]"). If it is a driver bug, it is only one that is exercised by by some state leakage or similar...My fear is that this is going to remain an issue for NVidia driversgoing forwards, but we'll have to see... perhaps someone with more authoritative knowledge can comment on why this could be happening. > 27.07.2011, 09:51, "Jeremy Moles" :> > On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:> > > >>  Hello folks! Anyone here using the 275 series of NVidia drivers?> >>  (Doesn't matter what OS, the bug is on Linux and Windows for me...)> >>> >>  It appears that this driver doesn't understand GLSL arrays anymore. At > >>  least, not like it used to. Crazy, huh? Yeah, I thought so too.> >>> >>  I've attached a __VERY__ simple application demonstrating this. If> >>  anyone has a sec (particularly Mike Wieblen), I'd be interested to see > >>  if they could compile it and perhaps shed some light on this mystery. :)> >>> >>  I've been googling and checking the NVidia forums, but so far nothing.> >> > There have been a few replies to this original thread, and I'm not > > trying to beat a dead horse here, but I recently purchased a video card> > that is ONLY support by 275+ (in Linux). So I'm back to investigating> > this issue.> >> > If I use GLSL arrays via OSG, as demonstrated in the example app, it > > completely misbehaves. However, non-array uniforms are just fine.> >> > Interestingly, if I write a purse OpenGL application using GLSL arrays,> > that works just fine. Is it possible there's some kind of bug in OSG > > that these newer drivers expose? I don't imagine they're going to "fix"> > this for OSG, so eventually people will have to upgrade to 275 and> > beyond...> >> > I've been trying to track down the issue, but have had no luck so far. > > I'll keep investigating, but if anyone has acquired any NEW information> > in the last month, that would be stellar. :)> >> >>  ___ > >>  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 listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org___osg-users mailing listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt, Manipulator keyEvent, Seeking for Help in an Emergency

[J.P. Delport]

Hi,

AFAIK alt must be pressed with some other key before you'll get an event.

jp

On 05/08/2011 09:59, ramy panda wrote:

Hi,

In my codes, i rewrite keyPressEvent function like below:


void AdapterWidget::keyPressEvent( QKeyEvent* event )
{
 _gw->getEventQueue()->keyPress( (osgGA::GUIEventAdapter::KeySymbol) 
*(event->text().toAscii().data() ) );
}



In my osg codes, i write like this:


bool ManipulatorEventHandler::handle(const osgGA::GUIEventAdapter&  ea, 
osgGA::GUIActionAdapter&  aa,
 osg::Object*, osg::NodeVisitor*)
{

 bool alt = (ea.getModKeyMask()&  
(osgGA::GUIEventAdapter::MODKEY_LEFT_ALT|osgGA::GUIEventAdapter::MODKEY_RIGHT_ALT)) 
!= 0;
 if (alt) return false;

 if (ea.getEventType() == osgGA::GUIEventAdapter::KEYDOWN)
 {
 switch (ea.getKey())
 {
 case 'r': resetTransform(); break;
 }
 }

 return true;
}


but when i press alt key there is no reponse in my application. I need a help 
in an emergency and i'm waiting answer online. Thanks very much.

Thank you!

Cheers,
ramy

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





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


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.


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

Re: [osg-users] Animations, weights, and priority.

[Cedric Pinson]

It Looks like we need a document explaining the behaviour of animation.
I would be happy to start this but I am really busy to do it.
If anyone want to start it, I will be happy to re read it, and try to
help.

Cedric
On Fri, 2011-08-05 at 10:23 +0200, Peter Wrobel wrote:
> Hi Garth,
> 
> I am as well interested in the answer of your questions, and you're 
> explenation helped me in my understanding. I would like to ask you to keep on 
> posting your observations in this thread.
> 
> I am co-author of maya2osg, have implemented rudimentary animation support ( 
> only transforms, no skining till now ) and I face some problems with 
> exporting maya trax animation clips to osgAnimation.
> 
> What you described is an automatic weight normalization of running clips with 
> similar priorities. If this is allways active, its not possible to add up 
> animation channels of different animations ( mayas behaviour ). 
> E.g. when splitting up walkcycles into legs and arms animations, to be able 
> to recombine them, the arm animations will half the weights of the leg 
> animations, and vice versa. If you face the same issues, or anybody else, 
> would be glad to hear of a sollution.
> 
> Thank you!
> 
> Cheers, ParticlePeter
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=41869#41869
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 

-- 
Cedric Pinson
Provide OpenGL, WebGL and OpenSceneGraph services
+33 659 598 614 - cedric.pin...@plopbyte.com
http://plopbyte.com - http://osgjs.org - http://showwebgl.com


signature.asc
Description: This is a digitally signed message part
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [forum] Problem with OcclusionQueryNode with no children

[Revanth Reddy]

Hi,

My code loads a scenegraph where all children are OcclusionQueryNodes and no 
geometry. Based on the spatial location of the camera I load and attach the 
geometry to the respective OQNode and set the Queries enabled for that OQNode. 
So at any time only a few OQNodes of my scenegraph have children attached and 
queries enabled.

My problem is I am only able to render the scene when all the OQNodes have 
children. Nothing is visible even if one OQNode has no children. How can I fix 
this ?

... 


Thank you!

Cheers,
Revanth

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





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

Re: [osg-users] [build] Can't build version osg 2.9.11 for IOS using CMake

[Stephan Maximilian Huber]

Hi,

Am 04.08.11 05:16, schrieb Aruna Faster:
> Any help greatly appreciated.

Can you provide some more details, like used cMake- and XCode-version,
what OS you are using?

Seems like a bug with cmake and a newer xcode version when compiling
with the IOS-sdk:

http://cmake.org/Bug/view.php?id=12288

It works on my machine with xcode 3.2.x and cmake 2.8.x

Perhaps you can use the xcode-project files from
https://github.com/stmh/osg/tree/iphone

cheers,

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

Re: [osg-users] Animations, weights, and priority.

[Peter Wrobel]

Hi Garth,

I am as well interested in the answer of your questions, and you're explenation 
helped me in my understanding. I would like to ask you to keep on posting your 
observations in this thread.

I am co-author of maya2osg, have implemented rudimentary animation support ( 
only transforms, no skining till now ) and I face some problems with exporting 
maya trax animation clips to osgAnimation.

What you described is an automatic weight normalization of running clips with 
similar priorities. If this is allways active, its not possible to add up 
animation channels of different animations ( mayas behaviour ). 
E.g. when splitting up walkcycles into legs and arms animations, to be able to 
recombine them, the arm animations will half the weights of the leg animations, 
and vice versa. If you face the same issues, or anybody else, would be glad to 
hear of a sollution.

Thank you!

Cheers, ParticlePeter

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





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

Re: [osg-users] NVidia 275-series Driver Bug

[John Ivar Haugland]

FYI, I just tested the new NVIDIA beta driver 280.19. Same problem as with
275 series.
John Ivar

On Wed, Jul 27, 2011 at 3:56 PM, Jeremy Moles wrote:

> On Wed, 2011-07-27 at 12:06 +0400, Sergey Polischuk wrote:
> > Hi Jeremy
> >
> > You can try to append "[]" to array uniform name string when create
> osg::Uniform, mb this helps.
>
> It won't because it seems that internally OSG changes:
>
>Color
>
> ...to...
>
>Color[0]
>
> ...even, on non-array Uniforms.
>
> If I edit Program.cpp and remove this behavior (that is, the appending
> of the "[0]" to uniform names), it works again. This issue was also
> discussed briefly here:
>
> http://forum.openscenegraph.org/viewtopic.php?t=1828
>
> Robert responded saying it was truly a bug with the driver, which may
> still be the case. However, if I write a small, pure OpenGL application,
> EITHER syntax works ("Color" or "Color[0]"). If it is a driver bug, it
> is only one that is exercised by by some state leakage or similar...
>
> My fear is that this is going to remain an issue for NVidia drivers
> going forwards, but we'll have to see... perhaps someone with more
> authoritative knowledge can comment on why this could be happening.
>
> > 27.07.2011, 09:51, "Jeremy Moles" :
> > > On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:
> > >
> > >>  Hello folks! Anyone here using the 275 series of NVidia drivers?
> > >>  (Doesn't matter what OS, the bug is on Linux and Windows for me...)
> > >>
> > >>  It appears that this driver doesn't understand GLSL arrays anymore.
> At
> > >>  least, not like it used to. Crazy, huh? Yeah, I thought so too.
> > >>
> > >>  I've attached a __VERY__ simple application demonstrating this. If
> > >>  anyone has a sec (particularly Mike Wieblen), I'd be interested to
> see
> > >>  if they could compile it and perhaps shed some light on this mystery.
> :)
> > >>
> > >>  I've been googling and checking the NVidia forums, but so far
> nothing.
> > >
> > > There have been a few replies to this original thread, and I'm not
> > > trying to beat a dead horse here, but I recently purchased a video card
> > > that is ONLY support by 275+ (in Linux). So I'm back to investigating
> > > this issue.
> > >
> > > If I use GLSL arrays via OSG, as demonstrated in the example app, it
> > > completely misbehaves. However, non-array uniforms are just fine.
> > >
> > > Interestingly, if I write a purse OpenGL application using GLSL arrays,
> > > that works just fine. Is it possible there's some kind of bug in OSG
> > > that these newer drivers expose? I don't imagine they're going to "fix"
> > > this for OSG, so eventually people will have to upgrade to 275 and
> > > beyond...
> > >
> > > I've been trying to track down the issue, but have had no luck so far.
> > > I'll keep investigating, but if anyone has acquired any NEW information
> > > in the last month, that would be stellar. :)
> > >
> > >>  ___
> > >>  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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Qt, Manipulator keyEvent, Seeking for Help in an Emergency

[ramy panda]

Hi,

In my codes, i rewrite keyPressEvent function like below:

> void AdapterWidget::keyPressEvent( QKeyEvent* event )
> {
> _gw->getEventQueue()->keyPress( (osgGA::GUIEventAdapter::KeySymbol) 
> *(event->text().toAscii().data() ) );
> }


In my osg codes, i write like this:

> bool ManipulatorEventHandler::handle(const osgGA::GUIEventAdapter& ea, 
> osgGA::GUIActionAdapter& aa,
> osg::Object*, osg::NodeVisitor*)
> {
> 
> bool alt = (ea.getModKeyMask() & 
> (osgGA::GUIEventAdapter::MODKEY_LEFT_ALT|osgGA::GUIEventAdapter::MODKEY_RIGHT_ALT))
>  != 0;
> if (alt) return false;
> 
> if (ea.getEventType() == osgGA::GUIEventAdapter::KEYDOWN)
> {
> switch (ea.getKey())
> {
> case 'r': resetTransform(); break;
> }
> }
> 
> return true;
> }

but when i press alt key there is no reponse in my application. I need a help 
in an emergency and i'm waiting answer online. Thanks very much.

Thank you!

Cheers,
ramy

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





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

Re: [osg-users] osgAndroidExampleGLES1 crashed

[Jorge Izquierdo Ciges]

Oh good now we are talking the same languaje ^__^ happy!

Ok if you read the exception carefully is obvious where the error comes.

*Caused by: java.lang.UnsatisfiedLinkError: Library osgNativeLib not found*


That means what it means he hasn't found the native part of the application.
Short version. Android aplications can be full or half native. Full native
can only be achieved in 2.3 and3.x. The examples are in half native half
java dalvik code. What you have done is compiling ONLY the java/dalvik part.
You need to compile the Native C part. It's confusing... I know well xD.
Read the documentation for the proper way to deploy a native application (in
Google Io 2011 there's a conference that treat that theme) or just simplify
your life with sequoyah an extension to Eclipse. You will only need to state
that your project has native code, the name of the library and the route to
NDK and he will manage just fine.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org