Re: [osg-users] StateSet and changes

[Ulrich Hertlein]

Hi Mathieu,

On 17/07/10 1:32 , Mathieu Scorpionis wrote:
> I try to manage with the model of an aircraft. I whish my 3d model to react 
> to the
> mouse cursor when one of its sub-models is intersected by this cursor.
> 
> This is the simplified architecture of the OSG file :
>... 
> osg::Group *groupSceneRoot;
> osg::Group *ExteriorCab;
> osg::Group *ExteriorCab_OFFSET;
>...
> groupSceneRoot = mModel->asGroup();
> ExteriorCab = groupSceneRoot->getChild(0)->asGroup();
> ExteriorCab_OFFSET= ExteriorCab->getChild(0)->asGroup();
>...

First of all, you should adopt the habit of keeping osg::ref_ptr rather than 
raw pointers
of OSG objects.  They might be deleted which leaves you with a dangling, 
invalid pointer.

> for (int i=0;i<8;i++)
> ListGeodeStateSet[index] = ListGeode[i]->getOrCreateStateSet();
> 
> // What I want is to display only polygons if the cursor mouse picks a 
> sub-model
> (here, one of the 8 geodes that decompose the whole aircraft):
> 
> osg::PolygonMode *PolyModeObj[8];
> for (int i=0;i<8;i++)
> {
> PolyModeObj[i] = dynamic_cast< osg::PolygonMode* >
>   ( ListGeodeStateSet[i]->getAttribute( 
> osg::StateAttribute::POLYGONMODE ));
> if ( !PolyModeObj[i] ) 
> { 
> PolyModeObj[i] = new osg::PolygonMode;
> ListGeodeStateSet[i]->setAttribute( PolyModeObj[i]);
> }
> }

I'd actually not worry about looking up (and storing) StateSets and PolygonModes
beforehand.  It makes the core more complex and doesn't really gain you 
anything.  But
that's more a question of coding style.  If you have/want to, use osg::ref_ptr, 
see above.

> // In the pick callback, I check which geode was selected by the cursor:
> osgUtil::LineSegmentIntersector::Intersections::iterator hitr;
> if (Viewer->computeIntersections(x, y, intersections))
> {
> hitr = intersections.begin();
> osg::Geode *GeodeParent = hitr->drawable->getParent(0)->asGeode();
> for (int d=0;d<8;d++)
> {
> if (GeodeParent == ListGeode[d])
> {
> PolyModeObj[d]->setMode( osg::PolygonMode::FRONT_AND_BACK, 
> osg::PolygonMode::LINE );
> break;
> }
> }
> }
> 
> But... when the cursor selects the geode ExteriorCab_GEODE, the whole aircaft 
> moves to
> polygon display (even wheels, tail and the rest...). Only the cabin should 
> appear as polygons.

Most likely (depends on how the object is modelled) this is because the 
'ExteriorCa-GEODE'
StateSet is shared with other Geodes.  You can easily verify this by comparing 
the
StateSet pointer values.

If you want to avoid that you need to give each Geode it's private (deep) copy 
of the
StateSet.  This however incurs a performance penalty, as now there are more 
StateSets.

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

[osg-users] Event Handling from outside a Viewer

[Tom Pearce]

Hi,

I'm looking to implement event handling in a handler not attached to a View.  
The code snippet below is what I'm thinking of doing (the function would take 
an eventadapter similar to the handle method of the camera manipulators).  Is 
this a valid way to go, or am I missing something?  If multiple events accrue, 
do I have access to those through getCurrentEventState(), or just the most 
recent?  Or am I thinking about this entirely wrong? 


Code:
osgViewer::Viewer v;
while(!v.done())
{
v.frame();
MyEventHandlerFunctionOrClass(v.getEventQueue()->getCurrentEventState())
}



Thank you!

Cheers,
Tom

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





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

Re: [osg-users] My Lines Disapering but Ploygons don't

[David Glenn]

Hi Robert, 

The reason that I did this, was basically to echo the performer version of the 
viewer that this will replace - I used the osghud example as a guide. 

In the old performer code, they used multiple views because in some cases the 
data would be so bad that plains would fly through the terrain. 
Since I have a top down look at the terrain in this viewer (kida like a map) 
elevation is not an issue anyway, but we need to see all the elements in play. 
So we add a layer of objects over the terrain, then a layer for the Overlay on 
top of that, etc. 
Last, we have a hud view to display the text screen data. All this in a viewer 
that is suppose to suppose to resemble a Google earth like format. 

But for now I'm basically echoing what they did in the Performer code to retain 
the look and feel of the viewer I'm replacing. 

But we must be able to do some kind of layering effect. If there is anyway that 
I can do it with cameras rater than views, I would like to learn how! 

... 
D Glenn


D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your 
Desk!

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





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

[osg-users] StateSet and changes

[Mathieu Scorpionis]

Dear OSG community,

I try to manage with the model of an aircraft. I whish my 3d model to react to 
the mouse cursor when one of its sub-models is intersected by this cursor.

This is the simplified architecture of the OSG file :

