Re: [osg-users] OpenThread leak ?

[Adam Coates]

Because I am a sick human being, I coded a fix for this problem in
case anyone else should care.  A diff is attached.  Basically, I just
added some checking to detach() and join() so that if the thread has
not yet been joined or detached successfully by its owner when it is
destroyed, it will detach in the destructor.

Also, it was possible for detach() or join() to crash if called before
start() because pd->tid is uninitialized at that point.  I included an
error check for this and tried to return error codes consistent with
the behavior on Linux (which should be fairly standard for POSIX).

AC

On 9/25/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> Makes sense to me -- but at the least this is now a "documented" issue
> in case others are curious and need to solve it for their own reasons.
>
> Cheers,
> AC
>
> On 9/25/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> > On 9/25/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> > > I looked into this a tad more;  it looks like it is indeed caused by
> > > the thread not being detached.  I added the line:
> > >
> > > pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_DETACHED);
> > >
> > > before the thread creation so that the thread will clean up
> > > automatically.  This eliminates the memory leak.  This is a bad hack,
> > > since it will break the join() and detach() functions.  However,
> > > before I tried this, I tried calling join() and detach() on the Thread
> > > object, but that only leads to a segfault (not sure why yet).
> >
> > Just a quick comment, in early days of OpenThreads/OSG development we
> > tried out join() but found problems with it and certain platforms.  I
> > can't recall which platforms, nor which combinations of usage, nor the
> > actual symptoms exhibited - its was around 6 years ago.
> >
> > As for a small memory leak on exit from an app, well unix will clean
> > this up for you anyway on exit from the app, so while it'd be good
> > practice to solve it, its not going to make any significance to any
> > application built on the OSG.  Given how many other tasks I have on my
> > plate I'll leave this lower priority issue to others to chase up if
> > they fancy :-)
> >
> > Robert.
> >
> > Robert.
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>


OpenThreads.diff
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Camera position not resetting

[Mario Valle]

I create and display an empty scene and later add my model to it.
It works, but the camera position is not reset after adding the model, 
so half of it lies outside the screen. Pressing space obviously reset 
the camera position and all my model appears on the screen.

What I'm doing is:
sceneRoot = new osg::Group;
viewer->setSceneData(sceneRoot.get());
... and later after some GUI selection ...
osg::ref_ptr myscene = new osg::Group;
... fill myscene ...
sceneRoot->addChild(scene.get());

I tried various combination of dirtyBound() and computeBound() on 
sceneRoot and myscene without success.

Also trying to explicitly set the camera position as below seems to have 
no effect: for example I change the eye position but the scene
looks always the same.
const osg::BoundingSphere& boundingSphere= scene->getBound();
osg::Vec3 eye = boundingSphere._center+osg::Vec3(0.0f, -3.5f * 
boundingSphere._radius, 0.0f);
osg::Vec3 center = boundingSphere._center;
osg::Vec3 up = osg::Vec3(0.0f, 0.0f, 1.0f);
viewer->getCamera()->setViewMatrixAsLookAt(eye, center, up);

The only thing that makes a difference is to move the 
viewer->setSceneData(sceneRoot.get()); statement after my model load,
but this does not works if I want an empty scene that is later filled.

The application is derived from osgviewerWX on WinXP with osg 2.1.9
Thanks for your suggestions!
 mario

-- 
Ing. Mario Valle
Visualization Group  | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS)  | Tel:  +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax:  +41 (91) 610.82.82

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

[osg-users] Question on Node memory management.

[[EMAIL PROTECTED]]

Hello,

I am working on converting a project from SGI Performer in C
to OSG, so I am familiar with constructing a scene graph. 

For this project I load all the models I plan to use into a
data structure, at a later point in time based on the user
responses I swap out the sub-graphs that I wish displayed.
The problem is the memory manager ends up freeing my nodes.
I know the OSG answer will be to add a switch node as the
parent of each of the sub graphs then toggle those on and
off. 

Is there a way to tell OSG that I will let it know when I'm
done with a node? 



What should happen in this example snippet is loading two
models which are get swapped in/out by the user pressing "1"
or "2". 

What ends up happening is the program crashes the 2nd time I
tried to load either model. 

Setup in pseudo code based on the Glut example code is
something like ... 

osg::ref_ptr pNode1;
osg::ref_ptr pNode2;

void keyboard( unsigned char key, int /*x*/, int /*y*/ )
{
switch( key )
{
case '1':
   viewer->setSceneData( pNode1 );
   break;
case '2':
   viewer->setSceneData( pNode2 );
   break;
// other cases 
}
}

main() 
{
// some initilization ...
pNode1 = osgDB::readNodeFiles(File1);
pNode2 = osgDB::readNodeFiles(File2);

// more initilization
viewer->setSceneData( pNode1 );
viewer->realize();

glutMainLoop();
}





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

[osg-users] Using OpenGL code in OSG.

[[EMAIL PROTECTED]]

Hello, 

I have an application that was written for SGI Performer and
has a fair amount of OpenGL code that I have no interest in
recoding into the OSG node structure. 

My first thought is to use the example GLUT demo as a
baseline since I can directly call the various legacy pieces
and they seem to work. 

I was wondering if there was a better method for doing
legacy OpenGL code? 

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

[osg-users] OSG crash in _lock_fhandle

[Gert van Maren]

Hi Robert,

Finally managed to crash it in debug on exiting the app. I am running the  
latest SVN.


Crash in _lock_fhandle

Call stack attached. Hope this helps

Regards Gert

I forgot: this latest crash happens on exiting the app.

Gert

--
Gert van Maren

Head of Research & Development
K2Vi Virtual Reality Software
Data Interface Technologies Ltd

Phone: +64 21 2855581
Email: [EMAIL PROTECTED]
Web: http://www.k2vi.com>   msvcr71d.dll!_lock_fhandle(int fh=5)  Line 453  C
msvcr71d.dll!_close(int fh=5)  Line 60 + 0x9C
msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c8d8)  Line 127 + 0xc
C
msvcr71d.dll!fclose(_iobuf * stream=0x1027c8d8)  Line 58 + 0x9  C
msvcr71d.dll!_fcloseall()  Line 59 + 0x28   C
msvcr71d.dll!__endstdio()  Line 196 C
msvcr71d.dll!_initterm(void (void)* * pfbegin=0x1027a02c, void (void)* 
* pfend=0x1027a038)  Line 600C
msvcr71d.dll!doexit(int code=0, int quick=0, int retcaller=1)  Line 381 
+ 0xf   C
msvcr71d.dll!_cexit()  Line 318 + 0xb   C
msvcr71d.dll!_CRTDLL_INIT(void * hDllHandle=0x1020, unsigned long 
dwReason=0, void * lpreserved=0x0001)  Line 305   C
ntdll.dll!7c9011a7()
ntdll.dll!7c923f31()
ntdll.dll!7c960af8()
ntdll.dll!7c960bf0()
ntdll.dll!7c910945()
ntdll.dll!7c91094e()
kernel32.dll!7c81cd76() 
msvcr71d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x102028a4)  
Line 1818   C
msvcr71d.dll!_free_dbg_lk(void * pUserData=0x0004, int 
nBlockUse=270573648)  Line 1218 + 0x9C
msvcr71d.dll!_free_dbg(void * pUserData=0x0004, int nBlockUse=4000) 
 Line 1086 + 0x7C
msvcr71d.dll!_unlock(int locknum=4)  Line 347   C
msvcr71d.dll!operator delete(void * pUserData=0x0012ff50)  Line 57 + 
0x7C++
ntdll.dll!7c90f0aa()
kernel32.dll!7c81cdee() 
msvcr71.dll!__crtExitProcess(int status=2083928261)  Line 463 + 0x9 
C
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] more on Windows debugging

[Eric Sokolowsky]

Andy Skinner wrote:
> I can step into header files, but not the source.  I wonder why that is.
> 
> It seems I'm pretty close, since it is finding the header file.  If
> anyone could suggest why Visual Studio can find one and not the other,
> I'd be grateful.  I've added both to the list of debug source.

It sounds like there is no debugging information in the source files, 
especially if you're trying to step into the OSG sources which are 
located inside a library file. Header files are compiled into your 
program's sources so you can step into the functions contained therein. 
Are you using a debug version of the library?

Eric

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

Re: [osg-users] OpenThread leak ?

[Adam Coates]

Makes sense to me -- but at the least this is now a "documented" issue
in case others are curious and need to solve it for their own reasons.

Cheers,
AC

On 9/25/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> On 9/25/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> > I looked into this a tad more;  it looks like it is indeed caused by
> > the thread not being detached.  I added the line:
> >
> > pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_DETACHED);
> >
> > before the thread creation so that the thread will clean up
> > automatically.  This eliminates the memory leak.  This is a bad hack,
> > since it will break the join() and detach() functions.  However,
> > before I tried this, I tried calling join() and detach() on the Thread
> > object, but that only leads to a segfault (not sure why yet).
>
> Just a quick comment, in early days of OpenThreads/OSG development we
> tried out join() but found problems with it and certain platforms.  I
> can't recall which platforms, nor which combinations of usage, nor the
> actual symptoms exhibited - its was around 6 years ago.
>
> As for a small memory leak on exit from an app, well unix will clean
> this up for you anyway on exit from the app, so while it'd be good
> practice to solve it, its not going to make any significance to any
> application built on the OSG.  Given how many other tasks I have on my
> plate I'll leave this lower priority issue to others to chase up if
> they fancy :-)
>
> Robert.
>
> 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] OpenThread leak ?

[Robert Osfield]

On 9/25/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> I looked into this a tad more;  it looks like it is indeed caused by
> the thread not being detached.  I added the line:
>
> pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_DETACHED);
>
> before the thread creation so that the thread will clean up
> automatically.  This eliminates the memory leak.  This is a bad hack,
> since it will break the join() and detach() functions.  However,
> before I tried this, I tried calling join() and detach() on the Thread
> object, but that only leads to a segfault (not sure why yet).

