Re: [osg-users] OpenSceneGraph new website almost ready

2013-02-07 Thread Jordi Torres
Hi Torben,

We will maintain the trac instances both osg and VPB for archiving old
documentation. Anyway to migrate the VPB trac requires much less effort
than the osg site does. So once the osg site is totally done we can discuss
about where to place the VPB docs, maybe in the tools section or in a
separate joomla instance.

Cheers.

2013/2/7 Torben Dannhauer tor...@dannhauer.info

 Jordi,

 great job, thank you for your effort!

 One question: What will happen to the VirtualPlanetBuilder website?
 There are  some helpful tutorials which should survive :)

 Cheers,
 Torben

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





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




-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
___
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

2013-02-07 Thread Robert Osfield
Hi Frank,

If you nest a Camera below another Camera it operates within the the
parent Camera's RenderStage (the RenderStage is the rendering
back-ends way of managing what to draw each frame), and if it's
assigned as a PRE_RENDER then it'll be drawn before the main body of
the context of the parent Camera, if it's POST_RENDER then it's drawn
after.  If you use NESTED_RENDER then the contents of the child Camera
will just be treated as normal subgraph save for the changes in
projection and view matrices and will just be placed within the main
body of the parents RenderStage.

This arrangement enables complex render to texture schemes where you
can have multiple RTT Camera's nested within other RTT Camera and
still have all the correct results produced, an example of this in
action is the way the impostors are implemented.

This is a bit different than your proposed scheme where the parent
gets rendered first for a NESTED_RENDER, but such a scheme would break
the encapsulation of subgraphs that can be achieved with the present
scheme.  To have a subgraph drawn after it's parent you simply use
POST_RENDER.  If you don't care for the order then simply have sibling
RTT Camera share the same RenderOrder parameters.

Robert.

On 6 February 2013 19:47, Frank Sullivan knarf.navil...@gmail.com wrote:
 Thank you, Paul and Robert.

 Just as a suggestion, it may be useful to have a way for NESTED_RENDER 
 ordered cameras to render to a texture. It's my understanding, from looking 
 at the code and from past forum posts, that NESTED_RENDER cameras ignore the 
 camera RTT stuff. I was hoping that attaching an FBO to a StateSet below the 
 camera would be a useful way to compel a NESTED_RENDER camera to switch over 
 to a new FBO.

 The reason I bring it up is that it would make setting the render order on 
 these cameras brainless -- if camera A needs to render before camera B, then 
 one can simply place camera A as an ancestor of camera B, and not have to 
 worry about setting an explicit render order number. This could be useful for 
 systems that have data-driven pipelines where you have multiple passes over 
 multiple scenes, that are required to happen in a specific order.

 Thanks again!
 Frank

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





 ___
 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] i am having problem compiling program related to TraingleFunctor

2013-02-07 Thread Robert Osfield
Hi Om? Prakash? Paliawl?  Could you sign with your name so we know how to
address you?

As for you errors, it looks like you need to include osg/io_utils as this
will provide the helper functions for writing Vec3's etc. to ostream.

Robert.

On 7 February 2013 05:01, om prakash Paliwal
omprakash.paliwa...@gmail.comwrote:

 i am not able to compile program using TriangleFunctor. at the first
 compilation i got some error saying cout is not a member of std + some
 other chunks . So i added a iostream header file. And when i comiled it
 again there are 3-4 screenful errors. am not able to understand these
 scripts of error ...


 Errors and My program is attached below ...

 thanks for the help in advance 





 i am attaching my program 
  main.cpphttps://docs.google.com/file/d/0B3dFjVubf5gKQ2RrQzdhOU9OR28/edit

 ___
 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] Local coordinates

2013-02-07 Thread Robert Osfield
HI Zeki,

I don't know the specific cause of the problem but again as I don't
have your problem infront of me or the able to see the problem first
hand.  Best I can do is stress that you need to use doubles.  Go back
through your original code submission, is everything doubles???
Keeping looking until you spot an error in not using doubles.  Whether
this might be the cause of the problem I cannot say.  Developing your
observational skills is crucial for a programmer so I'll leave it to
you to sort out the details, practice makes perfect :-)

Robert.

