[osg-users] OSG version for Node-derivation of Drawable?

[Paul Martz]

Hi all -- A while back, OSG changed so that Geode derives from Group and
Drawable derives from Node. Can someone tell me the first OSG version number
that contained this change? I have some code in osgWorks that I need to
conditionally compile based on this version number. Thanks.
   -Paul


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

Re: [osg-users] is osgEphemeris incompatible with osgShadow?

[Paul Martz]

The official osgEphemeris repo is now on Google Code:
https://code.google.com/p/osgephemeris/
Please submit any changes as an issue and attach a patch. Thanks.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL NG: thoughts?

[Paul Martz]

I like the idea of revamping the OpenGL API.

In fact, I liked that idea when it was originally proposed in 2007 as
"OpenGL 3". Unfortunately, most other developers did not like what Khronos
and the ARB put forth in that design. It was not well-received. The final
OpenGL v3.0 spec came out a year later with almost no mention of the
previous year's promised sweeping API changes. Most hardware vendors found
themselves doing a mea culpa, recommitting to the FFP and promising
software vendors continued support and backwards compatibility. Will OpenGL
NG suffer the same fate? Let's see how it's marketed. They'll have to do
something different this time, that's for certain.

OpenGL v3.1 subsequently introduced the concepts of compatibility and core
profiles. Most of my recent work has been directly with OpenGL v4.x core
profile, and I've found it to be an amazingly flexible and powerful API. I
like the idea that I'm writing code for a state-of-the-art API and not
depending on deprecated functionality.

But apparently this was a false sense of security for me. Little is known
about OpenGL NG at this time, but one thing is almost certain: It will bear
little resemblance to OpenGL core profile. So, while I thought I was
writing state-of-the-art code, and was telling my clients it was the right
thing to do for a long-term investment, it now appears that OpenGL NG is
going to invalidate that.

I've been in the 3D graphics industry for almost 30 years and I've seen
APIs come and go. If you would've told me back in 1994 that I'd still be
working with OpenGL today, I would've laughed in your face. OpenGL FFP has
had an unprecedented run -- testimony to a great API. But there are new
kids in charge now, and they want to take OpenGL in a new direction, to
make it a better fir for today's chips, systems, and programming use cases.

Thus, my first point: Change is going to happen. OpenGL has been very
stable, but maintaining that stability forever would probably be harmful to
the API in the long run. As developers, we like stability. But we also jump
on new technologies as they come out. OpenGL NG? Some of us will like it,
some of us won't.


Secondly: Note that OpenGL NG is just vaporware at this point. The
announcement mentions several other new APIs that have been recently become
available. In my career, I have seen a lot of marketing FUD. I don't know
whether OpenGL NG will ever be a reality or not, but right now it smells a
little like FUD, dangling the promise of a shiny new redesigned OpenGL API
in front of any OpenGL developers considering jumping ship to another API.


Third, and finally. I'm tired of the OpenGL versus DirectX debate. I am so
tired of it. If Khronos feels it needs to churn out an OpenGL NG solely for
the purposes of "competing" with DirectX, then that is a sad statement.
OpenGL's evolution should not be driven by "team mentality".

I hate what Microsoft has done to try to kill OpenGL. Every time I start a
new OpenGL-based project that must be cross-platform, I have to re-evaluate
which one of the crappy GLEW-like kludges I'm going to use to get the code
running on Windows.

Has anyone from Khronos approached Microsoft regarding a single unified
API? I doubt it. "Remember Fahrenheit," yeah, yeah. But I have to wonder if
Microsoft is also getting tired of this particular API war. They are in an
especially vulnerable spot now, given the prevalence of OpenGL on embedded
devices, and their recent disastrous Windows 8. They might see some benefit
to contributing to OpenGL, rather than continue to fight it. This is not
the first time I've publicly stated that Khronos/ARB and Microsoft should
work together. It benefits us, and it benefits them. Call me an idealist.


If you've read this far, then you've indulged me much further than I
deserve. Go back to work. :-)


On Mon, Aug 11, 2014 at 5:13 PM, Ethan Fahy  wrote:

> OpenGL NG was announced today and is a complete API break.  It's not clear
> what the timeframe is on this project, but it does seem like a big deal
> long-term with major implications for OSG.  I'd be curious to hear any
> opinions on this development from the OSG community.
>
>
> http://www.anandtech.com/show/8363/khronos-announces-next-generation-opengl-initiative
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=60633#60633
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] transforming a directional vector into eye-space

[Paul Martz]

The OpenGL spec and GLSL both use post-multiply notation. OSG uses
pre-multiply notation. The two produce identical results because they do
the same thing internally.
   -Paul


On Mon, Aug 11, 2014 at 3:06 PM, Bram Vaessen 
wrote:

> thanks I noticed I had to use the (vec3, matrix) version instead of the
> (matrix, vec3) version to make it work. So that does a v*M[0..2,0..2]
>
> However in the shader (glsl) it's gl_NormalMatrix * gl_Normal...
>
> seems to be the other way around. Any clarification on this?
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pulling texture(s) off an object after each rendered frame and put them in an osg::Texture*...

[Paul Martz]

OSG doesn't have any facilities for this.

When you project a texture onto an object, or cube map a texture onto an
object, the texture coordinates are generated via FFP functionality or
procedurally in your vertex shader. And you now want the texels, as it
appears on the surface of an object, stored as a 2D image?

It seems like you'd need to have a mapping of your procedurally generated
texture coordinates to normalized 2D texture coordinates. Then you could
render a fullscreen textured quad with that mapping implemented in a
shader, and read back the rendered image of the quad. There might be other
approaches, but that's the strategy I'd try.

But, as I said, OSG does not have any existing utilities for that. You'd
have to write the code yourself.


On Thu, Aug 7, 2014 at 9:00 AM, Conan  wrote:

> Let me add some more detail/info to my question
>
> I am using RTT to create/modify a set of textures... actually a
> osg::TextureCubeMap
> I am taking this TextureCubeMap and projecting it onto an object.
> After I project the CubeMap onto the object I want peel this texture, or
> surface of the object, off as a single texture.
>
>
> On 2014-08-07 08:49, Paul Martz wrote:
>
>> If you are creating/modifying the textures in shaders, then you must
>> be rendering to texture using an FBO. Are you doing this with an
>> osg::Camera? If so, then you already have an osg::Texture attached to
>> your osg::Camera, right?
>>
>> You said you need them in an osg::Texture. Why? Are you actually
>> saying that you need a copy of the texture image data in host memory?
>>
>> If you attach an osg::Image as the color attachment for your
>> osg::Camera, it will automatically do a glReadPixels to read the
>> rendered image data into the osg::Image's host memory buffer.
>>
>> If you're not using any OSG constructs to create / modify the OpenGL
>> texture object, then just use OpenGL calls to read the texel data from
>> GPU back to host, and create an osg::Image / osg::Texture object with
>> that texel data..
>>
>> On Thu, Aug 7, 2014 at 8:36 AM, Conan  wrote:
>>
>>  Hi,
>>>
>>> I need to pull the texture(s) off an object after each rendered
>>> frame and put them in an osg::Texture*... (Not sure I said that all
>>> correctly, but...)  these textures are not loaded with the original
>>> geometry, are not in files, etc.  They are generated at startup and
>>> attached and modified through shaders each frame.
>>>
>>> I assume I need to use a post draw camera callback, but I am not
>>> sure how to get the textures since they don't have a filename
>>> associated with them in the stateset.
>>>
>>> Any suggestions?
>>>
>>> CD
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>>
>>>  http://lists.openscenegraph.org/listinfo.cgi/osg-users-
>> openscenegraph.org
>>
>>> [1]
>>>
>>
>> --
>>
>>-Paul
>>
>>
>>
>> Links:
>> --
>> [1] 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
>



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

Re: [osg-users] Pulling texture(s) off an object after each rendered frame and put them in an osg::Texture*...

[Paul Martz]

If you are creating/modifying the textures in shaders, then you must be
rendering to texture using an FBO. Are you doing this with an osg::Camera?
If so, then you already have an osg::Texture attached to your osg::Camera,
right?

You said you need them in an osg::Texture. Why? Are you actually saying
that you need a copy of the texture image data in host memory?

If you attach an osg::Image as the color attachment for your osg::Camera,
it will automatically do a glReadPixels to read the rendered image data
into the osg::Image's host memory buffer.

If you're not using any OSG constructs to create / modify the OpenGL
texture object, then just use OpenGL calls to read the texel data from GPU
back to host, and create an osg::Image / osg::Texture object with that
texel data..



On Thu, Aug 7, 2014 at 8:36 AM, Conan  wrote:

> Hi,
>
> I need to pull the texture(s) off an object after each rendered frame and
> put them in an osg::Texture*... (Not sure I said that all correctly,
> but...)  these textures are not loaded with the original geometry, are not
> in files, etc.  They are generated at startup and attached and modified
> through shaders each frame.
>
> I assume I need to use a post draw camera callback, but I am not sure how
> to get the textures since they don't have a filename associated with them
> in the stateset.
>
> Any suggestions?
>
> CD
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Hole in extrusion

[Paul Martz]

This seems like the age-old "you can't draw a flat-shaded cube with 8
vertices" dilemma.

Don't you need to repeat the same xyz vertex possibly multiple times? So
that you can have a different normal at the same vertex, depending on which
face you're rendering.
   -Paul


On Wed, Jul 23, 2014 at 8:25 AM, Yu Zhang  wrote:

> Hi everyone,
>
> Could anyone share some experience on handle 3D hole drawing?
> My implementation seems not good, the details are:
>
> Suppose a small rect is a hole inside a big rect:
> [img]http://www.youpic.tk/view.php?filename=706Hole.png[/img]
>
> The vertices are 0, 1, 2, 3, 4, 5, 6, 7. I'll do:
> 1) for extrusion direction, add some vertices in top plane. vertex 8, 9,
> 10, 11, 12, 13, 14, 15. Each vertex is offset from a bottom vertex. eg: 0
> ->8,
> 1 -> 9...
> 2) Use tessellator to process the bottom plane, get some prim sets with
> triangles.
> 3) For each triangles in bottom, add a side face prim set from top plane
> triangle. eg, for triangle 236, use 10, 11, 14. The side face's triangle
> strip is 2, 10, 3, 11, 6, 14, 2, 10.
> 4) Add all side faces for each triangles, add bottom, top planes.
>
> The result looks correct, but it have unnecessary side faces inside model.
> It sounds do no harm, but if it enable lighting, the look feel is not good:
> [img]http://www.youpic.tk/view.php?filename=474NotgoodLighting.png[/img]
>
> Turn off lighting seems ok, but it lacks lighting. Maybe this is more like
> a modeling question, could you please share your experience, thanks!
> Attached the picture also.
>
> Thank you!
>
> Cheers,
> Yu[/img]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=60411#60411
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] How to cancel transparency ?

[Paul Martz]

In the osgWorks osgwTools library, TransparencyUtils.cpp, I enable
transparency by first copying the original StateSet and saving it as
UserData, then modifying the active StateSet to turn on transparency
(BlendFunc, RenderBin, etc).

To disable transparency, I simply restore the original StateSet from
UserData.
   -Paul



On Fri, May 30, 2014 at 5:08 AM, sunpeng  wrote:

> I use following code to set transparency:
>
> osg::StateSet* state = root->getOrCreateStateSet();
>
>
> state->setMode(GL_LIGHTING,osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED);
>
> state->setMode(GL_BLEND,osg::StateAttribute::ON);
> state->setMode(GL_DEPTH_TEST,osg::StateAttribute::ON);
> state->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
>
> osg::BlendColor* bc =new osg::BlendColor(osg::Vec4(1.0,1.0,1.0,0.0));
> osg::BlendFunc*bf = new osg::BlendFunc();
> state->setAttributeAndModes(bf,osg::StateAttribute::ON);
> state->setAttributeAndModes(bc,osg::StateAttribute::ON);
> bf->setSource(osg::BlendFunc::CONSTANT_ALPHA);
> bf->setDestination(osg::BlendFunc::ONE_MINUS_CONSTANT_ALPHA);
> bc->setConstantColor(osg::Vec4(1,1,1,0.5));
>
> How to close transparency effect? I tried to use:
>  state->setMode(GL_BLEND,osg::StateAttribute::OFF);
>  state->setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF);
>
> but it seems not work?
> tks!
>
> peng
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

[osg-users] Question on CullVisitor::getRenderStage()

[Paul Martz]

Hi Robert (and all) --

I want to get the view matrix, projection matrix, and viewport from the
current slave Camera in a multi-display environment, and I want to get them
from a cull callback (which could be buried beneath a HUD Camera or
post-render processing Camera).

I think this is what I want to call:
CullVisitor::getRenderStage();

I can see from the code that it returns the "root" RenderStage. But what
exactly is that? Is it the RenderStage associated with the slave Camera? Or
with the top-level osgViewer::Viewer's "master" Camera that drives the
slaves?

Thanks for any info.

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

Re: [osg-users] OpenScenegGraph-3.2.1 release candidate 3 tagged, please test in prep for 3.2.1 release

[Paul Martz]

It looks like the osg::Geometry changes (deriving from osg::Node) are not
on the 3.2 branch, just on trunk. Is that correct?
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Obsolete osg-users archive search index?

[Paul Martz]

FYI, osg-users posts have been reflected to a Google Group for at least the
past six years, so you should just be able to search using Google. The
group is here:
http://groups.google.com/forum/#!forum/osg-users

I hope people find this helpful.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] New LUA plugin fails to link

[Paul Martz]

Hi Robert -- There is a new plugin, LUA, which fails to link on Windows
when building current trunk. It looks like multiply defined symbols. I'm
building for GLCORE, but that's probably irrelevant. I'm using the default
setting for the LUA local source CMake variable.

Here's the output:

1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@D@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@E@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@F@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@G@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@H@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@I@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@M@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@N@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)"
(??$getTypeEnum@PEAVImage@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)"
(??$getTypeEnum@PEAVObject@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum
>(void)" (??$getTypeEnum@V?$BoundingBoxImpl@VVec3d@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum
>(void)" (??$getTypeEnum@V?$BoundingBoxImpl@VVec3f@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum
>(void)" (??$getTypeEnum@V?$BoundingSphereImpl@VVec3d@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum
>(void)" (??$getTypeEnum@V?$BoundingSphereImpl@VVec3f@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum,class std::allocator > >(void)"
(??$getTypeEnum@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@
@std@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)"
(??$getTypeEnum@VMatrixd@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)"
(??$getTypeEnum@VMatrixf@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@VPlane
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@VQuat
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@VVec2b
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnum(void)" (??$getTypeEnum@VVec2d
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1>ReaderWriterLua.obj : error LNK2005: "enum osgDB::BaseSerializer::Type
__cdecl osgDB:

Re: [osg-users] New scheme for configuring the OSG for building against different versions of the OpenGL/OpenGL ES

[Paul Martz]

On Fri, Apr 25, 2014 at 2:25 AM, Robert Osfield wrote:

> Now things are compiling OK for you, could you let me know which bits
> if any of the original post you now want merged.
>

Thanks, Robert. I re-posted this to osg-submissions, in the original thread.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] New scheme for configuring the OSG for building against different versions of the OpenGL/OpenGL ES

[Paul Martz]

I'm still seeing this issue with trunk r14158.


On Wed, Apr 23, 2014 at 9:34 AM, Robert Osfield wrote:

> Hi Alberto,
>
> On 23 April 2014 16:18, Alberto Luaces  wrote:
> > It seems that OpenGL.in is uncommited:
> >
> > $ cmake .
> > CMake Error: File /.../src/osg/OpenGL.in does not exist.
>
> Sorry about this, files now checked in.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Easy blur effect with HUD Camera?

[Paul Martz]

If you're not picky about the blur quality, just render to a texture that
is 1/16th the size of your screen (1/4 width x 1/4 height), then apply the
texture to a fullscreen quad with GL_LINEAR filtering. This can be
accomplished with OpenGL v1.0 functionality and should be fast and
well-supported on all graphics cards.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL 3.x and OSG

[Paul Martz]

Unless, of course, you're actually trying to create a modern application.
Then you really do want core profile and must build OSG for GL3. Otherwise,
deprecated OpenGL usage will inevitably creep into your app code.

The OSG warnings in the OP's post really do serve a purpose. They alert you
to the fact that you're accessing outdated functionality, so that you can
proactively remove it.
   -Paul


On Thu, Mar 20, 2014 at 5:47 AM, Alistair Baxter  wrote:

> If you're only running on Windows, you'd be just as well not trying to
> build an OpenGL 3 core profile version of OSG, since by default it will use
> the most up-to-date version of OpenGL your card supports (probably
> 4.something), with the compatibility profile.
>
> That way you can get all of the new functionality, and all of the old
> functionality too.
>
> OpenGL's deprecation is only really enforced on OSX, so unless you are
> doing a mac port, it's probably easier to ignore it.
>
> Alistair Baxter
> Software Engineer
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Solar/Lunar Pos/osgEphemeris

[Paul Martz]

Yes, osgEphemeris can be used for calculation only.

osgEphemeris was moved from its old home to Google Code. Get the latest
from here: http://osgephemeris.googlecode.com.
   -Paul

On Thu, Mar 20, 2014 at 7:01 AM, Conan  wrote:

> I need to calculate the position of the sun/moon in my code.  Can
> osgEphemeris do this without utilitizing it for any rendering tasks?  I
> just need the data not rendering capabilities.
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Quick Start still valid?

[Paul Martz]

I was intending to update the Quick Start Guide a while back, but was
unable to follow through with that due to other commitments. It's still on
my to-do list. Specific changes I have in mind include:

 - Update section on best practice for functions returning ref_ptr'd memory.
 - Switch over to current .osgt/.osgb file format.
 - More use of shaders and less use of FFP.
 - More diagrams and illustrations.

That being said, I agree with Robert's statement that the Quick Start Guide
is still valid for the most part.

   -Paul



On Tue, Mar 18, 2014 at 9:08 AM, Robert Osfield wrote:

> On 18 March 2014 13:10, Conan Doyle  wrote:
>
>> Is the OOSGQ Quick Start guide still valid for OOSG 3.X?
>>
>
> There are a few differences but the majority of the OSG will look quite
> similar - the basic concepts and majority of the core classes are the same
> or very similar.
>
> Robert.
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] OSG static linking

