Re: [osg-users] Geometry kernels?

2009-01-07 Thread Sukender
Hi Cory,

What do you mean by "geometry engine"? I guess you'll be able to easily create 
a kind of exporter that converts your geometry to an OSG/OpenGL one. Perhaps 
geometries would even be directly read and added to Geodes.
I don't know HOOPS, but be aware that OSG is "only" (!) a scene graph (with 
many features and plugins), but not a CAD/infrastructure/mining/whatever 
software.

Please tell us if you find useful things.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Wed, 07 Jan 2009 16:44:15 +0100, Cory Riddell  a écrit:

> I'm looking for comments and suggestions for using OSG with a geometry
> engine like ACIS, Parasolid, or Open Cascade. Can they work well
> together? Is it a useful combination? The application is CAD-like and
> involves interactively building up a model from discrete components.
>
> I found OSG when looking for HOOPS competitors. Is it fair to compare
> HOOPS with OSG?
>
> Thanks,
> Cory

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


Re: [osg-users] Warning level

2009-01-07 Thread Sukender
Hi Robert, Matthew et al.,

IMHO, the "!=0" syntax in a "if" statement is the most portable. I know "if 
((a=b)!=0)" does not generate warning under MSVC and GCC. So I guess it would 
be the same for "if ( (a = fxn()) != 0 )". For my part, I always use the "!=0" 
syntax... and I avoid as much as possible the affectations in a "if" statement 
by splitting the instruction. :)

Cheers,

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Wed, 07 Jan 2009 17:51:58 +0100, Robert Osfield  a 
écrit:

> Hi Matthew,
>
> On Wed, Jan 7, 2009 at 4:36 PM, Matthew Fuesz  wrote:
>> Blanket-supression of C4706 isn't really a good thing, since as you pointed 
>> out, it can actually point out an error (usually a typo by the developer). 
>> C4706 will not be generated if it is made explicitly clear what the intent 
>> of the conditional is.
>>
>> i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 
>> )". This is covered in the MSDN page on C4706.
>>
>> I actually prefer the latter syntax (which doesn't generate C4706) anyway, 
>> since it eliminates any possible confusion as to the intended operations.
>
> All the instances if assignment in condtionaly already have a () added
> around the conditional to avoid the warning under gcc, I had hoped
> that this would be the end of it... but no...
>
> Personally I've got others things to chase up right now that are more
> important than adding more superfluous code to the OSG to fix silly
> warnings that have no relevance to fixing bugs in the OSG.  Feel free
> to dive in if you feel so inclined, otherwise I'll be happy to stick
> with the surpression of this warning under VS.
>
> 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] getYnormalized() and camera transforms

2009-01-07 Thread Guy Wallis
Hi Robert,
The behaviour you describe is exactly what I was hoping for: x in the
range -3 to +3 and y -1 to +1. But that's not what I get. I've created a
small program derived from the osgcamera example. It builds three
panels: left looks at -90 degrees, middle straight ahead, and the right
panel at +90. Everything works as expected moving the cow model using
your Trackball manipulator.

The program also spits out the normalized xy values into the shell
window on each frame. The middle panel behaves as one would expect for a
scaled viewport: x -.33 to +.33 and y -1 to +1. But move the mouse into
the left or right viewport and the numbers are all over the place.
Funny, because the manipulator works just fine.

Any ideas?

Thanks,

Guy

--

#include 
#include 
#include 
#include 

class ModelHandler : public osgGA::GUIEventHandler 
{
public: 

ModelHandler(){}

bool handle(const osgGA::GUIEventAdapter& ea,
osgGA::GUIActionAdapter& aa)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::FRAME):{
printf("%f %f\n", ea.getXnormalized(),
ea.getYnormalized());
return true;
}
default: break;
}
return false;
}
};


void multipleWindowMultipleCameras(osgViewer::Viewer& viewer)
{
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
unsigned int width=1000, height=600;
unsigned int numCameras = 3;
double aspectRatioScale = (double)numCameras;
double translate_x = double(numCameras)-1;
for(unsigned int i=0; i traits = new
osg::GraphicsContext::Traits;
traits->screenNum = 0;
traits->x = (i*width)/numCameras;
traits->y = 0;
traits->width = width/numCameras-1;
traits->height = height;
traits->windowDecoration = false;
traits->doubleBuffer = true;
traits->sharedContext = 0;

osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptr camera = new osg::Camera;
camera->setGraphicsContext(gc.get());
camera->setViewport(new osg::Viewport(0,0, width/numCameras,
height));
GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
camera->setDrawBuffer(buffer);
camera->setReadBuffer(buffer);
viewer.addSlave(camera.get(),
osg::Matrix::scale(aspectRatioScale, 1.0, 1.0),
osg::Matrix::rotate(osg::inDegrees(-90.0f+90.0f*i),0.0f,1.0f,0.0f));
}
}


int main( int argc, char **argv )
{
osgViewer::Viewer viewer;
osg::ref_ptr loadedModel;
ModelHandler* modelHandler = new ModelHandler;

multipleWindowMultipleCameras(viewer);
viewer.setCameraManipulator( new osgGA::TrackballManipulator());
loadedModel = osgDB::readNodeFile("cow.osg");
viewer.setSceneData(loadedModel.get());
viewer.addEventHandler(modelHandler);
viewer.realize();
while(!viewer.done())
{
viewer.frame();
}
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] High resolution screencast

2009-01-07 Thread Simon Loic
I tried it but I encountered few problems. I will send you the detailed
tomorrow. Still thanks for the tip.

On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles wrote:

> Not trying to hijack this thread--and I can't really read it all for now
> because I'm still fighting off lots of complications from a recent oral
> surgery--but what you want is called "bugle." I used it to make all of
> the old osgWidget and osgPango videos and it works like a charm.
>
> What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a
> version that shimmies off data to ffmpeg for encoding. Simple, clean,
> and easy for basic usage.
>
> On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote:
> > Hi,
> >
> > I apology in advance if this thread have been heavily answered before
> > (if so just tell where I can find the solution). Still I would like to
> > know the different alternative (the good ones) to record a video of my
> > scene.
> > So far I was using an external tool for screenCast (called istanbul).
> > But I'm not satisfied by this because when my scene is very complex,
> > my osg based application is lagging and this leads to a poor quality
> > of th video.
> >
> > I'm especially interested if there is a way to create an
> > RecordCameraPathHandler to record a path, and then instead of saving
> > it as a .path file compute the video in a batch mode. By batch mode I
> > mean that the creation of the video doesn't need to be real time. In
> > that way I could hopefully control the lag effects and eventually the
> > resolution of the video.
> >
> > Sincerely,
> >
> > --
> > Loïc Simon
> > ___
> > 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
>



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


Re: [osg-users] osganimationskinning broken?

2009-01-07 Thread Cedric Pinson

Hi Roland,

I updated osgAnimation and if forget to update this example, all others 
have been tested and it should work with updated data. Robert did you 
commited the updated data in the trunk ?
Else if not yet updated data of osgAnimation are here 
http://hg.plopbyte.net/osg-data/ you can grab this mercurial repository 
to get new osgAnimation data.
Yes now UpdateCallback are not set in the constructor, so a explicit 
call has to be made, that why this example segfault.


I will fix the example tomorrow.
Thank you for the report

Cheers,
Cedric

Roland Smeenk wrote:

Is it me or is osganimationskinning broken?

line 198:

Code:
osgAnimation::AnimationUpdateCallback* cb = 
dynamic_cast(right0->getUpdateCallback());



returns NULL, because the updatecallback was never set.

This is easily fixed, but then I run into the problem that the SkinGeometry is 
not updated. The bones move OK.

--
Roland

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4267#4267





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


--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:morni...@plopbyte.net 
http://www.plopbyte.net


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


Re: [osg-users] Head mounted display for OSG...

2009-01-07 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
David,

Thanks for that feedback. This will help out...:)

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David
Spilling
Sent: Wednesday, January 07, 2009 3:16 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Head mounted display for OSG...

Shayne,