*SceneRoot (MatrixTransform) : 1 children
***ExteriorCab (Group) : 4 children
*ExteriorCab-OFFSET (Group) : 1 children
***ExteriorCab-GEODE (Geode) : 8 drawables
*Tail (group) : 3 children
***Tail-OFFSET (Group) : 1 children
*Tail-GEODE (Geode) : 3 drawables
***RearRotor (Group) : 1 children
*RearRotor-GEODE (Geode) : 2 drawables
***Cylinder (Group) : 1 children
*Cylinder-OFFSET (Group) : 1 children
***Cylinder_GEODE (Geode) : 1 drawable
*RightWheel (Group) : 2 children
***RightWheel-OFFSET (Group) : 1 children
*RightWheel-GEODE (Geode) : 1 drawable
***RightWheelCylinder (Group) : 1 children
*RightWheelCylinder-GEODE (Geode) : 1 drawable
*LeftWheel (Group) : 2 children
***LeftWheel-OFFSET (Group) : 1 children
*LeftWheel-GEODE (Geode) : 1 drawable
***LeftWheelCylinder (Group) : 1 children
*LeftWheelCylinder-GEODE (Geode) : 1 drawable



(very simplified aircraft !)
the model comes from a file, i can't change it

What I do :

osg::ref_ptr mRoot;
osg::ref_ptr mModel;
mModel = osgDB::readNodeFile(m_ModelName);
mRoot->addChild(mModel.get());


osg::Group *groupSceneRoot;
osg::Group *ExteriorCab;
osg::Group *ExteriorCab_OFFSET;
osg::Group *Tail;
osg::Group *RightWheel;
osg::Group *LeftWheel;
osg::Geode *ExteriorCab_GEODE;
osg::Group *Tail_OFFSET;
osg::Group *RearRotor;
osg::Group *Cylinder;
osg::Group *Cylinder_OFFSET;
osg::Geode *Tail_GEODE;
osg::Geode *RearRotor_GEODE;
osg::Geode *Cylinder_GEODE;
osg::Group *RightWheel_OFFSET;
osg::Group *RightWheelCylinder;
osg::Geode *RightWheel_GEODE;
osg::Geode *RightWheelCylinder_GEODE;
osg::Group *LeftWheel_OFFSET;
osg::Group *LeftWheelCylinder;
osg::Geode *LeftWheel_GEODE;
osg::Geode *LeftWheelCylinder_GEODE;

groupSceneRoot = mModel->asGroup();
ExteriorCab = groupSceneRoot->getChild(0)->asGroup();

ExteriorCab_OFFSET  = ExteriorCab->getChild(0)->asGroup();
Tail = ExteriorCab->getChild(1)->asGroup();
RightWheel = ExteriorCab->getChild(2)->asGroup();
LeftWheel   = ExteriorCab->getChild(3)->asGroup();

ExteriorCab_GEODE = ExteriorCab_OFFSET->getChild(0)->asGeode();
Tail_OFFSET = Tail->getChild(0)->asGroup();
RearRotor = Tail->getChild(1)->asGroup();
Cylinder = Tail->getChild(2)->asGroup();
Cylinder_OFFSET = Cylinder->getChild(0)->asGroup();
Tail_GEODE = Tail_OFFSET->getChild(0)->asGeode();
RearRotor_GEODE = RearRotor->getChild(0)->asGeode();
Cylinder_GEODE = Cylinder_OFFSET->getChild(0)->asGeode();

RightWheel_OFFSET = RightWheel->getChild(0)->asGroup();
RightWheelCylinder = RightWheel->getChild(1)->asGroup();
RightWheel_GEODE = RightWheel_OFFSET->getChild(0)->asGeode();
RightWheelCylinder_GEODE = RightWheelCylinder ->getChild(0)->asGeode();
LeftWheel_OFFSET = LeftWheel->getChild(0)->asGroup();
LeftWheelCylinder = LeftWheel->getChild(1)->asGroup();
LeftWheel_GEODE = LeftWheel_OFFSET->getChild(0)->asGeode();
LeftWheelCylinder_GEODE = LeftWheelCylinder ->getChild(0)->asGeode();


// I have thus access to all geodes ()
// Now i create an array of stateset, and an array of geodes
osg::StateSet *ListGeodeStateSet[8];
osg::Geode *ListGeode[8];

ListGeode[0] = ExteriorCab_GEODE;
ListGeode[1] = Tail_GEODE;
ListGeode[2] = RearRotor_GEODE;
ListGeode[3] = Cylinder_GEODE;
ListGeode[4] = RightWheel_GEODE;
ListGeode[5] = RightWheelCylinder_GEODE;
ListGeode[6] = LeftWheel_GEODE;
ListGeode[7] = LeftWheelCylinder_GEODE;

for (int i=0;i<8;i++)
ListGeodeStateSet[index] = ListGeode[i]->getOrCreateStateSet();

// What I want is to display only polygons if the cursor mouse picks a 
sub-model (here, one of the 8 geodes that decompose the whole aircraft):

osg::PolygonMode *PolyModeObj[8];
for (int i=0;i<8;i++)
{
PolyModeObj[i] = dynamic_cast< osg::PolygonMode* >
( ListGeodeStateSet[i]->getAttribute( 
osg::StateAttribute::POLYGONMODE ));
if ( !PolyModeObj[i] ) 
{ 
PolyModeObj[i] = new osg::PolygonMode;
ListGeodeStateSet[i]->setAttribute( PolyModeObj[i]);
}
}