[Paul Martz]

Setting OSG_MSVC_VERSIONED_DLL to OFF appears to fix this issue, and causes
the static .lib names to not contain the SO version. (After I rebuild with
this set to OFF, I'm guessing the stock CMake find scripts will find my
static-built OSG.)

Is that correct? The CMake variable clearly says "DLL", and this is a
static build, so no DLLs are being built. Yet disabling it changes the name
of the output static .lib name.

Just checking.


On Wed, Mar 12, 2014 at 3:17 PM, Paul Martz  wrote:

> Hi all -- Is anyone using CMake to find a static-built OSG? If so, how are
> you getting that to work?
>
> When building static OSG, all the library names are prefixed with
> osg. For example, with OSG v3.3.1, the so version is 111, so I
> get libs named: osg111-osg.lib, osg111-osgDB.lib, osg111-osgUtil.lib, etc.
> And the stock CMake find scripts fail to find those libraries because those
> scripts look for osg.lib, osgDB.lib, osgUtil.lib, etc.
>
> Any info would be appreciated.
>-Paul
>



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

Re: [osg-users] OSG static linking

[Paul Martz]

Hi all -- Is anyone using CMake to find a static-built OSG? If so, how are
you getting that to work?

When building static OSG, all the library names are prefixed with
osg. For example, with OSG v3.3.1, the so version is 111, so I
get libs named: osg111-osg.lib, osg111-osgDB.lib, osg111-osgUtil.lib, etc.
And the stock CMake find scripts fail to find those libraries because those
scripts look for osg.lib, osgDB.lib, osgUtil.lib, etc.

Any info would be appreciated.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG static linking

[Paul Martz]

Robert, Chris, Rui -- Thank you all for the information. Very helpful.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG static linking

[Paul Martz]

If OSG is linked statically, obviously I need to reference a plugin with
the USE_OSGPLUGIN macro.

Is there any way I can determine at compile time whether the OSG I'm
linking against was built as static or dynamic? I want to use USE_OSGPLUGIN
if OSG was built static, and not use it otherwise, right?

Should USE_OSGPLUGIN be defined as a no-op if OSG is built dynamic?

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

Re: [osg-users] Enabling instancing should automatically disable display lists

[Paul Martz]

How would you propose this work? Instancing is a property of the
PrimitiveSet, and display list usage is a property of the Geometry object.
Would you modify Geometry::addPrimitiveSet() to look for use of instancing,
and if detected, disable display lists? What if the instanced PrimitiveSets
are subsequently deleted? Would you need some way to save the original
setting of display lists so that it could be restored?
   -Paul

On Mon, Mar 3, 2014 at 12:09 PM, Trystan Larey-Williams  wrote:

> Wouldn't it makes sense to automatically disable display lists in the case
> instancing is enabled?
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Unresolved symbol

[Paul Martz]

Thanks, Robert -- That change resolved the issue.
   -Paul

On Sat, Feb 8, 2014 at 5:58 AM, Robert Osfield wrote:

> Hi Paul,
>
> Sorry about the error.  I missed changing the export #define from
> OSGUI_EXPORT to OSGGA_EXPORT.  I've fixed this and checked it into
> svn/trunk, hopefully this will resolve all the issues.
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Unresolved symbol

[Paul Martz]

Hi Robert -- I'm getting this linkger error from the osgGA serializer with
svn trunk.

3>Widget.obj : error LNK2019: unresolved external symbol "public: __cdecl
osgGA::Widget::Widget(void)" (??0Widget@osgGA@@QEAA@XZ) referenced in
function "class osg::Object * __cdecl
wrapper_createinstancefuncWidget(void)" (?wrapper_createinstancefuncWidget@
@YAPEAVObject@osg@@XZ)
3>C:\Projects\deps\osg-331-gl3\bld\bin\osgPlugins-3.3.1\osgdb_serializers_osggad.dll
: fatal error LNK1120: 1 unresolved externals

This if for a GL3 build, and I haven't tried an FFP build yet, but I expect
the issue has nothing to do with GL3.

I can take a closer look at this Saturday/tomorrow; I'm pretty much calling
it a night for now.

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

Re: [osg-users] Building for GL3 - need your input

[Paul Martz]

Hi Robert --

I have another, simpler, option to the cmake issue, and that is for me to
just add the include path to Visual Studio's include paths.

Then, the only change I'd want to submit, would be to change  to
, and unless I hear otherwise, I'd do that for Windows only.

It's a bit of a mess, but osg/GL seems to be handling things OK. I have
used other projects that owned/incorporated the GL header, and it
introduced many issues. Probably better to just have one "system" GL header
that all projects share.
   -Paul


On Fri, Feb 7, 2014 at 10:42 AM, Robert Osfield wrote:

> Hi Paul et. al,
>
> Perhaps another, controversial, route could be to embed the official
> headers within the OSG headers.
>
> I'm open to suggestions as it's presently a bit of mess with various
> versions of GL headers being renamed as versions have come and gone.
>
> Robert.
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Building for GL3 - need your input

[Paul Martz]

Hi all -- There's been a long-standing issue related to building OSG for
OpenGL3 on Windows, and that is the need to manually edit the
CMAKE_CXX_FLAGS variable to add the include path "/I" for wherever you have
placed the gl3.h (or glcorearb.h) header file. This is a problem because it
requires use of cmake-gui and makes it impossible to use cmake from command
line.

I'd like to add a "FindGL3.cmake" script to automate locating the GL3
header file.

My question is, do we need this solution only for Windows? I think this is
the case. I'm fairly certain this is *not* an issue for OSX. Linux is
really my question. Has anyone built OSG for OpenGL3 on Linux, and if so,
did you need to do anything special to find the GL3 header file?

While I'm making this change, I'd like to update the header used by OSG.
 is outdated. I'll submit a change that moves us to the
opengl.orgcurrent standatd .

Any input on this change would be appreciated. I'll put together a
submission shortly.

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

Re: [osg-users] Compile error, DDS plugin, GL_RG_SNORM and GL_RED_SNORM

[Paul Martz]

Hey Robert -- If no one else has any strong feelings on this, then I'll
request you proceed to apply my "Fixes for GL3 build" as posted to
osg-submissions. (As time allows, of course.) Thanks!
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Compile error, DDS plugin, GL_RG_SNORM and GL_RED_SNORM

[Paul Martz]

Thanks for the reply, Mathieu.

Hm. I don't think this is an OSX-only problem. I'm running into it on
Windows using current glcorearb.h from opengl.org.


On Thu, Nov 28, 2013 at 3:31 AM, Mathieu MARACHE
wrote:

> Hi Paul,
>
> I'm following your tracks it seems, I've gone forward with the easy way :
>
> --- a/src/osgPlugins/dds/ReaderWriterDDS.cpp
> +++ b/src/osgPlugins/dds/ReaderWriterDDS.cpp
> @@ -873,12 +873,15 @@ osg::Image* ReadDDSFile(std::istream& _istream, bool
> flipDDSRead)
>  pixelFormat= GL_RG;
>  dataType   = GL_UNSIGNED_BYTE;
>  break;
> -
> +#if defined(__APPLE__) && defined(OSG_GL3_AVAILABLE)
> +# pragma message("OSG_DXGI_FORMAT_R8G8_SNORM disabled on MacOsX with GL3")
> +#else
>  case OSG_DXGI_FORMAT_R8G8_SNORM:
>  internalFormat = GL_RG_SNORM;
>  pixelFormat= GL_RG;
>  dataType   = GL_BYTE;
>  break;
> +#endif
>
>  case OSG_DXGI_FORMAT_R8G8_SINT:
>  internalFormat = GL_RG8I;
> @@ -904,12 +907,15 @@ osg::Image* ReadDDSFile(std::istream& _istream, bool
> flipDDSRead)
>  dataType   = GL_UNSIGNED_SHORT;
>  break;
>
> +#if defined(__APPLE__) && defined(OSG_GL3_AVAILABLE)
> +# pragma message("OSG_DXGI_FORMAT_R16_SNORM disabled on MacOsX with GL3")
> +#else
>  case OSG_DXGI_FORMAT_R16_SNORM:
>  internalFormat = GL_RED_SNORM;
>  pixelFormat= GL_RED;
>  dataType   = GL_SHORT;
>  break;
> -
> +#endif
>  case OSG_DXGI_FORMAT_R16_SINT:
>  internalFormat = GL_R16I;
>  pixelFormat= GL_RED;
>
> --
> nǝıɥʇɐƜ
>
>
> On 26 November 2013 22:10, Paul Martz  wrote:
>
>> I'm trying to get OSG trunk built for GL3. Currently the DDS plugin is
>> failing to compile due to the undefined symbols GL_RG_SNORM and
>> GL_RED_SNORM. These symbols are used at ReaderWriterDDS.cpp lines 878 and
>> 908.
>>
>> Can I get some guidance from the author of this code as to the best way
>> to handle these switch cases when OSG is built for GL3? The easy way would
>> be to conditionally compile them, in which case they would default to
>> display a warning message.
>>
>> Please advise, thanks.
>>
>> --
>> Paul Martz
>> Skew Matrix Software LLC
>>
>> ___
>> 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
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Compile error, DDS plugin, GL_RG_SNORM and GL_RED_SNORM

[Paul Martz]

I'm trying to get OSG trunk built for GL3. Currently the DDS plugin is
failing to compile due to the undefined symbols GL_RG_SNORM and
GL_RED_SNORM. These symbols are used at ReaderWriterDDS.cpp lines 878 and
908.

Can I get some guidance from the author of this code as to the best way to
handle these switch cases when OSG is built for GL3? The easy way would be
to conditionally compile them, in which case they would default to display
a warning message.

Please advise, thanks.

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] v3.0 release of osgWorks and osgBullet

[Paul Martz]

Hi all -- I've now tagged new v3.0 releases of osgWorks and osgBullet,
which are compatible with the current OSG v3.3.0 release, and backwards
compatible to OSG v2.8.5.

Here are URLs for the project web pages:
http://osgworks.googlecode.com
http://osgbullet.googlecode.com

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Collision detection using osgBullets

[Paul Martz]

Jan's advice is sound.

For use with Bullet and osgBullet, ideally each Geode (or maybe Geometry)
should be a convex object. If so, osgBullet can be used to create a Bullet
compound shape for the entire model, consisting of sub-shapes that are all
simple convex shapes.

Bullet does not support concave collision shapes, to my knowledge. But you
can emulate a concave shape by creating a compound shape consisting of
convex sub-shapes.

You mentioned cow.osg. Just FYI, the osgBullet examples that use that model
create a btConvexHull collision shape, I think -- that is a convex mesh of
triangles around the model. But, as Jan said, triangle meshes are very
slow. The parameterized convex shapes (sphere, box, cylinder) are much more
efficient.

What you might want to do with cow.osg is create a convex shape for each of
its parts (four cylinders for the legs, a larger cylinder for the torso,
etc.). But you would have to model this manually. osgBullet can't do this
automatically because all of the cow.osg geometry is inside a single
Geometry object. Bullet contains a convex decomposition implementation, but
the algorithm has limitations.



On Mon, Nov 18, 2013 at 6:27 AM, Jan Ciger  wrote:

>
>
> On Mon, Nov 18, 2013 at 12:34 PM, Mots G  wrote:
>
>> Thank you Paul and Jan for the explanations!
>>
>>
> You are welcome. BTW, that stuff is also in the Bullet's documentation
> *wink* :)
>
>
>
>> On digging further, I came across a post 
>> (here<http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=6816>),
>> which suggested that collision between two "Trimesh:
>> btBvhTriangleMeshShape" does not work with the default dispatcher. It
>> suggests the use of gimpact algorithm and create
>> 'btGImpactConvexDecompositionShape' collision shapes for the osg-geode.
>>
>> I am yet to figure out the correct way to generate a
>> 'btGImpactConvexDecompositionShape' shape for an osg-geode.
>>
>
> Ah yes, this I remember as well. If you can, try to avoid using arbitrary
> meshes for collision testing, because it is slow. Unless you absolutely
> need the accuracy, try to use a bounding volume(s) for it instead - i.e.
> you have one mesh for display and another, simpler one, for collision
> testing. Replacing the complicated non-convex object with a one or more
> spheres, boxes or cylinders does wonders for performance and it is a lot
> simpler than doing the convex decomposition.
>
> Regards,
>
> Jan
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Collision detection using osgBullets

[Paul Martz]

There is an example called "collision" that comes with osgBullet. Take a
look at the two objects that are created. The box on the left is created
with CF_STATIC_OBJECT because it never moves. The box on the right is
created with CF_KINEMATIC_OBJECT, and can be moved with ctrl-leftmouse.
When you drag the kinematic object into the static object, the collision
information is displayed on the console.

I hope this helps.


On Sun, Nov 17, 2013 at 10:42 AM, Mots G  wrote:

> Hi Paul,
> I'm confused between static and dynamic objects. Does dynamic object mean
> the rigid body dynamic object and the dynamic world? I thought dynamic
> objects were only needed if I had to get inertia and motion states
> properties to the objects. In my case I only need to test if the 3D models
> collide among themselves so their movement(translations etc) could be
> restricted.
>
> Therefore I was under the impression only the collision library
> (osgbCollision) would suffice my purpose. However I'm still missing on
> something and unable to get it work.
>
> Thanks
> Mots
>
>
> On Fri, Nov 15, 2013 at 12:32 AM, Paul Martz  wrote:
>
>> My guess is that you've somehow created the collision shapes as static
>> instead of dynamic. Bullet uses the static classification for objects that
>> never move. If you have two objects that never move, Bullet will assume
>> they never collide.
>>
>> Although I've done quite a bit of work in the past with Bullet and
>> osgBullet, I would not consider myself a Bullet expert. This is really just
>> a guess. Since the warning comes from Bullet, the Bullet forum might be a
>> better place. osgBullet also has its own discussion group.
>>
>>
>> On Thu, Nov 14, 2013 at 7:56 AM, Mots G  wrote:
>>
>>> Hi all,
>>> I'm trying to use osgBullets in my application for collision detection.
>>> The library comes with a sample example for detection between two
>>> box-geodes.
>>> I've modified it to use a cessna and a cow model and obtained a
>>> 'btCollisionObject' by calling:
>>>
>>> *osgbCollision::btCompoundShapeFromOSGGeodes(cess_model,COMPOUND_SHAPE_PROXYTYPE
>>> )*
>>>
>>> However, the collision detection does not happen and I'm unable to
>>> figure out what's going wrong.
>>> I also get a warning "warning btCollisionDispatcher::needsCollision:
>>> static-static collision".
>>>
>>> Sorry for the noob question but I'm trying to get this feature in my app
>>> and using the bullet/osgBullet library for the first time. Also I'm not
>>> sure if this question belongs here or to another forum.
>>> Inconvenience regretted.
>>>
>>> Best regards,
>>> Mots
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>>
>> --
>> Paul Martz
>> Skew Matrix Software LLC
>>
>> ___
>> 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
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Updated osgWorks and osgBullet

[Paul Martz]

Hey Robert -- Thanks for the info.

CDash might be my answer for testing osgWorks/osgBullet against current
OSG. I have no current contract work involving either project, so I rarely
have the need to update and build the whole stack.


On Sun, Nov 17, 2013 at 2:39 AM, Robert Osfield wrote:

> Hi Paul,
>
>
> On 16 November 2013 18:27, Paul Martz  wrote:
>
>> I see there is a redesign of the osgGA module taking place. If there is
>> reason to believe that this is the last of these changes, then I'm willing
>> to hold up tagging a release while the issue is resolved.
>>
>
> This is spot on.  I've introduced a new osgGA::Event base class to enable
> more generic events being handled by the OSG's event system, it's still
> early days for it.  To implement it cleanly some of the old features of
> osgGA I've removed, and hoped that 3rd party code wouldn't be using it as
> these were principally implementation details.
>
> For backwards compatibility I could potentially re-introduce the removed
> method handleWithCheckAgainstIgnoreHandledEventsMask() and just implement
> it as a pass through.  There isn't an EventMask in the current rev of osgGA
> so it wouldn't be entirely functionality equivalent but would call the
> standard handle method.
>
>
> But if it's likely that additional such breakages are forthcoming, then
>> holding back on a release seems pointless. There would never be another
>> osgWorks/osgBullet release if we took that approach. osgWorks/osgBullet
>> have been broke for OSG since v3.1.9, but I believe we have something now
>> that builds for OSG v2.8.5-v3.3.0. Shouldn't that be tagged and released
>> regardless of continuing non-backwards compatible changes on OSG trunk?
>>
>
> Testing and providing feedback of how 3rd Party codes like osgWorks are
> working against svn/trunk is really useful for me.  If I break something
> soon after making changes then a discussion about the issues would help
> resolve things.  Finding out things are broken long after the change has
> been made is more difficult to re-trace steps or make appropriate
> amendments.
>
> Cheers,
> Robert.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Updated osgWorks and osgBullet

