[osg-users] LineSegmentIntersector numerical imprecisions

2013-08-19 Thread PCJohn
Hi Robert,

there was recently a commit concerning epsilon in LineSegmentIntersector
that is now carried as class member. I can imagine motivation behind, but I 
belive there is a better approach to the problem.

If the motivation is just to allow the setting bigger epsilon for bigger 
objects (too small epsilon, recently statically assigned to 1e-5, will not 
affect big bounding boxes because of limited float resolution. I belive, this 
was the motivation behind the change for the person who submitted the patch.)

The correct solution in my opinion would be to make epsilon depend on size of 
bounding box of the intersected object:

// extend bounding box a little bit to avoid floating point imprecisions
double epsilon = (bb_max-bb_min).length() * 1e-5;
bb_min.x() -= epsilon;
bb_min.y() -= epsilon;
bb_min.z() -= epsilon;
bb_max.x() += epsilon;
bb_max.y() += epsilon;
bb_max.z() += epsilon;

This should work in all cases, for both - small and big objects. Hard-coding 
epsilon, even when giving the user the ability to change it, is not correct 
way in my opinion, as there may be very small objects (requiring small 
epsilon) together with big objects (requiring big epsilon) in the scene. We 
can give the user the callback to adjust the epsilon for each visited object 
in the scene, but I do not belive this is the best approach.

I would very prefer to scale epsilon by the size of the object as this is how 
the floats change their precision. Bigger the object, bigger the value in 
float, 
smaller float precision, bigger the epsilon is needed. The precision of float 
is 
between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5 should 
provide big enough increase of the bounding box to avoid numerical 
imprecisions.

Having to specify epsilon by programmer is making the things more difficult for 
him, as he should understand float problems and has to think about the 
precision value, while he usually just wants intersector to work correctly, 
not taking care about hardware precision limitations. Scaling the epsilon 
would do the work for him without giving him another parameter that may turn 
things wrong if not set properly.

Your opinion on this point?
I can create patch based on your suggestions.
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [forum] osgAnimation with bvh and model

2013-08-19 Thread Peter Wraae Marino
Hi,

I'm not giving up on this (but I'm sure am tired of failing).

I can see that that the bvh reader actually plays the animation and I can add 
the option solids to the loader... this basically should show the bvh file 
animating which it doesn't:




Code:
osg::Node* createScene()
{
osgDB::ReaderWriter::Options* o = new osgDB::ReaderWriter::Options;
o-setOptionString( solids );

osg::Node* bvh = osgDB::readNodeFile( osgDB::findDataFile( test.bvh 
), o );
return bvh;
}



Something is just not right here... the poor documentation makes this even 
harder to figure out? I'm starting to think that the bvh reader is the problem.

Thank you!

Cheers,
Peter

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





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


Re: [osg-users] LineSegmentIntersector numerical imprecisions

2013-08-19 Thread Alistair Baxter
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of PCJohn
Sent: 19 August 2013 07:38
To: OpenSceneGraph Users
Subject: [osg-users] LineSegmentIntersector numerical imprecisions

 The correct solution in my opinion would be to make epsilon depend on size of 
 bounding box of the intersected object:

I'd support that strategy. The recent change doesn't really fix the problem 
that we had to locally alter the source to fix.



Alistair Baxter
Software Engineer


Our next public training event is in Houston, USA on 20th - 22nd August 2013 

For further information please visit www.mve.com/calendar
Midland Valley Exploration Ltd.
144 West George Street
Glasgow G2 2HG
United Kingdom
Tel: +44 (0) 141 332 2681
Fax:+44 (0) 141 332 6792
The structural geology experts 

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


Re: [osg-users] LineSegmentIntersector numerical imprecisions

2013-08-19 Thread Robert Osfield
Hi John et. al,

I too am not too happy with the approach of a fixed epilson, adding the
ability for the user to set this value isn't much better.

Scaling the epsilon by the size of the bounding box may be an improvement
but I'm not yet convinced it's the best approach.  The epsilon is there is
account for numerical precision issues associated with the mathematical
functions being performed.

The maths in this case is clamping the present line segment start and end
points to the bounding box, here the distance of the sides from the start
and the start to the end point along each axis is what will determine the
size of the values and the range of the numerical errors that are likely.
The largest value is likely to be the length of the line segment so might
be the best distance to use as the scale.

Thoughts?
Robert.