// In the pick callback, I check which geode was selected by the cursor:
osgUtil::LineSegmentIntersector::Intersections::iterator hitr;
if (Viewer->computeIntersections(x, y, intersections))
{
hitr = intersections.begin();
osg::Geode *GeodeParent = hitr->drawable->getParent(0)->asGeode();
for (int d=0;d<8;d++)
{
if (GeodeParent == ListGeode[d])
{
PolyModeObj[d]->setMode( osg::PolygonMode::FRONT_AND_BACK, 
osg::PolygonMode::LINE );
break;
}
}
}


But... when the cursor selects the geode ExteriorCab_GEODE, the whole aircaft 
moves to polygon display (even wheels, tail and the rest...). Only the cabin 
should appear as polygons.
When the cursor selects a wheel, nothing appears. The setMode( 
osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE ); function has no 
effect

Re: [osg-users] cmake errors with 2.9.8

[Jean-Sébastien Guay]

Hi John,


I hope you're not asking me! 8^)


Nah, it was more kind of a general question aimed at the universe :-)

I'm not sure how to do that myself. I'll let Stephan and Robert see if 
they can come up with any ideas, I was just thinking out loud...


Sorry I can't help more,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] cmake errors with 2.9.8

[John Kelso]

On Fri, 16 Jul 2010, Jean-Sébastien Guay wrote:


Perhaps we could have that function in a separate file which would only
be loaded IF(APPLE)? Would that work?

J-S



I hope you're not asking me!  8^)

But, send me something I'd be happy to try it out.

Thanks,

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

Re: [osg-users] Stop back buffer swap during rendering traversals

[Michael Irby II]

Hi Robert,

We have a custom 2d and 3d rendering path, we are in the process of replacing 
the 3d path with OSG. I took a look at the GraphicsWindowEmbedded. We still 
want to have OSG handle 99% of the graphics context work, but just needed a way 
to stop the back buffer swap at the end of the renderingTraversals.

I was able to implement the recommendation from Jean-Sébastien and it worked 
out great. Would there be any issues with using that solution?

Thanks,
Michael Irby

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





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

Re: [osg-users] Select node on screen

[Ümit Uzun]

Selam Tufan,

Look at the hereand
download sourcecode which is related to Picking by Intersection on
model
by mouse clicks.

HTH.
Saygilar.

Ümit Uzun


2010/7/15 Trajce (Nick) Nikolov 

> Have a look at the osgpick example
>
>
> -Nick
>
>
>
> On Thu, Jul 15, 2010 at 4:53 PM, Tufan Taş  wrote:
>
>> Hi,
>> I have nodes on screen and I want to select a node by clicking on it using
>> mouse. Do you know any samples about this subject?
>>
>> ...
>>
>> Thank you!
>>
>> Cheers,
>> Tufan
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=30027#30027
>>
>>
>>
>>
>>
>> ___
>> 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] cmake errors with 2.9.8

[Jean-Sébastien Guay]

Hi John,


As a quick test I deleted the line

FRAMEWORK DESTINATION /Library/Frameworks

in CMakeModules/ModuleInstall.cmake, and everything builds and installs
just fine.


Yes, that's great news.


I tried this:

INSTALL(
TARGETS ${LIB_NAME}
RUNTIME DESTINATION ${INSTALL_BINDIR} COMPONENT libopenscenegraph
LIBRARY DESTINATION ${INSTALL_LIBDIR} COMPONENT libopenscenegraph
ARCHIVE DESTINATION ${INSTALL_ARCHIVEDIR} COMPONENT libopenscenegraph-dev
IF(APPLE)
FRAMEWORK DESTINATION /Library/Frameworks
ENDIF
)


That won't work, the IF construct is not a preprocessor directive like 
#if would be in C, it's like if() in C. Consider this code:


sprintf("my string is %s",
if (0)
  "string"
else
  "otherstring"
);

Would that work in C? No because your if is within a function call. Same 
thing here, you need to have your if outside the INSTALL() function 
call, and copy it in both the IF and ELSE and just have FRAMEWORK in the 
IF(APPLE) branch.


But if what Stephan says is true, then it means that even if guarded by 
an IF(APPLE) the parser will choke on the FRAMEWORK keyword so it won't 
work...


Perhaps we could have that function in a separate file which would only 
be loaded IF(APPLE)? Would that work?


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] cmake errors with 2.9.8

[John Kelso]

Same thing.

Parse error.  Function missing ending ")".  Instead found left paren with
text "(".
CMake Error: Error in cmake code at
/usr/local/HEV-beta/apps/osg/osg-2.9.8/OpenSceneGraph/CMakeModules/ModuleInstall.cmake:33:

Line 33 is the "IF(APPLE)" line.

Just to be sure, this is what I have (run through cat -n):
33  IF(APPLE)
34  FRAMEWORK DESTINATION /Library/Frameworks
35  ENDIF()

Thanks,

John

On Fri, 16 Jul 2010, Robert Osfield wrote:


Hi Johm,

Try ENDIF() rather than ENDIF.

Robert.

On Fri, Jul 16, 2010 at 3:13 PM, John Kelso  wrote:

Good news!

As a quick test I deleted the line

   FRAMEWORK DESTINATION /Library/Frameworks

in CMakeModules/ModuleInstall.cmake, and everything builds and installs just
fine.