[Paul Martz]

I see there is a redesign of the osgGA module taking place. If there is
reason to believe that this is the last of these changes, then I'm willing
to hold up tagging a release while the issue is resolved.

But if it's likely that additional such breakages are forthcoming, then
holding back on a release seems pointless. There would never be another
osgWorks/osgBullet release if we took that approach. osgWorks/osgBullet
have been broke for OSG since v3.1.9, but I believe we have something now
that builds for OSG v2.8.5-v3.3.0. Shouldn't that be tagged and released
regardless of continuing non-backwards compatible changes on OSG trunk?



On Fri, Nov 15, 2013 at 5:18 PM, Jan Ciger  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/15/2013 09:49 PM, Paul Martz wrote:
> > Given the recent flurry of interest in osgBullet, I've proceeded
> > with features cuts that allow osgWorks and osgBullet to build with
> > OSG >= v3.1.9. My basic strategy was to simply remove any code that
> > didn't compile with current OSG.
> >
> > Please try out svn trunk of osgWorks and osgBullet, and let me know
> > if there are any issues. I've tested against OSG v3.3.0 and things
> > seems to be running fine. I'll tag a release for these projects
> > shortly.
>
> Hello Paul,
>
> For me it fails to compile against 3.3.1 with this error:
>
> [ 60%] Building CXX object
> src/osgwControls/CMakeFiles/osgwControls.dir/SliderControl.cpp.o
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp: In
> member function ‘virtual void
> ButtonPickHandler::operator()(osg::Node*, osg::NodeVisitor*)’:
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp:106:111:
> error:
> ‘handleWithCheckAgainstIgnoreHandledEventsMask’ was not declared in
> this scope
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp: In
> member function ‘virtual void
> SliderPickHandler::operator()(osg::Node*, osg::NodeVisitor*)’:
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp:215:111:
> error:
> ‘handleWithCheckAgainstIgnoreHandledEventsMask’ was not declared in
> this scope
> make[2]: ***
> [src/osgwControls/CMakeFiles/osgwControls.dir/SliderControl.cpp.o] Error 1
> make[1]: *** [src/osgwControls/CMakeFiles/osgwControls.dir/all] Error 2
> make: *** [all] Error 2
>
> Jan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iD8DBQFShrm7n11XseNj94gRAnMRAKDbYr8AU6rr37e+Jm/jW8UIROqvWQCeMBhc
> QQNELlItkdkmw+k6ris+Wc0=
> =KrcP
> -END PGP SIGNATURE-
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Updated osgWorks and osgBullet

[Paul Martz]

Do you mean OSG svn trunk? There doesn't appear to be a v3.3.1 yet (didn't
see a tag).

If trunk, then is this something that is temporarily broken in OSG and will
be fixed?


On Fri, Nov 15, 2013 at 5:18 PM, Jan Ciger  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/15/2013 09:49 PM, Paul Martz wrote:
> > Given the recent flurry of interest in osgBullet, I've proceeded
> > with features cuts that allow osgWorks and osgBullet to build with
> > OSG >= v3.1.9. My basic strategy was to simply remove any code that
> > didn't compile with current OSG.
> >
> > Please try out svn trunk of osgWorks and osgBullet, and let me know
> > if there are any issues. I've tested against OSG v3.3.0 and things
> > seems to be running fine. I'll tag a release for these projects
> > shortly.
>
> Hello Paul,
>
> For me it fails to compile against 3.3.1 with this error:
>
> [ 60%] Building CXX object
> src/osgwControls/CMakeFiles/osgwControls.dir/SliderControl.cpp.o
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp: In
> member function ‘virtual void
> ButtonPickHandler::operator()(osg::Node*, osg::NodeVisitor*)’:
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp:106:111:
> error:
> ‘handleWithCheckAgainstIgnoreHandledEventsMask’ was not declared in
> this scope
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp: In
> member function ‘virtual void
> SliderPickHandler::operator()(osg::Node*, osg::NodeVisitor*)’:
> /media/u/build/osg/osgworks/src/osgwControls/SliderControl.cpp:215:111:
> error:
> ‘handleWithCheckAgainstIgnoreHandledEventsMask’ was not declared in
> this scope
> make[2]: ***
> [src/osgwControls/CMakeFiles/osgwControls.dir/SliderControl.cpp.o] Error 1
> make[1]: *** [src/osgwControls/CMakeFiles/osgwControls.dir/all] Error 2
> make: *** [all] Error 2
>
> Jan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iD8DBQFShrm7n11XseNj94gRAnMRAKDbYr8AU6rr37e+Jm/jW8UIROqvWQCeMBhc
> QQNELlItkdkmw+k6ris+Wc0=
> =KrcP
> -END PGP SIGNATURE-----
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Updated osgWorks and osgBullet

[Paul Martz]

Given the recent flurry of interest in osgBullet, I've proceeded with
features cuts that allow osgWorks and osgBullet to build with OSG >=
v3.1.9. My basic strategy was to simply remove any code that didn't compile
with current OSG.

Please try out svn trunk of osgWorks and osgBullet, and let me know if
there are any issues. I've tested against OSG v3.3.0 and things seems to be
running fine. I'll tag a release for these projects shortly.

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Collision detection using osgBullets

[Paul Martz]

My guess is that you've somehow created the collision shapes as static
instead of dynamic. Bullet uses the static classification for objects that
never move. If you have two objects that never move, Bullet will assume
they never collide.

Although I've done quite a bit of work in the past with Bullet and
osgBullet, I would not consider myself a Bullet expert. This is really just
a guess. Since the warning comes from Bullet, the Bullet forum might be a
better place. osgBullet also has its own discussion group.


On Thu, Nov 14, 2013 at 7:56 AM, Mots G  wrote:

> Hi all,
> I'm trying to use osgBullets in my application for collision detection.
> The library comes with a sample example for detection between two
> box-geodes.
> I've modified it to use a cessna and a cow model and obtained a
> 'btCollisionObject' by calling:
>
> *osgbCollision::btCompoundShapeFromOSGGeodes(cess_model,COMPOUND_SHAPE_PROXYTYPE
> )*
>
> However, the collision detection does not happen and I'm unable to figure
> out what's going wrong.
> I also get a warning "warning btCollisionDispatcher::needsCollision:
> static-static collision".
>
> Sorry for the noob question but I'm trying to get this feature in my app
> and using the bullet/osgBullet library for the first time. Also I'm not
> sure if this question belongs here or to another forum.
> Inconvenience regretted.
>
> Best regards,
> Mots
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Preferred method for per-context uniforms

[Paul Martz]

Hi all -- I've been inactive with OSG lately, but from time to time get
called back. Given my lack of recent experience, I would appreciate your
help with this issue.

I have a multicontext/multidisplay app that needs to compute a uniform
during cull, and it will have a different value for each context/display.
Computing the uniform value is straightforward, but actually executing the
uniform per-context during draw is somewhat difficult.

I can't simply store the uniform in the Node's StateSet, for example,
because doing that during cull is not thread safe.

Ideally I would store the uniform in a vector indexed by context ID, but I
don't have a context ID during cull.

Would it be feasible to store the uniforms in a map indexed by RenderStage
address, then execute the uniforms from a Camera per-draw callback?

Assuming I use a per-context or per-RenderStage container to store the
uniforms, how do I initially grow that container in a thread-safe way
during the first frame?

What are other people doing in this situation? Thanks in advance for the
advice.

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] how to disable the frustum culling?

[Paul Martz]

It's often desirable to disable culling for any geometry that is
non-spatial in nature. Such geometry is very common in modern graphics
programming.

Even after you disable near/far auto-compute, and set culling disabled on
your scene graph, the CullVisitor will still cull any geometry that is
behind the eye point. This makes rendering non-spatial geometry just a
little tricky. You must add such geometry to its own Camera node, and
configure the Camera so that the CullVisitor will not discard its child
geometry.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Occlusion Query Node Error

[Paul Martz]

OcclusionQueryNode (OQN) has changed significantly since I contributed to
this effort, so I can only provide general advice.

OQN issues occlusion queries to OpenGL, and to avoid stalling the pipe,
waits until the Camera's post-draw callback to retrieve the query results.
Then it uses those results to determine what is visible in the next frame.
RetrieveQueriesCallback is the post-draw callback that is used to retrieve
the queries. For some reason, your Camera doesn't have such a callback
attached.

I'd suggest searching the OSG source to see where RetrieveQueriesCallback
is attached to the Camera. I believe OQN was originally written to perform
this task automatically.

It is also possible that you have attached some other Camera post-draw
callback. If so, you would need to take steps to ensure that both callbacks
are being executed.


On Wed, Aug 7, 2013 at 4:07 PM, Zach Basanese wrote:

> Hello and thank you for any help in advance,
>
> I am working with some code that a coworker had created, but is
> unavailable at the moment. It deals with Occlusion Query Nodes.
> When we were still in OSG version 2.8, my coworker had grabbed a lot of
> the methods from the 3.0 version's OcclusionQueryNode.cpp and put them in
> our code so that we could use them for our sun. However, now that we have
> transitioned to 3.0, the code that was brought in isn't being used anymore,
> defaulting to OSG's code.
> The issue is, whenever our sun is on screen, we are getting the following
> error now: "osgOQ: QG: Invalid RQCB."
> This apparenlty happens becaues of this area of code:
>
> Code:
>
> RetrieveQueriesCallback* rqcb = dynamic_cast<
> RetrieveQueriesCallback* >( cam->getPostDrawCallback() );
> if (!rqcb)
> {
> OSG_FATAL << "osgOQ: QG: Invalid RQCB." << std::endl;
> return;
> }
>
>
>
> I think it might be that we aren't setting up the nodes correctly, but I
> haven't been able to find any examples or documentation related to this
> error or how to properly set up occlusion query nodes in OSG.
> Any help is appreciated, please let me know if you have any questions
> regarding my question.
>
> Zach[/code]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=55804#55804
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to grasp an object in virtual scene by using a CyberGlove and OSG?

[Paul Martz]

Yes, osgBullet does have a collision-only library.

I just wanted to provide additional information, as the O.P. seemed unaware
of osgBullet and what had already been done there.


On Sat, Aug 3, 2013 at 3:35 AM, Jan Ciger  wrote:

> I think that what Robert meant was to simply use the collision
> detection library in Bullet, without going the whole hog with the full
> simulation (which is, indeed, complicated).
>
> Regards,
>
> Jan
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to grasp an object in virtual scene by using a CyberGlove and OSG?

[Paul Martz]

There was some development in osgBullet for grappling with a data glove and
hand model. Without haptics, the user had no feedback over how tightly the
objects were grasped, and Bullet had difficulty resolving the constraints
in this situation.

We found a better approach was to detect gestures with the data glove, such
as fist, point, open, etc., and use those as a signal to the application
for creating and removing different types of constraints between the hand
model and a target object in the scene. This approach allowed for very easy
scene interaction, and no issues with Bullet constraint resolution.


On Fri, Aug 2, 2013 at 3:21 AM, Robert Osfield wrote:

> Hi Junjie,
>
> The OSG doesn't have general collision support, it only provides line
> segment and polytope intersectors that probably aren't what you are
> looking for.  You are problably best looking at a dedicate collision
> detection and perhaps physics library to handle this side of things.
> For instance the 3rd party project osgBullet might the thing.
> Robert.
>
>
> On 23 May 2013 12:25, Junjie Xue  wrote:
> > Hi,
> >
> > I am working on a virtual assembly demo by using OSG and CyberGlove
> together. Currently i have sucessfully connect  and drive the virtual hand
> in the scene using realtime data sent from the glove. Now i want to add
> collision detection between the hand and a part in the scene. when the
> collision is detected, the part will move with the hand.
> >
> > Here comes the problem:
> > 1. How do collision detection in osg? What class or function should i
> use?
> > 2. How to make the part move with the hand?  What class or function
> should i use?
> >
> > Any suggestion or reply will be appreciated.
> > Thank you!
> >
> > Cheers,
> > Junjie
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=54133#54133
> >
> >
> >
> >
> >
> > ___
> > 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
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL 4 support

[Paul Martz]

If you don't build OSG with the "GL3_AVAILABLE" CMake flag, then OSG
"supports" GL3 and GL4 functionality via a GL 2.1 context and the OpenGL
extension interface.

Selecting the "GL3_AVAILABLE" flag allows you to open GL3/4 contexts. This
functionality was added in the OSG 2.9.x series. To my knowledge, there has
been little or no development of GL3/4 contexts since; that's why OSG still
includes gl3.h instead of glcorearb.h. You might consider contributing an
update.

To my knowledge, the osgQt library was never tested with a GL3/4 context.

There is an example osgsimplegl3 to test/demo an OpenGL 3.1 context. This
example works fine on Windows last time I checked. The example source has
some comments at the bottom of the file.

There is a known issue with core profile contexts because core profile
requires use of vertex array objects. As far as I know, OSG has no support
for vertex array objects. This is a roadblock to using OSG/GL3 on OSX.

Much of this has been discussed in the past, so I'd recommend searching the
osg-users archives for additional information.


On Thu, Jun 27, 2013 at 3:08 AM, Roger Floydman wrote:

> Hi,
>
> I'd heard lots of good things about OpenSceneGraph so decided to give it a
> try. On the 'features' page it says "OpenGL 1.0 through to OpenGL 4.2, and
> OpenGL ES 1.1 and 2.0 are supported" which is good as i wanted to use
> 'modern GL techniques'
>
> I decided to build from source as i wanted to integrate with Qt and it
> seems there's been some work related to this in the osgQt module which i
> thought would be good to have.
>
> The problems started when i wanted to use a newer GL version. In CMake the
> option was to used GL3 so i selected that and deselected all the other GL
> options. When trying to build OSG it complained that gl3.h couldn't be
> found. So i went on a hunt for that and found the file no longer exists. It
> has been replaced by glcorearb.h.
>
> I made a work around to get passed that error but creating my own gl3.h
> file and including the glcorearb.h file & defining GLCOREARB_PROTOTYPES 1
>
> Later in the build though i come across another error as GL/gl.h is
> included via osgQt/GraphicsWindowQt and this file cannot be mixed with
> glcorearb.h
>
> Am i missing something here or is it a real pain to get GL3+ working with
> OSG? How does OSG support OpenGL 4.2 (as mentioned on the website) if it
> isn't in sync with the glcorearb.h file and is still looking for gl3.h?
>
> Any help much appreciated.
>
> Thanks,
>
> Roger
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=54943#54943
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Using c++11 smartpointer instead of osg::ref_ptr?

[Paul Martz]

You can pass references to shared_ptr objects. You only need to copy them
for long-term storage, which is typically not a performance critical
operation in a scene graph.


On Thu, Aug 1, 2013 at 12:21 AM, Robert Osfield wrote:

> Hi Maik? Klein? how do you like to be addressed?
>
> On 29 April 2013 00:53, Maik Klein  wrote:
> > I am wondering if it is possible to use the c++11 smartpointer instead
> of osg::ref_ptr? Is there any advantage in using the osg::ref_ptr?
>
> As others have said osg::ref_ptr<> is an intrusive smart pointer like
> boost::intrusive_ptr<>, and osg::observer_ptr<> is kinda equivalent to
> weak_ptr<>.
>
> The OSG doesn't have or use an equivalent to std::shared_ptr<>, and if
> I were to write a new scene graph tomorrow I would not use a
> std::shared_ptr<> for general nodes in the scene graph. shared_ptr<>
> isn't as robust as ref_ptr<> in general usage as you are forced to use
> a single shread_ptr<> group to reference a single object, you can't
> just assign a C pointer to a node and create your own shared_ptr<> to
> it as it breaks the design and you'll end up with dangling pointers.
> This design problem with shared_ptr<> forces you to copy
> shared_ptr<>'s all the time when access data members which just can't
> be efficient and requires end users to always stick to this rule.
>
> It's a shame that intrusive_ptr<> isn't part of the standard.
>
> Robert.
> _______
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 3D mice

[Paul Martz]

I'm not sure what you want to control with the spaceball, but... I'd like
to point out that osgwMx (part of osgWorks) controls a matrix. You can use
that matrix for whatever you want, such as controlling a view position or
MatrixTransform. So you should be able to use osgGA mouse/kbd to control
your view, and use osgwMx/spaceball to control whatever else you want to
control. They should be completely independent.


On Mon, May 20, 2013 at 5:21 PM, Thomas Lerman  wrote:

> Thank you, I will check it out. The difficulty that I see with osgWorks
> and osgToy is that they seem to maintain their own internal data that is
> used to set the view matrix. This is problematic for me as I want to still
> allow mouse and keyboard manipulation of the camera. So far, I have not
> seen how to basically translate from the current view to a new view based
> upon the movements of the 3D mouse.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=54071#54071
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] META_OBJECT

[Paul Martz]

Ah. I see now that you're asking about how to use a macro that is defined
in a project external to OSG. Sorry for my confusion.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] META_OBJECT

[Paul Martz]