On 19 August 2013 06:38, PCJohn pec...@fit.vutbr.cz wrote:

 Hi Robert,

 there was recently a commit concerning epsilon in LineSegmentIntersector
 that is now carried as class member. I can imagine motivation behind, but I
 belive there is a better approach to the problem.

 If the motivation is just to allow the setting bigger epsilon for bigger
 objects (too small epsilon, recently statically assigned to 1e-5, will not
 affect big bounding boxes because of limited float resolution. I belive,
 this
 was the motivation behind the change for the person who submitted the
 patch.)

 The correct solution in my opinion would be to make epsilon depend on size
 of
 bounding box of the intersected object:

 // extend bounding box a little bit to avoid floating point
 imprecisions
 double epsilon = (bb_max-bb_min).length() * 1e-5;
 bb_min.x() -= epsilon;
 bb_min.y() -= epsilon;
 bb_min.z() -= epsilon;
 bb_max.x() += epsilon;
 bb_max.y() += epsilon;
 bb_max.z() += epsilon;

 This should work in all cases, for both - small and big objects.
 Hard-coding
 epsilon, even when giving the user the ability to change it, is not correct
 way in my opinion, as there may be very small objects (requiring small
 epsilon) together with big objects (requiring big epsilon) in the scene. We
 can give the user the callback to adjust the epsilon for each visited
 object
 in the scene, but I do not belive this is the best approach.

 I would very prefer to scale epsilon by the size of the object as this is
 how
 the floats change their precision. Bigger the object, bigger the value in
 float,
 smaller float precision, bigger the epsilon is needed. The precision of
 float is
 between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5
 should
 provide big enough increase of the bounding box to avoid numerical
 imprecisions.

 Having to specify epsilon by programmer is making the things more
 difficult for
 him, as he should understand float problems and has to think about the
 precision value, while he usually just wants intersector to work correctly,
 not taking care about hardware precision limitations. Scaling the epsilon
 would do the work for him without giving him another parameter that may
 turn
 things wrong if not set properly.

 Your opinion on this point?
 I can create patch based on your suggestions.
 John
 ___
 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] [forum] osgAnimation with bvh and model

2013-08-19 Thread Sebastian Messerschmidt

Hi Peter,

Since your questions were a bit confusion:

I had problems loading skeleton models with geometry and playing some 
different animation on them as well.
In order to get this working (as skeletons and animations were not 
matching) I had to build a set of visitors which would match the 
animation to the skeleton an vice versa.


My first advice is to display the skeleton bones (and potentiall the 
bones of the animation)


Here's some snippet that might be helpful (It's from the 
osganimationviewer). Apply it to your loaded models and play found 
animations.
In my case I saw that the skeleton is animated, but not the one 
containing the geometry.


I can send you a complete example of what I've done, but I'm not sure if 
it solves your problem.
Send me a personal message (email) so we maybe could test your data sets 
with my algorithm.


snip
osg::Geode* createAxis(float scale)
{
osg::Geode* geode= new osg::Geode();
osg::Geometry*  geometry = new osg::Geometry();
osg::Vec3Array* vertices = new osg::Vec3Array();
osg::Vec4Array* colors   = new osg::Vec4Array();

vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
vertices-push_back(osg::Vec3(scale, 0.0f, 0.0f));
vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
vertices-push_back(osg::Vec3(0.0f, scale, 0.0f));
vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
vertices-push_back(osg::Vec3(0.0f, 0.0f, scale));

colors-push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));
colors-push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));
colors-push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));
colors-push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));
colors-push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));
colors-push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));

geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::LINES, 0, 6));

geometry-getOrCreateStateSet()-setMode(GL_LIGHTING, false);

geode-addDrawable(geometry);

return geode;
}
struct AddHelperBone : public osg::NodeVisitor
{
AddHelperBone() : 
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}

void apply(osg::Transform node) {
osgAnimation::Bone* bone = 
dynamic_castosgAnimation::Bone*(node);

if (bone)
bone-addChild(createAxis(5));
traverse(node);
}
};

/snip


Hi,

I'm trying to animate a character with data from a bvh

I have tried a lot of different setups.. but none work. The osgAnimation seems 
to have what it needs to get this working, but there isn't enough documentation 
to make sense of it.

This is where I am at now:


Code:

osg::Node* createScene()
{
// convenience variables
osg::Node* bvh = osgDB::readNodeFile( osgDB::findDataFile( test.bvh ) 
);
osg::Node* model = osgDB::readNodeFile( osgDB::findDataFile( test.dae 
) );
osgAnimation::BasicAnimationManager* manager = new 
osgAnimation::BasicAnimationManager;

// get animation from bvh
osgAnimation::AnimationManagerBase* animationManager = 
dynamic_castosgAnimation::AnimationManagerBase*(bvh-getUpdateCallback());
osgAnimation::Animation* anim = animationManager-getAnimationList()[0];
anim-setPlayMode( osgAnimation::Animation::LOOP );

osg::Group* group = new osg::Group;
 group-setUpdateCallback( manager );
group-addChild( model );

manager-registerAnimation(anim);
 manager-buildTargetReference();
 manager-playAnimation( anim );

return group;
}