We use these (http://www.vuzix.com/iwear/products_vr920.html)
experimentally, because they are cheap, and slightly surprisingly support
quad buffer stereo, which means they more or less work with OSG (on Nvidia
Quadro's, at least) straight out of the box. 

Unfortunately, most of our in-house OSG apps hijack the camera in one way or
another and assume that they are not being run stereo, so all goes a bit
awry. Work in progress...

David




smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Head mounted display for OSG...

2009-01-07 Thread David Spilling
Shayne,

We use these (http://www.vuzix.com/iwear/products_vr920.html)
experimentally, because they are cheap, and slightly surprisingly support
quad buffer stereo, which means they more or less work with OSG (on Nvidia
Quadro's, at least) straight out of the box.

Unfortunately, most of our in-house OSG apps hijack the camera in one way or
another and assume that they are not being run stereo, so all goes a bit
awry. Work in progress...

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


Re: [osg-users] Warning level

2009-01-07 Thread Paul Martz
Your recommendation below seems like it would depend on what type fxn()
returns, am I correct?

For example, if fxn() returns an int (and 'a' is declared as an int), then
the following is correct:
"if ( (a = fxn()) != 0 )

But the above is incorrect - and possibly inefficient - if fxn() returns a
bool (and 'a' is declared as a bool), because that code would causes a bool
to be compared against an int (0). If fxn() returns a bool, the following
should be sufficient (and should not generate a warning IMHO):
"if ( a = fxn() )"

This is off topic for a scene graph mailing list, but I would like to
prevent someone from going through the code and doing a blanket replace of
good code with bad code.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Matthew
Fuesz
Sent: Wednesday, January 07, 2009 9:36 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Warning level


Skylark (J-S) wrote:
> 
> I'm fine with suppressing C4706 as it's true that it's a warning that 
> only tells you that you *might* be doing something unsafe... Whether 
> it's actually safe or not is totally context-dependent.
> 


Blanket-supression of C4706 isn't really a good thing, since as you pointed
out, it can actually point out an error (usually a typo by the developer).
C4706 will not be generated if it is made explicitly clear what the intent
of the conditional is.

i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0
)". This is covered in the MSDN page on C4706.

I actually prefer the latter syntax (which doesn't generate C4706) anyway,
since it eliminates any possible confusion as to the intended operations.


Matthew W Fuesz
Software Engineer Asc
Lockheed Martin STS

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4253#4253





___
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] osganimationskinning broken?

2009-01-07 Thread Roland Smeenk
Is it me or is osganimationskinning broken?

line 198:

Code:
osgAnimation::AnimationUpdateCallback* cb = 
dynamic_cast(right0->getUpdateCallback());



returns NULL, because the updatecallback was never set.

This is easily fixed, but then I run into the problem that the SkinGeometry is 
not updated. The bones move OK.

--
Roland

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4267#4267





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


Re: [osg-users] Warnings in VS

2009-01-07 Thread Paul Martz
Interesting. With current svn, I am able to toggle
OSG_USE_AGGRESSIVE_WARNINGS from OFF to ON without deleting my cache. This
seems to have fixed itself (I'm not using Mattias' fix).

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Wednesday, January 07, 2009 2:31 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Warnings in VS

Hello Mattias,

> Makes it kind of hard to test. Sorry about that. Trying again before 
> submitting the file to osg-submissions.

Got the file, thanks. (third time's a charm right? ;-) )

I'll try it out tomorrow.

> i didn't either at first. I was really trying to get my head around 
> the internal cache variables involved and things didn't behave as 
> expected. I have now tested this on linux with cmake-2.6.3-RCx and 
> there this problem doesn't exist. Btw I'm currently using 
> msvc90Express on Vista 32-bit and cmake-2.6.2.

I'm on msvc8 but the rest is the same for me. It would be surprising if it
was Linux itself that fixed the problem, so it must be cmake-2.6.3-RCx...
I'll try downloading RC5 from http://www.cmake.org/files/v2.6/ and see.

> Cool. And I'm working on a submission for the cpack stuff we talked 
> about before the holidays ;-)

Excellent, I was just about to ask you if that was still planned or not...
:-)

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

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


Re: [osg-users] Warnings in VS

2009-01-07 Thread Jean-Sébastien Guay

Hello Mattias,


Makes it kind of hard to test. Sorry about that. Trying again before
submitting the file to osg-submissions.


Got the file, thanks. (third time's a charm right? ;-) )

I'll try it out tomorrow.


i didn't either at first. I was really trying to get my head around
the internal cache variables involved and things didn't behave as
expected. I have now tested this on linux with cmake-2.6.3-RCx and
there this problem doesn't exist. Btw I'm currently using
msvc90Express on Vista 32-bit and cmake-2.6.2.


I'm on msvc8 but the rest is the same for me. It would be surprising if 
it was Linux itself that fixed the problem, so it must be 
cmake-2.6.3-RCx... I'll try downloading RC5 from 
http://www.cmake.org/files/v2.6/ and see.



Cool. And I'm working on a submission for the cpack stuff we talked
about before the holidays ;-)


Excellent, I was just about to ask you if that was still planned or 
not... :-)


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] Warnings in VS

2009-01-07 Thread Mattias Helsing
Hi again,

yes I forgot again. I'm terrible at this.

Mattias

On Wed, Jan 7, 2009 at 10:09 PM, Mattias Helsing  wrote:
> Hi J-S,
>
> On Wed, Jan 7, 2009 at 2:57 PM, Jean-Sébastien Guay
>  wrote:
>> Hello Mattias,
>>
>>
>> I'd like to test, but it seems you forgot to attach the file?
>
> Makes it kind of hard to test. Sorry about that. Trying again before
> submitting the file to osg-submissions.
>
>>
>>> I stumbled upon another problem with the aggresive warnings. I needed
>>> to configure twice before a changed aggresive setting would take
>>> effect because the changes to CMAKE_CXX_FLAGS are made after source is
>>> processed. Have you seen this?
>>> Actually this should be seen on any platform. Have people on other
>>> platforms seen it?
>>
>> I didn't see this specifically, but didn't try either. I just changed the
>> value, generated the project files and noticed that the actual compiler
>> flags hadn't changed. I didn't think to click "configure" twice.
>
> i didn't either at first. I was really trying to get my head around
> the internal cache variables involved and things didn't behave as
> expected. I have now tested this on linux with cmake-2.6.3-RCx and
> there this problem doesn't exist. Btw I'm currently using
> msvc90Express on Vista 32-bit and cmake-2.6.2.
>
>>
>> I'll investigate.
>
> Cool. And I'm working on a submission for the cpack stuff we talked
> about before the holidays ;-)
>
> cheers
> Mattias
>
>>
>> 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
>>
>
IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)

if(COMMAND cmake_policy)
# Works around warnings libraries linked against that don't
# have absolute paths (e.g. -lpthreads)
cmake_policy(SET CMP0003 NEW)

# Works around warnings about escaped quotes in ADD_DEFINITIONS
# statements.
cmake_policy(SET CMP0005 NEW)

# cmake-2.6.1 introduces policy cmp0008 decide how to treat full path 
libraries that do not appear to be valid library file names
# quote from cvslog "Such libraries worked by accident in the VS IDE and 
Xcode generators in CMake 2.4 and below."
if(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4 AND 
${CMAKE_PATCH_VERSION} GREATER 0)
cmake_policy(SET CMP0008 OLD)
endif(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4 
AND ${CMAKE_PATCH_VERSION} GREATER 0)
endif(COMMAND cmake_policy)

PROJECT(OpenSceneGraph)

SET(OPENSCENEGRAPH_MAJOR_VERSION 2)
SET(OPENSCENEGRAPH_MINOR_VERSION 7)
SET(OPENSCENEGRAPH_PATCH_VERSION 8)
SET(OPENSCENEGRAPH_SOVERSION 53)

# set to 0 when not a release candidate, non zero means that any generated 
# svn tags will be treated as release candidates of given number
SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 0)

SET(OPENSCENEGRAPH_VERSION 
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})

SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})

SET(OSG_PLUGIN_PREFIX "")

IF (CYGWIN)
SET(OSG_PLUGIN_PREFIX "cygwin_")
ENDIF(CYGWIN)

IF(MINGW)
SET(OSG_PLUGIN_PREFIX "mingw_")
ENDIF(MINGW)


# We want to build SONAMES shared librariess
SET(OPENSCENEGRAPH_SONAMES TRUE)
SET(OPENTHREADS_SONAMES TRUE)

SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR})

# We have some custom .cmake scripts not in the official distribution.
# Maybe this can be used override existing behavior if needed?
SET(CMAKE_MODULE_PATH 
"${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH}")


# Okay, here's the problem: On some platforms, linking against OpenThreads
# is not enough and explicit linking to the underlying thread library
# is also required (e.g. FreeBSD). But OpenThreads may be built with different
# backends (Pthreads, Sproc, Windows) so we don't know what the underlying
# thread library is because some platforms support multiple backends (e.g.
# IRIX supports Sproc and Pthreads). Linking all libraries won't work
# because the libraries may be incompatible.
# So the current solution is to attempt best guess linking and exempt certain
# cases. With IRIX, we're going to hope explicit linking to the underlying
# library is not necessary. We currently don't case for pthreads on Windows
# which might be an issue on things like Cygwin. This may need to be fixed.
FIND_PACKAGE(Threads)
IF(CMAKE_SYSTEM MATCHES IRIX)
# Erase CMAKE_THREAD_LIBS_INIT and hope it works
SET(CMAKE_THREAD_LIBS_INIT "" CACHE IN

Re: [osg-users] Warnings in VS

2009-01-07 Thread Mattias Helsing
Hi J-S,

On Wed, Jan 7, 2009 at 2:57 PM, Jean-Sébastien Guay
 wrote:
> Hello Mattias,
>
>
> I'd like to test, but it seems you forgot to attach the file?

Makes it kind of hard to test. Sorry about that. Trying again before
submitting the file to osg-submissions.

>
>> I stumbled upon another problem with the aggresive warnings. I needed
>> to configure twice before a changed aggresive setting would take
>> effect because the changes to CMAKE_CXX_FLAGS are made after source is
>> processed. Have you seen this?
>> Actually this should be seen on any platform. Have people on other
>> platforms seen it?
>
> I didn't see this specifically, but didn't try either. I just changed the
> value, generated the project files and noticed that the actual compiler
> flags hadn't changed. I didn't think to click "configure" twice.

i didn't either at first. I was really trying to get my head around
the internal cache variables involved and things didn't behave as
expected. I have now tested this on linux with cmake-2.6.3-RCx and
there this problem doesn't exist. Btw I'm currently using
msvc90Express on Vista 32-bit and cmake-2.6.2.

>
> I'll investigate.

Cool. And I'm working on a submission for the cpack stuff we talked
about before the holidays ;-)

cheers
Mattias

>
> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Problem with pointlightmanip.exe example?

2009-01-07 Thread Cory Riddell

Cory Riddell wrote:
I've been running the pointlightmanip.exe example and as soon as I 
rotate even a tiny amount (using either the hand or the wheels), the 
top right sphere disappears. I've attached a screenshot but I suspect 
that will get filtered out by the list software.


Is this an instance of http://www.vis-sim.com/osg/osg_faq_1.htm#f22 ?
I'm seeing similar behavior with the plasmafun.exe sample as well. A 
section out of the torus is missing (or rather, it's there but flashes 
constantly).


Any idea what this might be?

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


Re: [osg-users] ANN: osgSWIG/Py available

2009-01-07 Thread Randolph Fritz

All right! The best news, and just in time for my project. :-)

Thanks

Randolph

Hartmut Seichter wrote:

Dear OSG Community,

first of all a late Happy New Year! The osgSWIG team is happy to announce osgSWIG/Py 0.9.1 for Python 2.6 which corresponds to the OpenSceneGraph 2.6.1 version. There is an installer for Win32/Python 2.6 or if you feel funky you can try to compile osgSWIG/Py straight from the source. 


Please note that on Windows we can only support you with Python 2.6 - hence 
build with Visual Studio 2008. And another note, we decided to only support 
stable releases, like 2.6.x or the upcoming 2.8.x releases as the maintenance 
of the interface files becomes more problematic. Be assured we are looking into 
some alternative ways to generate them :)