Just a quick comment, in early days of OpenThreads/OSG development we
tried out join() but found problems with it and certain platforms.  I
can't recall which platforms, nor which combinations of usage, nor the
actual symptoms exhibited - its was around 6 years ago.

As for a small memory leak on exit from an app, well unix will clean
this up for you anyway on exit from the app, so while it'd be good
practice to solve it, its not going to make any significance to any
application built on the OSG.  Given how many other tasks I have on my
plate I'll leave this lower priority issue to others to chase up if
they fancy :-)

Robert.

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

Re: [osg-users] OpenThread leak ?

[Adam Coates]

I looked into this a tad more;  it looks like it is indeed caused by
the thread not being detached.  I added the line:

pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_DETACHED);

before the thread creation so that the thread will clean up
automatically.  This eliminates the memory leak.  This is a bad hack,
since it will break the join() and detach() functions.  However,
before I tried this, I tried calling join() and detach() on the Thread
object, but that only leads to a segfault (not sure why yet).

AC

On 9/24/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> I'm not sure if this is the source but it's a possible issue anyway:
>
> Neither detach() nor join() are called on the thread, and it looks
> like threads are created in the joinable state.  The thread package
> has to allocate some resources to the thread that are not
> automatically cleaned up when the thread exits (e.g., a place to hold
> its return value until another thread joins it).  The thread's owner
> should probably call join() to wait for the thread to finish, or
> detach() to specify that the library is allowed to free this data.
>
> AC
>
> On 9/24/07, Cedric Pinson <[EMAIL PROTECTED]> wrote:
> > I have a leak but i don't know if it's justified or if it's a known
> > issue, i googled a little on internet,  and i did not find anything.
> > So i ask on the mailing before searching deeper.
> > For information i call the cancel method at the end of my program.
> >
> > ==18164== 152 bytes in 1 blocks are definitely lost in loss record 3 of 4
> > ==18164==at 0x4020848: calloc (in
> > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> > ==18164==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so)
> > ==18164==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so)
> > ==18164==by 0x4F88A98: pthread_create@@GLIBC_2.1 (in
> > /lib/libpthread-2.5.so)
> > ==18164==by 0x4D4A704: OpenThreads::Thread::start() (PThread.c++:624)
> > ==18164==by 0x4D4A74A: OpenThreads::Thread::startThread()
> > (PThread.c++:642)
> > ==18164==by 0x8068C42: markneting::MarkNeting::update()
> > (MarkNeting.cpp:219)
> > ==18164==by 0x8057E39:
> > markneting::MyFixturetest_updateHelper::RunTest(UnitTest::TestResults&)
> > (test-MarkNeting.cpp:137)
> > ==18164==by 0x80588DE:
> > markneting::TestMyFixturetest_update::RunImpl(UnitTest::TestResults&)
> > const (test-MarkNeting.cpp:124)
> > ==18164==by 0x4D50FA3: UnitTest::Test::Run(UnitTest::TestResults&)
> > const (in /usr/lib/libunittest++.so.0.0.0)
> > ==18164==by 0x4: ???
> > ==18164==by 0x4F7EFF3: (within /lib/libc-2.5.so)
> >
> > I try with an osg example (osgtext), and it seems to have the same leak
> >
> > ==18217== 152 bytes in 1 blocks are possibly lost in loss record 20 of 33
> > ==18217==at 0x4020848: calloc (in
> > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> > ==18217==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so)
> > ==18217==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so)
> > ==18217==by 0x450FA98: pthread_create@@GLIBC_2.1 (in
> > /lib/libpthread-2.5.so)
> > ==18217==by 0x402834E: OpenThreads::Thread::start() (in
> > /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6)
> > ==18217==by 0x402839C: OpenThreads::Thread::startThread() (in
> > /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6)
> > ==18217==by 0x448D065: osgViewer::Viewer::startThreading() (in
> > /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9)
> > ==18217==by 0x448FED6: osgViewer::Viewer::setUpThreading() (in
> > /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9)
> >
> > maybe it's just a valgrind mistake :) if someone has more informations
> >
> > --
> > +33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
> > http://www.plopbyte.net
> >
> >
> > ___
> > 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] OpenThreads threading bug on creation/deletion (leads to crashes)

[Adam Coates]

That looks like it'll do the trick -- and valgrind now gives a clean
report as far as memory accesses (because the lock is now safe to
access).  One last thing:  you might look into the memory leak issue
reported from pthread_create;  see my replies there for the issue.

Best,
Adam

On 9/25/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> Hi Adamn,
>
> On 9/25/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> > On 9/24/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> > > It looks like there's still a problem with the current setup.  The
> > > Thread object itself can get deleted before the pthread actually gets
> > > to the lock (which, I guess is what you just added).
>
> I have modified osgunittests so it now has a function that tests the
> creation, start and deletion of a thread, as per code example, you can
> run it via:
>
>   osgunittests thread
>
> With the yesterdays code it worked fine on my system about 2/3rd of
> the times that it was run, more if I didn't add the delay (this is now
> a Thread::microSleep).  The tests I did yesterday were done without
> the delay which is probably why I didn't see any crashes after my
> first round of fixes yesterday.
>
> Armed with a relatively reliable means for recreating the crash I've
> now set about refactoring the OpenThreads::Thread code so that instead
> of using a mutex in the start method and destructor it uses a
> OpenThreads::Block in the Thread::start() method and static
> StartThread() function such that the thread that calls the
> thread->startThread() will be held back until the new thread has been
> successfully started.  With this change I'm now able to run the
> osgunittest thread test 1000 times without error (I use a repeat
> script to do this).
>
> I have also rolled these changes into Windows and IRIX spoc code
> paths, revert the previous Mutex based code.
>
> Could you check out the latest version in SVN and let me know if this
> problem is now properly fixed.
>
> 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] more on Windows debugging

[Andy Skinner]

I can step into header files, but not the source.  I wonder why that is.

It seems I'm pretty close, since it is finding the header file.  If
anyone could suggest why Visual Studio can find one and not the other,
I'd be grateful.  I've added both to the list of debug source.

andy

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian
Sent: Monday, September 24, 2007 11:10 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging


Usually, VS will prompt you for a file location if it cannot find a
file.  It sounds like your DLLs are being loaded from the correct place,
but just in case, make certain that the DLLs you just recently built
match the ones that are being loaded.  It's been my experience that PDB
files can be very picky (frustatingly so, sometimes).  Check your output
window for the DLL names.  Also, set a breakpoint on some code that
calls an OSG function.  Step into that code and see what happens.  The
IDE should prompt you for a source filename if it cannot determine where
it is.

That's all that I can think of at the moment.

Hope it helps,
Brian

 On Mon Sep 24 10:39 , 'Andy Skinner' <[EMAIL PROTECTED]> sent:

>Has anyone had to do anything tricky to see OSG source code while
>debugging their application?
>
>I've been able to compile OSG debug, and to put the .pdb files where
>Visual Studio can see them.  If I stop in my code, I can see OSG
symbols
>on the stack trace.  But I can't see the source code.
>
>I've added the directories I need to a list of debug source locations.
>
>Does anyone else know how I should be able to see into the OSG source
in
>Visual Studio?
>
>thanks,
>andy
>
>___
>osg-users mailing list
>osg-users@lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o
rg

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

[osg-users] Fw: osgDotNet : Nodes adding to scenegraphoutsidemain()function scope

[Christophe Medard]

Hi Mike

It's an OSGExp export of a 3DSMax scene. I can send you the .osg or .ive file 
if you want to.

The overall content is mere geometries (osg::Geodes and some 
osg::MatrixTransform), no particle effects, no LOD, no camera.
Many geometries have their DataVariance DYNAMIC though (which isn't necessary 
and optimal) : it must have kept OSGExp's default options when exporting...

The location of the camera definitely seems to be an issue, but only at 
initialization.

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29




- Original Message - 
From: Mike Wittman 
To: OpenSceneGraph Users 
Sent: Tuesday, September 25, 2007 5:26 PM
Subject: Re: [osg-users] osgDotNet : Nodes adding to 
scenegraphoutsidemain()function scope


Hi Christophe,

 

The dependency on camera position is an interesting and potentially important 
insight.  There may be some location-related conditional behavior within the 
native code that osgDotNet is not handling properly.

 

Can you tell me generally what is contained in the scene graphs of the models 
that you are loading?  That may have some bearing on the problem.

 

-Mike


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

Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope

[Mike Wittman]

Hi Jason,

 

I expect this is a pretty deep problem related to the way reference counting is 
handled by osgDotNet.  I'd recommend reviewing the RefCount Deletion Statechart 
diagram in the GeneratedCode.uml file, which gives insight into the (intended) 
reference counting strategy.  Also I found the book CLR via C# extremely 
helpful in understanding how the CLR GC works.

 

I do intend to look into this more when I have the time, but I'm not sure how 
soon that will happen.  If you figure it out in the mean time I'll be happy to 
accept a patch. :)

 

-Mike

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage
Sent: Tuesday, September 25, 2007 10:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgDotNet : Nodes adding to scene 
graphoutsidemain()function scope

 

Hi Mike,

I tried to do some debugging with regards to the PAT issue I added and it has 
something to do with the finalizer being run a NodeVisitor object, but that's 
about as far as I got.  I couldn't understand why it would be an issue for 
nodes containing particle systems, but other nodes are fine.  I think it has 
something to do with the adapter pattern being used that allows a user to 
subclass Nodes in C#, but I haven't gotten any further. 

Jason

On 9/25/07, Christophe Medard <[EMAIL PROTECTED]> wrote:

Hi Mike,

 

Thanks for telling me the same kind of thing was already reported ! 

I understand passin in OSG 2.1.12 would do no good.

 

Thanks also for confirming the OSG reference count management being done by the 
wrapper layer in a .NET Managed-fashion...

 

It's quite hard to find the root cause indeed, since it seems to depend on 
independant factor, like where the camera is -initially- positionned : I only 
get the problem when letting osgViewer set it away from the scene (no 
osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). 
There's something about an intersect visitor apparently (a culling pass ?).