I tried this:

INSTALL(
   TARGETS ${LIB_NAME}
   RUNTIME DESTINATION ${INSTALL_BINDIR} COMPONENT libopenscenegraph
   LIBRARY DESTINATION ${INSTALL_LIBDIR} COMPONENT libopenscenegraph
   ARCHIVE DESTINATION ${INSTALL_ARCHIVEDIR} COMPONENT libopenscenegraph-dev
   IF(APPLE)
       FRAMEWORK DESTINATION /Library/Frameworks
   ENDIF
)

but get the error:

CMake Error: Error in cmake code at
/usr/local/HEV-beta/apps/osg/osg-2.9.8/OpenSceneGraph/CMakeModules/ModuleInstall.cmake:33:
Parse error.  Function missing ending ")".  Instead found left paren with
text "(".

I suspect this is an easy fix for someone who knows cmake.

Thanks,

John

On Fri, 16 Jul 2010, John Kelso wrote:


Hi,

Yes, I'm very willing to do this, but realisticaly won't have a chance to
do
it until August.

But, I'll take a look at the effort involved right now, and if it isn't
too
messy I'll see if I can fit into the interstisal spaces of my schedule and
knock it out.

Thanks,

John

On Fri, 16 Jul 2010, Jean-Sébastien Guay wrote:


Hi Robert, John,


Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.


Yes, but who will do it? It would need to be someone who runs into the
problem... John, do you have a bit of time to look into it?

In theory you'd just have to surround lines that have FRAMEWORK with
if(APPLE)...ELSE()...ENDIF() constructs. Hopefully you won't have to
copy whole blocks into the ELSE side, otherwise you could make a macro
you put in the CMakeModules/OSGMacroUtils.cmake that would do what you
need, i.e. omit FRAMEWORK on non-APPLE configs.

Argh, messy... :-)


So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.


I agree with you, and I remembered that some systems and distributions
are stuck on old versions for a long time (as is the case for John), so
yeah, going around guarding the FRAMEWORK keyword is pretty much the
only thing we can do.

Thanks,

J-S


___
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] cmake errors with 2.9.8

[Robert Osfield]

Hi Johm,

Try ENDIF() rather than ENDIF.

Robert.

On Fri, Jul 16, 2010 at 3:13 PM, John Kelso  wrote:
> Good news!
>
> As a quick test I deleted the line
>
>    FRAMEWORK DESTINATION /Library/Frameworks
>
> in CMakeModules/ModuleInstall.cmake, and everything builds and installs just
> fine.
>
> I tried this:
>
> INSTALL(
>    TARGETS ${LIB_NAME}
>    RUNTIME DESTINATION ${INSTALL_BINDIR} COMPONENT libopenscenegraph
>    LIBRARY DESTINATION ${INSTALL_LIBDIR} COMPONENT libopenscenegraph
>    ARCHIVE DESTINATION ${INSTALL_ARCHIVEDIR} COMPONENT libopenscenegraph-dev
>    IF(APPLE)
>        FRAMEWORK DESTINATION /Library/Frameworks
>    ENDIF
> )
>
> but get the error:
>
> CMake Error: Error in cmake code at
> /usr/local/HEV-beta/apps/osg/osg-2.9.8/OpenSceneGraph/CMakeModules/ModuleInstall.cmake:33:
> Parse error.  Function missing ending ")".  Instead found left paren with
> text "(".
>
> I suspect this is an easy fix for someone who knows cmake.
>
> Thanks,
>
> John
>
> On Fri, 16 Jul 2010, John Kelso wrote:
>
>> Hi,
>>
>> Yes, I'm very willing to do this, but realisticaly won't have a chance to
>> do
>> it until August.
>>
>> But, I'll take a look at the effort involved right now, and if it isn't
>> too
>> messy I'll see if I can fit into the interstisal spaces of my schedule and
>> knock it out.
>>
>> Thanks,
>>
>> John
>>
>> On Fri, 16 Jul 2010, Jean-Sébastien Guay wrote:
>>
>>> Hi Robert, John,
>>>
 Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
 it's a bit of pain, but it would allow those using cmake out of the
 box on older OS spins to keep working.
>>>
>>> Yes, but who will do it? It would need to be someone who runs into the
>>> problem... John, do you have a bit of time to look into it?
>>>
>>> In theory you'd just have to surround lines that have FRAMEWORK with
>>> if(APPLE)...ELSE()...ENDIF() constructs. Hopefully you won't have to
>>> copy whole blocks into the ELSE side, otherwise you could make a macro
>>> you put in the CMakeModules/OSGMacroUtils.cmake that would do what you
>>> need, i.e. omit FRAMEWORK on non-APPLE configs.
>>>
>>> Argh, messy... :-)
>>>
 So far it hasn't been a big problem, but it's something we should
 monitor - just how hassle is it to support older CMake versions.  On a
 pure engineering standpoint I'd rather we'd just have a single CMake
 min version as well, but from a pragmatic standpoint it can shift the
 a small amount of disruption in one place to more disruption
 elsewhere.  Where to draw the line is the difficult thing, something I
 try to do on a case by case basis when reviewing submissions, and by
 monitoring the pain threshold out in the community.