On 7 February 2013 06:50, Zeki Yugnak zeki.yug...@gmail.com wrote:
 Hi Shayne,

 Thanks for your help.

 Your's transformation code block is the same as mine's. I really do not know 
 why object's translation is not smooth.

 Also I could not use second code block because of terrain-object correlation 
 problem. But I hope that I will translate object smoothly using local 
 coordinates, if I can transform terrain or scene to a origin point that is 
 used to calculate object local coordinates.

 Do you have any idea that could not handle with over million values in ECEF 
 coordinate system using different coordinates system to transform object ?

 For example, If I transform root scene to the center of the terrain in ECEF 
 coordinate system or add my object as a child of the terrain, Can I calculate 
 object transformations again according to the center of the terrain in ECEF 
 coordinate system? Do you think that it makes sense?

 Thank you!
 Regards

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





 ___
 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] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Ulrich Hertlein
Hi Philip,

On 7/02/13 15:34, Philip Lamb wrote:
 UpdateCallback: className is AnimationPathCallback and type_id.name() is 
 PN3osg12NodeCallbackE
 
 So it looks like a failure somewhere in RTTI. Both typeid and the 
 dynamic_cast fail to
 convert the osg::NodeCallback* to an osg::AnimationPathCallback*. Yet 
 clearly, the
 callback IS the right type, as evidenced by OSG's className() function's 
 output.
 
 Any ideas about where this kind of issue might be coming from?

This does ring a dim bell somewhere.  Something about type-comparisons being 
done by
pointer rather than name and hence failing when the objects come from different
compilation units.

I haven't got any keywords or links, but I believe there is a compiler flag 
that you can set.

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


Re: [osg-users] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Robert Osfield
HI Philip,

Could you try another compiler under OSX as this looks like a compiler
bug to me.

Robert.

On 7 February 2013 04:34, Philip Lamb p...@eden.net.nz wrote:
 Hi all,

 I'm running into an interesting bug in my code which manifests as behaviour
 that works on one platform (Windows) and not on another (OS X) with the same
 OSG code. (Using OSG trunk, around 3.1.4)

 I am using the following node visitor to reset animations attached to
 transform nodes:

 class ResetAnimationNodesVisitor : public osg::NodeVisitor
 {
 public:



 ResetAnimationNodesVisitor():
 osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}



 virtual void apply(osg::Transform transform)
 {
 osg::NodeCallback *nc = transform.getUpdateCallback();
 osg::AnimationPathCallback* apc =
 dynamic_castosg::AnimationPathCallback*(nc);
 if (apc) {
 apc-reset();
 apc-update(transform);
 }
 traverse(transform);
 }
 };

 This visitor is instantiated on a node thus:

 void resetAnimationTime(osg::ref_ptrosg::Node modelNode)
 {
 ResetAnimationNodesVisitor ranv;
 modelNode-accept(ranv);
 }

 When compiled and run on an animated model under Windows (compiled with
 Visual Studio 2010 SP1) all works as expected. When the exact same code is
 compiled and run under OS X (using Xcode 4.5.2, with LLVM 4.2.1) the dynamic
 cast to osg::AnimationPathCallback* is always NULL.

 I have checked that RTTI is not disabled (it's on by default, and no errors
 are produced by the dynamic_cast, and that indeed things are as expected
 with this snippet inside apply():

 if (nc) osg::notify(osg::NOTICE)  UpdateCallback: className is 
  std::string(transform.getUpdateCallback()-className())   and
 type_id.name() is  typeid(transform.getUpdateCallback()).name() 
 std::endl;

 which produces the output:

 UpdateCallback: className is AnimationPathCallback and type_id.name() is
 PN3osg12NodeCallbackE

 So it looks like a failure somewhere in RTTI. Both typeid and the
 dynamic_cast fail to convert the osg::NodeCallback* to an
 osg::AnimationPathCallback*. Yet clearly, the callback IS the right type, as
 evidenced by OSG's className() function's output.

 Any ideas about where this kind of issue might be coming from?

 Regards,
 Phil.

 ___
 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] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Stephan Huber

Hi Phil,

this worked for me in the past: check your project settings, Symbols 
hidden By default should be deactivated for both osg and your project.


cheers,