One could think it's only where the AccessViolation first occur. I'm not sure : 
if I initialize the camera close to the scene geometry, not only does my 
AccessViolation vanish, but I don't have the OSG Notice warning about a 
possible problem anymore either. That whether I leave space between my point of 
the scene and scene geometry through manipulator's behaviour afterwards in the 
run time of my application...

 

Anyway, if anyone happen to lock the root cause, please don't hesitate to post !

 

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
 

 

- Original Message - 

From: Mike Wittman   

To: OpenSceneGraph Users   

Sent: Tuesday, September 25, 2007 3:58 PM

Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph 
outsidemain()function scope

 

Hi Christophe,

 

This sounds like a bug that Jason reported where a particle system 
under a PAT node gives the same symptoms - 
http://www.openscenegraph.org/projects/osgDotNet/ticket/1.  I've dug into that 
problem some, but only enough to know that it will take quite a bit more time 
to track down the root cause.

 

You're correct about the reference count management; it's intended to 
be completely handled by the wrappers and transparent to the C# user.  
Obviously something is going wrong in this particular case.

 

Mike Wittman

[EMAIL PROTECTED]   

___ 

Seismic Micro-Technology, Inc.

8584 Katy Freeway, Suite 400 / Houston, Texas 77024 

Tel.  +1 (713) 464-6188

Fax. +1 (713) 464-6440

Web:  www.seismicmicro.com 

___ 

CONTACT US TODAY for more information.

 


___
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] MODKEY_CTRL problem

[Panagiotis Papadakos]

Yesterday's SVN.

Panagiotis Papadakos

On Tue, 25 Sep 2007, Robert Osfield wrote:

> Hi Panagiotis,
>
> Which version of the OSG are you using?
>
> Robert.
>
> On 9/25/07, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>> I still have problems with MODKEY_CTRL modifiers. See
>> http://osgcvs.no-ip.com/osgarchiver/archives/May2007/0203.html.
>>
>> Also another problem I have is that if I switch to another application and
>> then I switch back to my OSG app, it seems that I can't catch key
>> events anymore!
>>
>> Thanks in advance.
>>
>> Panagiotis Papadakos
>> ___
>> 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] FBO

[[EMAIL PROTECTED]]

Thanks,
 eventually it was my own bug. doh! sorry for the interruption. I hanged the
scene view data according to some condition and didn't set it back to the
original that create all the objects.
now it works.
thanks again,
 Guy.
- Original Message -
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, September 25, 2007 1:44 PM
Subject: Re: [osg-users] FBO


> Hi Guy,
>
> 2.x and 1.2 and substantially different when it comes to management of
> clean up of graphics contexts.
>
> I suggest you upgrade, your problems might be fixed right away, but if
> not then there is much better chance that others will be able to
> support you.
>
> Robert.
>
> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to
compare
> > with, and the clean up is similar. I also try to keep the questions not
> > specific to the 1.2 implementation
> > I noticed that on the clean_frame, the pass over the scene doesn't get
to
> > all the objects for some reason. For example, it releases only one
texture
> > object while there suppose to be two, and it gets only to one camera of
the
> > pair of RTT and show texture on screen cameras.
> > and I'm now debugging it. Maybe I changed the scene and lose pointers to
> > objects somewhere...
> >
> > Could it be that since one of the camera is pre-render and the other is
> > nested, that the cleanup get only to the nested rendered camera?
> >
> > thanks,
> >  Guy.
> >
> >
> > - Original Message -
> > From: "Robert Osfield" <[EMAIL PROTECTED]>
> > To: "OpenSceneGraph Users" 
> > Sent: Tuesday, September 25, 2007 10:10 AM
> > Subject: Re: [osg-users] FBO
> >
> >
> > > Hi Guy,
> > >
> > > If you destroy a window then all the OpenGL objects associated with it
> > > will be removed.  If you are using 2.0/osgViewer it should be able to
> > > automatically release the OpenGL objects and reallocated them on the
> > > new graphics context.
> > >
> > > Which verison of the OSG/viewer library are you using?
> > >
> > > Robert.
> > >
> > > On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Hi Robert,
> > > >  in my application I have the scene graph in some variable, and a
camera
> > in
> > > > another variable, then I attach it to viewer, in multi-document
window.
> > > > After I close the window, the scene graph & the camera are still
alive.
> > > > The next time I want to attach them to a new window I get OpenGL
error
> > that
> > > > the frame buffer object is not complete (and nothing is drawn), so I
> > wanted
> > > > to force the renderstage to re-create it, and achieved this by
setting
> > the
> > > > rendering cache of the existing camera to NULL.
> > > >
> > > > I just wanted to know if there is another and better way to deal
with
> > this
> > > > problem, and also if you know why the FBO was defected after the
window
> > was
> > > > closed.
> > > >
> > > > thanks,
> > > >  Guy.
> > > > - Original Message -
> > > > From: "Robert Osfield" <[EMAIL PROTECTED]>
> > > > To: "OpenSceneGraph Users" 
> > > > Sent: Monday, September 24, 2007 3:04 PM
> > > > Subject: Re: [osg-users] FBO
> > > >
> > > >
> > > > > Hi Guy,
> > > > >
> > > > > Have a look at the osgprerender example.  You shouldn't need to
set
> > > > > anything related to the render cache is this is managed
internally.
> > > > >
> > > > > Robert.
> > > > >
> > > > > On 9/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > > OK, I got over it but I'm not sure that was the best way.
> > > > > > What I did was to set the camera rendering cache (for the
related
> > > > contextID)
> > > > > > to NULL, so the next time the cull visitor applied on the
camera, it
> > > > > > recreated the FBO. Any other ideas?
> > > > > > thanks,
> > > > > >  Guy.
> > > > > >
> > > > > > - Original Message -
> > > > > > From: [EMAIL PROTECTED]
> > > > > > To: osg-users@lists.openscenegraph.org
> > > > > > Sent: Monday, September 24, 2007 1:51 PM
> > > > > > Subject: [osg-users] FBO
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >  How do I enforce a camera to recreate FBO attached to the color
> > buffer?
> > > > > >
> > > > > > 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.op

Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope

[Mike Wittman]

Hi Christophe,

 

The dependency on camera position is an interesting and potentially important 
insight.  There may be some location-related conditional behavior within the 
native code that osgDotNet is not handling properly.

 

Can you tell me generally what is contained in the scene graphs of the models 
that you are loading?  That may have some bearing on the problem.

 

-Mike

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Tuesday, September 25, 2007 9:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgDotNet : Nodes adding to scene 
graphoutsidemain()function scope

 

Hi Mike,

 

Thanks for telling me the same kind of thing was already reported ! 

I understand passin in OSG 2.1.12 would do no good.

 

Thanks also for confirming the OSG reference count management being done by the 
wrapper layer in a .NET Managed-fashion...

 

It's quite hard to find the root cause indeed, since it seems to depend on 
independant factor, like where the camera is -initially- positionned : I only 
get the problem when letting osgViewer set it away from the scene (no 
osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). 
There's something about an intersect visitor apparently (a culling pass ?).

One could think it's only where the AccessViolation first occur. I'm not sure : 
if I initialize the camera close to the scene geometry, not only does my 
AccessViolation vanish, but I don't have the OSG Notice warning about a 
possible problem anymore either. That whether I leave space between my point of 
the scene and scene geometry through manipulator's behaviour afterwards in the 
run time of my application...

 

Anyway, if anyone happen to lock the root cause, please don't hesitate to post !

 

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
 

 

- Original Message - 

From: Mike Wittman   

To: OpenSceneGraph Users   

Sent: Tuesday, September 25, 2007 3:58 PM

Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph 
outsidemain()function scope

 

Hi Christophe,

 

This sounds like a bug that Jason reported where a particle system 
under a PAT node gives the same symptoms - 
http://www.openscenegraph.org/projects/osgDotNet/ticket/1.  I've dug into that 
problem some, but only enough to know that it will take quite a bit more time 
to track down the root cause.

 

You're correct about the reference count management; it's intended to 
be completely handled by the wrappers and transparent to the C# user.  
Obviously something is going wrong in this particular case.

 

Mike Wittman

[EMAIL PROTECTED]  

___

Seismic Micro-Technology, Inc.

8584 Katy Freeway, Suite 400 / Houston, Texas 77024

Tel.  +1 (713) 464-6188

Fax. +1 (713) 464-6440

Web:  www.seismicmicro.com 
http://www.seismicmicro.com> 

___

CONTACT US TODAY for more information.

 

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

Re: [osg-users] MODKEY_CTRL problem

[Robert Osfield]

Hi Panagiotis,

Which version of the OSG are you using?

Robert.

On 9/25/07, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I still have problems with MODKEY_CTRL modifiers. See
> http://osgcvs.no-ip.com/osgarchiver/archives/May2007/0203.html.
>
> Also another problem I have is that if I switch to another application and
> then I switch back to my OSG app, it seems that I can't catch key
> events anymore!
>
> Thanks in advance.
>
> Panagiotis Papadakos
> ___
> 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] MODKEY_CTRL problem

[Panagiotis Papadakos]

On Tue, 25 Sep 2007, Panagiotis Papadakos wrote:

>
> Also another problem I have is that if I switch to another application and
> then I switch back to my OSG app, it seems that I can't catch key
> events anymore!
>

Well the above is probably my problem, because osgkeyboard works!

Panagiotis Papadakos

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

Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope

[Jason Beverage]

Hi Mike,

I tried to do some debugging with regards to the PAT issue I added and it
has something to do with the finalizer being run a NodeVisitor object, but
that's about as far as I got.  I couldn't understand why it would be an
issue for nodes containing particle systems, but other nodes are fine.  I
think it has something to do with the adapter pattern being used that allows
a user to subclass Nodes in C#, but I haven't gotten any further.

Jason