For those users looking for an update of the version including osgART (http://www.osgart.org) - please be patient, we are working on the release of osgART 2.x and would like to keep things in sync - there will be an update but not right now. 


Please give the installer a spin - let us know of your problems in the issue 
tracker.

Now, head over to http://code.google.com/p/osgswig/

Cheers,
Hartmut

--
Dr Hartmut Seichter, Post-Doctoral Research Fellow, Human Interface Technology 
Laboratory New Zealand


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



--
Randolph Fritz
 design machine group
 architecture department
 university of washington
rfr...@u.washington.edu

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


Re: [osg-users] atomic_xor_uint_nv on Solaris

2009-01-07 Thread Andy Skinner
I've not heard from Blasius Czink yet, but I have found out that there is a 
/usr/include/sys/atomic.h that declares things like atomic_or_uint_nv(), but 
does not declare atomic_xor_uint_nv().  Maybe the xor operation could be 
removed instead of the whole thing.  I can't find any reference to xor in the 
header file.

andy

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday, January 07, 2009 9:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris

Hi Andy,

I don't have a Sun box or up to date knowledge to be about to
suggestion resolution of this problem, save for reverting the addition
of this code.  The code was part of the submission below from Blasius
Czink, perhaps we just remove the elements that are problematic - the
OSG itself doesn't use the "and", "or" and "xor" features.

Robert.

--

r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37
lines

>From Blasius Czink, "Among other things I added support for atomic
operations on BSD-like systems and additional methods (for "and",
"or", "xor").
"

and a later post the same osg-submissions thread:

"it's been a while since I have made the changes but I think it was
due to problems with static builds of OpenThreads on windows. I was
using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the
CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to
OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a
"__declspec(dllexport)" or "__declspec(dllimport)" which is a problem
for static builds."

And another post from Blasius on this topic:

"I tested with VS2005 and VS2008. For 32 bit everything works as
expected. For x64 and VS2008 I could successfully do the
cmake-configure and then the compilation but I had occasional crashes
of cmTryCompileExec.exe (during the cmake-configure phase) which seems
to be a cmake bug. With VS2005 and 64bit cmake does not set
_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked
functionality should be there. If I place the source snippet from the
CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and
run the resulting executable successfully. Forcing
OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug
in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.

In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))

should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64
volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64
volatile *a, __int64 b))

The worst thing that can happen is that interlocked funtionality is
not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I
attached a corrected version.



Why is the OT_LIBRARY_STATIC added to the config file? It is not
needed anywhere.

OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows.
See my previous post on that.
"
___
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] Problem with pointlightmanip.exe example?

2009-01-07 Thread Cory Riddell




I've been running the pointlightmanip.exe example and as soon as I
rotate even a tiny amount (using either the hand or the wheels), the
top right sphere disappears. I've attached a screenshot but I suspect
that will get filtered out by the list software.

Is this an instance of http://www.vis-sim.com/osg/osg_faq_1.htm#f22 ?






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


Re: [osg-users] Bug in adding view to compositeViewer aftersettingscene data

2009-01-07 Thread Paul Martz
This issue is resolved with current svn of OSG. Thanks for the quick fix,
Robert!

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz
Sent: Wednesday, January 07, 2009 9:13 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Bug in adding view to compositeViewer
aftersettingscene data

I also encountered this with one of my own test programs. I got around it by
swapping the lines of code. I'll back that change out and test the latest.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday, January 07, 2009 7:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Bug in adding view to compositeViewer after
settingscene data

Hi Alexandre,

I've just fixed the problem and checked it in.  Could you try out the svn
version of the OSG.

Thanks,
Robert.

On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric 
wrote:
> Hi Robert,
>
> here is the modified example.
>
> 2009/1/7 Robert Osfield 
>>
>> HI Alexandre,
>>
>> Could you post the modified example in the form that reproduces the
crash.
>>
>> Thanks,
>> Robert.
>>
>> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric 
>> 
>> wrote:
>> > Hi osg-users and Happy New Year to all of you :-)
>> >
>> > I recently downloaded OSG 2.7.8 to link with my application (wich 
>> > was linked before with OSG 2.7.4) and I discovered a bug wich can 
>> > be easily produced by modifying osgcompositeviewer.cpp in Examples 
>> > osgcompositeviewer.
>> >
>> > At line 236 :
>> >
>> > osgViewer::View* view = new osgViewer::View; viewer.addView(view);
>> >
>> > view->setSceneData(scene.get());
>> >
>> > replace by swapping 2 lines (setting scene data before adding new
>> > view)
>> > :
>> >
>> > osgViewer::View* view = new osgViewer::View;
>> >
>> > view->setSceneData(scene.get());
>> > viewer.addView(view);
>> >
>> > Be sure to run the example to call this code section...
>> >
>> > It crashes in osgViewer::View::setSceneData when calling
>> >
>> > getViewerBase()->getThreadingModel()
>> >
>> > because viewerbase is NULL
>> >
>> > With older version 2.7.4 it works, apparently not with new 2.7.8.
>> >
>> > I need my application to stay the same, setting data scene before 
>> > adding new view to the composite viewer, if you have any tips to do 
>> > this let me hear.
>> >
>> > --
>> > Alexandre AMALRIC   Ingénieur R&D
>> > ===
>> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille 
>> > http://www.pixxim.fr
>> >
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegra
>> > ph.org
>> >
>> >
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph
>> .org
>
>
>
> --
> Alexandre AMALRIC   Ingénieur R&D
> ===
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille 
> http://www.pixxim.fr
>
> ___
> 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Head mounted display for OSG...

2009-01-07 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Can anyone give me an update on the maturity of the head mounted display
support in OSG? Is it a work in progress? What is its capability? Any input
or details would be appreciated.

 

Also does anyone have a particular recommendation for a Head-mounted display
brand or hardware that works well with OSG?

 

Thanks,

-Shayne



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Warning level

2009-01-07 Thread Robert Osfield
Hi Matthew,