Stephan


Am 07.02.13 05:34, schrieb Philip Lamb:

Hi all,

I'm running into an interesting bug in my code which manifests as 
behaviour that works on one platform (Windows) and not on another (OS 
X) with the same OSG code. (Using OSG trunk, around 3.1.4)


I am using the following node visitor to reset animations attached to 
transform nodes:


class ResetAnimationNodesVisitor : public osg::NodeVisitor
{
public:


ResetAnimationNodesVisitor():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}


virtual void apply(osg::Transform transform)
{
osg::NodeCallback *nc = transform.getUpdateCallback();
osg::AnimationPathCallback* apc = 
dynamic_castosg::AnimationPathCallback*(nc);

if (apc) {
apc-reset();
apc-update(transform);
}
traverse(transform);
}
};

This visitor is instantiated on a node thus:

void resetAnimationTime(osg::ref_ptrosg::Node modelNode)
{
ResetAnimationNodesVisitor ranv;
modelNode-accept(ranv);
}

When compiled and run on an animated model under Windows (compiled 
with Visual Studio 2010 SP1) all works as expected. When the exact 
same code is compiled and run under OS X (using Xcode 4.5.2, with LLVM 
4.2.1) the dynamic cast to osg::AnimationPathCallback* is always NULL.


I have checked that RTTI is not disabled (it's on by default, and no 
errors are produced by the dynamic_cast, and that indeed things are 
as expected with this snippet inside apply():


if (nc) osg::notify(osg::NOTICE)  UpdateCallback: className is   
std::string(transform.getUpdateCallback()-className())   and 
type_id.name() is  typeid(transform.getUpdateCallback()).name()  
std::endl;


which produces the output:

UpdateCallback: className is AnimationPathCallback and type_id.name() 
is PN3osg12NodeCallbackE


So it looks like a failure somewhere in RTTI. Both typeid and the 
dynamic_cast fail to convert the osg::NodeCallback* to an 
osg::AnimationPathCallback*. Yet clearly, the callback IS the right 
type, as evidenced by OSG's className() function's output.


Any ideas about where this kind of issue might be coming from?

Regards,
Phil.


___
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] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Robert Osfield
Hi Stephan,

On 7 February 2013 10:43, Stephan Huber ratzf...@digitalmind.de wrote:
 this worked for me in the past: check your project settings,  Symbols
 hidden By default should be deactivated for both osg and your project.

Is this a workaround for a bug in the compiler or is it some obscure
way of enabling proper RTTI support?

Should we be adding this as an option by default for the LLVM compiler?

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