On 9/25/07, Christophe Medard <[EMAIL PROTECTED]> wrote:
>
>  Hi Mike,
>
> Thanks for telling me the same kind of thing was already reported !
> I understand passin in OSG 2.1.12 would do no good.
>
> Thanks also for confirming the OSG reference count management being done
> by the wrapper layer in a .NET Managed-fashion...
>
> It's quite hard to find the root cause indeed, since it seems to depend on
> independant factor, like where the camera is -initially- positionned : I
> only get the problem when letting osgViewer set it away from the scene (no
> osgViewer.getCameraManipulator().setHomePosition() call in my mainloop).
> There's something about an intersect visitor apparently (a culling pass ?).
> One could think it's only where the AccessViolation first occur. I'm not
> sure : if I initialize the camera close to the scene geometry, not only does
> my AccessViolation vanish, but I don't have the OSG Notice warning about a
> possible problem anymore either. That whether I leave space between my point
> of the scene and scene geometry through manipulator's behaviour afterwards
> in the run time of my application...
>
> Anyway, if anyone happen to lock the root cause, please don't hesitate to
> post !
>
> --
> Christophe Médard
> Société OKTAL (http://www.oktal.fr)
> 2 impasse Boudeville
> 31100 Toulouse (France)
> Tél. : (+33) 5 62 11 50 10
> Fax : (+33) 5 62 11 50 29
>
>
>
> - Original Message -
> *From:* Mike Wittman <[EMAIL PROTECTED]>
> *To:* OpenSceneGraph Users 
> *Sent:* Tuesday, September 25, 2007 3:58 PM
> *Subject:* Re: [osg-users] osgDotNet : Nodes adding to scene graph
> outsidemain()function scope
>
>  Hi Christophe,
>
>
>
> This sounds like a bug that Jason reported where a particle system under a
> PAT node gives the same symptoms -
> http://www.openscenegraph.org/projects/osgDotNet/ticket/1.  I've dug into
> that problem some, but only enough to know that it will take quite a bit
> more time to track down the root cause.
>
>
>
> You're correct about the reference count management; it's intended to be
> completely handled by the wrappers and transparent to the C# user.
> Obviously something is going wrong in this particular case.
>
>
>
> *Mike Wittman*
>
> [EMAIL PROTECTED]
>
> *___*
>
> *Seismic Micro-Technology, Inc.*
>
> *8584 Katy Freeway, **Suite 400 / Houston, Texas 77024*
>
> *Tel.  +1 (713) 464-6188*
>
> *Fax. +1 (713) 464-6440*
>
> *Web:  www.seismicmicro.com*
>
> *___*
>
> *CONTACT US TODAY for more information.*
>
>
>
>
> ___
> 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] (no subject)

[David Callu]

Hi Jan

Take a look to the ShapeDrawable::accept(const HeightField& field) to see
how osg
render a height field.

Take a look to the osgtexture2d example to know how to enable and render
texture.

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

[osg-users] MODKEY_CTRL problem

[Panagiotis Papadakos]

Hi!

I still have problems with MODKEY_CTRL modifiers. See 
http://osgcvs.no-ip.com/osgarchiver/archives/May2007/0203.html.

Also another problem I have is that if I switch to another application and 
then I switch back to my OSG app, it seems that I can't catch key 
events anymore!

Thanks in advance.

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

Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope

[Christophe Medard]

Hi Mike,

Thanks for telling me the same kind of thing was already reported ! 
I understand passin in OSG 2.1.12 would do no good.

Thanks also for confirming the OSG reference count management being done by the 
wrapper layer in a .NET Managed-fashion...

It's quite hard to find the root cause indeed, since it seems to depend on 
independant factor, like where the camera is -initially- positionned : I only 
get the problem when letting osgViewer set it away from the scene (no 
osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). 
There's something about an intersect visitor apparently (a culling pass ?).
One could think it's only where the AccessViolation first occur. I'm not sure : 
if I initialize the camera close to the scene geometry, not only does my 
AccessViolation vanish, but I don't have the OSG Notice warning about a 
possible problem anymore either. That whether I leave space between my point of 
the scene and scene geometry through manipulator's behaviour afterwards in the 
run time of my application...

Anyway, if anyone happen to lock the root cause, please don't hesitate to post !

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
 

  - Original Message - 
  From: Mike Wittman 
  To: OpenSceneGraph Users 
  Sent: Tuesday, September 25, 2007 3:58 PM
  Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph 
outsidemain()function scope


  Hi Christophe,

   

  This sounds like a bug that Jason reported where a particle system under a 
PAT node gives the same symptoms - 
http://www.openscenegraph.org/projects/osgDotNet/ticket/1.  I've dug into that 
problem some, but only enough to know that it will take quite a bit more time 
to track down the root cause.

   

  You're correct about the reference count management; it's intended to be 
completely handled by the wrappers and transparent to the C# user.  Obviously 
something is going wrong in this particular case.

   

  Mike Wittman

  [EMAIL PROTECTED]

  ___

  Seismic Micro-Technology, Inc.

  8584 Katy Freeway, Suite 400 / Houston, Texas 77024

  Tel.  +1 (713) 464-6188

  Fax. +1 (713) 464-6440

  Web:  www.seismicmicro.com

  ___

  CONTACT US TODAY for more information.

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

Re: [osg-users] osgDotNet : Nodes adding to scene graph outside main()function scope

[Mike Wittman]

Hi Christophe,

 

This sounds like a bug that Jason reported where a particle system under a PAT 
node gives the same symptoms - 
http://www.openscenegraph.org/projects/osgDotNet/ticket/1.  I've dug into that 
problem some, but only enough to know that it will take quite a bit more time 
to track down the root cause.

 

You're correct about the reference count management; it's intended to be 
completely handled by the wrappers and transparent to the C# user.  Obviously 
something is going wrong in this particular case.

 

Mike Wittman

[EMAIL PROTECTED]  

___

Seismic Micro-Technology, Inc.

8584 Katy Freeway, Suite 400 / Houston, Texas 77024

Tel.  +1 (713) 464-6188

Fax. +1 (713) 464-6440

Web:  www.seismicmicro.com http://www.seismicmicro.com> 

___

CONTACT US TODAY for more information.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Tuesday, September 25, 2007 7:59 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgDotNet : Nodes adding to scene graph outside 
main()function scope

 

Hi everyone,

 

I don't know if I was very clear in my last post. My problem is to implement in 
C# small sfx in nodes in the scenegraph...

 

The fact is that as soon as the Osg.Node (in the example the _root 
Osg.PositionAttitudeTransform) that is added to the scene is enterily monitored 
by a C# class (and not statically or locally defined in the main loop 
function), there seems to occur destruction on that Node being nonetheless 
regular in term of OSG reference count (the _root is held by the MySfxInstance, 
added to the sceneGraph, and therefore its ref count is 1).

 

Of course, in osgDotNet (managed code), ref_ptr and 
osg::Referenced::ref()/unref() aren't ported.

I'm assuming that reference count managing is done according CLR behaviour (as 
long as a reference on your instance is held by someone, the CLR doesn't invoke 
Dispose on that instance). 

 

Am I missing something obvious ?

Am I the only one using osgDotNet having this problem ?

{ Hereafter follow the same code I sent on friday, focusing on the important 
class and functions and simplified of #regions and unsignicant comments : }


> file MySfx.cs <

public class MySfx
{
  protected Osg.PositionAttitudeTransform _root;
  protected Osg.Group _psScene;

  public MySfx(float fFar)
  {
_root = null;
_psScene = null;


// Sub scenegraph creation
_root = new Osg.PositionAttitudeTransform();
_root.setName("SkyModel_Root");
//_root.setDataVariance(Osg.Object.DataVariance.DYNAMIC);


// Init update callback
_root.setUpdateCallback(new Oktal.OvOsg.MySfxUpdateCallback(this));
  }

  public void setScene(Osg.Group psScene)
  {
if (psScene != null)
{
_psScene = psScene;
_psScene.addChild(_root);
}
  }

  public void update() 
  { 
// Place update code here
  } 
}

internal class MySfxUpdateCallback: Osg.NodeCallback
{
   protected Oktal.OvOsg.MySfx _mySfx;

   public MySfxUpdateCallback(Oktal.OvOsg.MySfx mysfx) 
   {
 _mySfx = mysfx; 
   }

   public override void op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv)
   {
   if (_mySfx != null)
   {
   _mySfx.update(); 
   }
   traverse(node, nv);
   }
}

> file Program.cs <

static void Main(string[] args)

{

// (...)


// load the data
Osg.Node loadedModel = 
OsgViewerExe.OsgDotNetGlobals.osgDBReadNodeFiles(arguments, new 
OsgDB.ReaderWriter.Options());

 // (...)

 

 // optimize the scene graph, remove redundant nodes and state etc.
 OsgUtil.Optimizer optimizer = new OsgUtil.Optimizer();
 optimizer.optimize(loadedModel);

 

 // DEDICATED CODE HERE
 Osg.Group root = new Osg.Group();
 Osg.BoundingSphere info = loadedModel.computeBound();
 root.addChild(loadedModel);

 

 Oktal.OvOsg.MySfx sfx = new Oktal.OvOsg.MySfx(info.radius());
 sfx.setScene(root); // equals root.addChild(skyModel);
 // END DEDICATED CODE

 

 // Comment that (default view is away from the scene) shows the bug 
better...
 //viewer.getCameraManipulator().setHomePosition(new Osg.Vec3d(0.0, -10.0, 
50.0), new Osg.Vec3d(0.0, 0.0, 50.0), new Osg.Vec3d(0.0, 0.0, 1.0)); 

 

 viewer.setSceneData(root);
 viewer.run();

 

}

 

>> 

 

Thx for any advice !

 

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29



- Original Message - 
From: Christophe Medard 
To: osg-users@lists.openscenegraph.org 
Sent: Friday, September 21, 2007 5:47 PM
Subject: osgDotNet : Nodes adding to scene graph outside main() function scope


Hi all, 

If I can still think straight (after such a long week), there seems to be a 
major 

Re: [osg-users] using Mesa instead of opengl

[J.P. Delport]

Hi,

we render off-screen to an OSMesa context in CPU memory using OSG's 
SceneView, so I'm not sure about any support in toolkits or visual 
displays for >8bits per channel.

regards
jp