The BVH contains Skeleton and Bones
The Model contains Skeleton, Bones, RigGeometry

so,.. what I basically do is create my own BasicAnimationManager extract the 
animation from bvh and register it.

I can see the character clearly being render, but with no animation.

Am I missing something?

Thank you!

Cheers,
Peter

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





___
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] [forum] osgAnimation with bvh and model

2013-08-19 Thread Peter Wraae Marino
Hi Sebastian Messerschmidt,

Thanks for your info.

it is correct that the model containing the geometry does not have the 
animation,.. this is as designed.

the bvh file contains the animation but no geometry also as designed.

I don't want geometry and animation in the same files, because I will have 
100's of bvh files that all use one character geometry. What I want is the 
ability to play what I want and blend what I want.

back to the subject at hand... I found out that the bvh file I have does not 
work well with openscenegraph, this file was exported from Daz3D. I exported a 
bvh file from 3dsmax and I got the animation to work (somewhat).

apparently there are many variations of the bvh files and openscenegraph only 
supports a subset of these. How I'm going to fix this is a good question... but 
at least now I know where the problem is.


Thank you!

Cheers,
Peter

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





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


Re: [osg-users] [forum] osgAnimation with bvh and model

2013-08-19 Thread Sebastian Messerschmidt

 Peter,



Hi Sebastian Messerschmidt,

Thanks for your info.

it is correct that the model containing the geometry does not have the 
animation,.. this is as designed.

the bvh file contains the animation but no geometry also as designed.

I don't want geometry and animation in the same files, because I will have 
100's of bvh files that all use one character geometry. What I want is the 
ability to play what I want and blend what I want.

This is exactly my approach, as I want to keep them separate.


back to the subject at hand... I found out that the bvh file I have does not 
work well with openscenegraph, this file was exported from Daz3D. I exported a 
bvh file from 3dsmax and I got the animation to work (somewhat).
Okay, check as I advised. All animations ran fine, but the linkage to 
the model were incorrect. That's why I had to write some technique to 
couple them again.


apparently there are many variations of the bvh files and openscenegraph only 
supports a subset of these. How I'm going to fix this is a good question... but 
at least now I know where the problem is.

Maybe the community can help if you provide such incompatible bhv.

cheers
Sebastian



Thank you!

Cheers,
Peter

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





___
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] [forum] osgAnimation with bvh and model

2013-08-19 Thread Peter Wraae Marino
Hi Sebastian,

The bvh file should be able to play without having to rename anything. there is 
no name matching in there. if you supply the option solids when loading they 
you will see a stick figure of the bones.

so why the bvh files doesn't animate is what I'm looking into now... 


Thank you!

Cheers,
Peter

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





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


Re: [osg-users] [forum] osgAnimation with bvh and model

2013-08-19 Thread Sebastian Messerschmidt

Am 19.08.2013 13:28, schrieb Peter Wraae Marino:
Peter,

long story short: It will not simply work without some renaming. Most 
exporters and the osg-importers simply don't agree on the same scheme here.
That is exactly why one should traverse the models and match the names. 
(I had to match them based on the groups and geometries for .fbx).
I guess they are simply not playing, because the matcher traverses the 
wrong skeleton.



Hi Sebastian,

The bvh file should be able to play without having to rename anything. there is no name 
matching in there. if you supply the option solids when loading they you will 
see a stick figure of the bones.

so why the bvh files doesn't animate is what I'm looking into now...


Thank you!

Cheers,
Peter

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





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

2013-08-19 Thread Alan Jesser
I'm just getting started with OSG and I know it uses the OpenThread library for 
threading. I was wondering if anyone has explored the new C++11 threading 
library as an alternative. If so how difficult would be to swap out and would 
there be a benefit in doing so?

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


Re: [osg-users] Threading

2013-08-19 Thread Robert Osfield
Hi Alan,

On 19 August 2013 16:15, Alan Jesser nigo...@hotmail.com wrote:

 I'm just getting started with OSG and I know it uses the OpenThread
 library for threading. I was wondering if anyone has explored the new C++11
 threading library as an alternative. If so how difficult would be to swap
 out and would there be a benefit in doing so?