I'm not sure what "META_OBJECT" (all caps) is, or where it's defined. Did
you intend to use "META_Object" from include/osg/Object instead?

One other possible issue I noted: Assuming you intended to use META_Object,
I believe you are required to implement the copy constructor, and I don't
see that in your code...


On Sun, Apr 28, 2013 at 6:38 AM, Sajjadul Islam wrote:

> Hi forum,
>
> I am extending a osg::Object as follows:
>
>
> Code:
>
> class LIBRARY_EXPORT osgOpenCLContext : public osg::Object
> {
> public:
> osgOpenCLContext();
>
> META_OBJECT(osgOpenCL,osgOpenCLContext);
>
>
> bool setupOsgOpenCLAndViewer(osgViewer::ViewerBase
> &viewer,
>  int ctxID = -1);
>
> ~osgOpenCLContext();
>
>   };
>
>
>
>
> And i am getting the following error among many others:
>
>
> Code:
>
> [ 62%] Building CXX object
> src/osgOpenCL/CMakeFiles/osgOpenCL.dir/osgOpenCLContext.cpp.o
> In file included from
> /home/sajjad/Downloads/OpenSceneGraph/osgCompute/osgCompute/src/osgOpenCL/osgOpenCLContext.cpp:7:0:
> /home/sajjad/Downloads/OpenSceneGraph/osgCompute/osgCompute/include/osgOpenCL/osgOpenCLContext:22:16:
> error: ‘osgOpenCL’ is not a type
> /home/sajjad/Downloads/OpenSceneGraph/osgCompute/osgCompute/include/osgOpenCL/osgOpenCLContext:22:42:
> error: ISO C++ forbids declaration of ‘META_OBJECT’ with no type
> [-fpermissive]
>
>
>
>
>
> Any idea folks ? i used to know that META_Object and META_Node are just
> convenience macro's that help streamline
> the writing of subclasses, have a look at their definition to see what they
> do.  The methods that these macros implement are useful for implementing IO
> and other ops that require richer RTTI info that C++ provides by default.
>
> Please fill out if i miss anything in the process
>
> Thank you!
>
> Cheers,
> Sajjadul
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=53846#53846
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Order Independent Transparancy with Per-Pixel-Linked-Lists

[Paul Martz]

Perhaps developing an OSG version of this example would be a good candidate
project for funding through catincan.com? What would be appropriate --
$1000USD? $2k? More?


On Thu, Apr 25, 2013 at 7:58 AM, Chris Hanson  wrote:

> Marcel, just to clarify, the example isn't mine. I only fixed it to work
> again. The original author moved on and works at NVidia.now.
>
> I would love to see an OSG version of this code.
>
>
> On Wed, Apr 24, 2013 at 11:08 PM, Mathias Fröhlich <
> mathias.froehl...@gmx.net> wrote:
>
>>
>> Hi,
>>
>> On Tuesday, April 23, 2013 22:17:42 Marcel Pursche wrote:
>> > I recently checked out the newest development release of OSG (version
>> > 3.1.5). After playing around with the osgatomiccounter and
>> osgcomputeshader
>> > examples I tried to implement order independent transparency with per
>> pixel
>> > linked lists as mentioned in this presentation: click!
>> > (
>> https://graphics.stanford.edu/wikis/cs448s-10/FrontPage?action=AttachFile&;
>> > do=get&target=CS448s-10-11-oit.pdf).
>> Ok, now that I see more public references to this:
>> There must be a publication from the university of stuttgart guys in the
>> mcsimvis project about this technique implemented in OpenGL 4.x.
>> May be this helps also.
>>
>> Greetings
>>
>> Mathias
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry •
> Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
> 623-PIXL [7495]
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Questions about OSG

[Paul Martz]

Core profile requires use of vertex array objects, and currently OSG
doesn't support VAO. As a result, OSG can't currently use core profile.
This may change in the future, when someone submits a patch that adds VAO
support.


On Sun, Apr 21, 2013 at 11:09 AM, maik klein wrote:

> I am studying computer graphics at my university and I have a few
> questions about OSG.
>
> Does OSG use the core profile?
>
> Are scenegraphs in general suited for games? Yesterday my professor said
> that scenegraphs are too expensive for games. (because of many state
> changes) Unfortunately he didn't mention an alternative. I also couldn't
> find any information about this topic. I only know that Ogre3d is using an
> scenegraph too. I also saw that there are many different implementations of
> scenegraphs, like BSP octree etc.
>
> Is OSG suited for a game engine?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=53714#53714
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] culling and vertex shaders still a problem

[Paul Martz]

Agreed, keeping Geometry out of the scene graph's inherent desire to deal
with it as spatial data is a serious issue in OSG.

One solution would be to disable culling on the Geode (as you did above)
and place it under its own dedicated Camera. Kind of heavyweight, though.

Another possibility would be to draw your Geometry from a post-draw
callback, but I haven't tried this.


On Sun, Apr 7, 2013 at 5:07 AM, Anton Fuhrmann  wrote:

> Hi,
>
> I need to disable culling on a geode which implements a skydome/plane as a
> shader.
>
> The problem is that the vertex shader places the existing vertices
> screen-aligned at the far plane, but OSG still thinks they are in their
> original positions.
>
> This problem as already been discussed - but not conclusively solved - in
> other threads:
> (cannot post URLs at the moment)
> viewtopic.php?t=20300
> viewtopic.php?t=10912
>
> For this situation, disabling the culling is necessary because I do not
> want the scene to include the "real" positions of the sky plane at
> "infinity". It would defy near/far calculation and I would need to
> introduce a callback that recalculates the positions outside the vertex
> shader just so that the skydome node does not get clipped.
>
> I already tried
> Code:
> Geode->setCullingActive(false)
>
> and
> Code:
> Camera()->setCullingMode( osg::CullSettings::NO_CULLING )
>
>
> but both cull my node as soon as the original vertex positions are behind
> the camera.
>
> My workaround at the moment is to set the initial bounds very large, but
> this is unnecessarily inflates the BBox of the real scene.
>
> Any suggestions would be appreciated!
>
> ...
>
> Thank you!
>
> Cheers,
> Anton
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=53481#53481
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How do remove a node's built in offset?

[Paul Martz]

You could translate them with the .trans pseudoloader:
osgconv infile.ive.(-x,-y,-z).trans outfile.ive

I'm not sure that's the right syntax for the .trans pseudoloader, but you
can check the source code in src/osgPlugins/trans.


On Mon, Apr 22, 2013 at 12:00 PM, Joshua Cook wrote:

> Ok, so I have a set of IVE files and each one of them has some sort built
> in offset.  For example: a cube with a center of X, Y, Z.  I really would
> love to be able to save these off as an IVE with a center of 0, 0, 0.
>
> My Google-Fu is weak today, master, and I humbly request assistance with
> this problem.
>
> Thanks,
> soulsabr
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=53725#53725
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgEphemeris status

[Paul Martz]

Hi all -- FYI, the osgEphemeris repo has moved to Google Code:
http://osgephemeris.googlecode.com

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSGDisneyland

[Paul Martz]

Anaheim this year, eh? Wow, that brings back memories. First SIGGRAPH I
attended was Anaheim, 1987, back when 1m lines/sec was a big deal...
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Collision Detection in OSG 1.2

[Paul Martz]

You didn't really provide much detail on how the code is failing, so we can
really only hazard a few wild guesses.

One potential problem area is that the osg::BoundingBox is axis-aligned. As
a result, rotating a BB just a few degrees will subtend a much larger area
than the unrotated box.

As Robert suggests, it might be better to transform the world location of
the eye into the local coordinate space of your ship node BB. To do this,
transform the eye by the ship node's world-to-local matrix. If OSG v1.2
doesn't give you direct access to that matrix, then simply take the inverse
of the getWorldMatrix() you're already using.


On Mon, Mar 25, 2013 at 9:34 AM, Robert Osfield wrote:

> Hi Todd,
>
> OSG-1.2 oh boy, that be a little out of date know.  You have my
> sympathies.  Being stuck on OSG-1.2 will limit the communities ability
> to help a bit as most will be on 3.x or later 2.x series releases.  On
> the positive side the core scene graph in OSG-1.2 is pretty similar to
> that in OSG-3.x, the really big differences are in the viewer and
> extensions to the core OSG.
>
> In terms of collision detection, the OSG even these days doesn't
> directly provide collision detection.  in OSG-1.2 there is only view
> frustum culling and line intersection testing available.  You can use
> the bounding volume classes osg::BoundingSphere (attached to Node) and
> osg::BoundBox (attached to Drawable/Geometry) that you can do tests
> with, and an osg::Polytope class that is used for view frustum culling
> that could potentially be reused.
>
> With all these different tools the key is getting point/line/volume
> tests in the same coordinate frames, usually this is done by
> transforming a world point into a local coordinate frame, or
> visa-versa.  Traverses like the PickVisitor and CullVisitor do the
> accumulation of transforms through the scene graph so have a look at
> how they are managed.  My guess is you will probably want to create
> your own custom visitor to do something similar.
>
> Robert.
>
> On 12 March 2013 05:08, Todd Baniak  wrote:
> > Hello all,
> >
> > Unfortunately my organization has made the decision to stick with OSG
> 1.2.  At this point it is not an option to upgrade, so the question
> pertains to how to solve a particular problem in 1.2.  I am a newbie to OSG
> and 3D in general, so please be patient with me!
> >
> > I have a window that displays a scene.  The scene is comprised of a
> series of Nodes, one of which I'll call a Ship Node.  All of the Nodes
> (including the Ship Node) are added to a single Root Node, which is then
> added to the SceneView.
> >
> > I believe I have successfully created a BoundingBox around this Ship
> Node.  What I'm trying to do is detect when the camera eye point intersects
> with this BoundingBox.
> >
> > The camera can move in and out (using setViewMatrixAsLookAt and changing
> the eye parameter).  I also have the ability to rotate up, down, left, and
> right.  This is done by applying the rotations to the Root Node.
> >
> > I have tried to obtain the world coordinates of the Ship Node at any
> given time via getBound() * getWorldMatrix()[0].  The camera eye point
> seems far more difficult.  No matter what I do, I can't get the camera to
> intersect with the BoundingBox properly.  Is the eye considered part of the
> 'world'?  And if so, does it need to be translated to world coordinates to
> make this work?
> >
> > I suspect I am going about this problem completely wrong.  I can post
> snippets of code if necessary.  Any ideas?
> >
> > Thank you for your time,
> >
> > Todd
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=53046#53046
> >
> >
> >
> >
> >
> > ___
> > 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
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Retrieving Z-Near & Far per-frame

[Paul Martz]

You might take a look at the osgthirdpersonview example, which draws two
views of the same scene, one of which contains a wireframe representation
of the view frustum used for the other view.


On Sat, Mar 23, 2013 at 9:41 PM, Randall Hand wrote:

> Is there (I'm sure there is) a way to retrieve the autocalculated ZNear &
> ZFar from the scene graph on a per-frame basis? I figure it's somewhere in
> a traversal structure, but I'm not exactly sure where or how to get to it.
>
> Can someone enlighten me?
> __**_
> osg-users mailing list
> osg-users@lists.**openscenegraph.org 
> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
> openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org>
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Rendering backface like front face

[Paul Martz]

There are a couple different scenarios.

If a surface is composed of triangles that all have a normal consistent
with the winding order, but some of the triangles are facing the wrong way,
then two-sided lighting will address the issue. That's why I asked the OP
if he had tried this.

If your surface has normals that are not consistent with vertex winding
order, then you might be able to fix this in a shader by flipping the
normal only when the dot product is negative, but I've never tried this.
I've always just called it a modeling bug. :-)


On Thu, Mar 14, 2013 at 12:27 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:

> If you enable two-sided lighting, the driver flips the lighting normals
> so that the back side of the polygon is lit correctly. There should be
> no need to do this in a shader (with OGL that supports fixed
> functionality...).
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
> Christian Buchner
> Sent: Thursday, March 14, 2013 10:46 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] [forum] Rendering backface like front face
>
>
> The front and back material properties were set to same values, it's
> just that when doing the calculations for the back side, the normal
> vector is not pointing towards the light source but away from it.
>
> I only looked at this issue briefly, and concluded that it would take
> some GLSL to fix it.
>
> Christian
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Rendering backface like front face

[Paul Martz]

On Thu, Mar 14, 2013 at 3:43 AM, Christian Buchner <
christian.buch...@gmail.com> wrote:

>
> When I tried two sided lighting yesterday, I found that the back faces
> were lit, but not in the same way as the front faces.
>

Are your front and back material colors set to the same values, or to
different values?

Two-sided lighting seems to work fine on my GeForce 650, no performance
issue that I am aware of. Obviously the lighting computation needs to be
done twice at each vertex, but if the model isn't vertex-limited this is
not an issue.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Rendering backface like front face

[Paul Martz]

Did you try turning on 2-sided lighting?


On Wed, Mar 13, 2013 at 11:47 AM, Florian Kolbe wrote:

> Hi,
>
>sorry if this may be too obvious. I was wondering if there is some kind
> of backface mode where backfaces are rendered like the front face?
> We have a model here that "looks" normal in Rhino and SimLab Composer
> because they seem to be able to render that way ("backface like front
> face") - see foot note. Looking at the model in OSG it becomes obvious,
> that some surfaces are inside out (e.g. black if culling is off, or
> invisible if backface culling is active).
>
> Instead of fixing the model, I was interested if I could teach OSG to
> render the backface like the front face (in terms of material and shading
> etc)?
>
>
> Thank you!
>
> Cheers,
> Florian
>
> e.g. for Rhino:
> http://docs.mcneel.com/rhino/5/help/en-us/options/view/display_mode_options.htm
> search for "Backface settings" the setting is called "Use front face
> settings" which seems to be the default
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=53088#53088
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg crashes when remove child

[Paul Martz]

..})
>  Ligne 62 + 0x25 octetsC++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
>
> osg80-osgUtild.dll!osgUtil::CullVisitor::handle_cull_callbacks_and_traverse(osg::Node
> & node={...})  Ligne 312 + 0xf octets C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Group &
> node={...})  Ligne 1128 C++
> osg80-osgd.dll!osg::Group::accept(osg::NodeVisitor & nv={...})
>  Ligne 38 + 0x41 octets  C++
> osg80-osgd.dll!osg::Switch::traverse(osg::NodeVisitor & nv={...})
>  Ligne 40 + 0x77 octets   C++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
>
> osg80-osgUtild.dll!osgUtil::CullVisitor::handle_cull_callbacks_and_traverse(osg::Node
> & node={...})  Ligne 312 + 0xf octets C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Group &
> node={...})  Ligne 1128 C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Switch &
> node={...})  Ligne 1214 + 0x13 octets  C++
> osg80-osgd.dll!osg::Switch::accept(osg::NodeVisitor & nv={...})
>  Ligne 40 + 0x41 octets C++
> osg80-osgd.dll!osg::Group::traverse(osg::NodeVisitor & nv={...})
>  Ligne 62 + 0x25 octetsC++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
>
> osg80-osgUtild.dll!osgUtil::CullVisitor::handle_cull_callbacks_and_traverse(osg::Node
> & node={...})  Ligne 312 + 0xf octets C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Group &
> node={...})  Ligne 1128 C++
> osg80-osgd.dll!osg::Group::accept(osg::NodeVisitor & nv={...})
>  Ligne 38 + 0x41 octets  C++
> osg80-osgd.dll!osg::Group::traverse(osg::NodeVisitor & nv={...})
>  Ligne 62 + 0x25 octetsC++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
>
> osg80-osgUtild.dll!osgUtil::CullVisitor::handle_cull_callbacks_and_traverse(osg::Node
> & node={...})  Ligne 312 + 0xf octets C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Transform &
> node={...})  Ligne 1151 C++
>
> osg80-osgd.dll!osg::NodeVisitor::apply(osg::PositionAttitudeTransform &
> node={...})  Ligne 141 + 0x13 octetsC++
>
> osg80-osgd.dll!osg::PositionAttitudeTransform::accept(osg::NodeVisitor &
> nv={...})  Ligne 41 + 0x41 octets  C++
> osg80-osgd.dll!osg::Group::traverse(osg::NodeVisitor & nv={...})
>  Ligne 62 + 0x25 octetsC++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
>
> osg80-osgUtild.dll!osgUtil::CullVisitor::handle_cull_callbacks_and_traverse(osg::Node
> & node={...})  Ligne 312 + 0xf octets C++
> osg80-osgUtild.dll!osgUtil::CullVisitor::apply(osg::Group &
> node={...})  Ligne 1128 C++
> osg80-osgd.dll!osg::Group::accept(osg::NodeVisitor & nv={...})
>  Ligne 38 + 0x41 octets  C++
> osg80-osgd.dll!osg::Group::traverse(osg::NodeVisitor & nv={...})
>  Ligne 62 + 0x25 octetsC++
> osg80-osgd.dll!osg::NodeVisitor::traverse(osg::Node & node={...})
>  Ligne 193 + 0x1c octets  C++
> osg80-osgUtild.dll!osgUtil::SceneView::cullStage(const
> osg::Matrixd & projection={...}, const osg::Matrixd & modelview={...},
> osgUtil::CullVisitor * cullVisitor=0x0ca69f50, osgUtil::StateGraph *
> rendergraph=0x0ca696f0, osgUtil::RenderStage * renderStage=0x0ca69788,
> osg::Viewport * viewport=0x0ca73dc8)  Ligne 980 + 0x1a octets C++
> osg80-osgUtild.dll!osgUtil::SceneView::cull()  Ligne 845 + 0x57
> octets  C++
> osg80-osgViewerd.dll!osgViewer::Renderer::cull()  Ligne 615 + 0xf
> octetsC++
> osg80-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
>  Ligne 793 + 0x15 octets  C++
> osg80-osgViewerd.dll!osgViewer::ViewerBase::frame(double
> simulationTime=1.7976931348623157e+308)  Ligne 645 + 0xf octetsC++
> osg80-osgViewerd.dll!osgViewer::ViewerBase::run()  Ligne 612 +
> 0x1b octets  C++
> osg80-osgViewerd.dll!osgViewer::Viewer::run()  Ligne 376C++
>     osgWrapper.dll!threadfunc(void * __formal=0x)  Ligne 128 +
> 0x25 octets  C++
> pthreadVC2.dll!0f7955e6()
> [Les frames ci-dessous sont peut-être incorrects et/ou manquants,
> aucun symbole chargé pour pthreadVC2.dll]
> msvcr100.dll!6113c556()
> msvcr100.dll!6113c600()
> kernel32.dll!74dd3677()
> ntdll.dll!77479f42()
> ntdll.dll!77479f15()
>
> Can you help me please?
> Thank you!
>
> Cheers,
> lucie
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=52981#52981
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