Re: [osg-users] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Sergey Polischuk
Hi I've one run into similar issue when was compiling some sample under linux, in my case it was solved by adding -rdynamic flag to gcc, i think there are some similar option to your compiler about exporting symbols. Cheers. 07.02.2013, 08:35, "Philip Lamb" p...@eden.net.nz:Hi all, I'm running into an interesting bug in my code which manifests as behaviour that works on one platform (Windows) and not on another (OS X) with the same OSG code. (Using OSG trunk, around 3.1.4) I am using the following node visitor to reset animations attached to transform nodes: class ResetAnimationNodesVisitor : public osg::NodeVisitor{public:        ResetAnimationNodesVisitor():    osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}        virtual void apply(osg::Transform transform)    {        osg::NodeCallback *nc = transform.getUpdateCallback();        osg::AnimationPathCallback* apc = dynamic_castosg::AnimationPathCallback*(nc);        if (apc) {            apc-reset();            apc-update(transform);        }        traverse(transform);    }}; This visitor is instantiated on a node thus: void resetAnimationTime(osg::ref_ptrosg::Node modelNode){    ResetAnimationNodesVisitor ranv;    modelNode-accept(ranv);} When compiled and run on an animated model under Windows (compiled with Visual Studio 2010 SP1) all works as expected. When the exact same code is compiled and run under OS X (using Xcode 4.5.2, with LLVM 4.2.1) the dynamic cast to osg::AnimationPathCallback* is always NULL. I have checked that RTTI is not disabled (it's on by default, and no errors are produced by the dynamic_cast, and that indeed things are as expected with this snippet inside apply():         if (nc) osg::notify(osg::NOTICE)  "UpdateCallback: className is "  std::string(transform.getUpdateCallback()-className())  " and type_id.name() is " typeid(transform.getUpdateCallback()).name()  std::endl;  which produces the output: UpdateCallback: className is AnimationPathCallback and type_id.name() is PN3osg12NodeCallbackE So it looks like a failure somewhere in RTTI. Both typeid and the dynamic_cast fail to convert the osg::NodeCallback* to an osg::AnimationPathCallback*. Yet clearly, the callback IS the right type, as evidenced by OSG's className() function's output. Any ideas about where this kind of issue might be coming from? Regards,Phil.,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Stephan Huber

Hi Robert,

this is not a compiler bug, this is by design. gcc compares instances of 
classes by the pointer to its vtable. (Visual Studio uses a 
string-comparision) If you define a class in a shared library and use it 
in your app there are chances that you end up with two vtables of a 
class, one in the app, one in the lib. If you don't setup proper symbol 
visibility of your methods the linker does not have a chance to see 
the two identical classes and merge them.


And this affects gcc = 4.0 (don't know about clang)

More info here: http://gcc.gnu.org/wiki/Visibility especially Problems 
with C++ exceptions (please read!)


Xcode defaults to hide symbols when creating a new project, that's all.

cheers,
Stephan


Am 07.02.13 11:48, schrieb Robert Osfield:

Hi Stephan,

On 7 February 2013 10:43, Stephan Huber ratzf...@digitalmind.de wrote:

this worked for me in the past: check your project settings,  Symbols
hidden By default should be deactivated for both osg and your project.

Is this a workaround for a bug in the compiler or is it some obscure
way of enabling proper RTTI support?

Should we be adding this as an option by default for the LLVM compiler?

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


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


Re: [osg-users] How to acquire the screen coordinates of a 3D object?

2013-02-07 Thread Fan ZHANG

S2LR wrote:
 If you're new to the OSG, it is really helpful to look at the examples and 
 also search the OSG forums for the problems you're looking for. Many of the 
 questions most new folks ask, have already been addressed and answered in the 
 forum.
 
 Hopefully the link below will help you...
 
 http://forum.openscenegraph.org/viewtopic.php?t=9172highlight=
 
 Shayne


Thank you so much for your kindly remind and reply, I will see to it next time.
Sorry to disturb you all again, because the result I got was quite strange:

Before transformation, the original coordinates of CityGML are X 
3450462.314718, Y 5430520.143368, Z 8.289120
After automatically transformation, the coordinates are X -840532249.575058, Y 
-1322874921.178542
After manually transformation, the coordinates are  X -840532249.575058, Y 
-1322874921.178542, Z 1.120752

Before transformation, the original coordinates of CityGML are X 
3450398.833305, Y 5430561.272085, Z 11.772124
After automatically transformation, the coordinates are X -591833875.402660, Y 
-931484454.045872
After manually transformation, the coordinates are  X -591833875.402660, Y 
-931484454.045872, Z 1.085055


Firstly I load a CityGML dataset and then acquire some of the 3D point 
information. Automatically and manually are just two names I set, but in fact 
the same, just to compare the result. Here is the manual one:

Code:
osg::Matrix local2worldMatrix;
osg::MatrixList list = root-getWorldMatrices();
for(osg::MatrixList::iterator it = list.begin(); it != list.end(); ++it)
   {local2worldMatrix = local2worldMatrix*(*it);}//For loading one model, this 
step is not necessary actually

osg::Matrix finalMatrix;//the final MVPW matrix
osg::Matrix viewMatrix = cam-getViewMatrix();
osg::Matrix projectionMatrix = cam-getProjectionMatrix();
osg::Matrix windowMatrix = cam-getViewport()-computeWindowMatrix();
finalMatrix = local2worldMatrix*viewMatrix*projectionMatrix*windowMatrix;




And here is the automatic one I got from the link in reply above:


Code:
osg::Vec2d worldToScreen(const osg::Vec3d worldPosition, const osg::Camera* 
pCamera)
{
osg::Vec2d screenPosition;

osg::Matrixd MVPW = pCamera-getViewMatrix() * 
pCamera-getProjectionMatrix();
osg::Vec4d screenPosition4d = osg::Vec4d(worldPosition, 1.0) * MVPW;
screenPosition4d = screenPosition4d / screenPosition4d.w();
screenPosition4d = 
screenPosition4d*pCamera-getViewport()-computeWindowMatrix();
//screenPosition4d.y() = pCamera-getViewport()-height() - 
screenPosition4d.y();
screenPosition.set(screenPosition4d.x(), screenPosition4d.y());


return screenPosition;
}





Actually no big difference. I think I've missed one important step some where.
But I really don't know why.
Perhaps it is because the camera is just viewer.getCamera().
Then how can I deal with it?

Thanks a lot in advance.


ohh newbie to OSG..

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





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


Re: [osg-users] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Robert Osfield
Hi Stephan,

Thanks for the explanation, you learn something new everyday :-)

Incompatibility like this I'd personally put down as a bug in the
design/implementation rather than a feature.  I am curious why we
haven't seen this particular issue more often.  If the visibility of
classes is hidden by default then we should be seeing these issues
between OSG libs and applications all the time - for instance the code
almost identical that that Philip is using is used in osgPresentation
with it doing dynamic_cast on objects provided by the core osg lib.

The question next is really what to do about the issue.  Just document
the bug and it's workaround - changing symbol visibility via compiler
options or do we change the OSG itself so it by default doesn't hide
visibility of symbols.

Robert.

On 7 February 2013 12:10, Stephan Huber ratzf...@digitalmind.de wrote:
 Hi Robert,

 this is not a compiler bug, this is by design. gcc compares instances of
 classes by the pointer to its vtable. (Visual Studio uses a
 string-comparision) If you define a class in a shared library and use it in
 your app there are chances that you end up with two vtables of a class, one
 in the app, one in the lib. If you don't setup proper symbol visibility of
 your methods the linker does not have a chance to see the two identical
 classes and merge them.

 And this affects gcc = 4.0 (don't know about clang)

 More info here: http://gcc.gnu.org/wiki/Visibility especially Problems with
 C++ exceptions (please read!)

 Xcode defaults to hide symbols when creating a new project, that's all.

 cheers,
 Stephan


 Am 07.02.13 11:48, schrieb Robert Osfield:

 Hi Stephan,

 On 7 February 2013 10:43, Stephan Huber ratzf...@digitalmind.de wrote:

 this worked for me in the past: check your project settings,  Symbols
 hidden By default should be deactivated for both osg and your project.

 Is this a workaround for a bug in the compiler or is it some obscure
 way of enabling proper RTTI support?

 Should we be adding this as an option by default for the LLVM compiler?

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


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


Re: [osg-users] How to acquire the screen coordinates of a 3D object?

2013-02-07 Thread Shayne Tueller
It looks like you forgot to concatenate the window matrix from the Viewport 
object onto the MVPW matrix in what you call the automatic version. You also 
need to remove the matrix mutiply of the window matrix with the 
screenPosition4d object. This should not happen after the perspective divide.

Look again closely at the orginal code snippet you used for your automatic 
version to see the error.

I think it would be helpful for you to understand the OpenGL transformation 
pipeline since that is what the OSG is using under the hood. Paul Martz does a 
great job of explaining this in his book.

http://www.opengldistilled.com/

Shayne

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





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


Re: [osg-users] Failure in casting to osg::AnimationPathCallback*

2013-02-07 Thread Philip Lamb
Hi all,

Thanks for the pointers to the source of the problem. Indeed it is related to 
symbol visibility. For reference, I had to change Xcode's default settings as 
follows:

GCC_SYMBOLS_PRIVATE_EXTERN = NO (Setting name in Xcode is Symbols 
Hidden by Default)
GCC_INLINES_ARE_PRIVATE_EXTERN = NO (Setting name in Xcode is Inline 
Methods Hidden)

and finally things work as expected on OS X. In my case I needed both for the 
fix. For reference, this is with Clang/LLVM 4.2.1.

A thread on the Clang/LLVM mailing list indicates that there is a warning flag 
which can be activated to alert to these kind of issues:
-Wweak-vtables
With the default Xcode settings (hiding symbols not explicitly exported) and 
this warning activated, I got a lot of warnings like: 
'ResetAnimationNodesVisitor' has no out-of-line virtual method 
definitions; its vtable will be emitted in every translation unit

This is in spite of it clearly having a virtual method -- it would be more 
helpful if the weak vtables check could have told me that the vtable was being 
discarded by the symbol hiding, rather than not being created at all. A missing 
(or weak) vtable would certainly prevent RTTI from working correctly.

Many thanks for the help with a rather obscure problem.

Regards,
Phil.

On 8/02/2013, at 8:40 AM, Robert Osfield robert.osfi...@gmail.com wrote:

 Hi Stephan,
 
 Thanks for the explanation, you learn something new everyday :-)
 
 Incompatibility like this I'd personally put down as a bug in the
 design/implementation rather than a feature.  I am curious why we
 haven't seen this particular issue more often.  If the visibility of
 classes is hidden by default then we should be seeing these issues
 between OSG libs and applications all the time - for instance the code
 almost identical that that Philip is using is used in osgPresentation
 with it doing dynamic_cast on objects provided by the core osg lib.
 
 The question next is really what to do about the issue.  Just document
 the bug and it's workaround - changing symbol visibility via compiler
 options or do we change the OSG itself so it by default doesn't hide
 visibility of symbols.
 
 Robert.

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


Re: [osg-users] i am having problem compiling program related to TraingleFunctor

2013-02-07 Thread om prakash Paliwal
call me Om 
by the way thanks Robert for the help. it fixed my errors and after this i
just have to add one more header file to complete my compilation .. i
included osg/TrangleFunctor ...

thanks again ...



On Thu, Feb 7, 2013 at 2:44 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Om? Prakash? Paliawl?  Could you sign with your name so we know how to
 address you?

 As for you errors, it looks like you need to include osg/io_utils as
 this will provide the helper functions for writing Vec3's etc. to ostream.

 Robert.

 On 7 February 2013 05:01, om prakash Paliwal 
 omprakash.paliwa...@gmail.com wrote:

 i am not able to compile program using TriangleFunctor. at the first
 compilation i got some error saying cout is not a member of std + some
 other chunks . So i added a iostream header file. And when i comiled it
 again there are 3-4 screenful errors. am not able to understand these
 scripts of error ...


 Errors and My program is attached below ...

 thanks for the help in advance 





 i am attaching my program 
  main.cpphttps://docs.google.com/file/d/0B3dFjVubf5gKQ2RrQzdhOU9OR28/edit

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



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


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


[osg-users] i am not able to build GLUT libraries in Ubuntu to use it in OSG program

2013-02-07 Thread om prakash Paliwal
i want to write the  Teapot program which requires GLUT libraries...
i am using Ubuntu 12.10 and downloaded GLUT-3.7.tar.gz file from the
official website of openGL... but i am facing problem in building these
pakages ...

i first replaces the Glut.cf file in the glut-3.7 dir with the file in
/glut-3.7/linux/Glut.cf  as the Readme file Said ... but when i
./mkmfiles.imake it replied

...
mv -f Makefile Makefile.bak   /dev/null






if ( -d /usr/lib/X11/config ) then


if ( -d /usr/lpp/X11/Xamples/config ) then


if ( -x /usr/openwin/bin/xmkmf ) then


if ( -d /usr/X11R6/lib/X11/config ) then


xmkmf
xmkmf: Command not found.
endif
endif
endif
endif
make Makefiles
make: *** No rule to make target `Makefiles'.  Stop.





make depend
make: *** No rule to make target `depend'.  Stop.

...

which means building process is not succesful  anything i am missing ??
plz help .
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Local coordinates

2013-02-07 Thread Zeki Yugnak
Hi Robert,

I found the problem yesterday. You are right, the problem is regarding to 
floating point usage. 

I am computing camera position using center of the object's BoundingSphere. 
When I start debug whole code, I figure out that the BoundingSphere type is 
floating point and OSG_USE_FLOAT_BOUNDINGSPHERE parameter is defined in 
Config header file as default. So, Flicker problem is regarding to camera 
position. The problem is gone after this parameter is undefined.

One more question is Why is osg::Vec3's type defined as a floating point?

Thanks for all yours help.
Regards.

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





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