The new C++ 11 threading library has the potential for replacing
OpenThreads completely, but for the OSG-3.x series we'll be sticking with
OpenThreads to retain backwards compatibility.

One could potentially implement a C++ 11 theading as an OpenThreads
implementation that sits alongside the current pthreads/win32 threads
implementations, but practically this won't provide much benefit as all C++
11 threads currently does is provided a portable API that is implementation
with platform specific threading libraries much in the same way that
OpenThreads does right now.

The benefit from eventually moving to C++ 11 threads would be simplifying
the OSG code base via the removal of OpenThreads, but speed and
functionality wise I wouldn't expect to see any difference.  If I were to
write a new scene graph today then I'd use C++ threads, but for the OSG as
it stands there isn't yet a strong reason to port over in the near term.

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


[osg-users] Model Load Crash

2013-08-19 Thread John Farrier
Hi,

I am attempting to load a 3D model (.osgb) in my application using 


Code:
auto model = osgDB::readNodeFile(this-_modelFile);




After that, I immediately want to get the bounding sphere size:


Code:
osg::BoundingSphere bs = model-getBound();



While this generally works fine, there are some models that this consistently 
crashes (it's not an exception) on.  It seems to be calling 
discardAllDeletedDisplayLists just before the crash.  Here's the stack trace:

 
Code:
osg80-osg.dll!osg::Drawable::Extensions::setupGLExtensions() + 2336 bytes
osg80-osg.dll!osg::Drawable::discardAllDeletedDisplayLists() +  bytes
osg80-osg.dll!osg::Geometry::accept() + 543 bytes
osg80-osg.dll!osg::Drawable::computeBound() + 123 bytes
osg80-osg.dll!osg::Drawable::getBound() + 124 bytes
osg80-osg.dll!osg::Geode::computeBound() + 120 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes
osg80-osg.dll!osg::Group::computeBound() + 209 bytes
osg80-osg.dll!osg::Node::getBound() + 96 bytes




The really odd thing here is that the model loads just fine with osgViewer.  Is 
there something I could be doing to the state of OSG that would cause it to 
fail in my own application?

(The application isn't trivial, or I would post more code.)

Thank you!

Cheers,
John

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





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


Re: [osg-users] Model Load Crash

2013-08-19 Thread Robert Osfield
HI John,

Something is rather messed up for the track traces to appear in the way you
have posted - the Geometry::accept() method has no nested call
to Drawable::discardAllDeletedDisplayLists().  For this to appear I can
only assume something has got corrupted in memory or with the build.

Any chance you've build build types for your libs and applications?

Robert.


On 19 August 2013 18:24, John Farrier john.farr...@gmail.com wrote:

 Hi,

 I am attempting to load a 3D model (.osgb) in my application using


 Code:
 auto model = osgDB::readNodeFile(this-_modelFile);




 After that, I immediately want to get the bounding sphere size:


 Code:
 osg::BoundingSphere bs = model-getBound();



 While this generally works fine, there are some models that this
 consistently crashes (it's not an exception) on.  It seems to be calling
 discardAllDeletedDisplayLists just before the crash.  Here's the stack
 trace:


 Code:
 osg80-osg.dll!osg::Drawable::Extensions::setupGLExtensions() + 2336 bytes
 osg80-osg.dll!osg::Drawable::discardAllDeletedDisplayLists() +  bytes
 osg80-osg.dll!osg::Geometry::accept() + 543 bytes
 osg80-osg.dll!osg::Drawable::computeBound() + 123 bytes
 osg80-osg.dll!osg::Drawable::getBound() + 124 bytes
 osg80-osg.dll!osg::Geode::computeBound() + 120 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes




 The really odd thing here is that the model loads just fine with
 osgViewer.  Is there something I could be doing to the state of OSG that
 would cause it to fail in my own application?

 (The application isn't trivial, or I would post more code.)

 Thank you!

 Cheers,
 John

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





 ___
 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] Model Load Crash

2013-08-19 Thread Farshid Lashkari
Hi John,

Do you know what version of OSG the model was created with?

I've noticed that older versions of OSG will crash when attempting to load
osgb files created with newer versions. I haven't pinpointed exactly which
version caused this issue, but it happened when I upgraded from 72 to 93. I
noticed that you are using version 80, so this could explain the crashes
you are experiencing.

Cheers,
Farshid





On Mon, Aug 19, 2013 at 11:24 AM, John Farrier john.farr...@gmail.comwrote:

 Hi,

 I am attempting to load a 3D model (.osgb) in my application using


 Code:
 auto model = osgDB::readNodeFile(this-_modelFile);




 After that, I immediately want to get the bounding sphere size:


 Code:
 osg::BoundingSphere bs = model-getBound();



 While this generally works fine, there are some models that this
 consistently crashes (it's not an exception) on.  It seems to be calling
 discardAllDeletedDisplayLists just before the crash.  Here's the stack
 trace:


 Code:
 osg80-osg.dll!osg::Drawable::Extensions::setupGLExtensions() + 2336 bytes
 osg80-osg.dll!osg::Drawable::discardAllDeletedDisplayLists() +  bytes
 osg80-osg.dll!osg::Geometry::accept() + 543 bytes
 osg80-osg.dll!osg::Drawable::computeBound() + 123 bytes
 osg80-osg.dll!osg::Drawable::getBound() + 124 bytes
 osg80-osg.dll!osg::Geode::computeBound() + 120 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Transform::computeBound() + 56 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Switch::computeBound() + 382 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes
 osg80-osg.dll!osg::Group::computeBound() + 209 bytes
 osg80-osg.dll!osg::Node::getBound() + 96 bytes




 The really odd thing here is that the model loads just fine with
 osgViewer.  Is there something I could be doing to the state of OSG that
 would cause it to fail in my own application?

 (The application isn't trivial, or I would post more code.)

 Thank you!

 Cheers,
 John

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





 ___
 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] Model Load Crash

2013-08-19 Thread John Farrier
Hi,

Thanks for the quick response.  I have used the same compiler (VS2012, x64, 
SP3) for the libs and my application.  I have also tested this in Release and 
Debug configurations (Windows, CMake projects).  The problem is 100% consistent 
and repeatable.  The stack trace looked odd to me as well.  I can try to 
re-build OSG and see if that helps, but I hate to do things like that without a 
good reason!

Thank you!

Cheers,
John

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





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


Re: [osg-users] Model Load Crash

2013-08-19 Thread John Farrier
Hi,


 Do you know what version of OSG the model was created with? 


The OSGB file and the application are using an identical copy of OSG 3.0.1.  
And, like I mentioned, osgViewer runs the problem models just fine.  (both 
release and debug versions of osgViewer were tested.)

Thank you!

Cheers,
John

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





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


Re: [osg-users] Model Load Crash

2013-08-19 Thread John Farrier
Hi,

Given Farshid's comments, I used osgConv to convert my .osgb model to .3ds.  I 
then converted it back to .osgb.  The new .osgb model loads fine.  I lost its 
animation, but other than that, it seems to be good...now I just need to figure 
out a way to do this little conversion dance and keep the embedded animation!

Thank you!

Cheers,
John

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





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


Re: [osg-users] Model Load Crash

2013-08-19 Thread John Farrier
Hi,


 now I just need to figure out a way to do this little conversion dance and 
 keep the embedded animation! 


So, perhaps, I posted too soon.  I re-converted the model from the .lws 
original into .osgb.  It was a file of identical size, but a binary comparison 
showed many differences.  It would still not load in my app.  Then I converted 
the .osgb to an .ive.  The .ive would not load either.  

Since the models all load fine with osgViewer, I wonder if I haven't corrupted 
OSG's internal state somehow.  I don't know what I could have done to affect 
this, but that's my suspicion.

Thank you!

Cheers,
John

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





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


[osg-users] Pseydo-cylindrical projection

2013-08-19 Thread Alexandre Vaillancourt
Hello List and Forum,

We're developing an application that aims to take the best advantages of
ultra-wide screen, which in our terms is basically using 3 widescreen
monitors.

Since our camera is to be of a kind of first person, I'd like to be able
to display a field of view of about 180 degrees.

I've been able to achieve that by using something like what's in
osgdistortion, which is using a CompositeViewer with the main camera and 3
slave cameras.

Now the items that should look straight are now bent at the 2 viewport
junctions.

So the 2 options I found were:
1) RTT everything that is in the scene and draw the texture on a distorted
polygon (like in osgdistortion)
2) Draw on a quad and use a shader to distort the quad or what's on it.

Questions:
1) In both cases I need to draw to a texture.
--- camera-attach(osg::Camera::COLOR_BUFFER, texture, 0,
osg::TextureCubeMap::POSITIVE_Z);
This approach uses 6 faces of a cube map. Is there a way to use only 3
cameras, i.e. tell the camera to draw only on a part of the texture?

2) Would there be a way to tell the viewer to draw on a texture instead of
the cameras?

3) Is the shader approach the best or the textured mesh is better?


Thanks all; and sorry if I'm not too clear, it's not much clearer to me :P



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