[Paul Martz]

Now that I give this some more thought, the concept of post-processing is
inherently non-spatial, so it really doesn't belong in a scene graph at
all. Repeatedly "culling" entities that we know will always be rendered is
redundant at best. Wouldn't it be better to have a list of dedicated RTT
objects as described by Rui, and process them as a Camera post-draw
callback?

Just thinking out loud...


On Thu, Feb 14, 2013 at 5:50 PM, Wang Rui  wrote:

> Hi all,
>
> Thanks for the replies. It is always midnight for me when most community
> members are active so I have to reply to you all later in my morning. :-)
>
> Paul, I haven't done any comparisons yet. Post processing steps won't be
> too many in a common application, and as Robert says, the cull time cost of
> a camera and a normal node won't be too different, so I think the results
> may be difficult to measure.
>
> Aurelien's past idea (using RenderBins directly) also interests me but it
> will change the back-end dramatically. I'm also focusing on implementing a
> complete deferred pipeline including HDR, SSAO, color grading and AA work,
> and finally merge it with normal scenes like the HUD GUI.
> The automatic switch between DS and normal pipeline is done by changing
> whole 'technique' instead of moving child nodes, which may be found in the
> osgRecipes project I'm maintaining.
>
> But I don't think it easy to implement an executeCameraAsync() method at
> present. As OSG is a lazy rendering system and one can hardly insert some
> CPU side computation into FBO cameras. Maybe it could be done by using pre-
> and post-draw callbacks of a specified camera.
>
> I also agree with Daniel's second opinion that the pipeline should be
> compatible with multi-views. As a node in the scene graph we can easily do
> this by sharing the same root node in different views. For the first
> opinion, because we also have nodes that should not be affected by the
> post-processing effects (like the GUI, HUD display), and developers may
> require multiple post effects in the same scene graph (e.g., draw dynamic
> and static objects differently), I don't think it convincing to totally
> separate the post processing framework and place it in draw callbacks or
> viewer's graphics operations.
>
> So, in conclusion, I will agree with Robert that OSG itself don't need an
> additional RTT node at present and will use cameras to perform every
> passes, which is already proved in my client work to be compatible with
> most current OSG functionalities including the VDSM shadows, and some
> external libraries like SilverLining and osgEarth.
>
> I will try to tidy and submit my current code in the next week as well as
> a demo scene. And then I will modify the osgRecipes project to use the new
> idea flashed in my mind to find the pros and cons of it.
>
> Thanks,
>
> Wang Rui
>
>
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

[Paul Martz]

This is how I've been doing post-rendering effects, too.

However, I have never done any performance benchmarks. My instinct tells me
that this method should have faster cull time than using a Camera, but if
post-rendering cull time makes up only a small percentage of the total cull
time, then I imagine the performance benefit would be difficult to measure.

Have you done any performance comparisons against equivalent use of Camera
nodes?


On Thu, Feb 14, 2013 at 8:33 AM, Wang Rui  wrote:

> Hi Robert, hi all,
>
> I want to raise this topic when reviewing my effect
> composting/view-dependent shadow code. As far as I know, most of us use
> osg::Camera for rendering to texture and thus the post-processing/deferred
> shading work. We attach the camera's sub scene to a texture with attach()
> and set render target to FBO and so on. It works fine so far in my client
> work.
>
> But these days I found another way to render scene to FBO based
> texture/image:
>
> First I create a node (include input textures, shaders, and the sub scene
> or a screen sized quad) and apply FBO and Viewport as its state attributes:
>
> osg::ref_ptr tex = new osg::Texture2D;
> tex->setTextureSize( 1024, 1024 );
>
> osg::ref_ptr fbo = new osg::FrameBufferObject;
> fbo->setAttachment( osg::Camera::COLOR_BUFFER,
> osg::FrameBufferAttachment(tex) );
>
> node->getOrCreateStateSet()->setAttributeAndModes( fbo.get() );
> node->getOrCreateStateSet()->setAttributeAndModes( new
> osg::Viewport(0, 0, 1024, 1024) );
>
> Then if we need more deferred passes, we can add more nodes with screen
> sized quads and set texOutput as texture attributes. The intermediate
> passes require fixed view and projection matrix. So we can add it a cull
> callback like:
>
> cv->pushModelViewMatrix( new RefMatrix(Matrix()),
> Transform::ABSOLUTE_RF );
> cv->pushProjectionMatrix( new RefMatrix(Matrix::ortho2D(0.0, 1.0, 0.0,
> 1.0)) );
>
> each_child->accept( nv );
>
> cv->popProjectionMatrix();
> cv->popModelViewMatrix();
>
> This works well in my initial tests and it won't require a list of
> osg::Camera classes. I think this would be a light-weighted way for the
> post-processing work as it won't create multiple RenderStages at the
> back-end and will reduce the possibility of having too many nests of
> cameras in a scene graph.
>
> Do you think it useful to have such a class? User input a sub-scene or any
> texture; the class uses multiple passes to process it and output to a
> result texture. The class won't have potential cameras for the RTT work,
> and can be placed anywhere in the scene graph as a deferred pipeline
> implementer, or a pure GPU-based image filter.
>
> I'd like to rewrite my effect compositor implementation with the new idea
> if it is considered necessary, or I will forget it and soon be getting
> ready to submit both the deferred shading pipeline and the new VDSM code in
> the following week. :-)
>
> Cheers,
>
> Wang Rui
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] TriMeshVisitor possible bug?

[Paul Martz]

Ah. I see. The code assumes all vertices in a DrawArrays are unique. I
mistakenly expected that the code was doing vertex (and attribute)
comparisons and eliminating vertices that were duplicates.


On Thu, Feb 14, 2013 at 12:32 AM, Sergey Polischuk  wrote:

>  Hi
>
> Looks ok to me
> as it written in comment, code converts DrawArrays to DrawElements, and if
> primitive set is already indexed it is not DrawArrays any more, and there
> should not be duplicate vertices in first place (besides ones with same
> vertex position but different other vertex attributes like tc's or normals)
>
> Cheers.
>
> 14.02.2013, 01:17, "Paul Martz" :
>
> Hi all -- Primarily Tim Moore...
>
> The code comments for osgUtil::IndexMeshVisitor reads as follows:
> // Convert geometry that uses DrawArrays to DrawElements i.e.,
> // construct a real mesh. This removes duplicate vertices.
>
> However, if a PrimitiveSet is already indexed (i.e., DrawElementsUInt),
> then the code skips removal of duplicate vertices. Is this the intended
> behavior? From reading the documentation, I expected the code would still
> go through and remove the duplicate vertices.
>
> Does the code need to be corrected, or the code comment?
>
> --
> Paul Martz
> Skew Matrix Software LLC
> ,
>
> ___
> 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
>
>


-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] TriMeshVisitor possible bug?

[Paul Martz]

Hi all -- Primarily Tim Moore...

The code comments for osgUtil::IndexMeshVisitor reads as follows:
// Convert geometry that uses DrawArrays to DrawElements i.e.,
// construct a real mesh. This removes duplicate vertices.

However, if a PrimitiveSet is already indexed (i.e., DrawElementsUInt),
then the code skips removal of duplicate vertices. Is this the intended
behavior? From reading the documentation, I expected the code would still
go through and remove the duplicate vertices.

Does the code need to be corrected, or the code comment?

-- 
Paul Martz
Skew Matrix Software LLC
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] what is the replacement class for Producer::CameraConfig ?

[Paul Martz]

This is something you might want to ask on the producer-users email list, I'd 
think. Producer is not a dependency of OSG any longer (but they still work 
together, as far as I am aware).

http://www.andesengineering.com/mailman/listinfo/producer-users
   -Paul


On 2/8/2013 10:40 AM, Selvakumar Chellamuthu wrote:

Hi,

Im using OSG 3.0.0. Can somebody tell me what is the replacement class for 
Producer::CameraConfig or alternate way ?

Thank you!

Cheers,
Selvakumar

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





___
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] Question about the correct use of osg::FrameBufferObject

[Paul Martz]

Hi Frank -- Just adding to what Robert said:

Although FrameBufferObject does derive from StateAttribute, I have never seen it 
used as an attribute attached to a StateSet. Rather, it's something that Camera 
uses essentially internally.


Previous postings from Art Tevs (osgPPU) have warned of issues when attaching a 
FrameBufferObject as an attribute to a StateSet... I think he expected it to 
override the FrameBufferObject used by some parent Camera, but it didn't work 
that way. There were possibly other issues too, I don't recall.


The bottom line is that you should probably not use FrameBufferObject directly, 
and should always let Camera manage it for you.

   -Paul


On 2/5/2013 4:10 PM, Frank Sullivan wrote:

Hi,

I'm looking at the source code for osg::FrameBufferObject, and as far as I can 
tell, I just have to set this as an attribute on a node's StateSet and be done 
with it?

If this is true, then can I use it in conjunction with Nested Render cameras in 
order to get render-to-texture cameras that render in the order in which they 
are encountered in the scene graph?

Thank you!

Cheers,
Frank

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





___
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] OSC plugin, VS2010 64-bit

[Paul Martz]

Thanks, Stephan! That worked great. Cross-posting to osg-submissions.
   -Paul


On 2/5/2013 4:52 PM, Stephan Huber wrote:

Hi Paul,

as I do only have VS2005 I can't build for 64bit. Attached is a possible
fix for 64bit-builds with VS2010. Can you test the modified file on your
end and report back?


Thanks in advance,

Stephan
Am 05.02.13 23:53, schrieb Paul Martz:

Forgot to mention: 32-bit builds fine, 64-bit is the issue.
-Paul


On 2/5/2013 3:41 PM, Paul Martz wrote:

Hi Stephan -- The OSC plugin has compile errors with VS2010 for 64-bit
builds,
and I thought you might want to take a look at it. This is from trunk
r13330.
Thanks!
 -Paul