Jonathan Richard wrote:
> Did you use glut on top of Mesa? Does glut support 16 bits/32 bits
> color channel? If not do you know another toolkit that can be use
> instead of glut? Thanks
> 
> Jo
> 
> On 9/25/07, J.P. Delport <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> we have used it with OSMesa to get float colour channels.
>>
>> jp
>>
>> Jonathan Richard wrote:
>>> Hi, did someone try to run open scene graph with Mesa instead of
>>> opengl? Is it working? Or is it possible to use 16 bits color channel
>>> with opengl instead of 8 bits color channel? Thanks
>>>
>>> Jo
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>> --
>> This message is subject to the CSIR's copyright terms and conditions, e-mail
>> legal notice, and implemented Open Document Format (ODF) standard.
>> The full disclaimer details can be found at
>> http://www.csir.co.za/disclaimer.html.
>>
>> This message has been scanned for viruses and dangerous content by
>> MailScanner,
>> and is believed to be clean.  MailScanner thanks Transtec Computers for
>> their support.
>>
>> ___
>> 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
> 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail 
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their 
support.

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

[osg-users] (no subject)

[Jan Hettwer]

Hi everybody,
I'm new in delveloping with osg and I have a problem with texturing.
I created a heightmap composed of triangles.
Now I want to texture this plane.
My problem is that I don't know how to do that.
If I have a 3x3 map I have 16 vertices. As said in the pyramid-example there 
must be 1 texture coordinate for each vertex. But my 3x3 "quads" are consisting 
of two triangles so I have to use three texturecoordinates per triangle. 
Alltogether 54 of them.
If I try to implement the texturing, nothing senceful is displayed.
I think this is because of the "double" use of the vertices.
Has anyone an idea how to fix my problem?

Thanks a lot,
Jan
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] applying textures

[David Callu]

Hi Enrico

   For a good explanation of texture mapping and texcoord generator, take a
look the redbook
and to the
OpenGL Specification, Chap
2.11.4, p 50.  Keep in mind that osg is a c++ wrapper of OpenGL (and little
more of course :-)), and all graphic concep t   come from OpenGL. as the
texcoord generator.

HTH
david


2007/9/25, Enrico Villani <[EMAIL PROTECTED]>:
>
>
>
> Hi to all!
>i'm a newbie of osg and i would share my problem with the
> community...
> i'm developing a VR application which should load various kind of 3D
> models (mainly flt and osg/ive), insert them into an appropriate
> environement and allow to modify all the scenegraph at runtime. in fact it
> shows the scenegraph and the user can decide to change positions of nodes,
> their visibility, etc. When the user chooses to modify the texture of these
> models, he searches the disk for a good looking image (bmp, jpg, etc), but
> the texture is not mapped correctly (the node selected by the user changes
> only its color, texture too big ). otherwise when he applies these
> textures onto the environement sphere or the terrain, all look more or less
> correct. I use an extended nodevisitor to traverse the scenegraph from the
> node choosed by the user in search of geodes. Every time the visitor finds a
> geode it does:
>
> int Num = geode.getNumDrawables();
> for(int j = 0; j < Num; j++) {
> osg::StateSet* stateset = geode.getDrawable
> (j)->getOrCreateStateSet();
> osg::Texture2D* myTexture=new osg::Texture2D;
> myTexture->setDataVariance(osg::Object::DYNAMIC);
> myTexture->setImage(myImage);
> stateset->setTextureAttributeAndModes(0, myTexture,
> osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
> geode.getDrawable(j)->setStateSet(stateset);
> }
>
> I'm in trouble understanding texture mapping. I looked at BumpMapping to
> get useful hints about texcoordgenerator... but i don't know how to use it.
> Having multiple geometries, how to map them correctly or even
> approssimatively?
>
> Can anyone help me??
>
> Sorry for my maybe silly question but I'm new to to the computer graphics
> world!
>
> I'd be very grateful..
> Many thanks in advance..
>
> Enrico
>
> ___
> 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] using Mesa instead of opengl

[Jonathan Richard]

Did you use glut on top of Mesa? Does glut support 16 bits/32 bits
color channel? If not do you know another toolkit that can be use
instead of glut? Thanks

Jo

On 9/25/07, J.P. Delport <[EMAIL PROTECTED]> wrote:
> Hi,
>
> we have used it with OSMesa to get float colour channels.
>
> jp
>
> Jonathan Richard wrote:
> > Hi, did someone try to run open scene graph with Mesa instead of
> > opengl? Is it working? Or is it possible to use 16 bits color channel
> > with opengl instead of 8 bits color channel? Thanks
> >
> > Jo
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean.  MailScanner thanks Transtec Computers for
> their support.
>
> ___
> 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] osgDotNet : Nodes adding to scene graph outside main() function scope

[Christophe Medard]

Hi everyone,

I don't know if I was very clear in my last post. My problem is to implement in 
C# small sfx in nodes in the scenegraph...

The fact is that as soon as the Osg.Node (in the example the _root 
Osg.PositionAttitudeTransform) that is added to the scene is enterily monitored 
by a C# class (and not statically or locally defined in the main loop 
function), there seems to occur destruction on that Node being nonetheless 
regular in term of OSG reference count (the _root is held by the MySfxInstance, 
added to the sceneGraph, and therefore its ref count is 1).

Of course, in osgDotNet (managed code), ref_ptr and 
osg::Referenced::ref()/unref() aren't ported.
I'm assuming that reference count managing is done according CLR behaviour (as 
long as a reference on your instance is held by someone, the CLR doesn't invoke 
Dispose on that instance). 

Am I missing something obvious ?
Am I the only one using osgDotNet having this problem ?

{ Hereafter follow the same code I sent on friday, focusing on the important 
class and functions and simplified of #regions and unsignicant comments : }

> file MySfx.cs <

public class MySfx
{
  protected Osg.PositionAttitudeTransform _root;
  protected Osg.Group _psScene;

  public MySfx(float fFar)
  {
_root = null;
_psScene = null;

// Sub scenegraph creation
_root = new Osg.PositionAttitudeTransform();
_root.setName("SkyModel_Root");
//_root.setDataVariance(Osg.Object.DataVariance.DYNAMIC);

// Init update callback
_root.setUpdateCallback(new Oktal.OvOsg.MySfxUpdateCallback(this));
  }

  public void setScene(Osg.Group psScene)
  {
if (psScene != null)
{
_psScene = psScene;
_psScene.addChild(_root);
}
  }

  public void update() 
  { 
// Place update code here
  } 
}

internal class MySfxUpdateCallback: Osg.NodeCallback
{
   protected Oktal.OvOsg.MySfx _mySfx;

   public MySfxUpdateCallback(Oktal.OvOsg.MySfx mysfx) 
   {
 _mySfx = mysfx; 
   }

   public override void op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv)
   {
   if (_mySfx != null)
   {
   _mySfx.update(); 
   }
   traverse(node, nv);
   }
}

> file Program.cs <

static void Main(string[] args)
{
// (...)

// load the data
Osg.Node loadedModel = 
OsgViewerExe.OsgDotNetGlobals.osgDBReadNodeFiles(arguments, new 
OsgDB.ReaderWriter.Options());

 // (...)

 // optimize the scene graph, remove redundant nodes and state etc.
 OsgUtil.Optimizer optimizer = new OsgUtil.Optimizer();
 optimizer.optimize(loadedModel);

 // DEDICATED CODE HERE
 Osg.Group root = new Osg.Group();
 Osg.BoundingSphere info = loadedModel.computeBound();
 root.addChild(loadedModel);

 Oktal.OvOsg.MySfx sfx = new Oktal.OvOsg.MySfx(info.radius());
 sfx.setScene(root); // equals root.addChild(skyModel);
 // END DEDICATED CODE

 // Comment that (default view is away from the scene) shows the bug 
better...
 //viewer.getCameraManipulator().setHomePosition(new Osg.Vec3d(0.0, -10.0, 
50.0), new Osg.Vec3d(0.0, 0.0, 50.0), new Osg.Vec3d(0.0, 0.0, 1.0)); 

 viewer.setSceneData(root);
 viewer.run();

}

>>

Thx for any advice !

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29



- Original Message - 
From: Christophe Medard 
To: osg-users@lists.openscenegraph.org 
Sent: Friday, September 21, 2007 5:47 PM
Subject: osgDotNet : Nodes adding to scene graph outside main() function scope


Hi all, 

If I can still think straight (after such a long week), there seems to be a 
major problem for people that want to code special Effects in osgDotNet in C#  
: 
If you want to add to your main scenegraph osg::Nodes that are held by (because 
created, updated and modified by) an SFX class, you quickly have memory 
corruption problems due to the fact that Dispose calls are done on those nodes 
whose reference count is greater than 0.  