On Wed, Jan 7, 2009 at 4:36 PM, Matthew Fuesz  wrote:
> Blanket-supression of C4706 isn't really a good thing, since as you pointed 
> out, it can actually point out an error (usually a typo by the developer). 
> C4706 will not be generated if it is made explicitly clear what the intent of 
> the conditional is.
>
> i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 
> )". This is covered in the MSDN page on C4706.
>
> I actually prefer the latter syntax (which doesn't generate C4706) anyway, 
> since it eliminates any possible confusion as to the intended operations.

All the instances if assignment in condtionaly already have a () added
around the conditional to avoid the warning under gcc, I had hoped
that this would be the end of it... but no...

Personally I've got others things to chase up right now that are more
important than adding more superfluous code to the OSG to fix silly
warnings that have no relevance to fixing bugs in the OSG.  Feel free
to dive in if you feel so inclined, otherwise I'll be happy to stick
with the surpression of this warning under VS.

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


Re: [osg-users] [osg-submissions] Support for draw_instanced

2009-01-07 Thread Robert Osfield
Hi Paul and Lionel,

In the implementation that I went for in osg::State for the required
calls glDraw*Instanced*() calls I used a query for glDraw*Instanced
and glDraw*InstancedEXT.  glDraw*Instanced doesn't exist yet but the
code will pick up on it when it comes along.  We could add a check for
glDraw*InstancedARB into the mix as well.

There isn't presently any extension checking beyond the query for the
function pointers.

Robert.

On Wed, Jan 7, 2009 at 4:24 PM, Paul Martz  wrote:
> Draw_instanced was promoted to an ARB extension in the OpenGL 3.0 timeframe
> (last August), and I found it was only available as ARB in NVIDIA's beta
> OpenGL 3.0 drivers. Rather than require OSG users to upgrade to beta drivers
> to access this functionality, I opted to use the EXT version.
>
> Using EXT also simplifies the vertex shader. To use the ARB extension, I
> would've been forced to use GLSL 1.3, which removes all the predefined
> uniforms. It's a whole new world of shader development, and one I wasn't
> quite ready to dive into given the non-existent funding for this feature.
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> +1 303 859 9466
>
> 
> From: osg-submissions-boun...@lists.openscenegraph.org
> [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of
> Lionel Lagarde
> Sent: Wednesday, January 07, 2009 1:52 AM
> To: OpenSceneGraph Submissions
> Subject: Re: [osg-submissions] Support for draw_instanced
>
> Hi,
>
> Why you use the EXT version of draw_instanced. This extension has an ARB
> version.
>
> Paul Martz wrote:
>
> Hi Robert -- My update and build of OSG went fine, and my draw instanced
> test programs ported to your implementation smoothly. Thanks again for your
> help on this great new feature of OSG.
>
> Hi to all -- Current svn head of OSG now supports EXT_draw_instanced. Check
> out the osgdrawinstanced example, which creates a scene graph consisting of
> a single Geode with a single Geometry with four vertices, but draws several
> hundred quads at different orientations, positions, and colors.
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> +1 303 859 9466
>
>
> -Original Message-
> From: osg-submissions-boun...@lists.openscenegraph.org
> [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of
> Robert Osfield
> Sent: Tuesday, January 06, 2009 9:14 AM
> To: OpenSceneGraph Submissions
> Subject: Re: [osg-submissions] Support for draw_instanced
>
> Hi Paul,
>
> On Tue, Jan 6, 2009 at 4:06 PM, Paul Martz  wrote:
>
>
> Especially thanks for placing the extension support check in State. I
> disliked having it in the draw() method, but wasn't sure where it should
>
>
> go.
>
> Extension checking/function call set up is both a strong and a weak point in
> the OSG, there are motivations for centralising extension setup and
> motivations for keeping them local to classes - so the OSG has ended up
> doing both in different places, sometimes for good reasons, sometime for the
> wrong reasons...  It'd be nice to have a simpler and more manageable scheme
> that avoids the issues of being pulled in different directions.  OpenGL ES
> and OpenGL 3.x into the mix will further complicate things unless we do come
> up with a new scheme...
>
>
>
> I'm updating and building now. I'll let you know if I find any issues.
>
>
> Thanks,
> Robert.
> ___
> osg-submissions mailing list
> osg-submissi...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.
> org
>
> ___
> osg-submissions mailing list
> osg-submissi...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
> __ Information provenant d'ESET NOD32 Antivirus, version de la base
> des signatures de virus 3745 (20090107) __
>
> Le message a été vérifié par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>
>
> ___
> 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] Warning level

2009-01-07 Thread Matthew Fuesz

Skylark (J-S) wrote:
> 
> I'm fine with suppressing C4706 as it's true that it's a warning that 
> only tells you that you *might* be doing something unsafe... Whether 
> it's actually safe or not is totally context-dependent.
> 


Blanket-supression of C4706 isn't really a good thing, since as you pointed 
out, it can actually point out an error (usually a typo by the developer). 
C4706 will not be generated if it is made explicitly clear what the intent of 
the conditional is.

i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 )". 
This is covered in the MSDN page on C4706.

I actually prefer the latter syntax (which doesn't generate C4706) anyway, 
since it eliminates any possible confusion as to the intended operations.


Matthew W Fuesz
Software Engineer Asc
Lockheed Martin STS

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4253#4253





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


Re: [osg-users] [osg-submissions] Support for draw_instanced

2009-01-07 Thread Paul Martz
Draw_instanced was promoted to an ARB extension in the OpenGL 3.0 timeframe
(last August), and I found it was only available as ARB in NVIDIA's beta
OpenGL 3.0 drivers. Rather than require OSG users to upgrade to beta drivers
to access this functionality, I opted to use the EXT version.
 
Using EXT also simplifies the vertex shader. To use the ARB extension, I
would've been forced to use GLSL 1.3, which removes all the predefined
uniforms. It's a whole new world of shader development, and one I wasn't
quite ready to dive into given the non-existent funding for this feature.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com <http://www.skew-matrix.com/> 
+1 303 859 9466
 

  _  

From: osg-submissions-boun...@lists.openscenegraph.org
[mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of
Lionel Lagarde
Sent: Wednesday, January 07, 2009 1:52 AM
To: OpenSceneGraph Submissions
Subject: Re: [osg-submissions] Support for draw_instanced


Hi, 

Why you use the EXT version of draw_instanced. This extension has an ARB
version.

Paul Martz wrote: 

Hi Robert -- My update and build of OSG went fine, and my draw instanced

test programs ported to your implementation smoothly. Thanks again for your

help on this great new feature of OSG.



Hi to all -- Current svn head of OSG now supports EXT_draw_instanced. Check

out the osgdrawinstanced example, which creates a scene graph consisting of

a single Geode with a single Geometry with four vertices, but draws several

hundred quads at different orientations, positions, and colors.



Paul Martz

Skew Matrix Software LLC

http://www.skew-matrix.com

+1 303 859 9466





-Original Message-

From: osg-submissions-boun...@lists.openscenegraph.org

[mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of

Robert Osfield

Sent: Tuesday, January 06, 2009 9:14 AM

To: OpenSceneGraph Submissions

Subject: Re: [osg-submissions] Support for draw_instanced



Hi Paul,



On Tue, Jan 6, 2009 at 4:06 PM, Paul Martz  <mailto:pma...@skew-matrix.com>
 wrote:

  

Especially thanks for placing the extension support check in State. I 

disliked having it in the draw() method, but wasn't sure where it should



go.



Extension checking/function call set up is both a strong and a weak point in

the OSG, there are motivations for centralising extension setup and

motivations for keeping them local to classes - so the OSG has ended up

doing both in different places, sometimes for good reasons, sometime for the

wrong reasons...  It'd be nice to have a simpler and more manageable scheme

that avoids the issues of being pulled in different directions.  OpenGL ES

and OpenGL 3.x into the mix will further complicate things unless we do come

up with a new scheme...



  

I'm updating and building now. I'll let you know if I find any issues.





Thanks,

Robert.

___

osg-submissions mailing list

osg-submissi...@lists.openscenegraph.org

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

org



___

osg-submissions mailing list

osg-submissi...@lists.openscenegraph.org

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



__ Information provenant d'ESET NOD32 Antivirus, version de la base
des signatures de virus 3745 (20090107) __



Le message a été vérifié par ESET NOD32 Antivirus.



http://www.eset.com









  

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


Re: [osg-users] Warning level

2009-01-07 Thread Robert Osfield
Hi Paul,

On Wed, Jan 7, 2009 at 4:08 PM, Paul Martz  wrote:
> If I understand correctly from this discussion, the intended usage is that
> developers will leave OSG_USE_AGGRESSIVE_WARNINGS set to the default ON, and
> we'll then tackle any warnings on a case by case basis, is that correct?

If we can leave the aggressive warnings on then I think this will be
better, but we can only leave it on if the vast majority of the build
is clean from warnings, spurious or not.  I think the way to tackle
this is to fix what warnings are practical and sensible to fix, and
then disable the spurious ones.

If we can't easily get a build clean from warnings on the major
platforms then we'll need to disable the aggressive warnings by
default on all platforms.  I'd rather strive for a bit longer before
falling back to this position.

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


Re: [osg-users] Bug in adding view to compositeViewer after settingscene data

2009-01-07 Thread Paul Martz
I also encountered this with one of my own test programs. I got around it by
swapping the lines of code. I'll back that change out and test the latest.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday, January 07, 2009 7:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Bug in adding view to compositeViewer after
settingscene data

Hi Alexandre,

I've just fixed the problem and checked it in.  Could you try out the svn
version of the OSG.

Thanks,
Robert.

On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric 
wrote:
> Hi Robert,
>
> here is the modified example.
>
> 2009/1/7 Robert Osfield 
>>
>> HI Alexandre,
>>
>> Could you post the modified example in the form that reproduces the
crash.
>>
>> Thanks,
>> Robert.
>>
>> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric 
>> 
>> wrote:
>> > Hi osg-users and Happy New Year to all of you :-)
>> >
>> > I recently downloaded OSG 2.7.8 to link with my application (wich 
>> > was linked before with OSG 2.7.4) and I discovered a bug wich can 
>> > be easily produced by modifying osgcompositeviewer.cpp in Examples 
>> > osgcompositeviewer.
>> >
>> > At line 236 :
>> >
>> > osgViewer::View* view = new osgViewer::View; viewer.addView(view);
>> >
>> > view->setSceneData(scene.get());
>> >
>> > replace by swapping 2 lines (setting scene data before adding new 
>> > view)
>> > :
>> >
>> > osgViewer::View* view = new osgViewer::View;
>> >
>> > view->setSceneData(scene.get());
>> > viewer.addView(view);
>> >
>> > Be sure to run the example to call this code section...
>> >
>> > It crashes in osgViewer::View::setSceneData when calling
>> >
>> > getViewerBase()->getThreadingModel()
>> >
>> > because viewerbase is NULL
>> >
>> > With older version 2.7.4 it works, apparently not with new 2.7.8.
>> >
>> > I need my application to stay the same, setting data scene before 
>> > adding new view to the composite viewer, if you have any tips to do 
>> > this let me hear.
>> >
>> > --
>> > Alexandre AMALRIC   Ingénieur R&D
>> > ===
>> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille 
>> > http://www.pixxim.fr
>> >
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegra
>> > ph.org
>> >
>> >
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph
>> .org
>
>
>
> --
> Alexandre AMALRIC   Ingénieur R&D
> ===
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille 
> http://www.pixxim.fr
>
> ___
> 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] Warning level

2009-01-07 Thread Paul Martz
If I understand correctly from this discussion, the intended usage is that
developers will leave OSG_USE_AGGRESSIVE_WARNINGS set to the default ON, and
we'll then tackle any warnings on a case by case basis, is that correct?

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday, January 07, 2009 8:30 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Warning level

Hi Jean,

On Wed, Jan 7, 2009 at 3:13 PM, Jean-Sébastien Guay
 wrote:
> I just did an update and it doesn't seem you fixed the "warning C4512:
> 'classname' : assignment operator could not be generated" warning? 
> That's the most frequent... I'd like to see it fixed or suppressed if 
> you don't feel like adding a dummy assignment operator...

I might not have caught all instances, but I did implement a bucket load of
dummy assignment operators. A quick review of the change to to NodeAcceptOp
in include/osg/NodeVisitor shows that I got the parameter type wrong
though... now fixed and checked in.  Hopefully my other changes were a bit
more reliable...

> I'm fine with suppressing C4706 as it's true that it's a warning that 
> only tells you that you *might* be doing something unsafe... Whether 
> it's actually safe or not is totally context-dependent.

I've just checked in suppression of this warning.  Should clearly some of
the blizzard of misleading warnings.

> As for the other warnings, I can have a look at their descriptions and 
> see, but that might be more your alley since it requires a judgement 
> call. As I mentioned, just use  site:microsoft.com to 
> look up the documentation on a warning type.
>
> 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
>
___
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] overriding keyboard events in osgViewer::View...

2009-01-07 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Thank you Robert. That helps a lot...:)

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday, January 07, 2009 4:55 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] overriding keyboard events in osgViewer::View...

Hi Shayne,

There are no default event handlers in osgViewer save for the escape
sets done facility that you can turn off via
viewer.setKeyEventSetsDone(0);

>From your email it looks like you must be manually adding the
osgGA::StateSetManipulator, and if you still want this functionality
but want to customize the keys ysed just use the its setKeyEvent*()
methods:

void setKeyEventToggleBackfaceCulling(int key) {
_keyEventToggleBackfaceCulling = key; }

void setKeyEventToggleLighting(int key) {
_keyEventToggleLighting = key; }

void setKeyEventToggleTexturing(int key) {
_keyEventToggleTexturing = key; }

void setKeyEventCyclePolygonMode(int key) {
_keyEventCyclePolygonMode = key; }

Robert.

On Wed, Jan 7, 2009 at 12:25 AM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> This may be a stupid and/or trivial question but here goes.
>
>
>
> Is there a way to override the default keyboard event handlers when using
an
> osgViewer::View class? For example, if I create a viewer and then press
the
> "l" (lowercase L) key, it causes my rendered scene to enable and disable
> lighting. I want a different behavior when I press this key and other
keys.
>
>
>
> Thanks,
>
> -Shayne
>
> ___
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Geometry kernels?

