[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 ethanf...@gmail.com 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 bram.vaes...@gmail.com
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]

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 d...@celticblues.com 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] 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 d...@celticblues.com 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 d...@celticblues.com 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] 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 sciro...@163.com 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 blueva...@gmail.com 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:

1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumchar(void) (??$getTypeEnum@D@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumunsigned char(void) (??$getTypeEnum@E@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumshort(void) (??$getTypeEnum@F@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumunsigned short(void) (??$getTypeEnum@G@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumint(void) (??$getTypeEnum@H@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumunsigned int(void) (??$getTypeEnum@I@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumfloat(void) (??$getTypeEnum@M@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumdouble(void) (??$getTypeEnum@N@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Image *(void)
(??$getTypeEnum@PEAVImage@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Object *(void)
(??$getTypeEnum@PEAVObject@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::BoundingBoxImplclass osg::Vec3d
(void) (??$getTypeEnum@V?$BoundingBoxImpl@VVec3d@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::BoundingBoxImplclass osg::Vec3f
(void) (??$getTypeEnum@V?$BoundingBoxImpl@VVec3f@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::BoundingSphereImplclass osg::Vec3d
(void) (??$getTypeEnum@V?$BoundingSphereImpl@VVec3d@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::BoundingSphereImplclass osg::Vec3f
(void) (??$getTypeEnum@V?$BoundingSphereImpl@VVec3f@osg@@@osg@@@osgDB@
@YA?AW4Type@BaseSerializer@0@XZ) already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar  (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
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Matrixd(void)
(??$getTypeEnum@VMatrixd@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Matrixf(void)
(??$getTypeEnum@VMatrixf@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ)
already defined in LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Plane(void) (??$getTypeEnum@VPlane
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Quat(void) (??$getTypeEnum@VQuat
@osg@@@osgDB@@YA?AW4Type@BaseSerializer@0@XZ) already defined in
LuaScriptEngine.obj
1ReaderWriterLua.obj : error LNK2005: enum osgDB::BaseSerializer::Type
__cdecl osgDB::getTypeEnumclass osg::Vec2b(void) (??$getTypeEnum@VVec2b

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 robert.osfi...@gmail.comwrote:

 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 robert.osfi...@gmail.comwrote:

 Hi Alberto,

 On 23 April 2014 16:18, Alberto Luaces alua...@udc.es 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] 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 d...@celticblues.com 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] 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 alist...@mve.com 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] 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 robert.osfi...@gmail.comwrote:

 On 18 March 2014 13:10, Conan Doyle d...@celticblues.com 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]

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
osgsoversion. 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]

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 skewmat...@gmail.com 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
 osgsoversion. 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]

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 trys...@trystan.org
 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 robert.osfi...@gmail.comwrote:

 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] 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.
gl3/gl.h is outdated. I'll submit a change that moves us to the
opengl.orgcurrent standatd gl/glcorearb.h.

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] 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 GL3/gl3.h to
gl/glcorearb.h, 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 robert.osfi...@gmail.comwrote:

 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] Unresolved symbol

[Paul Martz]

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

3Widget.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)
3C:\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] 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
mathieu.mara...@gmail.comwrote:

 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 skewmat...@gmail.com 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

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 jan.ci...@gmail.com wrote:



 On Mon, Nov 18, 2013 at 12:34 PM, Mots G maverickm...@gmail.com 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 
 (herehttp://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

[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] 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 robert.osfi...@gmail.comwrote:

 Hi Paul,


 On 16 November 2013 18:27, Paul Martz skewmat...@gmail.com 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] 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 maverickm...@gmail.com 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 skewmat...@gmail.com 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 maverickm...@gmail.com 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]

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 jan.ci...@gmail.com 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]

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 jan.ci...@gmail.com 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 maverickm...@gmail.com 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 zach.basan...@gmail.comwrote:

 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 jan.ci...@gmail.com 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 robert.osfi...@gmail.comwrote:

 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 bit...@gmail.com 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] 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 robert.osfi...@gmail.comwrote:

 Hi Maik? Klein? how do you like to be addressed?

 On 29 April 2013 00:53, Maik Klein maikkl...@googlemail.com 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] 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 roger.floyd...@gmail.comwrote:

 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] 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 osgfo...@tevs.eu 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]

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 dosto.wa...@gmail.comwrote:

 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] 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] 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 xe...@alphapixel.com 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=gettarget=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] 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 countryartis...@gmail.comwrote:

 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

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 fuhrm...@vrvis.at 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] 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 maikkl...@googlemail.comwrote:

 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

[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 robert.osfi...@gmail.comwrote:

 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 tmban...@rockwellcollins.com 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 randall.h...@gmail.comwrote:

 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 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://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]

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 shayne.tuel...@hill.af.mil 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]

Did you try turning on 2-sided lighting?