>>>
>>> I agree with you, and I remembered that some systems and distributions
>>> are stuck on old versions for a long time (as is the case for John), so
>>> yeah, going around guarding the FRAMEWORK keyword is pretty much the
>>> only thing we can do.
>>>
>>> Thanks,
>>>
>>> J-S
>
> ___
> 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] cmake errors with 2.9.8

[John Kelso]

Good news!

As a quick test I deleted the line

FRAMEWORK DESTINATION /Library/Frameworks

in CMakeModules/ModuleInstall.cmake, and everything builds and installs just
fine.

I tried this:

INSTALL(
TARGETS ${LIB_NAME}
RUNTIME DESTINATION ${INSTALL_BINDIR} COMPONENT libopenscenegraph
LIBRARY DESTINATION ${INSTALL_LIBDIR} COMPONENT libopenscenegraph
ARCHIVE DESTINATION ${INSTALL_ARCHIVEDIR} COMPONENT libopenscenegraph-dev
IF(APPLE)
FRAMEWORK DESTINATION /Library/Frameworks
ENDIF
)

but get the error:

CMake Error: Error in cmake code at
/usr/local/HEV-beta/apps/osg/osg-2.9.8/OpenSceneGraph/CMakeModules/ModuleInstall.cmake:33:
Parse error.  Function missing ending ")".  Instead found left paren with
text "(".

I suspect this is an easy fix for someone who knows cmake.

Thanks,

John

On Fri, 16 Jul 2010, John Kelso wrote:


Hi,

Yes, I'm very willing to do this, but realisticaly won't have a chance to do
it until August.

But, I'll take a look at the effort involved right now, and if it isn't too
messy I'll see if I can fit into the interstisal spaces of my schedule and
knock it out.

Thanks,

John

On Fri, 16 Jul 2010, Jean-Sébastien Guay wrote:


Hi Robert, John,


Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.


Yes, but who will do it? It would need to be someone who runs into the
problem... John, do you have a bit of time to look into it?

In theory you'd just have to surround lines that have FRAMEWORK with
if(APPLE)...ELSE()...ENDIF() constructs. Hopefully you won't have to
copy whole blocks into the ELSE side, otherwise you could make a macro
you put in the CMakeModules/OSGMacroUtils.cmake that would do what you
need, i.e. omit FRAMEWORK on non-APPLE configs.

Argh, messy... :-)


So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.


I agree with you, and I remembered that some systems and distributions
are stuck on old versions for a long time (as is the case for John), so
yeah, going around guarding the FRAMEWORK keyword is pretty much the
only thing we can do.

Thanks,

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

Re: [osg-users] [osgCompute] osgCompute - using 32bit osgCudaTexture2D

[Mick Keller]

Hi Diana,

I am sorry - we simply overlooked your request. osgCompute has been 
continuously updated. The current svn version supports cuda 3.


Diana wrote:
> Hi,
> I try to make some changes to the osgTexDemo example to use 32bit 
> osgCudaTexture2D.
> I changed the source type to GL_FLOAT, and modified the kernel accordingly 
> (float4* instead of uchar4*).
> The resulting values in VBO were precise (32bit precision), but the values in 
> trgTexture still had 8bit precision, like in the original example.
>  
> Am I doing something wrong?
>  
> Thanks a lot, 
> Diana
>  



Did you also set the internal format correctly?

Code:

trgTexture->setInternalFormat( GL_RGBA32F_ARB )




Best regards,
Mick[/code]


SVT Group

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





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

Re: [osg-users] Misunderstanding NODE / DRAWABLE notions

[Mathieu Scorpionis]

I finally used a OSG file, and everything is solved.
Thank you  :D

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





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

Re: [osg-users] cmake errors with 2.9.8

[Stephan Huber]

Hi,

Am 16.07.10 11:03, schrieb Robert Osfield:
> Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
> it's a bit of pain, but it would allow those using cmake out of the
> box on older OS spins to keep working.

what I don't understand is:

AFAIK the FRAMEWORK is guarded by the OSG_COMPILE_FRAMEWORKS-flag ala

IF(NOT OSG_COMPILE_FRAMEWORKS)
  // link as dynamic libs
ELSE()
  // link as framework with FRAMEWORK-directive
ENDIF()

So another if(APPLE)-guard would not help, as the parser is choking
about FRAMEWORK, isn't it?

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

Re: [osg-users] cmake errors with 2.9.8

[John Kelso]

Hi,

Yes, I'm very willing to do this, but realisticaly won't have a chance to do
it until August.

But, I'll take a look at the effort involved right now, and if it isn't too
messy I'll see if I can fit into the interstisal spaces of my schedule and
knock it out.

Thanks,

John

On Fri, 16 Jul 2010, Jean-Sébastien Guay wrote:


Hi Robert, John,


Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.


Yes, but who will do it? It would need to be someone who runs into the
problem... John, do you have a bit of time to look into it?

In theory you'd just have to surround lines that have FRAMEWORK with
if(APPLE)...ELSE()...ENDIF() constructs. Hopefully you won't have to
copy whole blocks into the ELSE side, otherwise you could make a macro
you put in the CMakeModules/OSGMacroUtils.cmake that would do what you
need, i.e. omit FRAMEWORK on non-APPLE configs.

Argh, messy... :-)


So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.