2009-01-07 Thread Cory Riddell
I'm looking for comments and suggestions for using OSG with a geometry 
engine like ACIS, Parasolid, or Open Cascade. Can they work well 
together? Is it a useful combination? The application is CAD-like and 
involves interactively building up a model from discrete components.


I found OSG when looking for HOOPS competitors. Is it fair to compare 
HOOPS with OSG?


Thanks,
Cory


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


Re: [osg-users] Warning level

2009-01-07 Thread Robert Osfield
Hi Jean,

On Wed, Jan 7, 2009 at 3:13 PM, Jean-Sébastien Guay
 wrote:
> I just did an update and it doesn't seem you fixed the "warning C4512:
> 'classname' : assignment operator could not be generated" warning? That's
> the most frequent... I'd like to see it fixed or suppressed if you don't
> feel like adding a dummy assignment operator...

I might not have caught all instances, but I did implement a bucket
load of dummy assignment operators. A quick review of the change to to
NodeAcceptOp in include/osg/NodeVisitor shows that I got the parameter
type wrong though... now fixed and checked in.  Hopefully my other
changes were a bit more reliable...

> I'm fine with suppressing C4706 as it's true that it's a warning that only
> tells you that you *might* be doing something unsafe... Whether it's
> actually safe or not is totally context-dependent.

I've just checked in suppression of this warning.  Should clearly some
of the blizzard of misleading warnings.

> As for the other warnings, I can have a look at their descriptions and see,
> but that might be more your alley since it requires a judgement call. As I
> mentioned, just use  site:microsoft.com to look up the
> documentation on a warning type.
>
> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Warning level

2009-01-07 Thread Jean-Sébastien Guay

Hello Robert,


I've now checked in a number of warning fixes, out of over 1000
warnings that should be removed (mainly repeats) I think just four
were actual bugs fixes, whilst they might be minor bugs it's still
nice to see them caught and hopefully fixed .  The bulk left are
unused parameter and assignment in conditionals.


I just did an update and it doesn't seem you fixed the "warning C4512: 
'classname' : assignment operator could not be generated" warning? 
That's the most frequent... I'd like to see it fixed or suppressed if 
you don't feel like adding a dummy assignment operator...



My though now is to add suppression of C4706 into include/osg/Export
and then review each of the existing suppressed warnings to see if we
can remove ones that no longer effect us.  The warning codes used date
back to VS 6.0 days, and things have moved on a lot in compiler and on
the OSG side to warrant a revist of which warnings get suppressed.


I'm fine with suppressing C4706 as it's true that it's a warning that 
only tells you that you *might* be doing something unsafe... Whether 
it's actually safe or not is totally context-dependent.


As for the other warnings, I can have a look at their descriptions and 
see, but that might be more your alley since it requires a judgement 
call. As I mentioned, just use  site:microsoft.com to 
look up the documentation on a warning type.


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] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Paul Melis

Robert Osfield wrote:

On Wed, Jan 7, 2009 at 2:53 PM, Alexandre Amalric  wrote:
  

It will be a pleasure to check your fix but I'm sorry, I'm not well familiar
with SVN, I know it's not your role to do this but could you please send me
some information on how to do, is there a good tutorial on how works
subversion ?



It really isn't my place to teach people about 3rd party tools, there
are hundreds of websites out there that cover subversion usage, just
bring up a search engine in your browser and go learn about it.
  
I can give you a bit of help if you want. What platform are you working 
on? If Linux, find the subversion package for your distro (usually 
called "subversion" or "svn"). If you're on Windows, go to 
http://tortoisesvn.tigris.org/ and download the latest tortoisesvn and 
install it. Tortoisesvn is an add-on that contains Suversion, and that 
allows you to use it conveniently from Windows Explorer.


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


Re: [osg-users] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Robert Osfield
On Wed, Jan 7, 2009 at 2:53 PM, Alexandre Amalric  wrote:
> It will be a pleasure to check your fix but I'm sorry, I'm not well familiar
> with SVN, I know it's not your role to do this but could you please send me
> some information on how to do, is there a good tutorial on how works
> subversion ?

It really isn't my place to teach people about 3rd party tools, there
are hundreds of websites out there that cover subversion usage, just
bring up a search engine in your browser and go learn about it.

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


Re: [osg-users] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Alexandre Amalric
Hi Robert,

It will be a pleasure to check your fix but I'm sorry, I'm not well familiar
with SVN, I know it's not your role to do this but could you please send me
some information on how to do, is there a good tutorial on how works
subversion ?


2009/1/7 Robert Osfield 

> Hi Alexandre,
>
> I've just fixed the problem and checked it in.  Could you try out the
> svn version of the OSG.
>
> Thanks,
> Robert.
>
> On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric 
> wrote:
> > Hi Robert,
> >
> > here is the modified example.
> >
> > 2009/1/7 Robert Osfield 
> >>
> >> HI Alexandre,
> >>
> >> Could you post the modified example in the form that reproduces the
> crash.
> >>
> >> Thanks,
> >> Robert.
> >>
> >> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric <
> alex.pix...@gmail.com>
> >> wrote:
> >> > Hi osg-users and Happy New Year to all of you :-)
> >> >
> >> > I recently downloaded OSG 2.7.8 to link with my application (wich was
> >> > linked
> >> > before with OSG 2.7.4) and I discovered a bug wich can be easily
> >> > produced by
> >> > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer.
> >> >
> >> > At line 236 :
> >> >
> >> > osgViewer::View* view = new osgViewer::View;
> >> > viewer.addView(view);
> >> >
> >> > view->setSceneData(scene.get());
> >> >
> >> > replace by swapping 2 lines (setting scene data before adding new
> view)
> >> > :
> >> >
> >> > osgViewer::View* view = new osgViewer::View;
> >> >
> >> > view->setSceneData(scene.get());
> >> > viewer.addView(view);
> >> >
> >> > Be sure to run the example to call this code section...
> >> >
> >> > It crashes in osgViewer::View::setSceneData when calling
> >> >
> >> > getViewerBase()->getThreadingModel()
> >> >
> >> > because viewerbase is NULL
> >> >
> >> > With older version 2.7.4 it works, apparently not with new 2.7.8.
> >> >
> >> > I need my application to stay the same, setting data scene before
> adding
> >> > new
> >> > view to the composite viewer, if you have any tips to do this let me
> >> > hear.
> >> >
> >> > --
> >> > Alexandre AMALRIC   Ingénieur R&D
> >> > ===
> >> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> >> > http://www.pixxim.fr
> >> >
> >> > ___
> >> > 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
> >
> >
> >
> > --
> > Alexandre AMALRIC   Ingénieur R&D
> > ===
> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> > http://www.pixxim.fr
> >
> > ___
> > 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
>



-- 
Alexandre AMALRIC   Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Robert Osfield
Hi Alexandre,

I've just fixed the problem and checked it in.  Could you try out the
svn version of the OSG.

Thanks,
Robert.

On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric  wrote:
> Hi Robert,
>
> here is the modified example.
>
> 2009/1/7 Robert Osfield 
>>
>> HI Alexandre,
>>
>> Could you post the modified example in the form that reproduces the crash.
>>
>> Thanks,
>> Robert.
>>
>> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric 
>> wrote:
>> > Hi osg-users and Happy New Year to all of you :-)
>> >
>> > I recently downloaded OSG 2.7.8 to link with my application (wich was
>> > linked
>> > before with OSG 2.7.4) and I discovered a bug wich can be easily
>> > produced by
>> > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer.
>> >
>> > At line 236 :
>> >
>> > osgViewer::View* view = new osgViewer::View;
>> > viewer.addView(view);
>> >
>> > view->setSceneData(scene.get());
>> >
>> > replace by swapping 2 lines (setting scene data before adding new view)
>> > :
>> >
>> > osgViewer::View* view = new osgViewer::View;
>> >
>> > view->setSceneData(scene.get());
>> > viewer.addView(view);
>> >
>> > Be sure to run the example to call this code section...
>> >
>> > It crashes in osgViewer::View::setSceneData when calling
>> >
>> > getViewerBase()->getThreadingModel()
>> >
>> > because viewerbase is NULL
>> >
>> > With older version 2.7.4 it works, apparently not with new 2.7.8.
>> >
>> > I need my application to stay the same, setting data scene before adding
>> > new
>> > view to the composite viewer, if you have any tips to do this let me
>> > hear.
>> >
>> > --
>> > Alexandre AMALRIC   Ingénieur R&D
>> > ===
>> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
>> > http://www.pixxim.fr
>> >
>> > ___
>> > 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
>
>
>
> --
> Alexandre AMALRIC   Ingénieur R&D
> ===
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> http://www.pixxim.fr
>
> ___
> 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] atomic_xor_uint_nv on Solaris

2009-01-07 Thread Andy Skinner
Thanks.  I've sent an email to Blasius (hoping I got the email from Gmane 
correctly), and will see if he has a suggestion.

andy

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday, January 07, 2009 9:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris

Hi Andy,

I don't have a Sun box or up to date knowledge to be about to
suggestion resolution of this problem, save for reverting the addition
of this code.  The code was part of the submission below from Blasius
Czink, perhaps we just remove the elements that are problematic - the
OSG itself doesn't use the "and", "or" and "xor" features.

Robert.

--

r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37
lines

>From Blasius Czink, "Among other things I added support for atomic
operations on BSD-like systems and additional methods (for "and",
"or", "xor").
"

and a later post the same osg-submissions thread:

"it's been a while since I have made the changes but I think it was
due to problems with static builds of OpenThreads on windows. I was
using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the
CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to
OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a
"__declspec(dllexport)" or "__declspec(dllimport)" which is a problem
for static builds."

And another post from Blasius on this topic:

"I tested with VS2005 and VS2008. For 32 bit everything works as
expected. For x64 and VS2008 I could successfully do the
cmake-configure and then the compilation but I had occasional crashes
of cmTryCompileExec.exe (during the cmake-configure phase) which seems
to be a cmake bug. With VS2005 and 64bit cmake does not set
_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked
functionality should be there. If I place the source snippet from the
CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and
run the resulting executable successfully. Forcing
OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug
in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.

In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))

should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64
volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64
volatile *a, __int64 b))

The worst thing that can happen is that interlocked funtionality is
not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I
attached a corrected version.



Why is the OT_LIBRARY_STATIC added to the config file? It is not
needed anywhere.

OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows.
See my previous post on that.
"
___
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] Is it necessary a while cycle to remove a child?

2009-01-07 Thread Jean-Sébastien Guay

Hello Francesco,


2)If i use a while that cycle until the removal is not possible it
remove the child correctly.


This suggests that the child has simply been added multiple times to the 
same parent.


Just break at that location in the debugger and examine the parent's 
children vector, and see if the same address (i.e. child) is there 
multiple times.


Then examine your addition code to make sure you're only adding it once 
if that's what you expect. Perhaps add a test to check if the parent 
already has the child in its children before adding it...


OSG won't add children by itself. So if you need to use a while loop to 
remove a child which you *think* was only added once to the parent, that 
means you didn't just add it once...


Hope this helps,

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] Why the wave simulation so inefficiency?

2009-01-07 Thread Jean-Sébastien Guay

Hello flying5?

(2) Then, I realize it use OSG. But when I render 128*128*2 = 32768 
triangles grid and the FPS is only 13!!!.
(3) I don't think there is any difference between the two way I 
realize the wave. But why the great disparity in efficiency?


There must be a difference, or else the performance would be identical. 
As a first step to investigation, what are you using for your grids? 
osg::Geometry using VBOs would be the most efficient path.


Make sure you're at least disabling display lists on your osg::Geometry 
objects, then you'll be using Vertex Buffers which on dynamic geometry 
will gain a few orders of magnitude of performance, since OSG won't have 
to recompile display lists every frame. Then investigate using VBOs 
which will be the next step, search the mailing list archives for how to 
use those.


Hope this helps,

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] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Alexandre Amalric
Hi Robert,

here is the modified example.

2009/1/7 Robert Osfield 

> HI Alexandre,
>
> Could you post the modified example in the form that reproduces the crash.
>
> Thanks,
> Robert.
>
> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric 
> wrote:
> > Hi osg-users and Happy New Year to all of you :-)
> >
> > I recently downloaded OSG 2.7.8 to link with my application (wich was
> linked
> > before with OSG 2.7.4) and I discovered a bug wich can be easily produced
> by
> > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer.
> >
> > At line 236 :
> >
> > osgViewer::View* view = new osgViewer::View;
> > viewer.addView(view);
> >
> > view->setSceneData(scene.get());
> >
> > replace by swapping 2 lines (setting scene data before adding new view) :
> >
> > osgViewer::View* view = new osgViewer::View;
> >
> > view->setSceneData(scene.get());
> > viewer.addView(view);
> >
> > Be sure to run the example to call this code section...
> >
> > It crashes in osgViewer::View::setSceneData when calling
> >
> > getViewerBase()->getThreadingModel()
> >
> > because viewerbase is NULL
> >
> > With older version 2.7.4 it works, apparently not with new 2.7.8.
> >
> > I need my application to stay the same, setting data scene before adding
> new
> > view to the composite viewer, if you have any tips to do this let me
> hear.
> >
> > --
> > Alexandre AMALRIC   Ingénieur R&D
> > ===
> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> > http://www.pixxim.fr
> >
> > ___
> > 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
>



-- 
Alexandre AMALRIC   Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
/* OpenSceneGraph example, osgcompositeviewer.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 
#include 

#include 

#include 

#include 

// class to handle events with a pick
class PickHandler : public osgGA::GUIEventHandler {
public: 

PickHandler():
_mx(0.0f),
_my(0.0f) {}

~PickHandler() {}

bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa)
{
osgViewer::View* view = dynamic_cast(&aa);
if (!view) return false;

switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
_mx = ea.getX();
_my = ea.getY();
break;
}
case(osgGA::GUIEventAdapter::RELEASE):
{
if (_mx==ea.getX() && _my==ea.getY())
{
pick(view, ea.getX(), ea.getY());
}
break;
}
default:
break;
}
return false;
}

void pick(osgViewer::View* view, float x, float y)
{
osg::Node* node = 0;
osg::Group* parent = 0;

osgUtil::LineSegmentIntersector::Intersections intersections;
if (view->computeIntersections(x, y, intersections))
{
osgUtil::LineSegmentIntersector::Intersection intersection = 
*intersections.begin();
osg::NodePath& nodePath = intersection.nodePath;
node = (nodePath.size()>=1)?nodePath[nodePath.size()-1]:0;
parent = 
(nodePath.size()>=2)?dynamic_cast(nodePath[nodePath.size()-2]):0;
}

// now we try to decorate the hit node by the osgFX::Scribe to show 
that its been "picked"
if (parent && node)
{

osgFX::Scribe* parentAsScribe = 
dynamic_cast(parent);
 

Re: [osg-users] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Robert Osfield
HI Alexandre,

Could you post the modified example in the form that reproduces the crash.

Thanks,
Robert.

On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric  wrote:
> Hi osg-users and Happy New Year to all of you :-)
>
> I recently downloaded OSG 2.7.8 to link with my application (wich was linked
> before with OSG 2.7.4) and I discovered a bug wich can be easily produced by
> modifying osgcompositeviewer.cpp in Examples osgcompositeviewer.
>
> At line 236 :
>
> osgViewer::View* view = new osgViewer::View;
> viewer.addView(view);
>
> view->setSceneData(scene.get());
>
> replace by swapping 2 lines (setting scene data before adding new view) :
>
> osgViewer::View* view = new osgViewer::View;
>
> view->setSceneData(scene.get());
> viewer.addView(view);
>
> Be sure to run the example to call this code section...
>
> It crashes in osgViewer::View::setSceneData when calling
>
> getViewerBase()->getThreadingModel()
>
> because viewerbase is NULL
>
> With older version 2.7.4 it works, apparently not with new 2.7.8.
>
> I need my application to stay the same, setting data scene before adding new
> view to the composite viewer, if you have any tips to do this let me hear.
>
> --
> Alexandre AMALRIC   Ingénieur R&D
> ===
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> http://www.pixxim.fr
>
> ___
> 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] atomic_xor_uint_nv on Solaris

2009-01-07 Thread Robert Osfield
Hi Andy,

I don't have a Sun box or up to date knowledge to be about to
suggestion resolution of this problem, save for reverting the addition
of this code.  The code was part of the submission below from Blasius
Czink, perhaps we just remove the elements that are problematic - the
OSG itself doesn't use the "and", "or" and "xor" features.

Robert.

--

r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37
lines

>From Blasius Czink, "Among other things I added support for atomic
operations on BSD-like systems and additional methods (for "and",
"or", "xor").
"

and a later post the same osg-submissions thread:

"it's been a while since I have made the changes but I think it was
due to problems with static builds of OpenThreads on windows. I was
using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the
CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to
OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a
"__declspec(dllexport)" or "__declspec(dllimport)" which is a problem
for static builds."

And another post from Blasius on this topic:

"I tested with VS2005 and VS2008. For 32 bit everything works as
expected. For x64 and VS2008 I could successfully do the
cmake-configure and then the compilation but I had occasional crashes
of cmTryCompileExec.exe (during the cmake-configure phase) which seems
to be a cmake bug. With VS2005 and 64bit cmake does not set
_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked
functionality should be there. If I place the source snippet from the
CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and
run the resulting executable successfully. Forcing
OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug
in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.

In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))

should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64
volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64
volatile *a, __int64 b))

The worst thing that can happen is that interlocked funtionality is
not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I
attached a corrected version.



Why is the OT_LIBRARY_STATIC added to the config file? It is not
needed anywhere.

OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows.
See my previous post on that.
"
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Warnings in VS

2009-01-07 Thread Jean-Sébastien Guay

Hello Mattias,


I had a look at this. I suspect this was caused by the INTERNALly
cached OLD_CMAKE:CXX_FLAGS. I'm not sure I had your setup but made
some changes and at the same time removed a "fixme". I have attached
my current CMakeLists.txt. If you have the time please test, though I
guess your setups are fixed by now.


I'd like to test, but it seems you forgot to attach the file?


I stumbled upon another problem with the aggresive warnings. I needed
to configure twice before a changed aggresive setting would take
effect because the changes to CMAKE_CXX_FLAGS are made after source is
processed. Have you seen this?
Actually this should be seen on any platform. Have people on other
platforms seen it?


I didn't see this specifically, but didn't try either. I just changed 
the value, generated the project files and noticed that the actual 
compiler flags hadn't changed. I didn't think to click "configure" twice.


I'll investigate.

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

2009-01-07 Thread Robert Osfield
Hi JS et. al.,

I've now checked in a number of warning fixes, out of over 1000
warnings that should be removed (mainly repeats) I think just four
were actual bugs fixes, whilst they might be minor bugs it's still
nice to see them caught and hopefully fixed .  The bulk left are
unused parameter and assignment in conditionals.

I've reviewed almost all the assignment in conditional warnings and
all look perfectly correct code, fixing the code to not use an
assignment in an if() statement would lead to more code, so rather
award scoping and more opportunities to introducing bugs.  I really
detest it when warnings appear on valid C/C++ code that has no
ambiguity in it, this one boils down to prohibiting use of a
particular feature of the language because some careless programmers
might misuse it, but in the process screwing up things for programmers
who actually know what they are doing.  For these stopid warning cases
I think the right thing to do is just disable them as they cause more
harm than good.  The warning number is C4706.

The unused parameter warnings are for typically benign non usage of
parameters that won't affect anything, but are easily fixable by /*
commenting out */ the variable name or just deleting it.  Sometime the
variable name implies so extra information so is useful to keep in.