On Wed, Mar 13, 2013 at 11:47 AM, Florian Kolbe florian.ko...@in-gmbh.dewrote:

 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]

  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] 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 pol...@yandex.ru 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 skewmat...@gmail.com:

 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

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 wangra...@gmail.com 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_ptrosg::Texture2D tex = new osg::Texture2D;
 tex-setTextureSize( 1024, 1024 );

 osg::ref_ptrosg::FrameBufferObject 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] 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 wangra...@gmail.com 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

[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] 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]

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

[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 --
2Build started 2/5/2013 3:34:09 PM.
2InitializeBuildStatus:
2  Touching osgdb_osc.dir\Debug\Plugins osc.unsuccessfulbuild.
2CustomBuild:
2  All outputs are up-to-date.
2ClCompile:
2  OscOutboundPacketStream.cpp
2  OscReceivingDevice.cpp
2  OscSendingDevice.cpp
2  ReaderWriterOscDevice.cpp
2c:\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 '
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(197): 
warning C4244: 'initializing' : conversion from '__int64' to 'osc::uint32', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(225): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(236): 
warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss 
of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(236): 
warning C4244: 'initializing' : conversion from '__int64' to 'unsigned long', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(255): 
warning C4244: 'return' : conversion from '__int64' to 'unsigned int', possible 
loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(261): 
warning C4244: 'initializing' : conversion from '__int64' to 'unsigned int', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(265): 
warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss 
of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(340): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(366): 
warning C4244: 'initializing' : conversion from '__int64' to 'int', possible 
loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(376): 
warning C4244: 'initializing' : conversion from '__int64' to 'osc::uint32', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(578): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(582): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(598): 
warning C4267: 'argument' : conversion from 'size_t' to 'long', possible loss of 
data
2C:\Projects\OSG\trunk\src\osgPlugins\osc\osc\OscOutboundPacketStream.cpp(602): 
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned long', 
possible loss of data
2C:\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 '
2C:\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 '
2C:\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
2Build FAILED.
2
2Time 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] 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

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 ro...@audiomulch.com

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 );
OutboundPacketStream operator( double rhs );
OutboundPacketStream operator( const char* rhs );
OutboundPacketStream operator( const Symbol rhs );
OutboundPacketStream operator( const Blob rhs );

private:

char *BeginElement( char *beginPtr );
void EndElement( char *endPtr );

bool ElementSizeSlotRequired

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] 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] 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] 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]

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 alist...@mve.com
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 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 
mailto: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
http://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] 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 alist...@mve.com
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 GL_RENDERER string out of my OpenSceneGraph / Qt
application for debug purposes

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 pma...@skew-matrix.com
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::maposg::Camera*,PerViewData 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 pma...@skew-matrix.com
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

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 pma...@skew-matrix.com
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::maposg::Camera*,PerViewData 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 pma...@skew-matrix.com
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/ClampingTechnique.__cpp#L403

https://github.com/gwaldron

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]

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] 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] 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 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 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.org
http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org

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 horn...@googlemail.com 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 christian.schu...@onera.fr
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


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

1UdpSocket.obj : error LNK2001: unresolved external symbol __imp__ntohl@4
1NetworkingUtils.obj : error LNK2019: unresolved external symbol 
__imp__gethostbyname@4 referenced in function unsigned long __cdecl 
GetHostByName(char const *) (?GetHostByName@@YAKPBD@Z)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__socket@12 
referenced in function public: __thiscall 
UdpSocket::Implementation::Implementation(void) 
(??0Implementation@UdpSocket@@QAE@XZ)
1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__closesocket@4 
referenced in function public: __thiscall 
UdpSocket::Implementation::~Implementation(void) 
(??1Implementation@UdpSocket@@QAE@XZ)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.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)
1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__timeGetTime@0 
referenced in function private: double __thiscall 
SocketReceiveMultiplexer::Implementation::GetCurrentTimeMs(void)const  
(?GetCurrentTimeMs@Implementation@SocketReceiveMultiplexer@@ABENXZ)
1UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__ioctlsocket@12 referenced in function public: void __thiscall 
SocketReceiveMultiplexer::Implementation::Run(void) 
(?Run@Implementation@SocketReceiveMultiplexer@@QAEXXZ)
1UdpSocket.obj : error LNK2019: unresolved external symbol 
__imp__WSAEventSelect@12 referenced in function public: void __thiscall 
SocketReceiveMultiplexer::Implementation::Run(void) 

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

Re: [osg-users] Just more 3D primitives

[Paul Martz]

I'm definitely open to having such code contributed to osgWorks, where they 
would be Geometry-based rather than ShapeDrawable-based.

   -Paul


On 10/28/2012 10:28 PM, Andrey Zubarev wrote:

Hi, all!

In OSG we have some simple 3D primitives such as Sphere, Cylinder, etc., even 
Capsule! But what about more primitives, for example, Torus, Torus Arc, 
Truncated Pyramid, Truncated Cone, a Dish (half of Ellipsoid) and so on?
  I believe, all these entities could be done by hand, from the scratch. But, 
maybe, someone knows the source of these primitives - just to avoid 
re-inventing a bicycle?
...

Thank you!

Cheers,
Andrey

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





___
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