This problem doesn't occur in a similar code written in C++ - using native osg 
dlls - in which a destructor is implementable for the SFX class, and 
osg::Referenced::ref() (resp. unref()) methods can be called when osg::Nodes 
are created (resp. inside SFX class' destructor).

I'm attaching a very short C# example illustrating that.
The application crashes rapidly, in Release or Debug. The shallow Debug trace 
is :

I must say to be complete that for instance I'm using version 2.0.0 of OSG and 
osgWrappers.

If there's is a way to avoid those Dispose calls on regular Nodes I'm 
interested to know !!
(My preceeding attemps of sfx implementation in C# where done roughly entirely 
in the main() function, which doesn't raise problems...)

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29

[osg-users] osgviewerQT

[James E. Hopper]

Robert,

I agree something is happening with events, but its not the wrapper  
issue.  Well if i understand what you are saying


  I am building it as an application with proper wrapper.  thats why  
i used qmake which knows how to build a standard universal mac  
application.


In addition i verified that qt events are happening.  the data is  
going to osg, just not being used by osg as far as i can seen.


i will look more deeply at GraphicsWindowCarbon to see if there is  
something else missing.


best jim

there may be something else in carbon version, but its not the  
wrapper problem that has been discussed in the past.


best jim




I suspect this problem is down to stupid bit of behavior under OSX
that Apple decided was a good idea... basically you have to tell the
OS that you actually want events in your application.
osgViewer::GraphicsWindowCarbon has a call to do this, this must be
missing from QT.  The alternative to this call is to provide a
resource file which seems to be the "official" Apple but still crap
way of doing this.

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

Re: [osg-users] pbuffer performance

[Robert Osfield]

Hi RJ,

glCopyPixels will be doing a round trip to the CPU.  You might be able
to help out by using a PixelBuffer object for reading and writing, but
as general advice I have to say absolutely don't code the problem in
the way your are doing as it will be slow.  Use FBO to render a
texture and then render a quad screen aligned, don't use glCopyPixels
and glDrawPixels at all.

Robert.

On 9/24/07, Rahul Jain <[EMAIL PROTECTED]> wrote:
> Hi Guys,
> This question is not directly related to OSG, but I hope the OSG users
> must have answer to this problem and the reason i am asking this on this
> forum is that because the OSG has most number of OpenGL experts.;)
>
> I am transfering data from one pbuffer to other pbuffer using
> glCopyPixel and the transfer rate is two slow, 1MB/sec on my Nvidia
> Quadro 4600 (512MB) graphics card.
> Can some one tell me what can be the problem. The detail description of
> what i am doing is given below.
>
> The two pbuffers i have created using glXCreatePbuffer
> with GLXFBConfig atributes as mentioned below
>
> int attrib[] =
> {
> GLX_DOUBLEBUFFER, True,
> GLX_RED_SIZE, 8,
> GLX_GREEN_SIZE, 8,
> GLX_BLUE_SIZE, 8,
> GLX_ALPHA_SIZE, 8,
> GLX_RENDER_TYPE, GLX_RGBA_BIT,
> GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
> None
> }
> The attributes of the pbuufer are
>
> int pbufAttrib[] =
> {
> GLX_PBUFFER_WIDTH, 512,
> GLX_PBUFFER_HEIGHT, 512,
> GLX_LARGEST_PBUFFER, True,
> GLX_PRESERVED_CONTENTS,True,
> None
> }
>
> Now i created a context (contx0) and made the context current w.r.t
> pbuffer0.
>
> Now using glDrawPixel i draw an image in pbuffer0.
>
> Now using glXMakeContextCurrent(display,pbuufer1(drawable),
> pbuffer0(readable), contx0);
> i set the context so that pixelBuffer1 is my drawable and pixelBuffer0
> is my readable buffer.
>
> Now i am copying tha data from pixelBuffer0 to PixelBufer1 using
> glCopyPixel() and that is where i am getting the performace hit.
> Since i am transfering data from GPU to GPU the transfer rate should be
> very high (GB/sec)
> but i am getting aroung 1MB/sec.
>
> Thanks in advance
> rj
>
> ___
> 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] Problems with the latest registry version

[Robert Osfield]

Hi María,

There have been changes to Registry but I don't recall any that should
break your usage model.  Tracs provides online browsing of changes,
the place for Registry.cpp is:

http://www.openscenegraph.org/projects/osg/log/OpenSceneGraph/trunk/src/osgDB/Registry.cpp

Click on the ChngSt entry to see what the diffs are on each checkin.

As for a crash on an ATI card, when used with a Java, this is well
beyond what I have access to, experience of.  It could be an ATI
driver bug, it could be a Java related issue, it could be an OSG that
only appears in certain usage models.  With so little to go on there
is nothing I can do to divine what might be wrong though.

Robert.

On 9/25/07, María Ten <[EMAIL PROTECTED]> wrote:
>
> Hi Robert,
>
> I have a plugin to read some paged tiles. Our plugins are registered by code
> and don't use a dll system. It worked fine before the update. But yesterday,
> I updated my osg svn version and now the registry is saying that can't read
> the plugin.  I debug it and it seems like the registry doesn't search the
> plugin in the list and searchs it like a library. Did you make some change
> in the registry recently? I tried to find it in the logs but i didn't found
> it.
>
> Well, i have another bug too. We have a viewer in Java using jogl but
> recently it crashed when we run in a ATI graphic card. We tried to test the
> viewer with the osg cow and it worked in ATI too. The bug is when we try to
> load some paged tiles build with osgTerrain. It crashes in the call
> compileGLobjects because in the debugger you can see that there isn't a
> compile context. I can't debug now beacause the other bug don't let me. Have
> you some ideas?
>
> Thaks for all.
>
> --
> María Ten Rodríguez
> Instituto de Automática e Informática Industrial  http://www.ai2.upv.es
> Ciudad Politécnica de la Innovación
> Universidad Politécnica de Valencia
> ___
> 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] pbuffer performance

[Rahul Jain]

Hi Guys,
This question is not directly related to OSG, but I hope the OSG users
must have answer to this problem and the reason i am asking this on this
forum is that because the OSG has most number of OpenGL experts.;)

I am transfering data from one pbuffer to other pbuffer using
glCopyPixel and the transfer rate is two slow, 1MB/sec on my Nvidia
Quadro 4600 (512MB) graphics card.
Can some one tell me what can be the problem. The detail description of
what i am doing is given below.

The two pbuffers i have created using glXCreatePbuffer
with GLXFBConfig atributes as mentioned below 

int attrib[] = 
{
GLX_DOUBLEBUFFER, True,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
GLX_ALPHA_SIZE, 8,
GLX_RENDER_TYPE, GLX_RGBA_BIT,
GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
None
}
The attributes of the pbuufer are 

int pbufAttrib[] = 
{ 
GLX_PBUFFER_WIDTH, 512,
GLX_PBUFFER_HEIGHT, 512,
GLX_LARGEST_PBUFFER, True,
GLX_PRESERVED_CONTENTS,True, 
None
}

Now i created a context (contx0) and made the context current w.r.t
pbuffer0. 

Now using glDrawPixel i draw an image in pbuffer0.

Now using glXMakeContextCurrent(display,pbuufer1(drawable),
pbuffer0(readable), contx0);
i set the context so that pixelBuffer1 is my drawable and pixelBuffer0
is my readable buffer.

Now i am copying tha data from pixelBuffer0 to PixelBufer1 using
glCopyPixel() and that is where i am getting the performace hit.
Since i am transfering data from GPU to GPU the transfer rate should be
very high (GB/sec)
but i am getting aroung 1MB/sec.

Thanks in advance
rj

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

[osg-users] Problems with the latest registry version

[María Ten]

Hi Robert,

I have a plugin to read some paged tiles. Our plugins are registered by code
and don't use a dll system. It worked fine before the update. But yesterday,
I updated my osg svn version and now the registry is saying that can't read
the plugin.  I debug it and it seems like the registry doesn't search the
plugin in the list and searchs it like a library. Did you make some change
in the registry recently? I tried to find it in the logs but i didn't found
it.

Well, i have another bug too. We have a viewer in Java using jogl but
recently it crashed when we run in a ATI graphic card. We tried to test the
viewer with the osg cow and it worked in ATI too. The bug is when we try to
load some paged tiles build with osgTerrain. It crashes in the call
compileGLobjects because in the debugger you can see that there isn't a
compile context. I can't debug now beacause the other bug don't let me. Have
you some ideas?

Thaks for all.

-- 
María Ten Rodríguez
Instituto de Automática e Informática Industrial  http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FBO

[Robert Osfield]

Hi Guy,

2.x and 1.2 and substantially different when it comes to management of
clean up of graphics contexts.

I suggest you upgrade, your problems might be fixed right away, but if
not then there is much better chance that others will be able to
support you.

Robert.

On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to compare
> with, and the clean up is similar. I also try to keep the questions not
> specific to the 1.2 implementation
> I noticed that on the clean_frame, the pass over the scene doesn't get to
> all the objects for some reason. For example, it releases only one texture
> object while there suppose to be two, and it gets only to one camera of the
> pair of RTT and show texture on screen cameras.
> and I'm now debugging it. Maybe I changed the scene and lose pointers to
> objects somewhere...
>
> Could it be that since one of the camera is pre-render and the other is
> nested, that the cleanup get only to the nested rendered camera?
>
> thanks,
>  Guy.
>
>
> - Original Message -
> From: "Robert Osfield" <[EMAIL PROTECTED]>
> To: "OpenSceneGraph Users" 
> Sent: Tuesday, September 25, 2007 10:10 AM
> Subject: Re: [osg-users] FBO
>
>
> > Hi Guy,
> >
> > If you destroy a window then all the OpenGL objects associated with it
> > will be removed.  If you are using 2.0/osgViewer it should be able to
> > automatically release the OpenGL objects and reallocated them on the
> > new graphics context.
> >
> > Which verison of the OSG/viewer library are you using?
> >
> > Robert.
> >
> > On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Hi Robert,
> > >  in my application I have the scene graph in some variable, and a camera
> in
> > > another variable, then I attach it to viewer, in multi-document window.
> > > After I close the window, the scene graph & the camera are still alive.
> > > The next time I want to attach them to a new window I get OpenGL error
> that
> > > the frame buffer object is not complete (and nothing is drawn), so I
> wanted
> > > to force the renderstage to re-create it, and achieved this by setting
> the
> > > rendering cache of the existing camera to NULL.
> > >
> > > I just wanted to know if there is another and better way to deal with
> this
> > > problem, and also if you know why the FBO was defected after the window
> was
> > > closed.
> > >
> > > thanks,
> > >  Guy.
> > > - Original Message -
> > > From: "Robert Osfield" <[EMAIL PROTECTED]>
> > > To: "OpenSceneGraph Users" 
> > > Sent: Monday, September 24, 2007 3:04 PM
> > > Subject: Re: [osg-users] FBO
> > >
> > >
> > > > Hi Guy,
> > > >
> > > > Have a look at the osgprerender example.  You shouldn't need to set
> > > > anything related to the render cache is this is managed internally.
> > > >
> > > > Robert.
> > > >
> > > > On 9/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > OK, I got over it but I'm not sure that was the best way.
> > > > > What I did was to set the camera rendering cache (for the related
> > > contextID)
> > > > > to NULL, so the next time the cull visitor applied on the camera, it
> > > > > recreated the FBO. Any other ideas?
> > > > > thanks,
> > > > >  Guy.
> > > > >
> > > > > - Original Message -
> > > > > From: [EMAIL PROTECTED]
> > > > > To: osg-users@lists.openscenegraph.org
> > > > > Sent: Monday, September 24, 2007 1:51 PM
> > > > > Subject: [osg-users] FBO
> > > > >
> > > > >
> > > > > Hi,
> > > > >  How do I enforce a camera to recreate FBO attached to the color
> buffer?
> > > > >
> > > > > 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
> > >
> > ___
> > 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.opensceneg