My though now is to add suppression of C4706 into include/osg/Export
and then review each of the existing suppressed warnings to see if we
can remove ones that no longer effect us.  The warning codes used date
back to VS 6.0 days, and things have moved on a lot in compiler and on
the OSG side to warrant a revist of which warnings get suppressed.

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


[osg-users] Bug in adding view to compositeViewer after setting scene data

2009-01-07 Thread Alexandre Amalric
Hi osg-users and Happy New Year to all of you :-)

I recently downloaded OSG 2.7.8 to link with my application (wich was linked
before with OSG 2.7.4) and I discovered a bug wich can be easily produced by

modifying osgcompositeviewer.cpp in Examples osgcompositeviewer.

*At line 236 :*

osgViewer::View* view = new osgViewer::View;
viewer.addView(view);

view->setSceneData(scene.get());

*replace by swapping 2 lines (setting scene data before adding new view) :*

osgViewer::View* view = new osgViewer::View;

view->setSceneData(scene.get());
viewer.addView(view);

*Be sure to run the example to call this code section...*

It crashes in osgViewer::View::setSceneData when calling

getViewerBase()->getThreadingModel()

because viewerbase is NULL

With older version 2.7.4 it works, apparently not with new 2.7.8.

I need my application to stay the same, setting data scene before adding new
view to the composite viewer, if you have any tips to do this let me hear.

-- 
Alexandre AMALRIC   Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] atomic_xor_uint_nv on Solaris

2009-01-07 Thread Andy Skinner
A const cast does remove the second error (and atomic_cas_ptr does seem like it 
could have used a const argument, since this is the comparison arg, which 
shouldn't be changed).

I still haven't gotten rid of the atomic_xor_uint_nv issue, though, so I can't 
build the OpenSceneGraph on all our platforms.  The code looks like: 

_OPENTHREADS_ATOMIC_INLINE unsigned
Atomic::XOR(unsigned value)
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
return __sync_fetch_and_xor(&_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS)
return __xor_and_fetch(&_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_SUN)
return atomic_xor_uint_nv(&_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_MUTEX)
ScopedLock lock(_mutex);
_value ^= value;
return _value;
#else
_value ^= value;
return _value;
#endif
}

The line that complains that atomic_xor_uint_nv() needs a prototype is the one  
inside the condition for _OPENTHREADS_ATOMIC_USE_SUN.

If anyone has an idea of a include I'm supposed to have, or something I'm 
supposed to define, please help.

thanks,
andy


From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner
Sent: Tuesday, January 06, 2009 1:45 PM
To: OpenSceneGraph Users
Subject: [osg-users] atomic_xor_uint_nv on Solaris

I'm trying to build a recent SVN version, and get errors for 
include/OpenThreads/Atomic:

line 183: Error, badfunccp: The function "atomic_xor_uint_nv" must have a 
prototype.

  I'm not sure about this one.  How is that supposed to be defined?



line 243: Error, badargtype2: Formal argument 2 of type void* in call to 
atomic_cas_ptr(volatile void* void* void*) is being passed const void*const.

Is this one just a const issue?  Should it use a const cast, or is this a sign 
of a problem?

thanks
andy

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


[osg-users] OSG on ohloh

2009-01-07 Thread Sukender
Hi all,

I just discovered ohloh.net and saw OSG don't have much registered users (only 
18 users!). So, for OSG's visibility, I suggest that those who want go there 
and click the "I use this" button, or rate/review the project.
If like me you didn't know, it's an open source projects and developpers 
directory... well go and see! Registering is very fast.

https://www.ohloh.net/p/osg

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Is it necessary a while cycle to remove a child?

2009-01-07 Thread Robert Osfield
Hi Francesco,

There is waaay too little information about the code that is doing the
operations to know what might be wrong.  Please post the surrounding
code to your removeChild calls.

Robert.

On Wed, Jan 7, 2009 at 11:45 AM, Francesco Argese  wrote:
> Hi guys,
>
> i begin thanking all users that are helping me on this  mailing list;
> i don't thank always after the response to avoid the opening of a new
> thread because i receive only digest and i don't know if it is
> possible to receive as complete messages only the message in responce
> to me.
>
> i have a doubt: During my application event generated by user led to
> change my scenegraph deleting some child nodes. With version 1.2 on
> windows i have obtained the following behaviour:
>
> 1)If i remove the node in question with the following command
>
> this->unitTransform->removeChild(this->geodeSphere.get();
>
> it doesn't cancel it always but also sometimes.
>
> 2)If i use a while that cycle until the removal is not possible it
> remove the child correctly.
>
> My doubt is the following: is it necessary or could it be possible
> that i have done some errors that generate this behaviour?
>
> Thanks in advance
> Francesco Argese
> ___
> 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] overriding keyboard events in osgViewer::View...

2009-01-07 Thread Robert Osfield
Hi Shayne,

There are no default event handlers in osgViewer save for the escape
sets done facility that you can turn off via
viewer.setKeyEventSetsDone(0);

>From your email it looks like you must be manually adding the
osgGA::StateSetManipulator, and if you still want this functionality
but want to customize the keys ysed just use the its setKeyEvent*()
methods:

void setKeyEventToggleBackfaceCulling(int key) {
_keyEventToggleBackfaceCulling = key; }

void setKeyEventToggleLighting(int key) {
_keyEventToggleLighting = key; }

void setKeyEventToggleTexturing(int key) {
_keyEventToggleTexturing = key; }

void setKeyEventCyclePolygonMode(int key) {
_keyEventCyclePolygonMode = key; }

Robert.

On Wed, Jan 7, 2009 at 12:25 AM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> This may be a stupid and/or trivial question but here goes…
>
>
>
> Is there a way to override the default keyboard event handlers when using an
> osgViewer::View class? For example, if I create a viewer and then press the
> "l" (lowercase L) key, it causes my rendered scene to enable and disable
> lighting. I want a different behavior when I press this key and other keys…
>
>
>
> Thanks,
>
> -Shayne
>
> ___
> 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] getYnormalized() and camera transforms

2009-01-07 Thread Robert Osfield
Hi Guy,

I don't know what is up, usually things just work.  I wouldn't expect
a x range of -1 to 1 give the center screen will be -1 to 1, so the
overall x range would be more like -3 to 3 given that things are
scaled ralted to the master camera.

Robert.

On Wed, Jan 7, 2009 at 8:26 AM, Guy Wallis  wrote:
> Hi Robert,
> First, thanks for the quick reply.
> Second, oops, yes sorry, a slip of the keyboard there. I did mean to alter 
> the view matrix, not the projection matrix.
>
> I am setting up a 3 screen viewing cube with front, left and right screens 
> each rotated by 90 degrees to their neighbour(s). So, I meant to say the 
> following:
>
> If I ask for the camera to be swung around the y-axis:
>
> viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix::rotate(-pi/2, 0.0f, 
> 1.0f, 0.0f));
>
> the values for x and y no longer lie within the range -1 to 1. In fact the 
> values are a bit wild, I guess the pointer is regarded as no longer moving in 
> the x-y plane.
>
> At this stage I'm just looking to use the mouse position as a control for 
> speed (x-coord) and heading (y-coord) across all three windows.
>
> Cheers,
>
> Guy
>
> 
>
> From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield
> Sent: Tue 1/6/2009 10:43 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] getYnormalized() and camera transforms
>
>
>
> Hi Guy,
>
> The osgViewer library projects the slave cameras coordinates into the
> master cameras coordinates to enable seamless movement of the mouse
> from slave camera viewport to the next, this actually solves one of
> the problems that existed when handling mouse coords with multiple
> channels in Performer.
>
> I a bit surprised you are trying to rotate the projection matrix.
> Typically you shear the projection matrix or rotate the view matrix.
> What type of display set up are you trying to address?
>
> Robert.
>
> On Tue, Jan 6, 2009 at 11:13 AM, Guy Wallis  wrote:
>> G'Day from Down Under,
>>
>>
>>
>> I'm running OSG 2.6 under windows XP and on a trusty old SGI Octane (Yes, it
>> compiles nicely and even the Performer plug-in works!)
>>
>>
>>
>> I'm new to OSG and am struggling with the getXnormalized() routine (part of
>> osgGA::GUIEventAdapter).
>>
>>
>>
>> If I add a matrix transform to the viewer camera it affects the routine's
>> output.
>>
>>
>>
>>
>>
>> So, setting up the camera like this:
>>
>>
>>
>> viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix())
>>
>>
>>
>> gives me normal behaviour with mouse xy values scaled between -1 and 1.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> But if I ask for the camera to be swung around the x-axis like this:
>>
>>
>>
>> viewer.addSlave(camera.get(),osg::Matrix::rotate(pi/2, 1.0f, 0.0f, 0.0f),
>> osg::Matrix());
>>
>>
>>
>> the numbers returned by getYnormalized() are no longer in the range -1 to 1.
>>
>>
>>
>>
>>
>> How do I retrieve the simple, untransformed mouse xy position data?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Guy
>>
>>
>>
>> ___
>> 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Why the wave simulation so inefficiency?

2009-01-07 Thread Robert Osfield
Hi ?  (Could you sign with the name you wished to be addressed as, it
good list etiquete)

You shouldn't see a performance drop, the fact you do suggests that
your doing something wrong on the OSG, but your've provide way too
little information about how you've set up your scene graph to suggest
what this might be.

As a general note a 128x128 grid on modern is trivial for both OpenGL
and OSG.  With modern hardware you get render 1000x1000 grids at still
get 60Hz.  Your low end card might not quite be able to do this but it
won't be a long way off.   This clearly says that there is something
serious up with the way you are doing things.

Robert.