/*
oscpack -- Open Sound Control packet manipulation library
http://www.audiomulch.com/~rossb/oscpack

Copyright (c) 2004-2005 Ross Bencina 

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

Any person wishing to distribute modifications to the Software is
requested to send the modifications to the original developer so that
they can be incorporated into the canonical version.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#ifndef INCLUDED_OSCOUTBOUNDPACKET_H
#define INCLUDED_OSCOUTBOUNDPACKET_H

#include "OscTypes.h"
#include "OscException.h"


namespace osc{

class OutOfBufferMemoryException : public Exception{
public:
OutOfBufferMemoryException( const char *w="out of buffer memory" )
: Exception( w ) {}
};

class BundleNotInProgressException : public Exception{
public:
BundleNotInProgressException(
const char *w="call to EndBundle when bundle is not in progress" )
: Exception( w ) {}
};

class MessageInProgressException : public Exception{
public:
MessageInProgressException(
const char *w="opening or closing bundle or message while message 
is in progress" )
: Exception( w ) {}
};

class MessageNotInProgressException : public Exception{
public:
MessageNotInProgressException(
const char *w="call to EndMessage when message is not in progress" )
: Exception( w ) {}
};


class OutboundPacketStream{
public:
OutboundPacketStream( char *buffer, unsigned long capacity );
~OutboundPacketStream();

void Clear();

unsigned int Capacity() const;

// invariant: size() is valid even while building a message.
unsigned int Size() const;

const char *Data() const;

// indicates that all messages have been closed with a matching EndMessage
// and all bundles have been closed with a matching EndBundle
bool IsReady() const;

bool IsMessageInProgress() const;
bool IsBundleInProgress() const;

OutboundPacketStream& operator<<( const BundleInitiator& rhs );
OutboundPacketStream& operator<<( const BundleTerminator& rhs );

OutboundPacketStream& operator<<( const BeginMessage& rhs );
OutboundPacketStream& operator<<( const MessageTerminator& rhs );

OutboundPacketStream& operator<<( bool rhs );
OutboundPacketStream& operator<<( const NilType& rhs );
OutboundPacketStream& operator<<( const InfinitumType& rhs );
OutboundPacketStream& operator<<( int32 rhs );

#if !(defined(__x86_64__) || defined(_M_X64))
OutboundPacketStream& operator<<( int rhs )
{ *this << (int32)rhs; return *this; }
#endif

OutboundPacketStream& operator<<( float rhs );
OutboundPacketStream& operator<<( char rhs );
OutboundPacketStream& operator<<( const RgbaColor& rhs );
OutboundPacketStream& operator<<( const MidiMessage& rhs );
OutboundPacketStream& operator<<( int64 rhs );
OutboundPacketStream& operator<<( const TimeTag& rhs 

Re: [osg-users] OSC plugin, VS2010 64-bit

[Paul Martz]

Forgot to mention: 32-bit builds fine, 64-bit is the issue.
   -Paul


On 2/5/2013 3:41 PM, Paul Martz wrote:

Hi Stephan -- The OSC plugin has compile errors with VS2010 for 64-bit builds,
and I thought you might want to take a look at it. This is from trunk r13330.
Thanks!
-Paul



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

[osg-users] OSC plugin, VS2010 64-bit

[Paul Martz]

Hi Stephan -- The OSC plugin has compile errors with VS2010 for 64-bit builds, 
and I thought you might want to take a look at it. This is from trunk r13330. 
Thanks!

   -Paul


2>-- Build started: Project: Plugins osc, Configuration: Debug x64 --
2>Build started 2/5/2013 3:34:09 PM.
2>InitializeBuildStatus:
2>  Touching "osgdb_osc.dir\Debug\Plugins osc.unsuccessfulbuild".
2>CustomBuild:
2>  All outputs are up-to-date.
2>ClCompile:
2>  OscOutboundPacketStream.cpp
2>  OscReceivingDevice.cpp
2>  OscSendingDevice.cpp
2>  ReaderWriterOscDevice.cpp
2>c:\projects\osg\trunk\src\osgplugins\osc\osc\OscOutboundPacketStream.h(101): 
error C2535: 'osc::OutboundPacketStream &osc::OutboundPacketStream::operator 
<<(osc::int32)' : member function already defined or declared
2> 
c:\projects\osg\trunk\src\osgplugins\osc\osc\OscOutboundPacketStream.h(97) : see 
declaration of 'osc::OutboundPacketStream::operator <<'
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(197): 
warning C4244: 'initializing' : conversion from '__int64' to 'osc::uint32', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(225): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(236): 
warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss 
of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(236): 
warning C4244: 'initializing' : conversion from '__int64' to 'unsigned long', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(255): 
warning C4244: 'return' : conversion from '__int64' to 'unsigned int', possible 
loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(261): 
warning C4244: 'initializing' : conversion from '__int64' to 'unsigned int', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(265): 
warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss 
of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(340): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(366): 
warning C4244: 'initializing' : conversion from '__int64' to 'int', possible 
loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(376): 
warning C4244: 'initializing' : conversion from '__int64' to 'osc::uint32', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(578): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(582): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(598): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(602): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(101): 
error C2535: 'osc::OutboundPacketStream &osc::OutboundPacketStream::operator 
<<(osc::int32)' : member function already defined or declared
2> 
C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(97) : see 
declaration of 'osc::OutboundPacketStream::operator <<'
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(101): 
error C2535: 'osc::OutboundPacketStream &osc::OutboundPacketStream::operator 
<<(osc::int32)' : member function already defined or declared
2> 
C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(97) : see 
declaration of 'osc::OutboundPacketStream::operator <<'
2>C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(101): 
error C2535: 'osc::OutboundPacketStream &osc::OutboundPacketStream::operator 
<<(osc::int32)' : member function already defined or declared
2> 
C:\Projects\OSG\trunk\src\osgPlugins\osc\osc/OscOutboundPacketStream.h(97) : see 
declaration of 'osc::OutboundPacketStream::operator <<'

2>
2>Build FAILED.
2>
2>Time Elapsed 00:00:02.40
== Build: 1 succeeded, 1 failed, 5 up-to-date, 0 skipped ==
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fix for building with ref_ptr<>::get()

[Paul Martz]

On 2/5/2013 1:32 PM, Nathan Mielcarek wrote:

Hi all,

This just came up at work a few days ago since I was confused why both
assignment methods performed the same way.

I agree that the cmake option should be removed and set to a default to avoid
confusion. I don't have a preference for that default since the changes needed
to switch our code to either one should be minor.


Just to be clear, with the CMake variable ON, both assignments will compile and 
function properly:

osg::Group* dest;
osg::ref_ptr< osg::Group > refPtrToGrp;

dest = refPtrToGrp.get(); // OK when ON
dest = refPtrToGrp;   // OK when ON

But when set to OFF, use of ref_ptr::get() is required.
dest = refPtrToGrp.get(); // OK when OFF
dest = refPtrToGrp;   // Error when OFF

So, if we remove the variable but leave the code behaving in the ON state, then 
there would be no changes required in your code. Either assignment would work 
fine. But you might want to globally change it to one or the other just for 
consistency. :-)

   -Paul



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

Re: [osg-users] Fix for building with ref_ptr<>::get()

[Paul Martz]

(Please take C++11 discussion to another thread.)

If no one is setting OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION to OFF, I'll 
submit a change that removes the variable (with the code behaving as if the 
variable were present and set to ON).


Here's some history on the ref_ptr issue:

* In OSG 2.6.x and earlier, you always had to use ref_ptr::get() to access the 
pointer address. (This is the same behavior you'd get today if you set 
OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION to the OFF value.)


* Sometime in the 2.7 dev series, OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION was 
added with the default ON value, but there was consensus in osg-users at that 
time that OSG itself should build with the variable set either way.


* OSG 2.8.0 was the first stable release with 
OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION (set to ON by default).

   -Paul


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

Re: [osg-users] Fix for building with ref_ptr<>::get()

[Paul Martz]

Sorry; I cross-posted this to osg-users but forgot to mention why.

I wanted to start a discussion on the CMake variable 
OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION. Does anyone else besides me change 
this variable from its default ON state to OFF? If not, should we just remove it?


The reason I ask is that it seems like every time I do an update from trunk, the 
latest source contains some changes that assume this variable is always on, and 
the code fails to compile if the variable is off. Here's an example:

osg::ref_ptr< osg::Group > source;
osg::Group* dest;
dest = source; // Compile error, should be "dest = source.get()"

I got in the habit of always disabling implicit ref_ptr output conversion 
because someone once tried to use my osgWorks project with an OSG that had been 
built with the CMake variable turned off. The only way for me to make sure my 
project builds is to do all my testing with the CMake variable turned off. Code 
written with the variable in an OFF state will build whether the variable is ON 
or OFF, but code written with the variable in its default ON state stands a good 
chance of failing to compile when the variable is flipped OFF.


If no one else is turning it OFF and are submitting changes that assume it's ON, 
then perhaps I'm better off if I (osgWorks, osgBullet, osgAudio, etc) simply 
stop supporting the variable in an OFF state...? If so, it begs the larger 
question: should we simply remove the variable altogether?

   -Paul


On 2/4/2013 2:18 PM, Paul Martz wrote:

This is just a start, there are many others. Just don't have time to fix them
all at the moment.



___
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] 3D mice

[Paul Martz]

In osgWorks, this support is in the osgwMx library. See osgWorks/include/osgwMx.
   -Paul


On 2/4/2013 9:42 AM, Thomas Lerman wrote:

Thank you Sebastian, Jan, and Paul. Any code samples (I do not have the 
hardware or drivers yet)? I did check out osgWorks and did not see any mention 
of this capability, but could have missed it.
Thank you again,



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

Re: [osg-users] 3D mice

[Paul Martz]

The osgWorks project supports both VRPN and DirectX input devices, and works 
with OSG 2.8.5 and later.

http://osgworks.googlecode.com
   -Paul


On 2/3/2013 10:41 AM, Thomas Lerman wrote:

Hi,

Has anyone taken a look at integrating a device such as a 3D mouse into 
OpenSceneGraph?

Thank you!

Cheers,
Thomas

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





___
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] Method for Converting FLT files to use DDS Textures

[Paul Martz]

I'll second Robert's suggestion of simply loading the .FLT file, 
programmatically changing the texture references, and exporting back to .FLT. 
This seems like the easiest approach, so you should probably try it first before 
moving on to more elaborate solutions.


The potential problem is that the .FLT importer or exporter might drop some .FLT 
features that your (non-OSG) rendering software depends on.

   -Paul



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

Re: [osg-users] API changelog for OSG3

[Paul Martz]

On 1/25/2013 8:47 AM, Ehsan Azar wrote:

It seems I should be able to start with 3.0 but then I wonder why 2.8 is still 
popular.


In my experience providing OSG consulting and dev services, some of my customers 
are content with the stability of 2.8.5 (June 2011), and have no particular need 
for the features in OSG 3.0.1 (July 2011 -- so 2.8.5 is really not that much 
older per se).


Of my customers who *have* moved to 3.0.1, none are making extensive use of the 
big new features as far as I know. The big features that I recall are:

 - OpenGL ES support
 - OpenGL 3 support
 - New native file format
 - Performance enhancements for DBPager

I know there are many people on the list who are using these features. Whether 
you have a need to move to 3.0.1 or not is entirely up to you and your needs.

   -Paul

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

Re: [osg-users] center camera on click

[Paul Martz]

The MxEventHandler class in the osgWorks project has an event handler that lets 
you specify the center of rotation. Documentation is here:

http://vesuite.org/external/docs/osgworks/classosgw_mx_1_1_mx_event_handler.html#_details
so you can see that ctrl+shift+leftmouse sets the new center of rotation. (The 
event handler also supports changing the FOV and toggling between orthographic 
and perspective.)


osgWorks can be downloaded from here:
osgWorks.googlecode.com
and if you want to try this event handler, run the MxViewer example.

The MxViewer example and the MxEventHandler class are built on tools in the 
osgwMx library, which contains several matrix utility classes and functions, as 
well as support for DirectX input devices such as gamepads.

   -Paul


On 1/23/2013 8:52 AM, lucie lemonnier wrote:

Hello,
I click on a point in my node.
I get a world intersection point (hitr->getWorldIntersectPoint()).
I want to center my camera on this point that is to say this point becomes the 
pivot point of the rotation of the camera.
Can you help me please?



Thank you!

Cheers,
lucie

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





___
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] Lock the aspect ratio while allowing the window to be resized

[Paul Martz]

I also misunderstood the question. Apparently, you want to allow the window to 
be resized, but only in such a way that the window's aspect ratio is always the 
same. This really has little to do with OSG (except that you might use an osgGA 
event handler to capture the resize events and do the appropriate thing). And 
you're right, the projection matrix is independent of the window, so you should 
not need to change the projection matrix at all.

   -Paul


On 1/22/2013 8:22 AM, Laurens Voerman wrote:

Hi Ethan,
I did not understand your question correctly. Setting the camera to
camera->setProjectionResizePolicy(osg::Camera::FIXED) will fix the projection,
not the window. As the version you want is not implemented in osg, you will need
to catch resize attempts and force the window to resize while preserving the
aspect ratio.
the osgviewer application has a
 viewer.addEventHandler(new osgViewer::WindowSizeHandler);
You probably should replace that with a new handler, allowing only to resize
with fixed aspect ratio.
Laurens.

On 1/22/2013 2:10 PM, Ethan Fahy wrote:

Hi Laurens,

I tried setting the resize policy as you suggested for the osgViewer::Viewer
default camera as well as the rtt camera and hud camera that are in my
project, but I was still able to freely resize my viewer window without it
locking.  I didn't get any errors, it just didn't lock the window size.
Perhaps there is a difference between projection size and window size.

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





___
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] Lock the aspect ratio while allowing the window to be resized

[Paul Martz]

You can use a Camera update callback to repeatedly set the aspect ratio in the 
Camera projection matrix.

   -Paul


On 1/21/2013 8:14 AM, Ethan Fahy wrote:

Hello,

Is there any way to set up an osgViewer::Viewer with a locked aspect ratio that 
still allows the user to adjust the window size by dragging the bottom-right 
corner of the view window?

Thanks,

-Ethan

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





___
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] GL_RENDERER string

[Paul Martz]

(Cross-posting to the osgWorks Google Group.)

osgWorks r474 now has a singleton instance that allows apps to access 
GL_RENDERER and other values without a current context. To use this tool, do 
something like the following:


osgwTools::Capabilities* caps = 
osgwTools::CapabilitiesSingleton::instance()->getCaps();


Then you can do anything you would normally do with the Capabilities object, 
such as:

// Dump out all the queried values:
caps->dump( osg::notify( osg::ALWAYS ) );
// or just get a copy of the GL_RENDERER string:
const std::string rendererStr = caps->_glRenderer;

Calling dump() produces output like this:

osgWorks version 2.0.3 (20003).
OSG version: 3.1.4
  Queryable strings 
GL_VERSION: 3.3.0
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 9800M GT/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 3.30 NVIDIA via Cg compiler
  Texture implementation constants -
GL_MAX_TEXTURE_SIZE: 8192
GL_MAX_3D_TEXTURE_SIZE: 2048
GL_MAX_CUBE_MAP_TEXTURE_SIZE: 8192
GL_MAX_TEXTURE_UNITS: 4
  Shader implementation constants --
GL_MAX_TEXTURE_IMAGE_UNITS: 32
GL_MAX_TEXTURE_COORDS: 8
GL_MAX_VERTEX_ATTRIBS: 16
GL_DRAW_BUFFERS: 8

I'm not exactly sure how OSG's pbuffer creation works in the case of 
heterogeneous GPUs. I imagine there is a "primary" GPU that handles the context 
creation. To use osgWorks to get per-GPU capabilities, you would need to create 
a separate instance of an osgwTools::Capabilities object while a context is 
current on each separate GPU. This can probably be done with a Camera draw callback.

   -Paul


On 1/15/2013 10:16 AM, Paul Martz wrote:

Chris, you're right about the heterogeneous case.

Current svn trunk HEAD of the osgWorks project has a couple tools that might 
help.

There is a struct osgwTools::Capabilities that your app can invoke while any
context is current (as in a Camera pre-draw callback). It obtains the
GL_RENDERER string plus other strings and GL implementation dependent constants.
It has a dump(std::ostream&) method, which your app can invoke to display the
queried values.

There is also a standalone application called osgwcaps, which simply creates a
pbuffer context, makes it current, creates a Capabilities struct, and dumps the
values to osg::ALWAYS.

Chris, I agree it would be nice to have this someplace instantly accessible. I
might be able to add a static that would query these values at DLL load time.

I hope this helps.
-Paul


On 1/15/2013 8:17 AM, Chris Hanson wrote:

I've been in this situation before too, and it would be very handy to have the
GL_RENDERER and other identifying strings stored in OSG for the user code to
query. Since many people don't know you have to have the context valid, and
others don't know where/when OS has a valid context bound, it would be useful.

Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.


On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter mailto:alist...@mve.com>> wrote:

My solution thus far has been to call glGetString in the same function after
my call to osg::GL2Extensions::Get, since the OpenGL context appears to be
valid at that time - indeed the glGetString call is made internally by the
GLExtensions stuff at that time.

__ __

It just seems like the renderer string should be exposed by the extensions
object and it’s not.

__ __

*From:*osg-users-boun...@lists.openscenegraph.org
<mailto:osg-users-boun...@lists.openscenegraph.org>
[mailto:osg-users-boun...@lists.openscenegraph.org
<mailto:osg-users-boun...@lists.openscenegraph.org>] *On Behalf Of *Gianluca
Natale
*Sent:* 15 January 2013 10:54
*To:* OpenSceneGraph Users
*Subject:* [osg-users] R: GL_RENDERER string

__ __

Out of OSG/Qt, I think you should:

__1)__Create a very simple rendering context (associated to the window
created by your application);

__2)__Make that rendering context as the current one;

__3)__Call glGetString(GL_RENDERER, …);

__ __

Steps 1 and 2 are required, since all gl calls need a current rendering
context to work with.

About steps 1 and 2, you should look at how OSG create the rendering
context.

__ __

*Da:*osg-users-boun...@lists.openscenegraph.org
<mailto:osg-users-boun...@lists.openscenegraph.org>
[mailto:osg-users-boun...@lists.openscenegraph.org] *Per conto di *Alistair
Baxter
*Inviato:* martedì 15 gennaio 2013 10:47
*A:* osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
*Oggetto:* [osg-users] GL_RENDERER string

__ __

I’m wanting to get the 

Re: [osg-users] GL_RENDERER string

[Paul Martz]

Chris, you're right about the heterogeneous case.

Current svn trunk HEAD of the osgWorks project has a couple tools that might 
help.

There is a struct osgwTools::Capabilities that your app can invoke while any 
context is current (as in a Camera pre-draw callback). It obtains the 
GL_RENDERER string plus other strings and GL implementation dependent constants. 
It has a dump(std::ostream&) method, which your app can invoke to display the 
queried values.


There is also a standalone application called osgwcaps, which simply creates a 
pbuffer context, makes it current, creates a Capabilities struct, and dumps the 
values to osg::ALWAYS.


Chris, I agree it would be nice to have this someplace instantly accessible. I 
might be able to add a static that would query these values at DLL load time.


I hope this helps.
   -Paul


On 1/15/2013 8:17 AM, Chris Hanson wrote:

I've been in this situation before too, and it would be very handy to have the
GL_RENDERER and other identifying strings stored in OSG for the user code to
query. Since many people don't know you have to have the context valid, and
others don't know where/when OS has a valid context bound, it would be useful.

Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.


On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter mailto:alist...@mve.com>> wrote:

My solution thus far has been to call glGetString in the same function after
my call to osg::GL2Extensions::Get, since the OpenGL context appears to be
valid at that time - indeed the glGetString call is made internally by the
GLExtensions stuff at that time.

__ __

It just seems like the renderer string should be exposed by the extensions
object and it’s not.

__ __

*From:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org
] *On Behalf Of *Gianluca
Natale
*Sent:* 15 January 2013 10:54
*To:* OpenSceneGraph Users
*Subject:* [osg-users] R: GL_RENDERER string

__ __

Out of OSG/Qt, I think you should:

__1)__Create a very simple rendering context (associated to the window
created by your application);

__2)__Make that rendering context as the current one;

__3)__Call glGetString(GL_RENDERER, …);

__ __

Steps 1 and 2 are required, since all gl calls need a current rendering
context to work with.

About steps 1 and 2, you should look at how OSG create the rendering
context.

__ __

*Da:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org] *Per conto di *Alistair
Baxter
*Inviato:* martedì 15 gennaio 2013 10:47
*A:* osg-users@lists.openscenegraph.org

*Oggetto:* [osg-users] GL_RENDERER string

__ __

I’m wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt
application for debug purposes, and potentially for showing to users for
technical support purposes.

__ __

I can get the likes of GL and GLSL version from the osg::GL2Extensions
object, and I can see the renderer string being queries in the source code,
but I’m having difficulty figuring out how to get it out.


___
osg-users mailing list
osg-users@lists.openscenegraph.org 

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL
• OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography •
Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel
 (775) 623-PIXL [7495]


___
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] Create a custom RenderStage

[Paul Martz]

The CullVisitor traverses the scene graph and assembles a render graph. The 
structure of the render graph is composed of RenderBins, some of which might 
actually be RenderStages.


The current RenderBin changes under two circumstances:
 - The CullVisitor encounters a Node with a StateSet whose RenderBin details 
require a different RenderBin.
 - The CullVisitor encounters a Camera, or some custom Node that calls into the 
CullVisitor to change the RenderBin.


The CullVisitor contains built-in support for Camera. The CullVisitor changes 
the RenderBin to the Camera's RenderStage during CullVisitor::apply(Camera&).


If you want to derive a class from RenderStage and insert it into the render 
graph, you can do that with a custom Node class. But because CullVisitor doesn't 
know about your custom Node, you must overrides Node::traverse(). In that 
method, call into the CullVisitor to set your custom RenderStage. I have done 
this before, and it does work. Most recently, I used a custom RenderStage to 
implement depth peeling in which occlusion query was used to determine the 
number of passes.


You might also be able to insert a custom RenderStage by editing the render 
graph directly, perhaps with an osgViewer Operation. I have never tried this 
approach.


There is no way to "register" a RenderStage for Cameras to use, as far as I 
know. But as you already know, you can do this with RenderBin. So if you don't 
require any of the functionality of RenderStage, then perhaps a custom RenderBin 
would suffice.


Hope this helps,
   -Paul


On 1/2/2013 1:01 AM, Aurelien Albert wrote:

Hi,

I use differents custom RenderStages : as pre-renderstage for pre-processing 
and as post-renderstage for post processing.

These processing are executed using FBO render targets.

Currently I'm doing that with slaves cameras, but :
  - the "RenderStage" class is derived from the "RenderBin" class
  - it is possible to register new RenderBins using the  
"addRenderBinPrototype" method

So I wonder if it is possible to create a new RenderStage prototype to replace 
my slave cameras ?

How to configure the rendertarget of these renderstages ?

My goal here is to learn how to create / customize RenderStages and RenderBins.

Thank you!

Cheers,
Aurelien

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





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



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

Re: [osg-users] Multiple Cameras and lagging proj matrix

[Paul Martz]

I did come up with a reasonably confined solution for this, and I've added it to 
the osgWorks project, see:

https://code.google.com/p/osgworks/source/browse/trunk/src/osgwTools/MultiCameraProjectionMatrix.cpp
and the associated header in include/osgwTools/MultiCameraProjectionMatrix.h.

MultiCameraProjectionMatrix is a cull callback that you attach to the 
subordinate POST_RENDER Camera in your scene graph. Behind the scenes, it works 
with the root Camera to compute the max far and min near plane values from both 
Cameras, computes a corresponding projection matrix, then sets that uniform per 
render thread.


Glenn (and others), thanks for the extensive help and inspiration on this.
   -Paul


On 12/27/2012 11:43 AM, Paul Martz wrote:

Ah ha. And each Camera has it's own StateSet. I see.

My situation is a bit different, as I have a single subordinate Camera buried in
the scene graph, and it is on that Node that I want to set a projection matrix
Uniform that has a different value per render thread. I could, in theory, add
the Uniform much higher in the scene graph, at the top level slave Cameras used
to create each view. But, unfortunately, this project is a middleware utility
for use by OSG-based apps, so keeping my state and geometry local to a single
subgraph in desirable...

But thanks for the ideas and inspiration. Hopefully I can make this work yet.
-Paul



On 12/26/2012 2:31 PM, Glenn Waldron wrote:

On Wed, Dec 26, 2012 at 1:08 PM, Paul Martz mailto:pma...@skew-matrix.com>> wrote:

Hi Glenn -- I've managed to compute the matrix I need using the clamp
projection callbacks, so thanks for directing my attention there.

But I've ran into problems with multithreading, and it seems like you should
have the same issues, so...

1) When your cull callback sets the matrix uniform value, how are you
ensuring that's thread safe? How do you avoid thread collisions from
multiple cull threads writing the same uniform, or one draw thread reading
it while another cull thread writes it?


I use a separate set of uniforms for each thread with the "per-view data"
idiom. There is a std::map that the cull traversal
code accesses each time based on the active Camera. Map access is protected by a
Mutex. The PerViewData structure contains the actual Uniforms for that Camera.


2) And, along the same lines, it seems like the computed near/far (and
resulting projection matrix) would be different for each render thread
(depending on what was in that thread's view frustum). What technique are
you using that lets you set a different uniform value per render thread?


See above.


Thanks.
-Paul



On 12/15/2012 2:54 PM, Glenn Waldron wrote:

Yes, you got it. cullOvelayGroup() is called during the cull traversal
from an
overloaded traverse() method in OverlayDecorator (which subclasses
Group).

Glenn Waldron / @glennwaldron



    On Sat, Dec 15, 2012 at 1:54 PM, Paul Martz mailto:pma...@skew-matrix.com>
<mailto:pma...@skew-matrix.com <mailto:pma...@skew-matrix.com>__>> 
wrote:

 Thanks, Glenn -- I saw the callback for clamping the projection
matrix while
 I was sifting through the code, and your osgEarth example code is
very
 enlightening.

 Your function cullOverlayGroup(), is that a cull callback? Let me
 regurgitate what it does, so you can correct me if I'm
misunderstand: It
 runs the CullVisitor on its subgraph, then uses the resulting
clamped
 projection matrix (which it gets from the clampProjection callback)
as a
 uniform in your shader code. Hm. Cool idea.
 -Paul



 On 12/14/2012 1:27 PM, Glenn Waldron wrote:

 Paul,
 I had a similar problem (I think). I installed a custom
callback on the RTT
 camera
(CullSettings::setClampProjectionMatrixCallback). This

 callback would
 call the original implementation first, then store the results
of the
 projection
 matrix clamp so that I could use it immediately.

 You can see the custom callback here:


https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171


<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L171>




<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L171


<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171>>


 Each frame, I prime it with the current CullVisitor:


https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384


<http

Re: [osg-users] Multiple Cameras and lagging proj matrix

[Paul Martz]

Ah ha. And each Camera has it's own StateSet. I see.

My situation is a bit different, as I have a single subordinate Camera buried in 
the scene graph, and it is on that Node that I want to set a projection matrix 
Uniform that has a different value per render thread. I could, in theory, add 
the Uniform much higher in the scene graph, at the top level slave Cameras used 
to create each view. But, unfortunately, this project is a middleware utility 
for use by OSG-based apps, so keeping my state and geometry local to a single 
subgraph in desirable...


But thanks for the ideas and inspiration. Hopefully I can make this work yet.
   -Paul



On 12/26/2012 2:31 PM, Glenn Waldron wrote:

On Wed, Dec 26, 2012 at 1:08 PM, Paul Martz mailto:pma...@skew-matrix.com>> wrote:

Hi Glenn -- I've managed to compute the matrix I need using the clamp
projection callbacks, so thanks for directing my attention there.

But I've ran into problems with multithreading, and it seems like you should
have the same issues, so...

1) When your cull callback sets the matrix uniform value, how are you
ensuring that's thread safe? How do you avoid thread collisions from
multiple cull threads writing the same uniform, or one draw thread reading
it while another cull thread writes it?


I use a separate set of uniforms for each thread with the "per-view data"
idiom. There is a std::map that the cull traversal
code accesses each time based on the active Camera. Map access is protected by a
Mutex. The PerViewData structure contains the actual Uniforms for that Camera.


2) And, along the same lines, it seems like the computed near/far (and
resulting projection matrix) would be different for each render thread
(depending on what was in that thread's view frustum). What technique are
you using that lets you set a different uniform value per render thread?


See above.


Thanks.
-Paul



On 12/15/2012 2:54 PM, Glenn Waldron wrote:

Yes, you got it. cullOvelayGroup() is called during the cull traversal
from an
overloaded traverse() method in OverlayDecorator (which subclasses 
Group).

Glenn Waldron / @glennwaldron



    On Sat, Dec 15, 2012 at 1:54 PM, Paul Martz mailto:pma...@skew-matrix.com>
<mailto:pma...@skew-matrix.com <mailto:pma...@skew-matrix.com>__>> 
wrote:

 Thanks, Glenn -- I saw the callback for clamping the projection
matrix while
 I was sifting through the code, and your osgEarth example code is 
very
 enlightening.

 Your function cullOverlayGroup(), is that a cull callback? Let me
 regurgitate what it does, so you can correct me if I'm
misunderstand: It
 runs the CullVisitor on its subgraph, then uses the resulting 
clamped
 projection matrix (which it gets from the clampProjection callback)
as a
 uniform in your shader code. Hm. Cool idea.
 -Paul



 On 12/14/2012 1:27 PM, Glenn Waldron wrote:

 Paul,
 I had a similar problem (I think). I installed a custom
callback on the RTT
 camera
(CullSettings::setClampProjectionMatrixCallback). This

 callback would
 call the original implementation first, then store the results
of the
 projection
 matrix clamp so that I could use it immediately.

 You can see the custom callback here:


https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171

<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L171>



<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L171

<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171>>

 Each frame, I prime it with the current CullVisitor:


https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384

<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L384>



<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L384

<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384>>

 And then immediately use the result to set a uniform:


https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L403

<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L403>



<https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechn

Re: [osg-users] Multiple Cameras and lagging proj matrix

[Paul Martz]

Hi Glenn -- I've managed to compute the matrix I need using the clamp projection 
callbacks, so thanks for directing my attention there.


But I've ran into problems with multithreading, and it seems like you should 
have the same issues, so...


1) When your cull callback sets the matrix uniform value, how are you ensuring 
that's thread safe? How do you avoid thread collisions from multiple cull 
threads writing the same uniform, or one draw thread reading it while another 
cull thread writes it?


2) And, along the same lines, it seems like the computed near/far (and resulting 
projection matrix) would be different for each render thread (depending on what 
was in that thread's view frustum). What technique are you using that lets you 
set a different uniform value per render thread?


Thanks.
   -Paul


On 12/15/2012 2:54 PM, Glenn Waldron wrote:

Yes, you got it. cullOvelayGroup() is called during the cull traversal from an
overloaded traverse() method in OverlayDecorator (which subclasses Group).

Glenn Waldron / @glennwaldron



On Sat, Dec 15, 2012 at 1:54 PM, Paul Martz mailto:pma...@skew-matrix.com>> wrote:

Thanks, Glenn -- I saw the callback for clamping the projection matrix while
I was sifting through the code, and your osgEarth example code is very
enlightening.

Your function cullOverlayGroup(), is that a cull callback? Let me
regurgitate what it does, so you can correct me if I'm misunderstand: It
runs the CullVisitor on its subgraph, then uses the resulting clamped
projection matrix (which it gets from the clampProjection callback) as a
uniform in your shader code. Hm. Cool idea.
-Paul



On 12/14/2012 1:27 PM, Glenn Waldron wrote:

Paul,
I had a similar problem (I think). I installed a custom callback on the 
RTT
camera (CullSettings::__setClampProjectionMatrixCallba__ck). This
callback would
call the original implementation first, then store the results of the
projection
matrix clamp so that I could use it immediately.

You can see the custom callback here:


https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L171

<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171>

Each frame, I prime it with the current CullVisitor:


https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L384

<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384>

And then immediately use the result to set a uniform:


https://github.com/gwaldron/__osgearth/blob/master/src/__osgEarth/ClampingTechnique.__cpp#L403

<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L403>

Hope this helps.


Glenn Waldron / @glennwaldron / osgEarth.org


    On Fri, Dec 14, 2012 at 3:12 PM, Paul Martz mailto:pma...@skew-matrix.com>
<mailto:pma...@skew-matrix.com <mailto:pma...@skew-matrix.com>__>> 
wrote:

 I think I have a pretty good idea of the cause.

 The CullVisitor gathers near & far info during traversal but 
doesn't
 actually compute the final projection matrix until after the 
traversal
 completes. This means, obviously, that the projection matrix for
the current
 frame hasn't been computed at the time the CullVisitor encounters 
my
 post-render Camera. Instead, the CullVisitor inserts last frame's
projection
 matrix into the render graph, which is used for the box rendering.
Then it
 completes traversal, computes the *correct* projection matrix, and
uses this
 new matrix for the viewer root Camera's cylinder rendering. Thus,
the two
 projection matrices are off just slightly, and the result is
incorrect z
 interaction.

 But knowing this, I haven't been able to come up with a workaround.
(Okay,
 well, short of editing the render graph after cull, which seems
like I'd be
 asking for trouble.) So, still hoping for input from the community
on how to
 make this work without visual artifacts. Thanks.
 -Paul


 On 12/14/2012 11:28 AM, Paul Martz wrote:

 Hi all -- I'm attempting to render with two Cameras, where one
inherits the
 projection matrix of the other. But there appears to be some
latency
 such that
 the subordinate Camera doesn't get the projection matrix until
one frame
 late.
 You can reproduce the issue with the attached example and
  

Re: [osg-users] Model Matrix in Vertex Shader

[Paul Martz]

The OpenSceneGraph Reference Manual at lulu.com also has this info, but both 
resources are out of date.


You can easily get a list of OSG's built-in uniforms by doing a recursive grep 
in your OSG source tree for "getOrCreateUniform". All OSG built-in uniforms are 
created using this function.

   -Paul


On 12/20/2012 4:57 AM, Alberto Luaces wrote:

Christian Buchner writes:


Is there one definitive list that explains all the built-in osg
uniforms? This one would have come handy earlier, but I did not know
about it.


Take a look at Mike Weiblen's GLSL cheatsheet, although it could be
outdated:

http://mew.cx/glsl_quickref.pdf


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

Re: [osg-users] Use many effect on the same model

[Paul Martz]

There is only one model in the scene, but it is traversed and rendered twice 
with the two different effects. You said you were doing multipass rendering, and 
this is how multipass rendering is done in OSG. To avoid having one rendering on 
top of the other, you use blending** to composite the two renderings together.


** (Or some other mechanism, depending on what you're trying to accomplish.)
   -Paul


On 12/16/2012 10:42 AM, Peterakos wrote:

Hello.

Thank you for your answer but it seems it doesnt work because with
this graph we have 2 models in the scene (one on top of each other)
I want my model to be affected by both effects (only 1 model in the scene).

thnx again.
___
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] Use many effect on the same model

[Paul Martz]

I think you just want to multiparent the model to the two different effect 
nodes, like this:


  root
 /\
Effect1  Effect2
 \/
  model

   -Paul

On 12/15/2012 3:49 PM, Peterakos wrote:

Hello.

I want to use 2 different effects on the same model but i am not sure
if this is possible.
I have 2 multi pass render algorithms implemented in 2 different effects.
Can i have the following graph ?

Effect1
Effect2
Model

Knowing that the child's state overrides the parent's, i would say
that you cant use 2 different programs one
after another on the same model unless you use both on the same effect.

Any idea of how i can achieve this ?

Thank you for your time.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



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

Re: [osg-users] Multiple Cameras and lagging proj matrix

[Paul Martz]

Thanks, Glenn -- I saw the callback for clamping the projection matrix while I 
was sifting through the code, and your osgEarth example code is very enlightening.


Your function cullOverlayGroup(), is that a cull callback? Let me regurgitate 
what it does, so you can correct me if I'm misunderstand: It runs the 
CullVisitor on its subgraph, then uses the resulting clamped projection matrix 
(which it gets from the clampProjection callback) as a uniform in your shader 
code. Hm. Cool idea.

   -Paul


On 12/14/2012 1:27 PM, Glenn Waldron wrote:

Paul,
I had a similar problem (I think). I installed a custom callback on the RTT
camera (CullSettings::setClampProjectionMatrixCallback). This callback would
call the original implementation first, then store the results of the projection
matrix clamp so that I could use it immediately.

You can see the custom callback here:

https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171

Each frame, I prime it with the current CullVisitor:

https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384

And then immediately use the result to set a uniform:

https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L403

Hope this helps.


Glenn Waldron / @glennwaldron / osgEarth.org


On Fri, Dec 14, 2012 at 3:12 PM, Paul Martz mailto:pma...@skew-matrix.com>> wrote:

I think I have a pretty good idea of the cause.

The CullVisitor gathers near & far info during traversal but doesn't
actually compute the final projection matrix until after the traversal
completes. This means, obviously, that the projection matrix for the current
frame hasn't been computed at the time the CullVisitor encounters my
post-render Camera. Instead, the CullVisitor inserts last frame's projection
matrix into the render graph, which is used for the box rendering. Then it
completes traversal, computes the *correct* projection matrix, and uses this
new matrix for the viewer root Camera's cylinder rendering. Thus, the two
projection matrices are off just slightly, and the result is incorrect z
interaction.

But knowing this, I haven't been able to come up with a workaround. (Okay,
well, short of editing the render graph after cull, which seems like I'd be
asking for trouble.) So, still hoping for input from the community on how to
make this work without visual artifacts. Thanks.
    -Paul


On 12/14/2012 11:28 AM, Paul Martz wrote:

Hi all -- I'm attempting to render with two Cameras, where one inherits 
the
projection matrix of the other. But there appears to be some latency
such that
the subordinate Camera doesn't get the projection matrix until one frame
late.
You can reproduce the issue with the attached example and animation 
path.

The example configures the viewer's root Camera to render to an FBO with
color
and depth textures attached. It renders a cylinder into these textures. 
A
post-render Camera then splats the color texture into the window with a 
full
screen quad.

The problem occurs when a final post-render Camera draws the
checkerboard box.
It uses the depth texture an input to a fragment shader that performs a
manual
depth test. I have taken steps to ensure that this post-render Camera 
has
RELATIVE_RF ref frame, and set it to disable near & far computation, so
that it
will inherit the projection matrix of the viewer root Camera. This works
quite
well except for the slight lag, indicating that this post-render Camera
doesn't
get the correct projection matrix until about a frame too late.

The problem is definitely related to the fact that the viewer root 
Camera is
configured to auto-compute near & far, because if I disable this and set
a fixed
projection matrix on the root Camera, the problem goes away (uncomment
lines 49
and 50).

Can anyone explain the one-frame lag with the projection matrix? I'll be
digging
into the code over the weekend to figure this out myself, but would
appreciate
any input while I dig...

Thanks,
 -Paul





_
osg-users mailing list
osg-users@lists.__openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>

http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org

<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org>

_
osg-users mailing list
osg-users@lists.__openscenegraph.org 
<mailto:osg-users@lists.openscenegraph.

Re: [osg-users] Multiple Cameras and lagging proj matrix

[Paul Martz]

I think I have a pretty good idea of the cause.

The CullVisitor gathers near & far info during traversal but doesn't actually 
compute the final projection matrix until after the traversal completes. This 
means, obviously, that the projection matrix for the current frame hasn't been 
computed at the time the CullVisitor encounters my post-render Camera. Instead, 
the CullVisitor inserts last frame's projection matrix into the render graph, 
which is used for the box rendering. Then it completes traversal, computes the 
*correct* projection matrix, and uses this new matrix for the viewer root 
Camera's cylinder rendering. Thus, the two projection matrices are off just 
slightly, and the result is incorrect z interaction.


But knowing this, I haven't been able to come up with a workaround. (Okay, well, 
short of editing the render graph after cull, which seems like I'd be asking for 
trouble.) So, still hoping for input from the community on how to make this work 
without visual artifacts. Thanks.

   -Paul


On 12/14/2012 11:28 AM, Paul Martz wrote:

Hi all -- I'm attempting to render with two Cameras, where one inherits the
projection matrix of the other. But there appears to be some latency such that
the subordinate Camera doesn't get the projection matrix until one frame late.
You can reproduce the issue with the attached example and animation path.

The example configures the viewer's root Camera to render to an FBO with color
and depth textures attached. It renders a cylinder into these textures. A
post-render Camera then splats the color texture into the window with a full
screen quad.

The problem occurs when a final post-render Camera draws the checkerboard box.
It uses the depth texture an input to a fragment shader that performs a manual
depth test. I have taken steps to ensure that this post-render Camera has
RELATIVE_RF ref frame, and set it to disable near & far computation, so that it
will inherit the projection matrix of the viewer root Camera. This works quite
well except for the slight lag, indicating that this post-render Camera doesn't
get the correct projection matrix until about a frame too late.

The problem is definitely related to the fact that the viewer root Camera is
configured to auto-compute near & far, because if I disable this and set a fixed
projection matrix on the root Camera, the problem goes away (uncomment lines 49
and 50).

Can anyone explain the one-frame lag with the projection matrix? I'll be digging
into the code over the weekend to figure this out myself, but would appreciate
any input while I dig...

Thanks,
-Paul





___
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] gluDisk - how with OSG?

[Paul Martz]

The osgWorks project has a makeCircle function that will create a solid disk.

To create a disk with a hole in it, use the makeOpenCylinder function with a 0.0 
length and different radii for the cylinder ends.


osgWorks is here:
osgworks.googlecode.com

   -Paul


On 12/10/2012 2:20 AM, DavidHornung wrote:

Hi,

Thanks, that would be an solution, but a disk is defined to have a hole in the
middle, how to get this?

cheers,
David

Hi David,

I don't know if it is the best solution, but you can use an
osg::Drawable using an osg::Cylinder with low height as shape.

Cheers,
Carlos

On 10 December 2012 08:46, DavidHornung  wrote:

Hello,

in OpenGL i used gluDisk to drow a disk - how to do it in OSG

cheers,
David
___
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] Rendering sets of objects in layers/passes

[Paul Martz]

Use a different Camera for each set, and on each Camera call: cam->setClearMask( 
GL_DEPTH_BUFFER_BIT ) so that they clear only the depth buffer and not the color 
buffer.

   -Paul


On 12/8/2012 2:34 PM, Preet wrote:

Hiya,

I have multiple sets of depth sorted geometry that I'd like rendered in a
specific order. So the depth sorted part itself only matters within a single
set, if that makes any sense. For example, I might have three sets, each
containing 100 osg::Geometry objects. I'd like each of the objects to render
correctly with respect to the other objects in their own set, but I'd like all
the objects in the first set to show up over all the objects in the second set
and so on.

I'm not sure how to do this with OpenSceneGraph. I tried giving each set of
objects a separate DepthSorted render bin... but this doesn't do what I want.
I'd appreciate any advice.


Preet


___
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] GLES2/Trigonometry Question

[Paul Martz]

(Sorry if this shows up twice; I originally posted it Tuesday but it has not 
echoed back to the list. Test emails seem to work, so trying again...)


Hi Jeremy -- Since you know the FOV in y (it's 45.0 degrees), you can compute 
the distance to "fit" a bounding sphere with the following code:


double computeInitialDistanceFromFOVY( const osg::BoundingSphere& bs, const 
double fovy )

{
return( bs.radius() / sin( osg::DegreesToRadians( fovy * .5 ) ) );
}

That code comes from the matrix utility library (osgwMx) in the osgWorks 
project, but equivalent code exists in osgGA to compute home positions, which 
you could also use as a reference.

   -Paul



On 12/4/2012 7:47 AM, Jeremy Moles wrote:

Hello everyone! I'm writing a bit of code using parts of OSG and pure OpenGLES2.
This isn't exactly an OSG question, per se, but there are a lot of OpenGL
experts here and this is a great resource. :) Any help is appreciated!

In my particular scene, I do not maintain a matrix representing my "camera";
there is a global projection matrix and each Drawable maintains its own model
matrix. For this reason, whether pedantically right or wrong, I say that my
camera always sits at 0, 0, 0 and looks into a frustum created using the
equivalent of gluPerspective(45, 1, 1, 100).

What I'm looking for is the trigonometric calculation that would allow me to
determine either the Z value to translate my scene or the scale to apply to my
scene in order to fit the entire thing cleanly into my viewport.

I have both the osg::BoundingBox and osg::BoundingSphere of my scene, but since
I'm not using a camera manipulator or view matrix directly, I can't simply
reference the code in CameraManipulator.cpp.

Furthermore: I have this working currentls in a VERY TERRIBLE way. :) What I do
is use reimplementations of gluProject and gluUnproject to caclulate
screen-to-world and world-to-screen coordinates. I then use those values to
figure out how much to scale my scene by, but this feels so wrong (and bound to
a known window size) that I know there must be a better way.

Thanks!
___
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] test

[Paul Martz]

Sorry, please ignore.

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

Re: [osg-users] OSC plugin on Windows?

[Paul Martz]

Hi all --

There was an issue in this update that caused VS to misinterpret the libraries. 
The attached osc CMakeLists.txt fixes the issue and results in a clean build.

   -Paul


On 11/20/2012 3:38 AM, Robert Osfield wrote:

Hi Paul, Christian, Stephan et. al,

On 20 November 2012 07:36, Christian Schulte mailto:christian.schu...@onera.fr>> wrote:

looking at the errors the missing windows lib would be the one containing
the network features, as I know it is the basic WinSock library ws2_32.dll.


I've just copied in the include of ws2_32.dll as is done in the osgcluster
example, could you do an svn update and let me know if this fixes the build?

Robert.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_LIST_DIR})

SET(TARGET_SRC
ip/IpEndpointName.cpp
osc/OscOutboundPacketStream.cpp
osc/OscPrintReceivedElements.cpp
osc/OscReceivedElements.cpp
osc/OscTypes.cpp
OscDevice.cpp
OscProxyEventHandler.cpp
ReaderWriterOscDevice.cpp
)

SET(TARGET_H
ip/IpEndpointName.h
ip/NetworkingUtils.h
ip/PacketListener.h
ip/TimerListener.h
ip/UdpSocket.h
osc/MessageMappingOscPacketListener.h
osc/OscException.h
osc/OscHostEndianness.h
osc/OscOutboundPacketStream.h
osc/OscPacketListener.h
osc/OscPrintReceivedElements.h
osc/OscReceivedElements.h
osc/OscTypes.h
OscProxyEventHandler.hpp
OscDevice.hpp
)

if(WIN32)
SET(TARGET_SRC
${TARGET_SRC}
ip/win32/NetworkingUtils.cpp 
ip/win32/UdpSocket.cpp
)
SET(TARGET_EXTERNAL_LIBRARIES 
"${TARGET_EXTERNAL_LIBRARIES};Ws2_32.lib;winmm")
ELSE()
SET(TARGET_SRC
${TARGET_SRC}
ip/posix/NetworkingUtils.cpp 
ip/posix/UdpSocket.cpp
)
ENDIF()

SET(TARGET_ADDED_LIBRARIES osgGA )

 end var setup  ###
SETUP_PLUGIN(osc)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSC plugin on Windows?

[Paul Martz]

Hi Stephan -- Is the OSC plugin tested on Windows? I'm getting several undefined 
symbols during link using VS2010, building 32bit on Win7 (see below). I don't 
see any CMake controls to disallow this plugin on Windows, so I'm guessing these 
are build errors that should be fixed.

   -Paul


1>NetworkingUtils.obj : error LNK2019: unresolved external symbol 
__imp__WSAStartup@8 referenced in function "public: __thiscall 
NetworkInitializer::NetworkInitializer(void)" (??0NetworkInitializer@@QAE@XZ)
1>NetworkingUtils.obj : error LNK2019: unresolved external symbol 
__imp__WSACleanup@0 referenced in function "public: __thiscall 
NetworkInitializer::~NetworkInitializer(void)" (??1NetworkInitializer@@QAE@XZ)
1>NetworkingUtils.obj : error LNK2019: unresolved external symbol __imp__ntohl@4 
referenced in function "unsigned long __cdecl GetHostByName(char const *)" 
(?GetHostByName@@YAKPBD@Z)

1>UdpSocket.obj : error LNK2001: unresolved external symbol __imp__ntohl@4
1>NetworkingUtils.obj : error LNK2019: unresolved external symbol 
__imp__gethostbyname@4 referenced in function "unsigned long __cdecl 
GetHostByName(char const *)" (?GetHostByName@@YAKPBD@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__htons@4 
referenced in function "void __cdecl SockaddrFromIpEndpointName(struct 
sockaddr_in &,class IpEndpointName const &)" 
(?SockaddrFromIpEndpointName@@YAXAAUsockaddr_in@@ABVIpEndpointName@@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__htonl@4 
referenced in function "void __cdecl SockaddrFromIpEndpointName(struct 
sockaddr_in &,class IpEndpointName const &)" 
(?SockaddrFromIpEndpointName@@YAXAAUsockaddr_in@@ABVIpEndpointName@@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__ntohs@4 
referenced in function "class IpEndpointName __cdecl 
IpEndpointNameFromSockaddr(struct sockaddr_in const &)" 
(?IpEndpointNameFromSockaddr@@YA?AVIpEndpointName@@ABUsockaddr_in@@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__socket@12 
referenced in function "public: __thiscall 
UdpSocket::Implementation::Implementation(void)" 
(??0Implementation@UdpSocket@@QAE@XZ)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__closesocket@4 
referenced in function "public: __thiscall 
UdpSocket::Implementation::~Implementation(void)" 
(??1Implementation@UdpSocket@@QAE@XZ)
1>UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__WSAGetLastError@0 referenced in function "public: class IpEndpointName 
__thiscall UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName 
const &)const " 
(?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__getsockname@12 referenced in function "public: class IpEndpointName 
__thiscall UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName 
const &)const " 
(?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__connect@12 
referenced in function "public: class IpEndpointName __thiscall 
UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName const &)const " 
(?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__send@16 
referenced in function "public: void __thiscall 
UdpSocket::Implementation::Send(char const *,int)" 
(?Send@Implementation@UdpSocket@@QAEXPBDH@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__sendto@24 
referenced in function "public: void __thiscall 
UdpSocket::Implementation::SendTo(class IpEndpointName const &,char const 
*,int)" (?SendTo@Implementation@UdpSocket@@QAEXABVIpEndpointName@@PBDH@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__bind@12 
referenced in function "public: void __thiscall 
UdpSocket::Implementation::Bind(class IpEndpointName const &)" 
(?Bind@Implementation@UdpSocket@@QAEXABVIpEndpointName@@@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__recvfrom@24 
referenced in function "public: int __thiscall 
UdpSocket::Implementation::ReceiveFrom(class IpEndpointName &,char *,int)" 
(?ReceiveFrom@Implementation@UdpSocket@@QAEHAAVIpEndpointName@@PADH@Z)
1>UdpSocket.obj : error LNK2019: unresolved external symbol __imp__timeGetTime@0 
referenced in function "private: double __thiscall 
SocketReceiveMultiplexer::Implementation::GetCurrentTimeMs(void)const " 
(?GetCurrentTimeMs@Implementation@SocketReceiveMultiplexer@@ABENXZ)
1>UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__ioctlsocket@12 referenced in function "public: void __thiscall 
SocketReceiveMultiplexer::Implementation::Run(void)" 
(?Run@Implementation@SocketReceiveMultiplexer@@QAEXXZ)
1>UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__WSAEventSelect@12 referenced in function "public: void __thiscall 
SocketReceiveMultiplexer:

Re: [osg-users] Are shaders not saved during osgDB::writeNodeFile?

[Paul Martz]

I did this:
  osgconv glsl_confetti.osgt out.osg
then looked at out.osg in an editor and it definitely contains shaders.
   -Paul


On 11/16/2012 9:36 PM, michael kapelko wrote:

Hi.
I've attached custom shader for a node in a ShadowedScene. I then called
osgDB::writeNodeFile upon it and found out that it doesn't save those shaders
into osg file.
Is it so by design or am I doing it wrong?

PS:
Source code: http://pastie.org/5390724
Source code archive: 
https://dl.dropbox.com/u/12634473/osg/shader_not_saved.tar.bz2


___
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] Oddities when loading a FLT file

[Paul Martz]

I had another thought on this, Chris. Set a breakpoint in the Multiswitch 
constructor and verify that the "missing" Multiswitch is being created under 
both circumstances. Assuming that test passes, set a breakpoint in the 
Multiswitch destructor, it should get hit when the "missing" Multiswitch is 
deleted. Then you can look at the call stack and find out why and how it is 
being removed.

   -Paul


On 11/8/2012 7:55 PM, Chris Hanson wrote:


   I've encountered a strange behavior when loading a client-supplied FLT file
and I haven't been able to drill down and find an explanation. I think I know
what must be happening, but I can't find any mechanism to explain how.

   The customer has a TXP database which refers to a FLT model. The FLT model
has a named MultiSwitch node, which controls some LightPointNodes.

   The symptom is that if the FLT file is loaded by itself (into osgViewer.exe
for example) a NodeVisitor of ours is able to locate the MultiSwitch by name. If
the FLT file is loaded via the DataBasePager from the TXP file, the FLT loads,
but the visitor is unable to locate the MultiSwitch.

   Further investigation (adding debug code in a readfilecallback to save out a
temporary .OSG file) reveals that somehow the MultiSwitch is not even in the
resulting graph that gets produced from the FLT file. Converting the FLT file to
OSG via osgconv, or a simple readNodeFile+writeNodeFile at the beginning of
main() however produces an .OSG file that does contain the missing MultiSwitch.

   I've gone so far as to add this debug code at the beginning of main(), as
well as in the readfilecallback that is invoked when the databasepager loads the
FLT file:

osgDB::ReaderWriter::ReadResult result =
osgDB::Registry::instance()->readNodeImplementation("foo.flt",NULL);
osgDB::writeNodeFile(*(result.getNode()), "foo.osg");


   I use readNodeImplementation to ensure we're avoiding any callbacks.

  When execute from main(), this code produces a OSG file containing the
MultiSwitch. When copy & pasted to the readfilecallback, it produces a OSG file
lacking the MultiSwitch.
.
   I don't believe the osgUtil Optimizer is in play here, as the databasepager
runs that after the load returns. I don't think any of the FLT loader options (
http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight
 )like
preserveObject are affecting things, because I'm passing a NULL options pointer
in both cases.

   What else could be different between these two cases that could lead to a
different graph being produced from the same FLT file, and how do I unify this
to one (correct) behavior? (I wouldn't think preserveObject or other FLT loader
options would be optimizing out a MultiSwitch as redundant anyway, but perhaps
it's misguided.)


   Please grant me some sanity.


--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL
• OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR •
Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android



___
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] Oddities when loading a FLT file

[Paul Martz]

Are you sure you're getting the same FLT file in both cases? Echo the full path 
returned by osgDB::findDataFile().

   -Paul


On 11/8/2012 7:55 PM, Chris Hanson wrote:


   I've encountered a strange behavior when loading a client-supplied FLT file
and I haven't been able to drill down and find an explanation. I think I know
what must be happening, but I can't find any mechanism to explain how.

   The customer has a TXP database which refers to a FLT model. The FLT model
has a named MultiSwitch node, which controls some LightPointNodes.

   The symptom is that if the FLT file is loaded by itself (into osgViewer.exe
for example) a NodeVisitor of ours is able to locate the MultiSwitch by name. If
the FLT file is loaded via the DataBasePager from the TXP file, the FLT loads,
but the visitor is unable to locate the MultiSwitch.

   Further investigation (adding debug code in a readfilecallback to save out a
temporary .OSG file) reveals that somehow the MultiSwitch is not even in the
resulting graph that gets produced from the FLT file. Converting the FLT file to
OSG via osgconv, or a simple readNodeFile+writeNodeFile at the beginning of
main() however produces an .OSG file that does contain the missing MultiSwitch.

   I've gone so far as to add this debug code at the beginning of main(), as
well as in the readfilecallback that is invoked when the databasepager loads the
FLT file:

osgDB::ReaderWriter::ReadResult result =
osgDB::Registry::instance()->readNodeImplementation("foo.flt",NULL);
osgDB::writeNodeFile(*(result.getNode()), "foo.osg");


   I use readNodeImplementation to ensure we're avoiding any callbacks.

  When execute from main(), this code produces a OSG file containing the
MultiSwitch. When copy & pasted to the readfilecallback, it produces a OSG file
lacking the MultiSwitch.
.
   I don't believe the osgUtil Optimizer is in play here, as the databasepager
runs that after the load returns. I don't think any of the FLT loader options (
http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight
 )like
preserveObject are affecting things, because I'm passing a NULL options pointer
in both cases.

   What else could be different between these two cases that could lead to a
different graph being produced from the same FLT file, and how do I unify this
to one (correct) behavior? (I wouldn't think preserveObject or other FLT loader
options would be optimizing out a MultiSwitch as redundant anyway, but perhaps
it's misguided.)


   Please grant me some sanity.


--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL
• OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR •
Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android



___
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] Just more 3D primitives

[Paul Martz]

On 10/30/2012 5:05 AM, Christian Buchner wrote:

Hi,

for rendering a sphere (or any other round shapes) it might even be
better to use a shader, instead of trying to tesselate the shape into
a complex geometry consisting of a lot of triangles or quads.


One issue with this approach, as well as the ShapeDrawable approach, is that 
most existing code that operates on Drawables is designed to work with 
osg::Geometry. If you export your scene to some format other than OSG-native 
(3ds, obj, flt, etc), such shader-based geometry will likely be ignored by the 
exporter.


Just something to keep in mind.
   -Paul


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