[osg-users] ClipNode / clipplane, rendering water with RTT camera

[Michael Ebner]

Hello OSG users,

i'm trying to render a water surface with reflections. Rendering the 
reflected scene into a texture and projecting it on a water plane 
already works.
What i need is a clipplane at water height to avoid rendering anything 
below the water surface. I've tried to setup a ClipNode with clipplanes 
in various ways (also activating them on different positions at the 
scenegraph) but nothing gets clipped.

I post a code snippet below, perhaps i'm missing something obvious. I 
tried, setting up the ClipNode at root level and activating the plane at 
reflection cameras level. Tried adding the ClipNode above the reflection 
camera and activating it there. And below is the code, where the 
ClipNode is child of the RTT reflection_camera, but it doesn't work either.


snippet:

// reflection texture 
reflection_tex_ = new osg::Texture2D;
reflection_tex_->setTextureSize(1024,1024);
reflection_tex_->setInternalFormat(GL_RGBA);
reflection_tex_->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
reflection_tex_->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
reflection_tex_->setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER);
reflection_tex_->setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER);
reflection_tex_->setBorderColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f));


// reflection camera --
reflection_camera_ = new osg::Camera;
reflection_camera_->setName("WaterReflectionCamera");

reflection_camera_->setClearColor(osg::Vec4(0.1f,0.1f,0.3f,1.0f));
reflection_camera_->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
reflection_camera_->setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR);
reflection_camera_->setReferenceFrame(osg::Camera::ABSOLUTE_RF);
reflection_camera_->setViewport(0, 0,
  reflection_tex_->getTextureWidth(),
  reflection_tex_->getTextureHeight());

reflection_camera_->setRenderOrder(osg::Camera::PRE_RENDER);
reflection_camera_->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
reflection_camera_->attach(osg::Camera::COLOR_BUFFER, 
reflection_tex_.get());


// add clip node with clip plane, to avoid rendering anything below 
water surface
osg::ClipNode * clip_node = new osg::ClipNode();
clip_node->setName("Clip Node XZ plane");
clip_node->addClipPlane(new osg::ClipPlane(0,0.0,1.0,0.0,water_height));

osg::StateSet* clip_state = clip_node->getOrCreateStateSet();
clip_state->setMode(GL_CLIP_PLANE0, osg::StateAttribute::PROTECTED | 
osg::StateAttribute::ON);

clip_node->addChild(reflected_nodes.get());

reflection_camera_->addChild(clip_node);

root_node->addChild(reflection_camera_.get());


//---

Thanks in advance for any help,
Michael.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] may be some bug in dds plugin

[David Spilling]

Ah - just noticed. The DDS file you attached claims to have 10 mipmaps, but
there is only data for (and it only makes sense to have) 7. So, firstly,
something looks broken in whatever wrote the file, in terms of retrieving
the number of mipmaps. Setting it to a low value during the image load
works; i.e. the file reads fine.

As an aside, I just generated a DDS with 128x128, but only data for 5 mipmap
levels; on loading, image->getNumMipmapLevels reports 8 (i.e. what you would
expect for a fully mipmapped 128x128 image).

I haven't tracked this down any further, though (and won't have time to at
present).

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

Re: [osg-users] may be some bug in dds plugin

[David Spilling]

Just to add my 2p, the changes I submitted would only be seen as colour
changes (red/blue swap) on dds write; I didn't do anything with regard to
file sizes.

The image is DXT1 encoded, and includes 6 levels of mipmap. I had a quick
look, and it's falling over in the osgImage.release() method at the end of
the ReadDDSFile method - in particular, the destructor for the mipmaps
vector. My debugging skills are pretty primitive, but heres a stack trace in
case it helps anybody:

 msvcr71d.dll!_free_dbg_lk(void * pUserData=0x00239f20, int
nBlockUse=1)  Line 1154 + 0x3bC
 msvcr71d.dll!_free_dbg(void * pUserData=0x00239f20, int nBlockUse=1)
Line 1070 + 0xdC
 msvcr71d.dll!operator delete(void * pUserData=0x00239f20)  Line 54 +
0x10C++
 osgdb_ddsd.dll!std::allocator::deallocate(unsigned int *
_Ptr=0x00239f20, unsigned int __formal=6)  Line 132 + 0x9C++
 osgdb_ddsd.dll!std::vector
>::_Tidy()  Line 797C++
 osgdb_ddsd.dll!std::vector
>::~vector >()  Line 389C++
>
osgdb_ddsd.dll!ReadDDSFile(std::basic_istream >
& _istream={...})  Line 696 + 0x20C++

osgdb_ddsd.dll!ReaderWriterDDS::readImage(std::basic_istream
> & fin={...}, const osgDB::ReaderWriter::Options * options=0x)
Line 959 + 0x9C++
 osgdb_ddsd.dll!ReaderWriterDDS::readImage(const
std::basic_string,std::allocator > &
file={...},


I also generated a similarly DXT1 encoded DDS from scratch, with various
levels of mipmap, with and without alpha, and it loaded and displayed fine.
Plus the original (unmipmapped image) should be 2048 bytes (64 x 64, DXT1 =
1 byte per 2 pixels); this and the relative mipmap data positioning, and
total size, of your image, seems OK.

So I'm lost - sorry.

The image is DXT1 encoded; perhaps try writing it uncompressed?

This doesn't help you, but I have noticed that many 3rd party DDS viewing
apps are inconsistent with regards to how they interpret DDS images, so it's
sometimes worth checking a few apps. XnView seems to read the image fine;
ATI's DDS reader (Compressonator) can't read it at all.



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

Re: [osg-users] FBO

[[EMAIL PROTECTED]]

I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to compare
with, and the clean up is similar. I also try to keep the questions not
specific to the 1.2 implementation
I noticed that on the clean_frame, the pass over the scene doesn't get to
all the objects for some reason. For example, it releases only one texture
object while there suppose to be two, and it gets only to one camera of the
pair of RTT and show texture on screen cameras.
and I'm now debugging it. Maybe I changed the scene and lose pointers to
objects somewhere...

Could it be that since one of the camera is pre-render and the other is
nested, that the cleanup get only to the nested rendered camera?

thanks,
 Guy.


- Original Message -
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, September 25, 2007 10:10 AM
Subject: Re: [osg-users] FBO


> Hi Guy,
>
> If you destroy a window then all the OpenGL objects associated with it
> will be removed.  If you are using 2.0/osgViewer it should be able to
> automatically release the OpenGL objects and reallocated them on the
> new graphics context.
>
> Which verison of the OSG/viewer library are you using?
>
> Robert.
>
> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >  in my application I have the scene graph in some variable, and a camera
in
> > another variable, then I attach it to viewer, in multi-document window.
> > After I close the window, the scene graph & the camera are still alive.
> > The next time I want to attach them to a new window I get OpenGL error
that
> > the frame buffer object is not complete (and nothing is drawn), so I
wanted
> > to force the renderstage to re-create it, and achieved this by setting
the
> > rendering cache of the existing camera to NULL.
> >
> > I just wanted to know if there is another and better way to deal with
this
> > problem, and also if you know why the FBO was defected after the window
was
> > closed.
> >
> > thanks,
> >  Guy.
> > - Original Message -
> > From: "Robert Osfield" <[EMAIL PROTECTED]>
> > To: "OpenSceneGraph Users" 
> > Sent: Monday, September 24, 2007 3:04 PM
> > Subject: Re: [osg-users] FBO
> >
> >
> > > Hi Guy,
> > >
> > > Have a look at the osgprerender example.  You shouldn't need to set
> > > anything related to the render cache is this is managed internally.
> > >
> > > Robert.
> > >
> > > On 9/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > OK, I got over it but I'm not sure that was the best way.
> > > > What I did was to set the camera rendering cache (for the related
> > contextID)
> > > > to NULL, so the next time the cull visitor applied on the camera, it
> > > > recreated the FBO. Any other ideas?
> > > > thanks,
> > > >  Guy.
> > > >
> > > > - Original Message -
> > > > From: [EMAIL PROTECTED]
> > > > To: osg-users@lists.openscenegraph.org
> > > > Sent: Monday, September 24, 2007 1:51 PM
> > > > Subject: [osg-users] FBO
> > > >
> > > >
> > > > Hi,
> > > >  How do I enforce a camera to recreate FBO attached to the color
buffer?
> > > >
> > > > 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
> >
> ___
> 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] applying textures

[Enrico Villani]

Hi to all!
   i'm a newbie of osg and i would share my problem with the
community...
i'm developing a VR application which should load various kind of 3D
models (mainly flt and osg/ive), insert them into an appropriate
environement and allow to modify all the scenegraph at runtime. in fact it
shows the scenegraph and the user can decide to change positions of nodes,
their visibility, etc. When the user chooses to modify the texture of these
models, he searches the disk for a good looking image (bmp, jpg, etc), but
the texture is not mapped correctly (the node selected by the user changes
only its color, texture too big ). otherwise when he applies these
textures onto the environement sphere or the terrain, all look more or less
correct. I use an extended nodevisitor to traverse the scenegraph from the
node choosed by the user in search of geodes. Every time the visitor finds a
geode it does:

int Num = geode.getNumDrawables();
for(int j = 0; j < Num; j++) {
osg::StateSet* stateset = geode.getDrawable
(j)->getOrCreateStateSet();
osg::Texture2D* myTexture=new osg::Texture2D;
myTexture->setDataVariance(osg::Object::DYNAMIC);
myTexture->setImage(myImage);
stateset->setTextureAttributeAndModes(0, myTexture,
osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
geode.getDrawable(j)->setStateSet(stateset);
}

I'm in trouble understanding texture mapping. I looked at BumpMapping to get
useful hints about texcoordgenerator... but i don't know how to use it.
Having multiple geometries, how to map them correctly or even
approssimatively?

Can anyone help me??

Sorry for my maybe silly question but I'm new to to the computer graphics
world!

I'd be very grateful..
Many thanks in advance..

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

Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)

[Robert Osfield]

Hi Adamn,

On 9/25/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> > It looks like there's still a problem with the current setup.  The
> > Thread object itself can get deleted before the pthread actually gets
> > to the lock (which, I guess is what you just added).

I have modified osgunittests so it now has a function that tests the
creation, start and deletion of a thread, as per code example, you can
run it via:

  osgunittests thread

With the yesterdays code it worked fine on my system about 2/3rd of
the times that it was run, more if I didn't add the delay (this is now
a Thread::microSleep).  The tests I did yesterday were done without
the delay which is probably why I didn't see any crashes after my
first round of fixes yesterday.

Armed with a relatively reliable means for recreating the crash I've
now set about refactoring the OpenThreads::Thread code so that instead
of using a mutex in the start method and destructor it uses a
OpenThreads::Block in the Thread::start() method and static
StartThread() function such that the thread that calls the
thread->startThread() will be held back until the new thread has been
successfully started.  With this change I'm now able to run the
osgunittest thread test 1000 times without error (I use a repeat
script to do this).

I have also rolled these changes into Windows and IRIX spoc code
paths, revert the previous Mutex based code.

Could you check out the latest version in SVN and let me know if this
problem is now properly fixed.

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

Re: [osg-users] OpenSceneGraph-2.1.12 dev version released

[Robert Osfield]

On 9/25/07, Paul Melis <[EMAIL PROTECTED]> wrote:
> Builds fine here on FC4. One remark: the pkgconfig file for OSG contains
> an incorrect version number (2.1.11)

Thanks for the note.   Having version numbers all around the place is
a problem... I'll have to write a script to update them all.

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

Re: [osg-users] OSG crash in OpenThreads::ScopedLock

[Gert van Maren]

Hi Robert,

I forgot: this latest crash happens on exiting the app.

Gert


Used the latest SVN. Getting the occasional crash in release now. No crash
in debug yet.

>   msvcr71.dll!_lock_fhandle(int fh=4)  Line 453   C
msvcr71.dll!_close(int fh=)  Line 60 + 0x6  C
Gert



-- 
Gert van Maren

Head of Research & Development
K2Vi Virtual Reality Software
Data Interface Technologies Ltd

Phone: +64 21 2855581
Email: [EMAIL PROTECTED]
Web: http://www.k2vi.com

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

Re: [osg-users] OSG crash in OpenThreads::ScopedLock

[Gert van Maren]

Hi Robert,

Used the latest SVN. Getting the occasional crash in release now. No crash  
in debug yet.

>   msvcr71.dll!_lock_fhandle(int fh=4)  Line 453   C
msvcr71.dll!_close(int fh=)  Line 60 + 0x6  C
Gert



-- 
Gert van Maren

Head of Research & Development
K2Vi Virtual Reality Software
Data Interface Technologies Ltd

Phone: +64 21 2855581
Email: [EMAIL PROTECTED]
Web: http://www.k2vi.com

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

Re: [osg-users] OpenSceneGraph-2.1.12 dev version released

[Paul Melis]

Robert Osfield wrote:

>Hi All,
>
>I've just tagged the weekly dev release.  Links as usual can be found
>on the DeveloperReleases page:
>  
>
Builds fine here on FC4. One remark: the pkgconfig file for OSG contains 
an incorrect version number (2.1.11)

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

Re: [osg-users] OSG crash in OpenThreads::ScopedLock

[Robert Osfield]

On 9/25/07, Gert van Maren <[EMAIL PROTECTED]> wrote:
> I grabbed the latest dev release 2.1.12. Does this have your changes or do
> I need to grab the SVN?

The changes were checked in before 2.1.12.

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

Re: [osg-users] FBO

[Robert Osfield]

Hi Guy,

If you destroy a window then all the OpenGL objects associated with it
will be removed.  If you are using 2.0/osgViewer it should be able to
automatically release the OpenGL objects and reallocated them on the
new graphics context.

Which verison of the OSG/viewer library are you using?

Robert.

On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>  in my application I have the scene graph in some variable, and a camera in
> another variable, then I attach it to viewer, in multi-document window.
> After I close the window, the scene graph & the camera are still alive.
> The next time I want to attach them to a new window I get OpenGL error that
> the frame buffer object is not complete (and nothing is drawn), so I wanted
> to force the renderstage to re-create it, and achieved this by setting the
> rendering cache of the existing camera to NULL.
>
> I just wanted to know if there is another and better way to deal with this
> problem, and also if you know why the FBO was defected after the window was
> closed.
>
> thanks,
>  Guy.
> - Original Message -
> From: "Robert Osfield" <[EMAIL PROTECTED]>
> To: "OpenSceneGraph Users" 
> Sent: Monday, September 24, 2007 3:04 PM
> Subject: Re: [osg-users] FBO
>
>
> > Hi Guy,
> >
> > Have a look at the osgprerender example.  You shouldn't need to set
> > anything related to the render cache is this is managed internally.
> >
> > Robert.
> >
> > On 9/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > OK, I got over it but I'm not sure that was the best way.
> > > What I did was to set the camera rendering cache (for the related
> contextID)
> > > to NULL, so the next time the cull visitor applied on the camera, it
> > > recreated the FBO. Any other ideas?
> > > thanks,
> > >  Guy.
> > >
> > > - Original Message -
> > > From: [EMAIL PROTECTED]
> > > To: osg-users@lists.openscenegraph.org
> > > Sent: Monday, September 24, 2007 1:51 PM
> > > Subject: [osg-users] FBO
> > >
> > >
> > > Hi,
> > >  How do I enforce a camera to recreate FBO attached to the color buffer?
> > >
> > > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG crash in OpenThreads::ScopedLock

[Gert van Maren]

Hi Robert,

> In your code are you dynamically setting up text in the update phase,
> and loading a paged database?

Yes.

> across a few weeks back.  I suspect the failure mode is that two
> threads are using ref/unreffing the Registry's Option object at one
> time resulting in problems.  If this is correct the changes I've just
> checked in "should" fix this particular problem.
> Could you do an svn update and let me know how you get on?

I grabbed the latest dev release 2.1.12. Does this have your changes or do  
I need to grab the SVN?

Gert

-- 
Gert van Maren

Head of Research & Development
K2Vi Virtual Reality Software
Data Interface Technologies Ltd

Phone: +64 21 2855581
Email: [EMAIL PROTECTED]
Web: http://www.k2vi.com

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

Re: [osg-users] osg-users osgviewerQT

[Robert Osfield]

Hi Jim,

I suspect this problem is down to stupid bit of behavior under OSX
that Apple decided was a good idea... basically you have to tell the
OS that you actually want events in your application.
osgViewer::GraphicsWindowCarbon has a call to do this, this must be
missing from QT.  The alternative to this call is to provide a
resource file which seems to be the "official" Apple but still crap
way of doing this.

Robert.

On 9/25/07, James E. Hopper <[EMAIL PROTECTED]> wrote:
>
> David,
>
> I have an intel mac powerbook.  i built using qmake.  i created this pro
> file:
>
> --
>
>
>
> TEMPLATE = app
> TARGET =
> DEPENDPATH += .
> INCLUDEPATH += .
>
> # Input
> SOURCES += osgviewerQT.cpp
> QT   += opengl
> DEFINES = USE_QT4
> mac {
> LIBS = -framework OpenThreads -framework osg -framework osgDB \
>  -framework osgGA -framework osgViewer -framework osgUtil \
>  -framework osgText
> }
>
>
> --
>
>
> then i did
>
> qmake -spec macx-xcode osgviewerQT.pro
>
>
> this creates an xcode project which i then build and ran.
>
> the window comes up with the model in it.  from debugger i know that QT
> events are happening and being passed to OSG's GraphicsWindow   The timer is
> firing and updategl is being called which calls the paint method, which
> calls frame().  However nothing is changing in the display. its like its
> ignoring the mouse, or the frame() call is doing nothing.  So perhaps the
> events are not being passed properly?
>
>   i notice that there is a graphicswindowcarbon in the osg source, but no
> example seems to use it.  should it be perhaps used to get proper events to
> OSG?
>
> thanks jim
>
>
> 2007/9/24, James E. Hopper :
> >
> > David/Robert,
> >
> > i am on mac.  must be a mac issue.
>
>
> probably.
> Other mac-user, have you the same problem?
>
>
>   i have the same problem with the
> > MDI demo that someone else on the list had posted.
>
>
>
> MDI demo work well for me.
> Which Qt4 version are you used ?
> Can you give more info on you plateform ?
>
>
>
> ___
> 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] OpenThreads threading bug on creation/deletion (leads to crashes)

[Robert Osfield]

Hi Adam,

On 9/24/07, Adam Coates <[EMAIL PROTECTED]> wrote:
> It looks like there's still a problem with the current setup.  The
> Thread object itself can get deleted before the pthread actually gets
> to the lock (which, I guess is what you just added).

If I understand correctly you are saying that the Thread object is
being deleted before the static StartThread function gets called.   In
this case its rather an awkward problem to solve.  Perhaps one could
have lock made in the Thread::startThread method that is unlocked by
the static StartThread function once it's complete.

> While it looks
> like this doesn't cause a crash, the problem is evidenced by valgrind
> (reports uninitalized memory reads/writes to the lock -- which got
> freed by the Thread destructor).
>
> You seem like you're pretty busy, so if you want, I can take a crack
> at this -- I think the Thread code is simple enough, but I'll need to
> think a bit to figure out how to get around this.  One (simple)
> solution is to just join() the thread from the ~Thread() destructor.

I expect the valgrind warnings are unrelated to this start problem.

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