On Wed, Jan 7, 2009 at 4:41 AM, flying5  wrote:
> In a rain scene, I try to simulate rain ripple follow this article:
> http://www.gamedev.net/reference/articles/article915.asp.
> (1) First, I realize it use openGL, it works all right. I render
> 256*256*2 =131072 triangles grid and the FPS is 85 on my
> Intel Pentium(R)4 2*3.00GHz Cpu and GF7300GT(128M) video card.
> (2) Then, I realize it use OSG. But when I render 128*128*2 = 32768
> triangles grid and the FPS is only 13!!!.
> (3) I don't think there is any difference between the two way I realize
> the wave. But why the great disparity in efficiency?
>
> Do anyone hava a better wave simulation way?
>
> Some code likes:
> /*** process wave ***/
> void ProcessWave()
> {
>  float temp;
>  for (int i=1; i   for (int j=1; j   {
>temp = ((wavemap[currentMap][i-1][j] +
> wavemap[currentMap][i+1][j] +
> wavemap[currentMap][i][j-1] +
> wavemap[currentMap][i][j+1] +
> wavemap[currentMap][i-1][j+1] +
> wavemap[currentMap][i+1][j+1] +
> wavemap[currentMap][i-1][j-1] +
> wavemap[currentMap][i+1][j-1]) / 4) -
> wavemap[lastMap][i][j];
>temp = temp - (temp / damp);
>if (temp < 0.01) temp = 0;
>wavemap[nextMap][i][j] = temp;
>   }
> }
> /** invert wave map ***/
> void InvertWaveMap()
> {
>  float temp[MAPY][MAPX];
>  for (int i = 0; i < MAPX; i++)
>   for (int j = 0; j < MAPY; j++)
>  {
>   temp[i][j] = wavemap[nextMap][i][j];
>   wavemap[nextMap][i][j] = wavemap[lastMap][i][j];
>   wavemap[lastMap][i][j] = wavemap[currentMap][i][j];
>   wavemap[currentMap][i][j] = temp[i][j];
>  }
> }
>
> 
> [广告] 出名要趁"小",快来上传宝贝照片赢大奖吧!
> ___
> 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] Is it necessary a while cycle to remove a child?

2009-01-07 Thread Francesco Argese
Hi guys,

i begin thanking all users that are helping me on this  mailing list;
i don't thank always after the response to avoid the opening of a new
thread because i receive only digest and i don't know if it is
possible to receive as complete messages only the message in responce
to me.

i have a doubt: During my application event generated by user led to
change my scenegraph deleting some child nodes. With version 1.2 on
windows i have obtained the following behaviour:

1)If i remove the node in question with the following command

this->unitTransform->removeChild(this->geodeSphere.get();

it doesn't cancel it always but also sometimes.

2)If i use a while that cycle until the removal is not possible it
remove the child correctly.

My doubt is the following: is it necessary or could it be possible
that i have done some errors that generate this behaviour?

Thanks in advance
Francesco Argese
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Using DatabasePager And Precompile Data Option Within osgViewer

2009-01-07 Thread Robert Osfield
Hi Ryan,

I have fixed a couple of items in the precompile path of DatabasePager
since 2.6, so even though it's now disabled by default, when you do
enable it should function better.  So I'd recommend reviewing the code
in svn/trunk 2.7.7 rather than 2.6.0.

Robert.

On Tue, Jan 6, 2009 at 11:33 PM, Kawicki, Ryan H
 wrote:
> OSG Version: 2.6.0
> OS: Windows XP SP2
> Compiler: MS Version 13.10.3077 ( .NET 2003 )
>
> I am a little confused on how the precompile option works within OSG
> 2.6.0.  From what I understand, the intended use is to have all gl
> objects compiled in the background before they are merged with the scene
> graph.  I do not believe this is working as intended.  Please correct me
> if I am wrong about any of my assumptions.
>
> By default, the code indicates that this option is on.  This can be seen
> in the constructor of the DatabasePager.  As database requests are
> processed, the requests are placed inside of the _dataToCompileList.  A
> few statements later, an if statement is evaluated to see if loaded
> objects need to be compiled and that there are active graphics contexts.
> This statement evaluates to true, but when it tries to obtain a compile
> context for the graphics context, it returns NULL.  Because of this, I
> believe the objects to be compiled are being compiled on the same thread
> that is rendering the scene.
>
> void DatabasePager::DatabaseThread::run()
> {
> < ... Code Removed ... >
> // move the databaseRequest from the front of the fileRequest to the end
> of
> // dataToCompile or dataToMerge lists.
> if (loadedObjectsNeedToBeCompiled)
> {
> OpenThreads::ScopedLock
> lock(_pager->_dataToCompileList->_requestMutex);
> databaseRequest->_requestQueue = _pager->_dataToCompileList.get();
>
> _pager->_dataToCompileList->_requestList.push_back(databaseRequest);
> }
> < ... Code Removed ... >
> if (loadedObjectsNeedToBeCompiled &&
> !_pager->_activeGraphicsContexts.empty())
> {
> for(ActiveGraphicsContexts::iterator itr =
> _pager->_activeGraphicsContexts.begin();
> itr != _pager->_activeGraphicsContexts.end();
> ++itr)
> {
>  osg::GraphicsContext* gc =
> osg::GraphicsContext::getCompileContext(*itr);
>  if (gc)
>  {
>   < ... Code Removed ... >
>  }
> }
> < ... Code Removed ... >
> }
>
> I did some digging to see what needed to be provided to osgViewer to
> create the compile context.  I found that there was a command line
> argument ( "--cc" ) that could be passed to indicate to the pager that a
> compile context should be used.  This allowed for a compile context to
> be obtained, but the scene was no longer visible.  Nodes were being
> requested and being inserted into the data to compile list, but the
> graphics thread seems not to be compiling the data because nothing
> visually was showing up.
>
> if (gc)
> {
> osg::GraphicsThread* gt = gc->getGraphicsThread();
> if (gt)
> {
>  gt->add(new DatabasePager::CompileOperation(_pager));
> }
> else
> {
>  gc->makeCurrent();
>  _pager->compileAllGLObjects(*(gc->getState()));
>  gc->releaseContext();
> }
> }
>
> To make it even more interesting, I NOPed out all of the if statement
> and had it go straight to the first statement of the else clause, and
> the terrain began showing up, minus the textures.  I have not quite
> figured that one out yet.
>
> I do not claim to be an expert on the DatabasePager, but it looks like
> there might be a few things wrong with the precompile option.  I know it
> is going to be defaulted to off in later versions of OSG, but I wanted
> to do some testing with our terrains having this option on and off.  To
> me, it looked like having it on or off made no difference, and this is
> why I started to investigate.
>
> Can anyone confirm that this is the intended behavior of the precompile
> option?  Have I made any bad assumptions on how the system is intended
> to work?  Are there missing command line arguments that I have not
> explored?
>
> I am assuming that the graphics context created for the window is the
> same graphics context that is used to precompile the data.  What kind of
> system is in place to make sure that only one thread has access to the
> graphics context?
>
> Thanks for any help.  I'll report anything else I might find.
>
> Ryan H. Kawicki
> The Boeing Company
> Training Systems & Services
> Software Engineer
>
> ___
> 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] overriding keyboard events in osgViewer::View...

2009-01-07 Thread Vincent Bourdier
Hi,

The Handlers can be set when you need them.
By default, the statesetHandler is set, and manage the 'l' key for instance.

If you make your own viewer, you can put the handlers you want.

I'm not sure on how to remove the default handler, but If you set your
view(er), and add the eventHandlers you need and nothing more, that will let
you obtain what you need.

Hope it can help you...

Regards,
   Vincent.

2009/1/7 Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC <
shayne.tuel...@hill.af.mil>

>  All,
>
>
>
> This may be a stupid and/or trivial question but here goes…
>
>
>
> Is there a way to override the default keyboard event handlers when using
> an osgViewer::View class? For example, if I create a viewer and then press
> the "l" (lowercase L) key, it causes my rendered scene to enable and disable
> lighting. I want a different behavior when I press this key and other keys…
>
>
>
> Thanks,
>
> -Shayne
>
> ___
> 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] getYnormalized() and camera transforms

2009-01-07 Thread Guy Wallis
Hi Robert,
First, thanks for the quick reply.
Second, oops, yes sorry, a slip of the keyboard there. I did mean to alter the 
view matrix, not the projection matrix.
 
I am setting up a 3 screen viewing cube with front, left and right screens each 
rotated by 90 degrees to their neighbour(s). So, I meant to say the following:
 
If I ask for the camera to be swung around the y-axis:

viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix::rotate(-pi/2, 0.0f, 
1.0f, 0.0f));
 
the values for x and y no longer lie within the range -1 to 1. In fact the 
values are a bit wild, I guess the pointer is regarded as no longer moving in 
the x-y plane.
 
At this stage I'm just looking to use the mouse position as a control for speed 
(x-coord) and heading (y-coord) across all three windows.
 
Cheers,
 
Guy



From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield
Sent: Tue 1/6/2009 10:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] getYnormalized() and camera transforms



Hi Guy,

The osgViewer library projects the slave cameras coordinates into the
master cameras coordinates to enable seamless movement of the mouse
from slave camera viewport to the next, this actually solves one of
the problems that existed when handling mouse coords with multiple
channels in Performer.

I a bit surprised you are trying to rotate the projection matrix.
Typically you shear the projection matrix or rotate the view matrix.
What type of display set up are you trying to address?

Robert.

On Tue, Jan 6, 2009 at 11:13 AM, Guy Wallis  wrote:
> G'Day from Down Under,
>
>
>
> I'm running OSG 2.6 under windows XP and on a trusty old SGI Octane (Yes, it
> compiles nicely and even the Performer plug-in works!)
>
>
>
> I'm new to OSG and am struggling with the getXnormalized() routine (part of
> osgGA::GUIEventAdapter).
>
>
>
> If I add a matrix transform to the viewer camera it affects the routine's
> output.
>
>
>
>
>
> So, setting up the camera like this:
>
>
>
> viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix())
>
>
>
> gives me normal behaviour with mouse xy values scaled between -1 and 1.
>
>
>
>
>
>
>
>
>
> But if I ask for the camera to be swung around the x-axis like this:
>
>
>
> viewer.addSlave(camera.get(),osg::Matrix::rotate(pi/2, 1.0f, 0.0f, 0.0f),
> osg::Matrix());
>
>
>
> the numbers returned by getYnormalized() are no longer in the range -1 to 1.
>
>
>
>
>
> How do I retrieve the simple, untransformed mouse xy position data?
>
>
>
> Thanks,
>
>
>
> Guy
>
>
>
> ___
> 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