I agree with you, and I remembered that some systems and distributions
are stuck on old versions for a long time (as is the case for John), so
yeah, going around guarding the FRAMEWORK keyword is pretty much the
only thing we can do.

Thanks,

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

Re: [osg-users] cmake errors with 2.9.8

[Robert Osfield]

Hi John,

On Fri, Jul 16, 2010 at 1:21 PM, John Kelso  wrote:
> I'm glad to hear it's something simple.  Unfortunately for me, given the
> nature of the system I work on, it's not something I can change.  I'll just 
> have to
> wait until a newer version of cmake gets installed before I can update our
> version of OSG.

Are you not even allowed to have a local cmake executable in your own
home directory?  When I experiment with different versions of cmake
this is exactly what I do, one needn't ever install.


> BTW, the README.txt, and the link it references, both specify I only need
> cmake
> 2.4.6.

Please remember the dev releases and svn/trunk are developer versions
so stuff gets checked in that requires testing.  In this instance the
FRAMEWORK addition wasn't known to break older Cmake versions until
you revelled this.  We either need to find a fix or update the docs.

As J.S. mentioned your actually well placed to implement a fix to get
the build working as others doing so would require a round trip
waiting for you to test it.

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

Re: [osg-users] cmake errors with 2.9.8

[Jean-Sébastien Guay]

Hi Robert, John,


Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.


Yes, but who will do it? It would need to be someone who runs into the 
problem... John, do you have a bit of time to look into it?


In theory you'd just have to surround lines that have FRAMEWORK with 
if(APPLE)...ELSE()...ENDIF() constructs. Hopefully you won't have to 
copy whole blocks into the ELSE side, otherwise you could make a macro 
you put in the CMakeModules/OSGMacroUtils.cmake that would do what you 
need, i.e. omit FRAMEWORK on non-APPLE configs.


Argh, messy... :-)


So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.


I agree with you, and I remembered that some systems and distributions 
are stuck on old versions for a long time (as is the case for John), so 
yeah, going around guarding the FRAMEWORK keyword is pretty much the 
only thing we can do.


Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] cmake errors with 2.9.8

[John Kelso]

Hi,

I'm glad to hear it's something simple.  Unfortunately for me, given the nature 
of
the system I work on, it's not something I can change.  I'll just have to
wait until a newer version of cmake gets installed before I can update our
version of OSG.

BTW, the README.txt, and the link it references, both specify I only need cmake
2.4.6.

Thanks,

John



On Fri, 16 Jul 2010, Robert Osfield wrote:


Hi JS, Chuck, John et. al.

On Thu, Jul 15, 2010 at 9:48 PM, Jean-Sébastien Guay
 wrote:

But that means that on Win32 and anything other than APPLE, it will accept
old versions of CMake, and the FRAMEWORK keyword is not guarded to be used
only on APPLE everywhere it's used, so there's the problem.


Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.


I'd say we should use only one CMAKE_MINIMUM_REQUIRED version for all
platforms. Else it becomes a nightmare to maintain, you have to guard stuff
everywhere.


So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.

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] Visual Studio 2010 3rd Party

[Jason Alexander]

Hi,

Let me clarify...

OSG Links fine.  Many DLL's in my application link fine.  However, I find that 
in two specific DLL's, if I link in the OSG libraries, I get a linker error 
relating to std.


Code:

foo.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
public: void __thiscall std::basic_ifstream 
>::`vbase destructor'(void)" 
(__imp_??_d?$basic_ifstr...@du?$char_traits@d...@std@@@std@@QAEXXZ) referenced 
in function .

foo.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
public: void __thiscall std::basic_ifstream 
>::close(void)" 
(__imp_?cl...@?$basic_ifstream@du?$char_tra...@d@std@@@std@@QAEXXZ) referenced 
in function ..

foo.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
public: bool __thiscall std::basic_ifstream 
>::is_open(void)const " 
(__imp_?is_o...@?$basic_ifstream@du?$char_tra...@d@std@@@std@@QBE_NXZ) 
referenced in function ..

foo.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
public: __thiscall std::basic_ifstream 
>::basic_ifstream >(char const *,int,int)" 
(__imp_??0?$basic_ifstr...@du?$char_traits@d...@std@@@std@@q...@pbdhh@Z) 
referenced in function ..





These are the only calls to ifstream in the DLL.  Other DLL's that do NOT link 
in OSG do not give this error and, if I take out the references to OSG and 
recompile this DLL, I do not get these errors but the function calls are still 
in there.  

I recompiled all of OSG in VS2010 with the proper settings hoping that would 
resolve the issues, but it did not.  Then I started to rebuild the 3rd party 
libraries, but there are quite a few and I was hoping that someone would be 
able to send me or link me to some pre-built files so I can press on with my 
work.

If there was a way to narrow down which library caused this issue, I would love 
to learn about it.  Short of that, I would like to get this application running 
on VS2010 and not have to roll back to 2008.

Thank you!

Cheers,
Jason

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





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

[osg-users] Point in Polygon problem

[Benoît Bayol]

Hi,

I want to know if there is a standard algorithm included in osg for the point 
in polygon problem ? (ie finding if M belongs to P).

Thank you!

Cheers,
Benoît


-- 
Benoît Bayol
benoit.ba...@gmail.com

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





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

Re: [osg-users] simply rotation to MatrixTransform

[Robert Osfield]

Hi Anthony,

I would suggest you use osg::PosititionAttitudeTransform as it has
separate fields for position, scale and rotation (attitude).

Robert.

On Fri, Jul 16, 2010 at 8:22 AM, Anthony Face  wrote:
> Hello,
>
> i would like to use MatrixTransform to rotate an objet but i do not succed !
>
> this object already have a scale and a translation associeted.
>
>
> i would like a function like:
>
> Code:
> void Objet3D::rotateTo(double angle, double x,double y, double z){/* code */}
>
>
>
> i tried:
>
> Code:
>
> Matrix mr,mt,ms;
> mt.makeTranslate(getMatrix().getTrans());
> ms.makeScale(getMatrix().getScale());
> setMatrix(ms*mr*mt);
>
>
>
> but rotation dont work (something happend but not what i want).
>
> and
>
> Code:
>
> Matrix mr;
> mr.makeRotate(Quat(angle,x,y,z));
> setMatrix(mr*getMatrix());
>
>
>
> but same aproximatly result.
>
> i have to rotate my item only once every 20/50 frame (depends on fps)
>
> 
>
> i need your help, it can be something idio but ... need help :(
>
> 
>  (http://www.hordes.fr?ref=litllechicken)
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=30057#30057
>
>
>
>
>
> ___
> 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] Usage of the command line of osgTerrain

[Robert Osfield]

Hi Ting,

On Fri, Jul 16, 2010 at 2:16 AM, ting zhang  wrote:
> Do you know what kind of technique is used in the runtime generation. I 
> analysed osgTerrain, unfortunately,  I cannot find any runtime generation 
> techniques of terrains in osgTerrain, am I right?

There is only one "technique" available in osgTerrain right now - the
osgTerrain::GeometryTechnique which is a brute force tessellation of
the tiles, where a regular grid is generated, and only very simple
down sampling is provided in the form of a coarser regular grid.

The design of osgTerrain is that it allows you to provide your own
custom TerrainTechnique so you can implement any tessellation approach
you want.

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

Re: [osg-users] My Lines Disapering but Ploygons don't

[Robert Osfield]

Hi David,

As you seem to resolved the issue I'll not dive in too much further,
but the following comment from jumps out as needing a reply:

On Wed, Jul 14, 2010 at 11:37 PM, David Glenn
 wrote:
> Oh Yea, I forgot to add that I use two views, one for the terrain (the globe) 
> and one for the elements in play. This is to avoid terrain clashing with 
> other objects (like Terrain and the Overlays). This is necessary, because 
> sometimes some of the elevations of objects in play are unreliable and would 
> hide behind the terrain if I did think of a way to keep them visible.
>
> Both views are set up the same and use the same window (there like Photo Shop 
> layers). except each added layer has background turned off (or you don't see 
> the terrain in the first layer) and the cameras stay synced together. This 
> make them appear like they are the same view, but they are not.

Conceptually a View is a single view of your scene - this will may be
made up from several cameras attached to several windows, or several
cameras attached to a single window.  In you case you most definitely
have one conceptual view and you should be thinking about using one
osgViewer::View object for it.  Doing so will avoid the need for you
to synchronize the view and projection matrices by hand, as well as
simply make more sense.

The way to do multiple overlays like you want is to use multiple slave
Camera, these will be relative to the View's master Camera and can
clear the different colour/depth buffers or not as your require.  For
instance the osghud example uses a variation on this where it disables
the colour buffer clear for the HUD text Camera, it also changes the
ReferenceFrame of the Camera to ABSOLUTE_RF which you won't need, but
in essence it's just an extra layer just like what you want.

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

Re: [osg-users] cmake errors with 2.9.8

[Robert Osfield]

Hi JS, Chuck, John et. al.

On Thu, Jul 15, 2010 at 9:48 PM, Jean-Sébastien Guay
 wrote:
> But that means that on Win32 and anything other than APPLE, it will accept
> old versions of CMake, and the FRAMEWORK keyword is not guarded to be used
> only on APPLE everywhere it's used, so there's the problem.

Guarding the FRAMEWORK keyword sounds like the sensible thing to do,
it's a bit of pain, but it would allow those using cmake out of the
box on older OS spins to keep working.

> I'd say we should use only one CMAKE_MINIMUM_REQUIRED version for all
> platforms. Else it becomes a nightmare to maintain, you have to guard stuff
> everywhere.

So far it hasn't been a big problem, but it's something we should
monitor - just how hassle is it to support older CMake versions.  On a
pure engineering standpoint I'd rather we'd just have a single CMake
min version as well, but from a pragmatic standpoint it can shift the
a small amount of disruption in one place to more disruption
elsewhere.  Where to draw the line is the difficult thing, something I
try to do on a case by case basis when reviewing submissions, and by
monitoring the pain threshold out in the community.

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

Re: [osg-users] VRJuggler Particles Effects Not working?

[Robert Osfield]

HI Nick,

On Thu, Jul 15, 2010 at 4:19 PM, nick waller  wrote:
> Thanks Robert. We looked at the framestamp and found that VRJuggler was not 
> setting the simulation time of it.  Once we did that, particle and animation 
> effects started working.

Could you push these changes back to the VRJuggler team to enable
others to benefit from this fix as well.

> However, now we have run into a different but related problem.  The particles 
> that show up seem to move when we translate the scenegraph twice as much and 
> end up way out of place.  We've tried to apply the opposite transform to the 
> particle system geode, and that didn't change a thing, so we tried the 
> modular emitters and particle system updater but still not a single thing is 
> changing on the graph.
> Do you have any idea what could be causing this problem?

This is due to the particle emitter being transformed and the particle
system itself being transformed as well, this causes a double
transformation.  To avoid this you need to move the particle system
out from underneath your transforms an put it in world coordinates.
Have a look at the osgparticleeffects example for discussion in the
code about this.

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

Re: [osg-users] Stop back buffer swap during rendering traversals

[Robert Osfield]

Hi Michael,

On Thu, Jul 15, 2010 at 2:53 PM, Michael Irby II  wrote:
> Does anyone know how I could go about stopping the View from doing a back 
> buffer swap during the rendering traversals. I am outfitting OSG into current 
> rendering engine, but I need the OSG view to not swap the back buffer at the 
> end of the rendering traversals. Is there something I need to override or 
> derive from one of the view classes? Any suggestions would be appreciated.

I know nothing at all about your app or how you do windows, but
typically if users are grafting the OSG into an existing application
you'd use the osgViewer::GraphicsWindowEmbedded class to trick the
Viewer into not doing any graphics context operations, so allow it to
work with API's like GLUT and SDL, or other single windows apps.  See
the osgviewerSDL and osgviewerGLUT examples.

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

Re: [osg-users] LOD Culling issue

[Robert Osfield]

Hi Vincent,

> Do you mean that I have to initialize the Bounding Sphere of the PagedLOD
> node when I create it ? because I didn't found any special method in LOD or
> PagedLOD about that.

You obviously didn't look hard enough...  in the LOD header you'll find:

/** Modes which control how the center of object should be
determined when computing which child is active.*/
enum CenterMode
{
USE_BOUNDING_SPHERE_CENTER,
USER_DEFINED_CENTER
};

/** Set how the center of object should be determined when
computing which child is active.*/
void setCenterMode(CenterMode mode) { _centerMode=mode; }

/** Get how the center of object should be determined when
computing which child is active.*/
CenterMode getCenterMode() const { return _centerMode; }

/** Sets the object-space point which defines the center of
the osg::LOD.
center is affected by any transforms in the hierarchy
above the osg::LOD.*/
inline void setCenter(const vec_type& center) {
_centerMode=USER_DEFINED_CENTER; _userDefinedCenter = center; }

/** return the LOD center point. */
inline const vec_type& getCenter() const { if
(_centerMode==USER_DEFINED_CENTER) return _userDefinedCenter; else
return getBound().center(); }


/** Set the object-space reference radius of the volume
enclosed by the LOD.
  * Used to determine the bounding sphere of the LOD in the
absence of any children.*/
inline void setRadius(value_type radius) { _radius = radius; }

/** Get the object-space radius of the volume enclosed by the LOD.*/
inline value_type getRadius() const { return _radius; }


Use these user bounding sphere methods when your PagedLOD has all
external children to make sure it has a relevant bounding sphere.

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

Re: [osg-users] Visual Studio 2010 3rd Party

[Torben Dannhauer]

Hi jason,

If you are using VS 2010 and you build your libraries with VS 2010, everthing 
should be fine as long as you compiled for the same architecture (32 or 64 bit 
).

If you have linking issues while building your OSG, please play a little bit 
with the static or dynamic versions of your library. I had also some errors but 
managed them by switchgung from static to dynamic or vice versa.

I hope you manage to build the libraries!

Cheers,
Torben

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





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

Re: [osg-users] Problem running my OSG application

[Anthony Face]

hi,

i think is it not an OSG problem but an visual problem. 
You create an exe working in a special environment (with libs/dll/...) and 
visual link with them.

If you want to run your application by click² on .exe you have to put every 
dll/libs/... required to use your application in same directory.


 (http://www.hordes.fr?ref=litllechicken)

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





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

[osg-users] Visual Studio 2010 3rd Party

[Jason Alexander]

Hi,

I have successfully built OSG with Visual Studio 2010, but my application is 
still having issues with std libraries when I link in OSG.  I believe I have 
narrowed the problem down to not having all of the 3rd party libraries built 
with Visual Studio 2010.  Can anyone out there save me some serious time and 
provide 3rd party libraries built with VS10?

Thank you!

Cheers,
Jason

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





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

[osg-users] simply rotation to MatrixTransform

[Anthony Face]

Hello,

i would like to use MatrixTransform to rotate an objet but i do not succed !

this object already have a scale and a translation associeted.


i would like a function like:

Code:
void Objet3D::rotateTo(double angle, double x,double y, double z){/* code */}



i tried:

Code:

Matrix mr,mt,ms;
mt.makeTranslate(getMatrix().getTrans());
ms.makeScale(getMatrix().getScale());
setMatrix(ms*mr*mt);



but rotation dont work (something happend but not what i want).

and 

Code:

Matrix mr;
mr.makeRotate(Quat(angle,x,y,z));
setMatrix(mr*getMatrix());



but same aproximatly result.

i have to rotate my item only once every 20/50 frame (depends on fps)



i need your help, it can be something idio but ... need help :(


 (http://www.hordes.fr?ref=litllechicken)

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





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