Re: [osg-users] Particles being culled
I've ported Joseph's particle tutorial to osg version 2.4 and it works perfectly on my side. I'll try to find out the cause of this culling, thanks for the help so far. Date: Thu, 26 Jun 2008 23:14:04 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I'm totally guessing, but perhaps setting the max particle size smaller and the number of particles larger will help, as perhaps your particles are large enough to be touching the terrain and thereby being culled? More smaller particles might show some noticable difference...again, I'm totally guessing. I hope someone else can provide some help here. Are Joseph's tutorials up to date even? I haven't looked there in a long time. Sorry can't be more help. -c 2008/6/26 CG [EMAIL PROTECTED]: Hi Charles, Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrain, some of the particles will get culled. How does a terrain affect the particles? Regards, Cg Date: T hu, 26 Jun 2008 21:18:51 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Well, make a bare-bones test program and isolate the cause, and post it if necessary (in a new thread so someone else is compelled to jump in and help you!). It looks like, to me, that they are just rotated, not culled. Also, I guess you're using the connected system, and I didn't really look at that class ... try the bare-bones debug program! Good luck, Charles 2008/6/26 CG [EMAIL PROTECTED]: Hi Charles, That didn't work too. Just don't seem to see what is culling the particles? Regards, Cg Date: Thu, 26 Jun 2008 08:14:55 -0600 From: [EMAIL PROTECTED] om To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled CG: One more tr y: I'm just looking at old code b/c I know I've had a similar problem...and I didn't notice the next line of my code: ps-SetAlignVectorX(osg::Vec3(0.,1.,0.)); Hopefully that'll make a difference. -Charles On Thu, Jun 26, 2008 at 6:24 AM, Charles Cossé [EMAIL PROTECTED] wrote:Sorry, then, I tried ... maybe you should repost so Robert sees it.Charles On Thu, Jun 26, 2008 at 3:08 AM, CG [EMAIL PROTECTED] wrote:Hi Charles, I've tried the setParticleAlignment and it didn't work . Regards,Cg ___ _Date: Wed, 25 Jun 2008 23:28:53 -0600 From: [EMAIL PROTECTED]To: osg-users@lists.openscenegraph.orgSubject: Re: [osg-users] Particles being culled try: ps-setParticleAlignment(osgParticle::ParticleSys tem::BILLBOARD); On Wed, Jun 25, 2008 at 11:23 PM, CG [EMAIL PROTECTED] wrote: Hi Charles, Thanks for the reply, what are the settings for the eye point facing? BRRegards, Cg Date: Wed, 25 Jun 2008 23:18:07 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are facing g t; different directions. On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrote: Hi all, I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes? Thanks, Cg gt; Make the most of what you can do on your PC and the Web, just the way you want. Windows Live ___ BR osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-o penscenegraph.orggt ; gt ; -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Share your beautiful moments with Photo Gallery. Windows Live Photo Gallery gt ; ___ osg-users mailing list g t; osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on Rendering Streaming video
Hi, some code snippets: [EMAIL PROTECTED] wrote: Hey uli, What do you mean by getting a nice image from that is a b??ch? Is the image quality reduced? Not sure what de-bayer algorithm I'm going to use. I have the source for one that we have used before but I'm not sure how it will work on a shader. Is there an example of an osg::PixelBufferObject being used to stream to an Image?? How is one attached to the image? _VideoImage[i]-setImage(cameraImageWidth, cameraImageHeight, 1, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE, gImage[i], osg::Image::NO_DELETE); _VideoImage[i]-setPixelBufferObject(new osg::PixelBufferObject(_VideoImage[i].get())); Also, about the non-power of 2 textures can I make the texture scaled to the nearest power of two and just modify the texture coordinates on the quad? Will doing this avoid the CPU scalling of the texture? I just turn the scaling on CPU off: _VideoTexture[i]-setImage(_VideoImage[i].get()); _VideoTexture[i]-setResizeNonPowerOfTwoHint(false); -Steve jp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Hertlein Sent: Wednesday, June 25, 2008 10:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Advice on Rendering Streaming video [EMAIL PROTECTED] wrote: I've already set up an orthographic2D view that will look at a quad which will display the texture. The shader will then convert the texture into RGB and do the whitebalance. I am also able to swap the texture back and forth and maintain decent frame rates but the textures I'm using to test are only 64x64 pixels (tank.rgba and water.rgba) and I'm wondering if it would be too slow (30fps) to use the same method for 1000x1000 pixel images. The texture bandwidth isn't likely to be a problem, keep in mind that bayer images are only 1/3 of an RGB image of the same size. Things to look out for is to use non-power-of-two textures or texture rectangles to avoid CPU scaling of the image. You'll also want to attach a osg::PixelBufferObject to the osg::Image. Unfortunately getting a nice image from that is a b??ch and the shaders can get complex pretty fast, the number of texture lookups is probably the most expensive op. What de-bayer algorithms are you looking at? Cheers, /uli ___ 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 -- 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
Re: [osg-users] Paged simulation and culling performance drop
The requests queuing in the database pager didn't work. Robert Osfield wrote: On Thu, Jun 26, 2008 at 5:48 PM, Lionel Lagarde [EMAIL PROTECTED] wrote: It didn't work !!! What didn't work?? I've queued the database requests in the requestNodeFile method. These requests are merged in the DatabasePager lists in the run method using a little lock (just the time of a pop). Continuing my investigations ... ___ 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] LODScaleHandler crash on unref
Hi Robert, This fix is working great !!! No more texture disappearing. Kind regards, 2008/6/26 Robert Osfield [EMAIL PROTECTED]: On Thu, Jun 26, 2008 at 4:42 PM, amalric alexandre [EMAIL PROTECTED] wrote: 2nd Problem : I'm glad that you have reproduced the bug, loosing texture seems to me connected to context ID too, but I hadn't the time to go further. I've tracked down the problem to the reuse of contextID, something in itself was working correctly, but the subgraphs below the cameras weren't been modified to account for the removal of the previous contexts. The OSG already has a mechanism to help clean up a the scene graph to avoid these types of problems, but in this particular usage combination the required relaseGLObjects() wasn't been called. I have now changed the GraphicsContext::removedCamera() method to it works out which subgraphs need the releaseGLObjects() called upon, this fixes the texture/display lists issues you've seen. The changed GraphicsContext.cpp is attached, and also checked in to SVN. Could you please try it out at your end and confirm whether it's fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgthirdpersonview crashes on Linux
I want to let you known that on Linux Suse 10.3, with last minute SVN, osgthirdpersonview
crashes after few seconds of manipulation or almost immediately in gdb (compiled
RelWithDebInfo).
This happens with no arguments or specifying
--CullThreadPerCameraDrawThreadPerContext
does not happens with the other threading models.
$ gdb osgthirdpersonview
... bla bla...
This GDB was configured as i586-suse-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r
Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview
[Thread debugging using libthread_db enabled]
[New Thread 0xb6a19910 (LWP 29454)]
/local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified files. Trying
cow.osg instead.
[New Thread 0xb5f1fb90 (LWP 29461)]
[New Thread 0xb571eb90 (LWP 29462)]
[New Thread 0xb4f1db90 (LWP 29463)]
[New Thread 0xb471cb90 (LWP 29464)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5f1fb90 (LWP 29461)]
0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
28 ref_ptr(const ref_ptr rp) : _ptr(rp._ptr) { if (_ptr)
_ptr-ref(); }
(gdb) where
#0 0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
#1 0xb7e8f331 in osg::OperationThread::run (this=0x814b190)
at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:399
#2 0xb7f64093 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x814b19c)
at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170
#3 0xb7a1a192 in start_thread () from /lib/libpthread.so.0
#4 0xb761a02e in clone () from /lib/libc.so.6
(gdb)
Hope this helps
mario
--
Ing. Mario Valle
Data Analysis and Visualization Services | 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
Re: [osg-users] Particles being culled
Hi, maybe check what texture units are used by terrain and particles. jp CG wrote: I've ported Joseph's particle tutorial to osg version 2.4 and it works perfectly on my side. I'll try to find out the cause of this culling, thanks for the help so far. Date: Thu, 26 Jun 2008 23:14:04 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I'm totally guessing, but perhaps setting the max particle size smaller and the number of particles larger will help, as perhaps your particles are large enough to be touching the terrain and thereby being culled? More smaller particles might show some noticable difference...again, I'm totally guessing. I hope someone else can provide some help here. Are Joseph's tutorials up to date even? I haven't looked there in a long time. Sorry can't be more help. -c 2008/6/26 CG [EMAIL PROTECTED]: Hi Charles, Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrai n, some of the particles will get culled. How does a terrain affect the particles? Regards, Cg Date: Thu, 26 Jun 2008 21:18:51 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Well, make a bare-bones test program and isolate the cause, and post it if necessary (in a new thread so someone else is compelled to jump in and help you!). It looks like, to me, that they are just rotated, not culled. Also, I guess you're using the connected system, and I didn't really look at that class ... try the bare-bones debug program! Good luck, Charles 2008/6/26 CG [EMAIL PROTECTED] gt;: Hi Charles, That didn't work too. Just don't seem to see what is culling the particles? Regards, Cg Date: Thu, 26 Jun 2008 08:14:55 -0600 From: [EMAIL PROTECTED] om To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled CG: One more try: I'm just looking at old code b/c I know I've had a similar problem...and I didn't notice the next line of my code: ps-SetAlignVectorX(osg::Vec3(0.,1.,0.)); Hopefully that 'll make a difference. -Charles On Thu, Jun 26, 2008 at 6:24 AM, Charles Cossé [EMAIL PROTECTED] wrote: Sorry, then, I tried ... maybe you should repost so Robert sees it. Charles On Thu, Jun 26, 2008 at 3:08 AM, CG [EMAIL PROTECTED] wrote: Hi Charles, I've tried the setParticleAlignment and it didn't work . Regards, Cg ___ _ Date: Wed, 25 Jun 2008 23:28:53 -0600 gt; From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled try: ps-setParticleAlignment(osgParticle::ParticleSystem::BILLBOARD); On Wed, Jun 25, 2008 at 11:23 PM, CG [EMAIL PROTECTED] wrote: Hi Charles, Thanks for the reply, what are the settings for the eye point facing? BR Regards, Cg gt; Date: Wed, 25 Jun 2008 23:18:07 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are facing ; g t; different directions. On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrote: Hi all, I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes? Thanks, Cg gt; Make the most of what you can do on your PC and the Web, just the way you want. Windows Live ___ BR osg-users mailing list gt; osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org gt ; gt ; -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org
Re: [osg-users] Advice on Rendering Streaming video
Hi Steve, [EMAIL PROTECTED] wrote: What do you mean by getting a nice image from that is a b??ch? Is the image quality reduced? No, I'm just talking about the problem that the bayer image is missing two channels for every pixel and you have to somehow come up with those values. Also, about the non-power of 2 textures can I make the texture scaled to the nearest power of two and just modify the texture coordinates on the quad? Will doing this avoid the CPU scalling of the texture? Yes, that will work as well. You can use that when the hardware doesn't support NPOT (or texture rectangles). Cheers, /uli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
CG wrote: Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrain, some of the particles will get culled. How does a terrain Are you sure it's actually a culling problem and not maybe depth buffer precision? The screenshot didn't make that entirely clear. How do the terrain sizes compare? Is yours maybe larger? /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD and IntersectionVisitor
Hi Paul, On Thu, Jun 26, 2008 at 8:25 PM, Paul Martz [EMAIL PROTECTED] wrote: Switch derives from Group, and if I create a Switch and set all its children on, I think we can all agree that it should act just like Group. In the same way, since PagedLOD derives from LOD, once all its children are loaded, I'd expect it to work just like LOD. But this isn't what I see. Sorry but you can't make a PagedLOD work just like a LOD. Yes it's related but not identical as it has to have extra constraints to enable the ability to have fallback mechanism that is essential to PagedLOD. If you want LOD that has children that are paged in a uniform way than using LOD with ProxyNode as children is what you should do. Attached are two files, identical except that one uses an LOD and the other uses a PagedLOD. Run osgpick on both, and you'll see that it works fine for the PagedLOD case, but fails to pick anything for the LOD case. I suspect the problem is in how IntersectionVisitor has completely different logic for both LOD and PagedLOD, but without understanding the difference, I'm not inclined to tinker with the code. What do you make of it? Is the LOD test case just a badly-formed LOD because the max range doesn't go to zero distance? If so, again, this is a restriction of LOD usage that I'm not aware of, nor do I understand why it isn't also a restriction on PagedLOD usage... What I make of it is you a flogging the PagedLOD because it can handle misuse of it. Fix the database. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi J-S, On Thu, Jun 26, 2008 at 8:17 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: OSG SVN on Windows Vista, VS8, CMake 2.4.8 and 2.6, builds and runs fine. VPB SVN on Windows Vista, VS8, CMake 2.6 (didn't take time to test on 2.4.8), builds and runs fine. I'll test on my Ubuntu Virtualbox, but I suspect that's a bit unnecessary... Just being thorough. :-) Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Hi Wojtek,
I believe the Image::readPixels and Image::allocateImage are valid,
changes these because of some high level behaviour is going amiss due
to it relying upon a parameter that is modified on the fly suggest to
me that perhaps the high level code is at fault i.e. the Camera
attachments/FBO setup perhaps needs to be refactored slightly.
Robert.
On Thu, Jun 26, 2008 at 9:33 PM, Wojciech Lewandowski
[EMAIL PROTECTED] wrote:
Hi Robert,
I am not sure if this is a bug, but in my opinion Image::allocateImage
should not change internalTextureFormat or at least Image::readPixels
should
record and restore internalFromat after calling allocateImage.
I don't follow, are we talking about the the format in osg::Image or
the texture?
Sorry for being imprecise. All the time I was talking about
osg::Image::_internalTextureFormat member.
I may submit a fix but I am not sure what is desired course of action.
Should I remove the line changing it from Image::allocateImage or rather
modify Image::readPixels to preserve it from modification when
Image::allocateImage is called ? See the bits of code that could be
affected, below.
osg::Image::allocateImage is called from Image::readPixels, Line 608
[...]
void Image::readPixels(int x,int y,int width,int height,
GLenum format,GLenum type)
{
allocateImage(width,height,1,format,type);
glPixelStorei(GL_PACK_ALIGNMENT,_packing);
glReadPixels(x,y,width,height,format,type,_data);
}
[...]
osg::Image::_internalTextureFormat modified in:
Image.cpp, Image::allocateImage( int s,int t,int r, GLenum format,GLenum
type, int packing), Line 556
[...]
if (_data)
{
_s = s;
_t = t;
_r = r;
_pixelFormat = format;
_dataType = type;
_packing = packing;
_internalTextureFormat = format;
}
[...]
Image::_internalTextureFormat is used (through getInternalTextureFormat
accessor method) to select Renderbuffer format:
FrameBufferObject.cpp,
FrameBufferAttachment::FrameBufferAttachment(Camera::Attachment
attachment), Line 365:
[...]
osg::Image* image = attachment._image.get();
if (image)
{
if (image-s()0 image-t()0)
{
GLenum format = attachment._image-getInternalTextureFormat();
if (format == 0)
format = attachment._internalFormat;
_ximpl = new Pimpl(Pimpl::RENDERBUFFER);
_ximpl-renderbufferTarget = new osg::RenderBuffer(image-s(),
image-t(), format);
[...]
Cheers,
Wojtek
___
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] osgFX : Cartoon effect problem with textured object
Hi Mathieu, Thanks for your answer. I had a look in osgFX/Cartoon.cpp but I didn't realy find how I can manage it. I think I'm not a expert in Cartoon rendering with OSG. I must contact the creator of osgFX/Cartoon.cpp for help. But I think it could be useful for certain user to have this feature direclty in OSG. Perharps for a next release. Best regards, Arnaud ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple models, single texture
Hi Terry, On Fri, Jun 27, 2008 at 5:01 AM, Terry Welsh [EMAIL PROTECTED] wrote: Is it possible to load multiple model files that use the same texture but only have the texture get loaded once? It seems like a good way to save memory and reduce state changes. The loaders don't cache images and textures, but it is possible to combine duplicate state once the data is loaded. The osgUtil::Optimize::RemoveDuplicateState can be used on a whole scene graph, and the osgDB::SharedStateManager can be used when you are incrementally loading subgraphs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Paged simulation and culling performance drop
On Fri, Jun 27, 2008 at 8:10 AM, Lionel Lagarde [EMAIL PROTECTED] wrote: The requests queuing in the database pager didn't work. I really do think your problems will be solved by moving to the SVN version of the OSG, and rather than waste time looking into a problem that has already been solved just try out the latest in SVN, even if its just to to check that osgviewer runs your database without hiccups, once you've established that the problem is solved then you can make your plan. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Hi Mario,
What is your hardware setup? Is it 32bit or 64bit build?
Robert.
On Fri, Jun 27, 2008 at 8:21 AM, Mario Valle [EMAIL PROTECTED] wrote:
I want to let you known that on Linux Suse 10.3, with last minute SVN,
osgthirdpersonview crashes after few seconds of manipulation or almost
immediately in gdb (compiled RelWithDebInfo).
This happens with no arguments or specifying
--CullThreadPerCameraDrawThreadPerContext
does not happens with the other threading models.
$ gdb osgthirdpersonview
... bla bla...
This GDB was configured as i586-suse-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r
Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview
[Thread debugging using libthread_db enabled]
[New Thread 0xb6a19910 (LWP 29454)]
/local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified
files. Trying cow.osg instead.
[New Thread 0xb5f1fb90 (LWP 29461)]
[New Thread 0xb571eb90 (LWP 29462)]
[New Thread 0xb4f1db90 (LWP 29463)]
[New Thread 0xb471cb90 (LWP 29464)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5f1fb90 (LWP 29461)]
0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
28 ref_ptr(const ref_ptr rp) : _ptr(rp._ptr) { if (_ptr)
_ptr-ref(); }
(gdb) where
#0 0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
#1 0xb7e8f331 in osg::OperationThread::run (this=0x814b190)
at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:399
#2 0xb7f64093 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x814b19c)
at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170
#3 0xb7a1a192 in start_thread () from /lib/libpthread.so.0
#4 0xb761a02e in clone () from /lib/libc.so.6
(gdb)
Hope this helps
mario
--
Ing. Mario Valle
Data Analysis and Visualization Services |
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurat ions in aseparateConfig include file
Hi, On Friday 27 June 2008 05:48, James Killian wrote: [MemoryBarrier on available on msvc71] Hmm, I am unsure about that. Reading msdn, MemoryBarrier appears to be present on Vista and newer. But given that I do not use vista and it appears to be dependent on the compiler and sdk version, I am a little unsure under which define we should put that. Somebody with more win32 experience than me: Which preprocessor variable can I check here to make sure that the usage of that MemoryBarrier function/macro is guaranteed to be present? What DOES work, is the config file detecting interlocked (as you verified), I wonder why the use float bounding box and use float bounding sphere are float by default... perhaps this is a general default for all platforms. I've been using double instead, and things run fine. They were. Change it in the cmake configuration if you need. GReetings MAthais -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash with CompositeViewer on Win32
Hi Robert, Thanks for the hint, it seems to be my fault. I opened the OpenThreads/Config file to see the method used, and everything was commented... I hade to remove my CMakeCache.txt to have the file generated again and use the atomic pointers. Now it works like a charm ! On Thu, Jun 26, 2008 at 4:54 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Serge, On Thu, Jun 26, 2008 at 3:43 PM, Serge Lages [EMAIL PROTECTED] wrote: Forget to mention, in release before the crash I had this message : Warning: deleting still referenced object 0145DFF8 of type 'class osg::Referenced *' the final reference count was 2, memory corruption possible. It seems someone force the delete of the SwapBuffersOperation... It's sounds like reference counting has going awol on this object, this particular object is no different than any other osg::GraphicsOperation/osg::Operation, and which just subclass from osg::Referenced. There isn't any codes that do explicit calls to delete graphics operations, including SwapBuffersOperation, and as I believe all usage of them will be going via osg::ref_ptr, so it does sound like for some reason reference count is getting corrupted. Could this be related to Mathias' recent changes? Could you tweak your OpenThreads/Config so that OpenThreads/OSG build using the old slow Mutexed reference counting? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hi,
Sorry, I'm lost here, how do I check the texture units?Reards,Cg
Date: Fri, 27 Jun 2008 09:17:59 +0200 From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being
culled Hi, maybe check what texture units are used by terrain and
particles. jp CG wrote: I've ported Joseph's particle tutorial to
osg version 2.4 and it works perfectly on my side. I'll try to find out
the cause of this culling, thanks for the help so far.
Date: Thu, 26 Jun 2008 23:14:04 -0600 From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles
being culled I'm totally guessing, but perhaps setting the max
particle size smaller and the number of particles larger will help, as
perhaps your particles are large enough to be touching the terrain and
thereby being culled? More smaller particles might show some noticable
difference...agai
n, I'm totally guessing. I hope someone else can provide some help here.
Are Joseph's tutorials up to date even? I haven't looked there in a long
time. Sorry can't be more help. -c 2008/6/26 CG [EMAIL
PROTECTED]:Hi Charles, Thanks for your help, I've
narrowed it down to my terrain, when I useJoseph's terrain, the
particles look good. But when I switch over to myterrai n, some of the
particles will get culled. How does a terrain affectthe particles?
Regards,Cg
Date: Thu, 26 Jun 2008 21:18:51 -0600From: [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.orgSubject: Re: [osg-users]
Particles being culled Well, make a bare-bones test program and
isolate the cause, and postit if necessary (in a new thread so someone
else is compelled to jumpin and help you!). It looks lik
e, to me, that they are just rotated,not culled. Also, I guess you're
using the connected system, and Ididn't really look at that class ...
try the bare-bones debug program!Good luck,Charles
2008/6/26 CG [EMAIL PROTECTED] gt;: Hi Charles,
That didn't work too. Just don't seem to see what is culling the
particles? Regards, Cg
Date: Thu, 26 Jun 2008 08:14:55
-0600 From: [EMAIL PROTECTED] om To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users]
Particles being culled CG: One more try: I'm
just looking at old code b/c I know I've had a similar problem...and
I didn't notice the next line of my code:
ps-SetAlignVectorX(osg::Vec3(0.,1.,0.)); Hopefully that
'll make a differ
ence. -Charles On Thu, Jun 26, 2008 at 6:24
AM, Charles Cossé [EMAIL PROTECTED] wrote: Sorry,
then, I tried ... maybe you should repost so Robert sees it.
Charles On Thu, Jun 26, 2008 at 3:08 AM, CG [EMAIL
PROTECTED] wrote: Hi Charles, I've
tried the setParticleAlignment and it didn't work .
Regards, Cg ___
_ Date: Wed, 25 Jun 2008 23:28:53 -0600
gt; From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users]
Particles being culled try:
ps-setParticleAlignment(osgParticle::ParticleSystem::BILLBOARD);
On Wed, Jun 25, 2008 at 11:23 PM, CG [EMAIL
PROTECTED] wrote:
Hi Charles, Thanks for the
reply, what are the settings for the eye point
facing? BR Regards,
Cg gt;
Date:
Wed, 25 Jun 2008 23:18:07 -0600 From:
[EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Particles being culled
I think the default for particle
systems is that particles are little
billboards which always face the viewer's
eye point. It looks like
you've undone that setting somehow, and that the
billboards are facing ; g t;
different directions.
On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrot
e:Hi all, I'm
trying to simulate a smoke trail emitting from a moving
tankbyusing
Joseph's codes but some particles are being culled (see
attachedpicture).Any ideas what are
the causes? Thanks,
Cg gt;
Make the most of what you
can do on your PC and the Web, justthe
wayyouwant. Windows Live
___ BR
osg-users
Re: [osg-users] Crash with CompositeViewer on Win32
On Fri, Jun 27, 2008 at 9:49 AM, Serge Lages [EMAIL PROTECTED] wrote: Thanks for the hint, it seems to be my fault. I opened the OpenThreads/Config file to see the method used, and everything was commented... I hade to remove my CMakeCache.txt to have the file generated again and use the atomic pointers. Now it works like a charm ! Good to hear things are working again. I wonder if the Config file generated initially was incorrect, then CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. It might be that others will come up against the same issue during this transition between pre Config/Atomic days and what we have now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi, compiled r8504 on Debian sid, g++-4.3, cmake 2.6, core 2 duo 32-bit, NVidia 173.14.09. cmake said: -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS - Success compiled fine. osgthirdpersonview has been running for a while, seems OK. jp Robert Osfield wrote: Hi J-S, On Thu, Jun 26, 2008 at 8:17 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: OSG SVN on Windows Vista, VS8, CMake 2.4.8 and 2.6, builds and runs fine. VPB SVN on Windows Vista, VS8, CMake 2.6 (didn't take time to test on 2.4.8), builds and runs fine. I'll test on my Ubuntu Virtualbox, but I suspect that's a bit unnecessary... Just being thorough. :-) Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) Robert. ___ 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
Re: [osg-users] osgthirdpersonview crashes on Linux
Hi Mario, Look at the experience of other engineers it now looks like the Atomic generation may have not worked correctly on an early SVN version, but even with an SVN update the associated Config file wasn't updated to correct itself. Could you try removing your OpenSceneGraph/CMakeCache.txt and then doing a ./configure;make and then see if the problem persists. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hi, sorry, I was just guessing at possible problems. We have had problems with overlays and terrain texture units clashing, but I'm not sure it is related to particle system and terrain. OverlayNode-setOverlayTextureUnit(1); Terrain texture units can in newer osgdem be set with layer option. In other code you can look for: setTextureAttributeAndModes(0,texture.get(),osg::StateAttribute::ON); jp CG wrote: Hi, Sorry, I'm lost here, how do I check the texture units? Reards, Cg Date: Fri, 27 Jun 2008 09:17:59 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Hi, maybe check what texture units are used by terrain and particles. jp CG wrote: I've ported Joseph's particle tutorial to osg version 2.4 and it works perfectly on my side. I'll try to find out the cause of this culling, thanks for the help so far. Date: Thu, 26 Jun 2008 23:14:04 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I'm totally guessing, but perhaps setting the max particle size smaller an d the number of particles larger will help, as perhaps your particles are large enough to be touching the terrain and thereby being culled? More smaller particles might show some noticable difference...again, I'm totally guessing. I hope someone else can provide some help here. Are Joseph's tutorials up to date even? I haven't looked there in a long time. Sorry can't be more help. -c 2008/6/26 CG [EMAIL PROTECTED]: Hi Charles, Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrai n, some of the particles will get culled. How does a terrain affect the particles? Regards, Cg Date: Thu, 26 Jun 2008 21:18:51 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Well, make a bare-bones test program and isolate the cause, and post it if necessary (in a new thread so someone else is compelled to jump in and help you!). It looks like, to me, that they are just rotated, not culled. Also, I guess you're using the connected system, and I didn't really look at that class ... try the bare-bones debug program! Good luck, Charles 2008/6/26 CG [EMAIL PROTECTED] gt;: Hi Charles, That didn't work too. Just don't seem to see what is culling the particles? Regards, Cg Date: Thu, 26 Jun 2008 08:14:55 -0600 From: [EMAIL PROTECTED] om To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled CG: One more try: I'm just looking at old code b/c I know I've had a gt; similar problem...and I didn't notice the next line of my code: ps-SetAlignVectorX(osg::Vec3(0.,1.,0.)); Hopefully that 'll make a difference. -Charles On Thu, Jun 26, 2008 at 6:24 AM, Charles Cossé [EMAIL PROTECTED] wrote: Sorry, then, I tried ... maybe you should repost so Robert sees it. Charles On Thu, Jun 26, 2008 at 3:08 AM, CG [EMAIL PROTECTED] wrote: Hi Charles, I've tried the setParticleAlignment and it didn't work . Regards, Cg ___ _ Date: Wed, 25 Jun 2008 23:28:53 -0600 gt; From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled try: ps-setParticleAlignment(osgParticle::ParticleSystem::BILLBOARD); gt; On Wed, Jun 25, 2008 at 11:23 PM, CG [EMAIL PROTECTED] wrote: Hi Charles, Thanks for the reply, what are the settings for the eye point facing? BR Regards, Cg gt; Date: Wed, 25 Jun 2008 23:18:07 -0600 From: [EMAIL PROTECTED] gt; To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are
Re: [osg-users] Crash with CompositeViewer on Win32
I think the time laps when CMake was generating erroneous Config file under Windows was very short, and I had no luck by building at this moment. But having the ability to force CMake to regenerate this kind of file should be useful in the future if others modifications come. On Fri, Jun 27, 2008 at 11:04 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Fri, Jun 27, 2008 at 9:49 AM, Serge Lages [EMAIL PROTECTED] wrote: Thanks for the hint, it seems to be my fault. I opened the OpenThreads/Config file to see the method used, and everything was commented... I hade to remove my CMakeCache.txt to have the file generated again and use the atomic pointers. Now it works like a charm ! Good to hear things are working again. I wonder if the Config file generated initially was incorrect, then CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. It might be that others will come up against the same issue during this transition between pre Config/Atomic days and what we have now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Hi Mario, It really seems to be the same problem as me, just remove your CMake cache to be sure that the OpenThread/Config file will be regenerated. On Fri, Jun 27, 2008 at 11:19 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Mario, Look at the experience of other engineers it now looks like the Atomic generation may have not worked correctly on an early SVN version, but even with an SVN update the associated Config file wasn't updated to correct itself. Could you try removing your OpenSceneGraph/CMakeCache.txt and then doing a ./configure;make and then see if the problem persists. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Updating the OSG reference manual (doxygen pages)
Hi all, I have found that the bast way to look up in the reference manual is to google classes with their namespaces. E.g. if I need information on the class osgUtil::Optimizer then I just google that name and the first hit is almost always the OpenSceneGraph Class Reference for that class. However, several classes are missing because the last time http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/index.html was generated was at Fri Jun 15 16:28:09 2007 (a little more than a year ago) If someone with web server access could update these doxygen pages to reflect the latest stable release, I - for one - would be very happy. Best regards, John PS: I know that I can generate the doxypages locally (have done so), but it is not the same without the search engine;) I am not a stranger to studying code either, but the reference manual is helpful for getting a quick overview. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RSS feed for ProjectNews
Hi, Is there a way to get a RSS feed for http://www.openscenegraph.org/projects/osg/wiki/News/ProjectNews After talking with #trac peoples, it seems that something like http://trac-hacks.org/wiki/FullBlogPlugin or http://trac-hacks.org/wiki/TracBlogPlugin would allow this. Thanks in advance. -- Johan Euphrosine [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Updating the OSG reference manual (doxygen pages)
Hi John, I do plan to update the docs, just been rushed off my feet. Once we get OSG SVN stabilised and 2.5.3 out the door I'll look at getting the docs updated. Robert. On Fri, Jun 27, 2008 at 10:47 AM, John Vidar Larring [EMAIL PROTECTED] wrote: Hi all, I have found that the bast way to look up in the reference manual is to google classes with their namespaces. E.g. if I need information on the class osgUtil::Optimizer then I just google that name and the first hit is almost always the OpenSceneGraph Class Reference for that class. However, several classes are missing because the last time http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/index.html was generated was at Fri Jun 15 16:28:09 2007 (a little more than a year ago) If someone with web server access could update these doxygen pages to reflect the latest stable release, I - for one - would be very happy. Best regards, John PS: I know that I can generate the doxypages locally (have done so), but it is not the same without the search engine;) I am not a stranger to studying code either, but the reference manual is helpful for getting a quick overview. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] multi threaded with slave camera and fbo
Robert,
I totaly agree that high level FBO code could be modified to avoid potential
glitches with doubling resources.
But on low level discussion, I also think that indirect modification of
internalTextureFormat in readPixels may bring trouble for pieces of code
relying on Image::getInternalTextureFormat(). I did a quick scan and these
code includes initialization of FBO Renderbuffers and initilization of
Textures (obviously).
As far as I understand Image::setInternalTextureFormat is created to let
programer decide what will be internal format of the texture and
renderbuffer created from this image. Right ?
So now imagine this case. I want to create texture with RGBA32F internal
format from an Image. I create image and set its internalTextureFormat to
RGBA32. To fill image data I call readPixels from frame buffer. Then I
create Texture from this image and surpirisngly end up with RGBA ubyte
Texture. So I wanted RGBA32F texture but got RGBA. I don't think this is OK.
Cheers,
Wojtek
Hi Wojtek,
I believe the Image::readPixels and Image::allocateImage are valid,
changes these because of some high level behaviour is going amiss due
to it relying upon a parameter that is modified on the fly suggest to
me that perhaps the high level code is at fault i.e. the Camera
attachments/FBO setup perhaps needs to be refactored slightly.
Robert.
On Thu, Jun 26, 2008 at 9:33 PM, Wojciech Lewandowski
[EMAIL PROTECTED] wrote:
Hi Robert,
I am not sure if this is a bug, but in my opinion Image::allocateImage
should not change internalTextureFormat or at least Image::readPixels
should
record and restore internalFromat after calling allocateImage.
I don't follow, are we talking about the the format in osg::Image or
the texture?
Sorry for being imprecise. All the time I was talking about
osg::Image::_internalTextureFormat member.
I may submit a fix but I am not sure what is desired course of action.
Should I remove the line changing it from Image::allocateImage or rather
modify Image::readPixels to preserve it from modification when
Image::allocateImage is called ? See the bits of code that could be
affected, below.
osg::Image::allocateImage is called from Image::readPixels, Line 608
[...]
void Image::readPixels(int x,int y,int width,int height,
GLenum format,GLenum type)
{
allocateImage(width,height,1,format,type);
glPixelStorei(GL_PACK_ALIGNMENT,_packing);
glReadPixels(x,y,width,height,format,type,_data);
}
[...]
osg::Image::_internalTextureFormat modified in:
Image.cpp, Image::allocateImage( int s,int t,int r, GLenum format,GLenum
type, int packing), Line 556
[...]
if (_data)
{
_s = s;
_t = t;
_r = r;
_pixelFormat = format;
_dataType = type;
_packing = packing;
_internalTextureFormat = format;
}
[...]
Image::_internalTextureFormat is used (through getInternalTextureFormat
accessor method) to select Renderbuffer format:
FrameBufferObject.cpp,
FrameBufferAttachment::FrameBufferAttachment(Camera::Attachment
attachment), Line 365:
[...]
osg::Image* image = attachment._image.get();
if (image)
{
if (image-s()0 image-t()0)
{
GLenum format =
attachment._image-getInternalTextureFormat();
if (format == 0)
format = attachment._internalFormat;
_ximpl = new Pimpl(Pimpl::RENDERBUFFER);
_ximpl-renderbufferTarget = new
osg::RenderBuffer(image-s(),
image-t(), format);
[...]
Cheers,
Wojtek
___
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] multi threaded with slave camera and fbo
Hi Wojtek, So now imagine this case. I want to create texture with RGBA32F internal format from an Image. I create image and set its internalTextureFormat to RGBA32. To fill image data I call readPixels from frame buffer. Then I create Texture from this image and surpirisngly end up with RGBA ubyte Texture. So I wanted RGBA32F texture but got RGBA. I don't think this is OK. This suggest to me that one needs to pass more info into Image::readPixels to control the internaltextureFormat, or possible configuring things so that allocate reuses the original setting for internaltextureFormat if its non default setting. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Hi Robert, So now imagine this case. I want to create texture with RGBA32F internal format from an Image. I create image and set its internalTextureFormat to RGBA32. To fill image data I call readPixels from frame buffer. Then I create Texture from this image and surpirisngly end up with RGBA ubyte Texture. So I wanted RGBA32F texture but got RGBA. I don't think this is OK. This suggest to me that one needs to pass more info into Image::readPixels to control the internaltextureFormat, or possible configuring things so that allocate reuses the original setting for internaltextureFormat if its non default setting. Thats exactly what I was asking for. Lets either fix Image::readPixels to preserve internalTextureFormat, or Image::allocateImage to not change it. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Hi Wojtek, On Fri, Jun 27, 2008 at 11:24 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: This suggest to me that one needs to pass more info into Image::readPixels to control the internaltextureFormat, or possible configuring things so that allocate reuses the original setting for internaltextureFormat if its non default setting. Thats exactly what I was asking for. Lets either fix Image::readPixels to preserve internalTextureFormat, or Image::allocateImage to not change it. I'm uneasy about changing the existing behaviour as we may well be fixing one problem for one set of users, but introducing problems for users that currently rely upon the existing behaviour. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
32bits, Intel(R) Xeon(TM) CPU 3.00GHz quad core 4GB RAM.
GeForce 6800 GS NVIDIA Driver Version: 169.12
Suse 10.3
Let me know if other info or other tests are needed.
Ciao!
mario
Robert Osfield wrote:
Hi Mario,
What is your hardware setup? Is it 32bit or 64bit build?
Robert.
On Fri, Jun 27, 2008 at 8:21 AM, Mario Valle [EMAIL PROTECTED] wrote:
I want to let you known that on Linux Suse 10.3, with last minute SVN,
osgthirdpersonview crashes after few seconds of manipulation or almost
immediately in gdb (compiled RelWithDebInfo).
This happens with no arguments or specifying
--CullThreadPerCameraDrawThreadPerContext
does not happens with the other threading models.
$ gdb osgthirdpersonview
... bla bla...
This GDB was configured as i586-suse-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r
Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview
[Thread debugging using libthread_db enabled]
[New Thread 0xb6a19910 (LWP 29454)]
/local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified
files. Trying cow.osg instead.
[New Thread 0xb5f1fb90 (LWP 29461)]
[New Thread 0xb571eb90 (LWP 29462)]
[New Thread 0xb4f1db90 (LWP 29463)]
[New Thread 0xb471cb90 (LWP 29464)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5f1fb90 (LWP 29461)]
0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
28 ref_ptr(const ref_ptr rp) : _ptr(rp._ptr) { if (_ptr)
_ptr-ref(); }
(gdb) where
#0 0xb7e8db78 in osg::OperationQueue::getNextOperation (this=0x814b280,
blockIfEmpty=true)
at /local/OSG/OpenSceneGraph/include/osg/ref_ptr:28
#1 0xb7e8f331 in osg::OperationThread::run (this=0x814b190)
at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:399
#2 0xb7f64093 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x814b19c)
at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170
#3 0xb7a1a192 in start_thread () from /lib/libpthread.so.0
#4 0xb761a02e in clone () from /lib/libc.so.6
(gdb)
Hope this helps
mario
--
Ing. Mario Valle
Data Analysis and Visualization Services |
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Data Analysis and Visualization Services | 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
Re: [osg-users] osgthirdpersonview crashes on Linux
On Fri, Jun 27, 2008 at 11:48 AM, Mario Valle [EMAIL PROTECTED] wrote: 32bits, Intel(R) Xeon(TM) CPU 3.00GHz quad core 4GB RAM. GeForce 6800 GS NVIDIA Driver Version: 169.12 Suse 10.3 Let me know if other info or other tests are needed. The only test is the one suggested, remove your CMakeCache.txt, rerun ./configure or ccmake . to make sure it regenerates your include/OpenThreads/Config, check the contents of this Config file to make sure its been updated to a sensible value. On my Kubuntu 64bit system I get a include/OpenThreads/Config that looks like: /* -*-c++-*- OpenSceneGraph - Copyright (C) 2008 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ / * THIS FILE IS AUTOGENERATED BY CMAKE. DO NOT EDIT! / /* Changes to the configuration reflected here can be made with ccmake on * unix or with cmake-gui on windows. Alternatively you can use cmake's -D * or -P switches to set some configuration values at cmake configuration time. */ #ifndef _OPENTHREADS_CONFIG #define _OPENTHREADS_CONFIG #define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS /* #undef _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS */ /* #undef _OPENTHREADS_ATOMIC_USE_SUN */ /* #undef _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED */ /* #undef _OPENTHREADS_ATOMIC_USE_MUTEX */ #endif ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LODScaleHandler crash on unref
Hi Robert, About my first problem concerning MFC threading an resize events, I was thinking I resolved the bug with User Interface threads but the bug is back if I open/close a lot of new window. The bug appears later with this method but it doesn't resolve it. I'm sad about it. If someone has some experience with embedding osgViewer with MFC I'll be gratefull to get some help. Kind regards, 2008/6/27 amalric alexandre [EMAIL PROTECTED]: Hi Robert, This fix is working great !!! No more texture disappearing. Kind regards, 2008/6/26 Robert Osfield [EMAIL PROTECTED]: On Thu, Jun 26, 2008 at 4:42 PM, amalric alexandre [EMAIL PROTECTED] wrote: 2nd Problem : I'm glad that you have reproduced the bug, loosing texture seems to me connected to context ID too, but I hadn't the time to go further. I've tracked down the problem to the reuse of contextID, something in itself was working correctly, but the subgraphs below the cameras weren't been modified to account for the removal of the previous contexts. The OSG already has a mechanism to help clean up a the scene graph to avoid these types of problems, but in this particular usage combination the required relaseGLObjects() wasn't been called. I have now changed the GraphicsContext::removedCamera() method to it works out which subgraphs need the releaseGLObjects() called upon, this fixes the texture/display lists issues you've seen. The changed GraphicsContext.cpp is attached, and also checked in to SVN. Could you please try it out at your end and confirm whether it's fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LODScaleHandler crash on unref
Hi Amalric, I'll have to step back from helping out with the remaining problems as I know absolutely nothing about MFC, nor have a windows box to test aginst. Robert. On Fri, Jun 27, 2008 at 12:02 PM, amalric alexandre [EMAIL PROTECTED] wrote: Hi Robert, About my first problem concerning MFC threading an resize events, I was thinking I resolved the bug with User Interface threads but the bug is back if I open/close a lot of new window. The bug appears later with this method but it doesn't resolve it. I'm sad about it. If someone has some experience with embedding osgViewer with MFC I'll be gratefull to get some help. Kind regards, 2008/6/27 amalric alexandre [EMAIL PROTECTED]: Hi Robert, This fix is working great !!! No more texture disappearing. Kind regards, 2008/6/26 Robert Osfield [EMAIL PROTECTED]: On Thu, Jun 26, 2008 at 4:42 PM, amalric alexandre [EMAIL PROTECTED] wrote: 2nd Problem : I'm glad that you have reproduced the bug, loosing texture seems to me connected to context ID too, but I hadn't the time to go further. I've tracked down the problem to the reuse of contextID, something in itself was working correctly, but the subgraphs below the cameras weren't been modified to account for the removal of the previous contexts. The OSG already has a mechanism to help clean up a the scene graph to avoid these types of problems, but in this particular usage combination the required relaseGLObjects() wasn't been called. I have now changed the GraphicsContext::removedCamera() method to it works out which subgraphs need the releaseGLObjects() called upon, this fixes the texture/display lists issues you've seen. The changed GraphicsContext.cpp is attached, and also checked in to SVN. Could you please try it out at your end and confirm whether it's fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Robert Osfield schrieb: Hi All, At the end of last week/start of this week I tried to go for converging SVN to a stable enough state to go for an OSG-2.5.3 dev release, but alas submission/build fixes/build breaks kept coming in thick and fast, and no convergence was achieved. So... I still want to get a 2.5.3 dev release out, and fingers crossed the build is now looking more robust so could users please do an svn update, build and run on as many platforms as you can and see how things are working out. compiled fine on OS X 10.5 with CMake 2.6, XCode-projects compiled fine with the XCode project part of the distribution. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Hi Robert, I'm uneasy about changing the existing behaviour as we may well be fixing one problem for one set of users, but introducing problems for users that currently rely upon the existing behaviour. As I had my doubts as well, I have asked if allocateImage or readPixels is a better place for modification. Actually if I was pushed to choose, I would rather modify readPixels because changing internalTextureFormat as a result of this call is completely unintuitive. Its even more unexpected if one does not even directly call readPixels but only attaches image to the camera. My postition is that its better to fix it now than risk that even more users will rely on this unexpected side effect. Do as you think is appropriate. Since I know about this I am well prepared for all endings ;-) Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Deleted CMakeCache.txt, ccmake . recompiled, but it continue crashing. In GDB this time I have: Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview [Thread debugging using libthread_db enabled] [New Thread 0xb6a66910 (LWP 6697)] /local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified files. Trying cow.osg instead. [New Thread 0xb5f6cb90 (LWP 6708)] [New Thread 0xb576bb90 (LWP 6709)] [New Thread 0xb4f6ab90 (LWP 6710)] [New Thread 0xb4769b90 (LWP 6711)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb576bb90 (LWP 6709)] osg::OperationQueue::getNextOperation (this=0x814b4c0, blockIfEmpty=true) at /local/OSG/OpenSceneGraph/include/OpenThreads/Atomic:107 107 return ++_value; (gdb) where #0 osg::OperationQueue::getNextOperation (this=0x814b4c0, blockIfEmpty=true) at /local/OSG/OpenSceneGraph/include/OpenThreads/Atomic:107 #1 0xb7edc331 in osg::OperationThread::run (this=0x814b3d0) at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:399 #2 0xb7fb1093 in OpenThreads::ThreadPrivateActions::StartThread (data=0x814b3dc) at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170 #3 0xb7a67192 in start_thread () from /lib/libpthread.so.0 #4 0xb766702e in clone () from /lib/libc.so.6 My ./include/OpenThreads/Config has all the 5 #undef commented out. If I manually define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS as you have, osg does not build. Idem for what seems the most obvious fallback: _OPENTHREADS_ATOMIC_USE_MUTEX. I should add that I have: gcc (GCC) 4.2.1 (SUSE Linux) and cmake version 2.4-patch 7 Hope it helps mario Robert Osfield wrote: On Fri, Jun 27, 2008 at 11:48 AM, Mario Valle [EMAIL PROTECTED] wrote: 32bits, Intel(R) Xeon(TM) CPU 3.00GHz quad core 4GB RAM. GeForce 6800 GS NVIDIA Driver Version: 169.12 Suse 10.3 Let me know if other info or other tests are needed. The only test is the one suggested, remove your CMakeCache.txt, rerun ./configure or ccmake . to make sure it regenerates your include/OpenThreads/Config, check the contents of this Config file to make sure its been updated to a sensible value. On my Kubuntu 64bit system I get a include/OpenThreads/Config that looks like: /* -*-c++-*- OpenSceneGraph - Copyright (C) 2008 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ / * THIS FILE IS AUTOGENERATED BY CMAKE. DO NOT EDIT! / /* Changes to the configuration reflected here can be made with ccmake on * unix or with cmake-gui on windows. Alternatively you can use cmake's -D * or -P switches to set some configuration values at cmake configuration time. */ #ifndef _OPENTHREADS_CONFIG #define _OPENTHREADS_CONFIG #define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS /* #undef _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS */ /* #undef _OPENTHREADS_ATOMIC_USE_SUN */ /* #undef _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED */ /* #undef _OPENTHREADS_ATOMIC_USE_MUTEX */ #endif ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis and Visualization Services | 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
Re: [osg-users] Seeking OSG texture mapping application
Hello Judie, Well, I downloaded a 30 day trial of 3DS Max 2009 and it did not have an osg importer or exporter. There is an exporter, though I have no idea if it's still being developed and if it works with recent versions of 3DS Max. http://sourceforge.net/projects/osgmaxexp There is no importer I know of. Perhaps you can explore using osgconv to convert to some format Max can import (perhaps COLLADA, if you can build the OSG plugin for that), then do whatever you need in Max and save back into .osg (or again, COLLADA might be a good export path, since 3DS Max has a native COLLADA reader/writer). Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Hi, On Friday 27 June 2008 14:12, Mario Valle wrote: Deleted CMakeCache.txt, ccmake . recompiled, but it continue crashing. In GDB this time I have: Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview [Thread debugging using libthread_db enabled] [New Thread 0xb6a66910 (LWP 6697)] /local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified files. Trying cow.osg instead. [New Thread 0xb5f6cb90 (LWP 6708)] [New Thread 0xb576bb90 (LWP 6709)] [New Thread 0xb4f6ab90 (LWP 6710)] [New Thread 0xb4769b90 (LWP 6711)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb576bb90 (LWP 6709)] osg::OperationQueue::getNextOperation (this=0x814b4c0, blockIfEmpty=true) at /local/OSG/OpenSceneGraph/include/OpenThreads/Atomic:107 107 return ++_value; (gdb) where #0 osg::OperationQueue::getNextOperation (this=0x814b4c0, blockIfEmpty=true) at /local/OSG/OpenSceneGraph/include/OpenThreads/Atomic:107 #1 0xb7edc331 in osg::OperationThread::run (this=0x814b3d0) at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:399 #2 0xb7fb1093 in OpenThreads::ThreadPrivateActions::StartThread (data=0x814b3dc) at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170 #3 0xb7a67192 in start_thread () from /lib/libpthread.so.0 #4 0xb766702e in clone () from /lib/libc.so.6 My ./include/OpenThreads/Config has all the 5 #undef commented out. If I manually define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS as you have, osg does not build. Idem for what seems the most obvious fallback: _OPENTHREADS_ATOMIC_USE_MUTEX. I should add that I have: gcc (GCC) 4.2.1 (SUSE Linux) and cmake version 2.4-patch 7 Can you please start a build from scratch in an empty directory and tell me if this still does not work? You may start cmake with --debug-trycompile and provide the output of builddir/CMakeFiles/CMakeError.log. GReetings and thanks MAthias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Thanks Robert, Attached is Image.cpp modified to not update already set _internalTextureFormat. I haven't actually decided upon the merits of merging this yet though, but it could at least be tested on this specific problem you guys are seeing. It does the trick. I put the breakpoint in the line where Renderbuffers are created, and now they use the the same exact pixelformat set from Image::getInternalTextureFormat(). Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 64bit, OS X, (was: Re: Warning on 64bits: cast to pointer from integer of different size)
Hi Robert,
Robert Osfield schrieb:
As for a Cocoa implementation of GraphicsWindow and PixelBuffer, is
Cocoa fully threadable? Are there other constraints that it'll apply
to the way we open, render to, and get events from the windows?
Not all carbon is depreceated, only stuff which has something to do with
the UI. So windows, menus, buttons, etc should be done with cocoa. Some
parts of Cocoa are based on Carbon AFAIK, e.g. the event-handling code.
Cocoa is fully threadable, one nitpicking problem will be the main-loop.
Most of the cocoa applications call NSApplicationMainLoop (don't know
the exact function-name) instead of doing it's main loop by hand. This
could be get tricky but it should be doable.
I've started to refactor the GraphicsWindowCarbon-implementation so we
can use parts of the code (WindowingSystemInterface, MenubarController)
from both implementations. But there's a lot of work to do, and I am
busy like hell :)
The quicktime-plugin is also not 64bit savvy, E. Wing has coded a
replacement called ImageIO, but it has no movie- or live-video-support
and works only for quicktime.
| win32 | darwin 32bit | darwin 64bit
---+---+--+--
quicktime-image| x | x |
quicktime-video| x | x |
quicktime-live | x | x |
imageio| | x | x
So, we need a couple of defines to route to the correct plugin from
osgDB:Registry, perhaps we should refactor the quicktime-plugin into
three spearate plugins, one for image, one for video and one for live-video.
I suggest also a new virtual function to handle network-protocols.
Quicktime can stream movies from http and rtsp, but the current solution
in osgDB::Registry will reroute the request to the net-plugin.
Something like
class ReaderWriter {
virtual bool acceptsProtocol(const std::string protocol) { return
false; }
}
Implementations can override this method, and if no plugin handles the
given protocol, the net-plugin can handle these per default.
What do you think?
cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Just done a svn co in an empty dir
Can you please start a build from scratch in an empty directory and tell me if
this still does not work?
Done ccmake .
then cmake --debug-trycompile
You may start cmake with --debug-trycompile and provide the output of
builddir/CMakeFiles/CMakeError.log.
Log attached.
As soon as the build finishes, I will report back to you.
GReetings and thanks
Ciao!
mario
MAthias
--
Ing. Mario Valle
Data Analysis and Visualization Services | 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
Determining if the function pthread_create exists in the pthreads failed with the following output:
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.o
/usr/bin/gcc -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec
/usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake
/usr/bin/gcc -DCHECK_FUNCTION_EXISTS=pthread_create -fPIC CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.o -o cmTryCompileExec -rdynamic -lpthreads
/usr/lib/gcc/i586-suse-linux/4.2.1/../../../../i586-suse-linux/bin/ld: cannot find -lpthreads
collect2: ld returned 1 exit status
gmake[1]: *** [cmTryCompileExec] Error 1
gmake[1]: Leaving directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec/fast] Error 2
Determining if the Q_WS_MAC exist failed with the following output:
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o
/usr/bin/gcc -o CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o -c /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function 'main':
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: 'Q_WS_MAC' undeclared (first use in this function)
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: (Each undeclared identifier is reported only once
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: for each function it appears in.)
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o] Error 1
gmake[1]: Leaving directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec/fast] Error 2
File /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include QtCore/qglobal.h
void cmakeRequireSymbol(int dummy,...){(void)dummy;}
int main()
{
#ifndef Q_WS_MAC
cmakeRequireSymbol(0,Q_WS_MAC);
#endif
return 0;
}
Determining if the Q_WS_WIN exist failed with the following output:
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o
/usr/bin/gcc -o CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o -c /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function 'main':
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: 'Q_WS_WIN' undeclared (first use in this function)
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: (Each undeclared identifier is reported only once
/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: error: for each function it appears in.)
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.o] Error 1
gmake[1]: Leaving directory `/local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec/fast] Error 2
File /local/OSG/OpenSceneGraph/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include QtCore/qglobal.h
void cmakeRequireSymbol(int dummy,...){(void)dummy;}
int main()
{
#ifndef Q_WS_WIN
cmakeRequireSymbol(0,Q_WS_WIN);
#endif
return 0;
}
Performing C++ SOURCE FILE Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS failed with the following output:
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi Robert -- When I link one of my projects against current svn head, I get Atomic::operator++() as an unresolved external symbol. -Paul 2 Creating library C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.lib and object C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.exp 2ComputeTriMeshVisitor.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: unsigned int __thiscall OpenThreads::Atomic::operator++(void) ([EMAIL PROTECTED]@@QAEIXZ) referenced in function public: class osg::ref_ptrclass osg::TemplateArrayclass osg::Vec3f,10,3,5126 __thiscall osg::ref_ptrclass osg::TemplateArrayclass osg::Vec3f,10,3,5126 ::operator=(class osg::TemplateArrayclass osg::Vec3f,10,3,5126 *) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@$09$02$0BEAG@@osg@@@osg@@QAEAAV01 @[EMAIL PROTECTED]@osg@@$09$02$0BEAG@@1@@Z) 2MotionState.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: unsigned int __thiscall OpenThreads::Atomic::operator++(void) ([EMAIL PROTECTED]@@QAEIXZ) 2C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.dll : fatal error LNK1120: 1 unresolved externals ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi Paul, I had the same problem, to resolve it, I needed to link my app with OpenThread. On Fri, Jun 27, 2008 at 3:05 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- When I link one of my projects against current svn head, I get Atomic::operator++() as an unresolved external symbol. -Paul 2 Creating library C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.lib and object C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.exp 2ComputeTriMeshVisitor.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: unsigned int __thiscall OpenThreads::Atomic::operator++(void) ([EMAIL PROTECTED] @@QAEIXZ) referenced in function public: class osg::ref_ptrclass osg::TemplateArrayclass osg::Vec3f,10,3,5126 __thiscall osg::ref_ptrclass osg::TemplateArrayclass osg::Vec3f,10,3,5126 ::operator=(class osg::TemplateArrayclass osg::Vec3f,10,3,5126 *) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@$09$02$0BEAG@@osg@@@osg@ @QAEAAV01 @[EMAIL PROTECTED]@osg@@$09$02$0BEAG@@1@@Z) 2MotionState.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: unsigned int __thiscall OpenThreads::Atomic::operator++(void) ([EMAIL PROTECTED] @@QAEIXZ) 2C:\Projects\Physics\physics_hg\bld\lib\Release\osgBullet.dll : fatal error LNK1120: 1 unresolved externals ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese
There is a current issue with VS 7.1 against any version of cmake see Re: [osg-users][osg-submissions] API configurations in a separateConfig include file thread James Killian - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, June 27, 2008 3:22 AM Subject: Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese Hi J-S, On Thu, Jun 26, 2008 at 8:17 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: OSG SVN on Windows Vista, VS8, CMake 2.4.8 and 2.6, builds and runs fine. VPB SVN on Windows Vista, VS8, CMake 2.6 (didn't take time to test on 2.4.8), builds and runs fine. I'll test on my Ubuntu Virtualbox, but I suspect that's a bit unnecessary... Just being thorough. :-) Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) 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] PagedLOD and IntersectionVisitor
What I make of it is you a flogging the PagedLOD because it can handle misuse of it. Fix the database. I encourage you to reread my previous post, as the test data I posted clearly concerns questionable LOD behavior; the PagedLOD case works fine... -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Hi James, Good to see that things are starting to work for you. I guess VS7.1 is a less tested compiler as it's getting a bit old. I have no interest in getting it to work personally as I don't use it, and I suspect that's Mathias's case too. If you want to make it work under 7.1, you're welcome to try and submit the necessary changes. Oh yes, and the projects which are dependent on Open Threads and OSG now include the build directory, so while I do not quite understand the install workflow that you were saying it appears that we can build the solution without needing to do anything with install. To me the install is a folder which is ran last where, once the build has built successfully I click the install to put the stuff together, and then our client code includes and links to this folder... that way when the code breaks the install folder is still fine from the previous successful session. Yes, that's one of the advantages of doing an install. You seem to be doing the install manually from what I understand of your paragraph above though, and you don't need to. In CMake, there's a setting called CMAKE_INSTALL_PREFIX. Set that to wherever you want the bin/, include/, lib/ etc directories to be, and then after generating the project files, open the solution and build the INSTALL project (right-click it and select build). That will automatically build everything (as the INSTALL project is dependent on all the other projects) and then copy all the needed files to the directories under your CMAKE_INSTALL_PREFIX automatically. Note that you need to right-click the INSTALL project and build it, because by default it's skipped (for people who don't want to do that). So just doing a build solution won't run the INSTALL target. Doing an INSTALL is only of benefit for apps that depend on OSG, not for the OSG build itself. Anything that's in the OSG solution file will find the necessary headers and libs automatically without needing an INSTALL. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] cannot save osgtext::Text backdrop setting in the ive file
Hi, We cannot save osgtext::Text backdrop setting in the ive file. Is it a bug? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hi Cg, Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrain, some of the particles will get culled. How does a terrain affect the particles? Just for the record, if a particle is partially visible, that's not culling, that's clipping. If you don't want your particles clipped by the terrain, I guess you could put them into a higher render bin than the terrain? Perhaps others can confirm this. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese
Hi Robert -- When I link one of my projects against current svn head, I get Atomic::operator++() as an unresolved external symbol. Sorry: This is with cmake 2.6 and VS2005 SP1. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash with CompositeViewer on Win32
CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. This is true for 2.4.8, it continued to fail the am I win32 interlocked test (probably because this result was already cached)... So I also had to purge my cache and start over. I have not tested this case for 2.6 James Killian - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, June 27, 2008 4:04 AM Subject: Re: [osg-users] Crash with CompositeViewer on Win32 On Fri, Jun 27, 2008 at 9:49 AM, Serge Lages [EMAIL PROTECTED] wrote: Thanks for the hint, it seems to be my fault. I opened the OpenThreads/Config file to see the method used, and everything was commented... I hade to remove my CMakeCache.txt to have the file generated again and use the atomic pointers. Now it works like a charm ! Good to hear things are working again. I wonder if the Config file generated initially was incorrect, then CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. It might be that others will come up against the same issue during this transition between pre Config/Atomic days and what we have now. 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] osgthirdpersonview crashes on Linux
Mario, On Friday 27 June 2008 15:05, Mario Valle wrote: Just done a svn co in an empty dir Can you please start a build from scratch in an empty directory and tell me if this still does not work? Done ccmake . then cmake --debug-trycompile You may start cmake with --debug-trycompile and provide the output of builddir/CMakeFiles/CMakeError.log. Log attached. Ok, I see. You are running in gcc, i386 without any -march= compiler flag. So gcc assumes that you want to compile for a plain old i386 (read this does not even mean an i486). In this case gcc is limited to an instruction set where no such atomic operations are available. In fact you could not even programm a mutex with that i386 instruction set, as well as you could not build any SMP machine using an i386. In this case, when we cannot assume any atomic operations. So we need to use the previous mutex based behaviour. But for that, the old mechnisms are still there. You need to ensure that refcounting works in a threadsafe way using either the OSG_THREAD_SAFE_REF_UNREF environment variable or by calling osg::Referenced::setThreadSafeReferenceCounting(true); before *any* concurrently used osg::Referenced object is created. Alternatively you can uncomment that ENFORCE_THREADSAFE define in src/osg/Referenced.cpp that does change the default behaviour of referenced. As soon as the build finishes, I will report back to you. Are you running with the environment variable OSG_THREAD_SAFE_REF_UNREF set or unset? Greetings MAthias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osgswig
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn’t seem like it’s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
+#MESSAGE(--${${MYLIBRARY}}--${${MYLIBRARY}_DEBUG}--)
+IF( NOT
Re: [osg-users] Updating the OSG reference manual (doxygen pages)
Hi John, If someone with web server access could update these doxygen pages to reflect the latest stable release, I - for one - would be very happy. I have been asking for this for a while. Jose Luis Hidalgo is the one who set up the new web server, but right now it seems that there is some administrative change where the server is hosted and he has trouble getting access (at least that's what I understood from his last message). Hopefully he can get that resolved soon, as I too find it a shame that the doxygen on the site is that old... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osgswig
Any plans for building java binding with Cmake?
On 6/27/08 8:27 AM, Luigi Calori [EMAIL PROTECTED] wrote:
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn¹t seem like it¹s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
We are going to move to VS 9, we have been wanting to do that for a long time now. Aside from osg not building, I overlooked the OpenMP option available to VS 8 and 9. We want high performance from osg so, *hopefully OpenMP will help. I am going to start a thread on performance here real soon for anyone interested. Perhaps there should be plans to ditch 7.1 if no one is using it now. Thanks for explaining the install... I was right clicking on ALL_BUILD and then INSTALL, but I suppose I could just do INSTALL, if it breaks it will not start copying. *OpenMP has not been easy/intuitive to use with unpredictable performance results. James Killian - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, June 27, 2008 8:17 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hi James, Good to see that things are starting to work for you. I guess VS7.1 is a less tested compiler as it's getting a bit old. I have no interest in getting it to work personally as I don't use it, and I suspect that's Mathias's case too. If you want to make it work under 7.1, you're welcome to try and submit the necessary changes. Oh yes, and the projects which are dependent on Open Threads and OSG now include the build directory, so while I do not quite understand the install workflow that you were saying it appears that we can build the solution without needing to do anything with install. To me the install is a folder which is ran last where, once the build has built successfully I click the install to put the stuff together, and then our client code includes and links to this folder... that way when the code breaks the install folder is still fine from the previous successful session. Yes, that's one of the advantages of doing an install. You seem to be doing the install manually from what I understand of your paragraph above though, and you don't need to. In CMake, there's a setting called CMAKE_INSTALL_PREFIX. Set that to wherever you want the bin/, include/, lib/ etc directories to be, and then after generating the project files, open the solution and build the INSTALL project (right-click it and select build). That will automatically build everything (as the INSTALL project is dependent on all the other projects) and then copy all the needed files to the directories under your CMAKE_INSTALL_PREFIX automatically. Note that you need to right-click the INSTALL project and build it, because by default it's skipped (for people who don't want to do that). So just doing a build solution won't run the INSTALL target. Doing an INSTALL is only of benefit for apps that depend on OSG, not for the OSG build itself. Anything that's in the OSG solution file will find the necessary headers and libs automatically without needing an INSTALL. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi Paul, Hi Robert -- When I link one of my projects against current svn head, I get Atomic::operator++() as an unresolved external symbol. -Paul Make sure you link to OpenThreads.lib. Before, only OSG code would call OpenThreads directly (unless you created threads yourself), so you did not need to link to it, since osg.lib already linked to it. But now, since all ref_ptrs use atomic reference counting (whose implementation on Windows is in src/OpenThreads/Atomic.cpp to avoid including windows.h in a header), your code also calls code in OpenThreads, so you need to link to it in your project. Hope that explains it. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Hi James, Perhaps there should be plans to ditch 7.1 if no one is using it now. I think we should wait to see if anyone finds a fix so it compiles on 7.1. It has to come from someone who uses it though, as that's something that I personally can't check (since I don't have 7.1). Thanks for explaining the install... I was right clicking on ALL_BUILD and then INSTALL, but I suppose I could just do INSTALL, if it breaks it will not start copying. Exactly, in the INSTALL step it will say that there's a missing file and stop. At the bottom you'll see the number of failed projects as usual - if for example there are 2, you know that one project failed to compile and the INSTALL project failed as a result of that. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype doesn't show up in .net2005
Thanks that solved it. Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: 26 June 2008 16:53 To: OpenSceneGraph Users Subject: Re: [osg-users] Freetype doesn't show up in .net2005 Hi Kim, FREETYPE_INCLUDE_DIR_freetype2 = C:/Build/OpenSceneGraph 2.4/3rdParty/include/freetype FREETYPE_INCLUDE_DIR_ft2build = C:/Build/OpenSceneGraph 2.4/3rdParty/include/ FREETYPE_LIBRARY_DEBUG = C:/Build/OpenSceneGraph 2.4/3rdParty/lib/freetype219_D.lib There is another value, FREETYPE_LIBRARY, which is only shown when Show advanced values is checked in CMake. (why?) So I guess if you set that it'll generate the project. I agree that there are problems detecting the dependencies when you specify the 3rdParty directory manually (using ACTUAL_3RDPARTY_DIR). I don't know why that happens. I always put my 3rdParty dir as a sibling of the OpenSceneGraph dir (which contains src/, include/, etc.) and that works for me (tm), so perhaps doing that would help. But in the case that's not possible, perhaps you could check out CMakeModules/Find3rdPartyDependencies.cmake and try to find out what's wrong with it in your usage pattern? Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Ok, I see. You are running in gcc, i386 without any -march= compiler flag. So gcc assumes that you want to compile for a plain old i386 (read this does not even mean an i486). In this case gcc is limited to an instruction set where no such atomic operations are available. In fact you could not even programm a mutex with that i386 instruction set, as well as you could not build any SMP machine using an i386. Ahi Ahi Ahi!! That means that I'm working without this optimization since the beginning? And nevertheless OSG is so fast? I specify in the advanced cmake options: CMAKE_C_FLAGS-march=i486 -mtune=i486 CMAKE_CXX_FLAGS -march=i486 -mtune=i486 Then configure and generate, but the ./include/OpenThreads/Config file continues with everything commented out. Have I missed something? In this case, when we cannot assume any atomic operations. So we need to use the previous mutex based behaviour. But for that, the old mechnisms are still there. You need to ensure that refcounting works in a threadsafe way using either the OSG_THREAD_SAFE_REF_UNREF environment variable or by calling OK, thanks. But for now I want only to contribute with my ignorance :-) to polish this OSG functionality. osg::Referenced::setThreadSafeReferenceCounting(true); before *any* concurrently used osg::Referenced object is created. Alternatively you can uncomment that ENFORCE_THREADSAFE define in src/osg/Referenced.cpp that does change the default behaviour of referenced. As soon as the build finishes, I will report back to you. OK, now crashes in another place, see below. This run has been done before changing march/mtune. Are you running with the environment variable OSG_THREAD_SAFE_REF_UNREF set or unset? Unset Greetings MAthias Thanks Mathias! mario $ gdb osgthirdpersonview GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i586-suse-linux... Using host libthread_db library /lib/libthread_db.so.1. (gdb) r Starting program: /local/OSG/OpenSceneGraph/bin/osgthirdpersonview [Thread debugging using libthread_db enabled] [New Thread 0xb6a21910 (LWP 22570)] /local/OSG/OpenSceneGraph/bin/osgthirdpersonview: Could not find specified files. Trying cow.osg instead. [New Thread 0xb5f28b90 (LWP 22581)] [New Thread 0xb5727b90 (LWP 22583)] [New Thread 0xb4f26b90 (LWP 22584)] [New Thread 0xb4725b90 (LWP 22585)] Warning: deleting still referenced object 0x806cfd0 of type 'PN3osg10ReferencedE' the final reference count was 1, memory corruption possible. Warning: deleting still referenced object 0x806cfd0 of type 'PN3osg10ReferencedE' the final reference count was 4294967295, memory corruption possible. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5727b90 (LWP 22583)] 0xb7f61635 in typeinfo for osg::Scissor () from /local/OSG/OpenSceneGraph/lib/libosg.so.39 (gdb) where #0 0xb7f61635 in typeinfo for osg::Scissor () from /local/OSG/OpenSceneGraph/lib/libosg.so.39 #1 0xb7e6c5c4 in osg::Group::traverse (this=0x8056d50, [EMAIL PROTECTED]) at /local/OSG/OpenSceneGraph/src/osg/Group.cpp:62 #2 0xb7bd58c1 in osgUtil::CullVisitor::apply (this=0x8102668, [EMAIL PROTECTED]) at /local/OSG/OpenSceneGraph/include/osg/NodeVisitor:181 #3 0xb7e6dbaa in osg::Group::accept (this=0x8056d50, [EMAIL PROTECTED]) at /local/OSG/OpenSceneGraph/include/osg/Group:38 #4 0xb7c679a2 in osgUtil::SceneView::cullStage (this=0x8101750, [EMAIL PROTECTED], [EMAIL PROTECTED], cullVisitor=0x8102668, rendergraph=0x8102488, renderStage=0x81024d8, viewport=0x814a9f0) at /local/OSG/OpenSceneGraph/src/osgUtil/SceneView.cpp:926 #5 0xb7c633ea in osgUtil::SceneView::cull (this=0x8101750) at /local/OSG/OpenSceneGraph/src/osgUtil/SceneView.cpp:792 #6 0xb7ad39c1 in osgViewer::Renderer::cull (this=0x8101530) at /local/OSG/OpenSceneGraph/src/osgViewer/Renderer.cpp:302 #7 0xb7ad2afa in osgViewer::Renderer::operator() (this=0x8101530, object=0x8100a18) at /local/OSG/OpenSceneGraph/src/osgViewer/Renderer.cpp:624 #8 0xb7e96427 in osg::OperationThread::run (this=0x814b3d0) at /local/OSG/OpenSceneGraph/src/osg/OperationThread.cpp:413 #9 0xb7f6b093 in OpenThreads::ThreadPrivateActions::StartThread (data=0x814b3dc) at /local/OSG/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:170 #10 0xb7a22192 in start_thread () from /lib/libpthread.so.0 #11 0xb762202e in clone () from /lib/libc.so.6 (gdb) -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale
Re: [osg-users] Updating the OSG reference manual (doxygen pages)
John Vidar Larring wrote on Friday, June 27, 2008 4:48 AM: PS: I know that I can generate the doxypages locally (have done so), but it is not the same without the search engine;) I am not a stranger to studying code either, but the reference manual is helpful for getting a quick overview. Maybe Google Desktop would help with that? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Hi Mario, I specify in the advanced cmake options: CMAKE_C_FLAGS-march=i486 -mtune=i486 CMAKE_CXX_FLAGS -march=i486 -mtune=i486 Then configure and generate, but the ./include/OpenThreads/Config file continues with everything commented out. Have I missed something? I think you need to remove your CMakeCache.txt and the build/include/OpenThreads/Config file, otherwise CMake doesn't take into account the changes to regenerate it because it sees the old one. (at least that's what I gather from some previous posts today) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Hi Robert, I'll test on my Ubuntu Virtualbox, but I suspect that's a bit unnecessary... Just being thorough. :-) Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) The last one (Ubuntu) has now built correctly (as expected :-) ). I don't yet have VPB on that VM, so didn't test that. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Debug Libraries error (0xc0150002)
Hi, I'm running my app in VS2005 debug mode. I was getting crashes using readNodeFile, and as per the advice of this mailing list I downloaded and unzipped the osg debug libraries. Now my application throws an error when innitializing, 'learnOSG.exe': Loaded 'C:\Program Files\OpenSceneGraph\bin\osg35-osgDBd.dll', No symbols loaded. LDR: LdrpWalkImportDescriptor() failed to probe C:\Program Files\OpenSceneGraph\bin\osg35-osgDBd.dll for its manifest, ntstatus 0xc0150002 I haven't found any mentions of that error in relation to osg, but every solution to it I could find for other systems involved getting service pack 1 or replacing the library with a newer/fixed version. This machine has service pack 2, so the first isn't the problem. My own application is only using four of the .lib files, osgd.lib osgViewerd.lib osgDBd.lib osgGAd.lib I also tried it with the osgviewerGlut example, using debug mode and all the debug libraries, and got the same error. -Mark ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 dev releasese
Atomic::operator++() issue is now resolved by modifying my external projects to link with the additional OpenThreads library. Thanks for the assistance. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Mario, On Friday 27 June 2008 16:09, Mario Valle wrote: Ok, I see. You are running in gcc, i386 without any -march= compiler flag. So gcc assumes that you want to compile for a plain old i386 (read this does not even mean an i486). In this case gcc is limited to an instruction set where no such atomic operations are available. In fact you could not even programm a mutex with that i386 instruction set, as well as you could not build any SMP machine using an i386. Ahi Ahi Ahi!! That means that I'm working without this optimization since the beginning? And nevertheless OSG is so fast? I specify in the advanced cmake options: CMAKE_C_FLAGS-march=i486 -mtune=i486 CMAKE_CXX_FLAGS -march=i486 -mtune=i486 Then configure and generate, but the ./include/OpenThreads/Config file continues with everything commented out. Have I missed something? Ok, then throw away your build to make sure that nothing si left. I am not sure how many things are cached in what part of the cmake build system. I just want to be sure ... Then set again the cflags. And better set them to something like -march=pentiumpro. Also do not forget to include -O or -O3 or something like that. Without you do not get any optimizations I guess ... Then ensure that cmake does not see previous caches ... BTW: does anybody know a way to tell cmake that a variable should not be cached? In this case, when we cannot assume any atomic operations. So we need to use the previous mutex based behaviour. But for that, the old mechnisms are still there. You need to ensure that refcounting works in a threadsafe way using either the OSG_THREAD_SAFE_REF_UNREF environment variable or by calling OK, thanks. But for now I want only to contribute with my ignorance :-) to polish this OSG functionality. osg::Referenced::setThreadSafeReferenceCounting(true); before *any* concurrently used osg::Referenced object is created. Alternatively you can uncomment that ENFORCE_THREADSAFE define in src/osg/Referenced.cpp that does change the default behaviour of referenced. As soon as the build finishes, I will report back to you. OK, now crashes in another place, see below. This run has been done before changing march/mtune. Are you running with the environment variable OSG_THREAD_SAFE_REF_UNREF set or unset? Unset Can you test with this variable set? I believe that these thread safety defaults in osg are not good in face of that multithreaded viewer stuff, but I just left them as is. Robert, Should we include that ENFORCE_THREADSAFE define in the cmake configuration? And in face of all this threading usage in osg, should the default change to on? And, yes, I should write a wiki page. I hope to find some time today ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debug Libraries error (0xc0150002)
Hi Mark, I haven't found any mentions of that error in relation to osg, but every solution to it I could find for other systems involved getting service pack 1 or replacing the library with a newer/fixed version. This machine has service pack 2, so the first isn't the problem. I think they mean VS2005 SP1, not Windows XP SP1 - so SP1 for the compiler, not the OS. Check the Microsoft site. It's essential to have VS2005 SP1, otherwise you'll get weird crashes in debug mode, since the binaries Mike compiled were built with VS2005 SP1. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Sorry for the wrong word, i think my terrain is too heavy for my machine, I'll test it on another machine. I've put the particles into a renderbin that is higher than the terrain but the the particles still get clipped. Date: Fri, 27 Jun 2008 09:19:50 -0400 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Hi Cg, Thanks for your help, I've narrowed it down to my terrain, when I use Joseph's terrain, the particles look good. But when I switch over to my terrain, some of the particles will get culled. How does a terrain affect the particles? Just for the record, if a particle is partially visible, that's not culling, that's clipping. If you don't want your particles clipped by the terrain, I guess you could put them into a higher render bin than the terrain? Perhaps others can confirm this. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lis ts.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Check out Barclays Premier League exclusive video clips here! http://fc.sg.msn.com/index.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hello Cg, Sorry for the wrong word, Hehe that's ok, there's a lot of terminology and some terms are similar... I guess I just expected that someone who's name is Cg would know the CG terminology :-) Sorry I can't help more, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hehe that's ok, there's a lot of terminology and some terms are similar... I guess I just expected that someone who's name is Cg would know the CG terminology :-) hehe, because my initial is Cg, thanks for the help. Date: Fri, 27 Jun 2008 10:50:01 -0400 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled Hello Cg, Sorry for the wrong word, Hehe that's ok, there's a lot of terminology and some terms are similar... I guess I just expected that someone who's name is Cg would know the CG terminology :-) Sorry I can't help more, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Check out Barclays Premier League exclusive video clips here! http://fc.sg.msn.com/index.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Mathias Fröhlich wrote: Ok, then throw away your build to make sure that nothing si left. I am not sure how many things are cached in what part of the cmake build system. I just want to be sure ... Then set again the cflags. And better set them to something like -march=pentiumpro. Also do not forget to include -O or -O3 or something like that. Without you do not get any optimizations I guess ... Then ensure that cmake does not see previous caches ... Done, but nothing changes BTW: does anybody know a way to tell cmake that a variable should not be cached? Are you running with the environment variable OSG_THREAD_SAFE_REF_UNREF set or unset? Unset Can you test with this variable set? Yes, it crashes the same... I believe that these thread safety defaults in osg are not good in face of that multithreaded viewer stuff, but I just left them as is. Robert, Should we include that ENFORCE_THREADSAFE define in the cmake configuration? And in face of all this threading usage in osg, should the default change to on? And, yes, I should write a wiki page. I hope to find some time today ... Greetings Mathias Thanks Mathias! Now I go home for the weekend, maybe Monday things will be better... Ciao! mario -- Ing. Mario Valle Data Analysis and Visualization Services | 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
Re: [osg-users] Debug Libraries error (0xc0150002)
It is Service Pack 1 for Visual Studio 2005 This is a MUST have patch for VS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Friday, June 27, 2008 10:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Debug Libraries error (0xc0150002) Hi Mark, I haven't found any mentions of that error in relation to osg, but every solution to it I could find for other systems involved getting service pack 1 or replacing the library with a newer/fixed version. This machine has service pack 2, so the first isn't the problem. I think they mean VS2005 SP1, not Windows XP SP1 - so SP1 for the compiler, not the OS. Check the Microsoft site. It's essential to have VS2005 SP1, otherwise you'll get weird crashes in debug mode, since the binaries Mike compiled were built with VS2005 SP1. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debug Libraries error (0xc0150002)
Looks like that fixed the problem. Thanks. -Mark On Fri, Jun 27, 2008 at 11:07 AM, Gordon Tomlinson [EMAIL PROTECTED] wrote: It is Service Pack 1 for Visual Studio 2005 This is a MUST have patch for VS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Friday, June 27, 2008 10:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Debug Libraries error (0xc0150002) Hi Mark, I haven't found any mentions of that error in relation to osg, but every solution to it I could find for other systems involved getting service pack 1 or replacing the library with a newer/fixed version. This machine has service pack 2, so the first isn't the problem. I think they mean VS2005 SP1, not Windows XP SP1 - so SP1 for the compiler, not the OS. Check the Microsoft site. It's essential to have VS2005 SP1, otherwise you'll get weird crashes in debug mode, since the binaries Mike compiled were built with VS2005 SP1. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debug Libraries error (0xc0150002)
(clarifying comment added to the download section on http://mew.cx/osg/) -- mew On Fri, Jun 27, 2008 at 9:44 AM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Mark, I haven't found any mentions of that error in relation to osg, but every solution to it I could find for other systems involved getting service pack 1 or replacing the library with a newer/fixed version. This machine has service pack 2, so the first isn't the problem. I think they mean VS2005 SP1, not Windows XP SP1 - so SP1 for the compiler, not the OS. Check the Microsoft site. It's essential to have VS2005 SP1, otherwise you'll get weird crashes in debug mode, since the binaries Mike compiled were built with VS2005 SP1. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debug Libraries error (0xc0150002)
Hi Mike, (clarifying comment added to the download section on http://mew.cx/osg/) Thanks, good idea. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview crashes on Linux
Done, but nothing changes Did it work OK with 2.5.2? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Seeking OSG texture mapping application
On Jun 26, 4:50 pm, Paul Martz [EMAIL PROTECTED] wrote: Hi Judie -- Glad to see you're back with OSG. Another modeling option would be output your OSG data as .flt, load it into Carbon Graphics Geo, make your changes, then save as .flt (or .geo) and load back into your OSG app. So now I am trying to find the texture coordinates. I have just started on this leg so I won't ask any stupid questions until I have more info. In your .osg file, look for TexCoordArray? Yes, I have found out about that from your book, OSG Quck Start Guide. I want my metal machined piece to look like the cow.osg in the viewer. I wanted to open the cow.osg in a modeling application so I could understand the texture mapping applied. I will try the Carbon Graphics Geo. Or maybe I can figure it out by looking at the cow.osg file in an ascii reader. Thanks, Judie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Seeking OSG texture mapping application
On Jun 27, 5:26 am, Jean-Sébastien Guay [EMAIL PROTECTED] labs.com wrote: Hello Judie, Well, I downloaded a 30 day trial of 3DS Max 2009 and it did not have an osg importer or exporter. There is an exporter, though I have no idea if it's still being developed and if it works with recent versions of 3DS Max. http://sourceforge.net/projects/osgmaxexp There is no importer I know of. Perhaps you can explore using osgconv to convert to some format Max can import (perhaps COLLADA, if you can build the OSG plugin for that), then do whatever you need in Max and save back into .osg (or again, COLLADA might be a good export path, since 3DS Max has a native COLLADA reader/writer). That is a good idea. I will look into it. Thanks, Judie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osgswig
well not from me... I do not know Java well... but adding a new
language wrapping in CMake should not be too difficult.
Gerrick Bivins wrote:
Any plans for building java binding with Cmake?
On 6/27/08 8:27 AM, Luigi Calori [EMAIL PROTECTED] wrote:
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn¹t seem like it¹s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
Re: [osg-users] osgViewer help needed
Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OcclusionQueryNode Multiple Contexts
On Jun 17, 2008, at 8:47 AM, Todd J. Furlong wrote: Paul, Thanks, I will dig deeper. I've been in touch with Doug in the past about VR Juggler OSG interaction, and we were able to squash a bug or two on the VR Juggler side. However, my configuration (multiple graphics cards on one machine) tends to turn up more issues. We have used OQN tools in this type of configuration without problems. We could be doing something different in our VR Juggler app that may be getting us around this problem. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::CompositeViewer Thread Safety
Robert, We are making modifications to the scene graph from the application/GUI thread, and we create a Graphics thread that runs the frame() loop. We also have our own mutex which we lock() while frame() is being called, or while modifying the scene graph from the GUI thread. There are also times that the Graphics thread will call some of the same functions that lock() this mutex, via OSG Node Cull callbacks, camera final draw callbacks, etc. As I said before, our CompositeViewer is set to SINGLE_THREADED. My question is, if I am not calling frame() and modifying the scene in the GUI thread at the same time, is it necessary to call stopThreading/startThreading? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer::CompositeViewer Thread Safety Hi John, Could you give a bit more context to when in the frame and what thread you are doing operations from, without this info there is really no chance to help you. As a general not CompositeViewer and Viewer are identical when it comes to threading - they even share the same code for doing the rendering and threading. Robert. On Tue, Jun 24, 2008 at 4:07 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Guys, Is it safe to modify the scene graph outside of frame() with CompositeViewer with ThreadingModel SINGLE_THREADED, even if I don't call stopThreading()? We are changing the node mask of certain elements during the root node's cull callback. This turns certain draw elements on or off, but more importantly it turns the textures mapped to those elements on or off as well. The issue that I am seeing is that if I call stopThreading, the textures mapped to the draw elements are not the ones that I assigned, but random ones that exist on other elements. This might be some kind of display list corruption or something. One more question: If someone has seen this behavior before, is there a way to set up the draw elements so that this issue does not occur when I call stopThreading? I appreciate any input that you guys can provide that may help me on this issue. Sincerely, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 64bit, OS X, (was: Re: Warning on 64bits: cast to pointer from integer of different size)
HI Stephan,
On Fri, Jun 27, 2008 at 2:03 PM, Stephan Maximilian Huber
[EMAIL PROTECTED] wrote:
As for a Cocoa implementation of GraphicsWindow and PixelBuffer, is
Cocoa fully threadable? Are there other constraints that it'll apply
to the way we open, render to, and get events from the windows?
Not all carbon is depreceated, only stuff which has something to do with the
UI. So windows, menus, buttons, etc should be done with cocoa. Some parts of
Cocoa are based on Carbon AFAIK, e.g. the event-handling code.
Cocoa is fully threadable, one nitpicking problem will be the main-loop.
Most of the cocoa applications call NSApplicationMainLoop (don't know the
exact function-name) instead of doing it's main loop by hand. This could be
get tricky but it should be doable.
Thanks for the info. Not being driven by an event loop is absolutely
essential for visual simulation apps, so we have to figure out a way
to do it.
I've started to refactor the GraphicsWindowCarbon-implementation so we can
use parts of the code (WindowingSystemInterface, MenubarController) from
both implementations. But there's a lot of work to do, and I am busy like
hell :)
While the current implementations work I don't think there is an urgent need.
The quicktime-plugin is also not 64bit savvy, E. Wing has coded a
replacement called ImageIO, but it has no movie- or live-video-support and
works only for quicktime.
| win32 | darwin 32bit | darwin 64bit
---+---+--+--
quicktime-image| x | x |
quicktime-video| x | x |
quicktime-live | x | x |
imageio| | x | x
The only selling point of quicktime for me is the movie support, as we
have lots of image plugins that work just fine already, so it'd be
movie integration that I'd see as the key thing to get moved to. I
recall the Apple API for video is now Core Video, it this right? Does
it support live and video streams?
I also feel that replacing quicktime with DirectShow under Windows is
the right way to. So it might be possible to drop Quicktime
completely once we have replacements under Windows and OSX in place.
So, we need a couple of defines to route to the correct plugin from
osgDB:Registry, perhaps we should refactor the quicktime-plugin into three
spearate plugins, one for image, one for video and one for live-video.
Once we have the plugins building we can easily tweak the alias in Registry.
I suggest also a new virtual function to handle network-protocols. Quicktime
can stream movies from http and rtsp, but the current solution in
osgDB::Registry will reroute the request to the net-plugin.
Something like
class ReaderWriter {
virtual bool acceptsProtocol(const std::string protocol) { return false;
}
}
Implementations can override this method, and if no plugin handles the given
protocol, the net-plugin can handle these per default.
What do you think?
I recognize that we need some general mechanism, bit I haven't yet
thought about how we might go about implementing it. An
acceptsProtocol(..) methods at first glance looks like something that
might work out OK, one would really need to dive in a try out an
implementation to know how well it serves the purpose.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cannot save osgtext::Text backdrop setting in the ive file
On Fri, Jun 27, 2008 at 2:19 PM, Lilinx [EMAIL PROTECTED] wrote: We cannot save osgtext::Text backdrop setting in the ive file. Is it a bug? Maybe, go check the source code for the Text.cpp in the ive plugin out. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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.or g ___ 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] osgViewer::CompositeViewer Thread Safety
On Fri, Jun 27, 2008 at 5:20 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We are making modifications to the scene graph from the application/GUI thread, and we create a Graphics thread that runs the frame() loop. We also have our own mutex which we lock() while frame() is being called, or while modifying the scene graph from the GUI thread. There are also times that the Graphics thread will call some of the same functions that lock() this mutex, via OSG Node Cull callbacks, camera final draw callbacks, etc. As I said before, our CompositeViewer is set to SINGLE_THREADED. My question is, if I am not calling frame() and modifying the scene in the GUI thread at the same time, is it necessary to call stopThreading/startThreading? If your frame loop is running single threaded then stopTheading/startThreading will do nothing whatso ever. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD and IntersectionVisitor
On Fri, Jun 27, 2008 at 2:14 PM, Paul Martz [EMAIL PROTECTED] wrote: What I make of it is you a flogging the PagedLOD because it can handle misuse of it. Fix the database. I encourage you to reread my previous post, as the test data I posted clearly concerns questionable LOD behavior; the PagedLOD case works fine... Just re-read, and tested the paged.osg and lod.osg files, and confirm at my end that the picking ist working for paged.osg but not lod.osg. The IntersectionVistor code should be using the LOD::traverse() method, and the TRAVERSE_ACTIVE_CHILDREN method in particular. This code itself has been pretty reliable for a number of years, so I'd guess it's correct. Perhaps its the getDistanceToViewPoint code is not producing appropriate values. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to take a picture of my scene?
My code :
osg::Image *Ximage;
osg::Camera* cam = new osg::Camera;
cam-setProjectionMatrixAsPerspective(20,1,20,100);
cam-setViewport(0,0,640,180);
cam-setClearColor(osg::Vec4(0.7,0.7,1,1));
osgViewer::Viewer viewer;
viewer.setSceneData( root );
viewer.setCameraManipulator(new
osgGA::TrackballManipulator);
//viewer.setCamera(cam);
viewer.addEventHandler( new
myKeyboardEventHandler );
viewer.realize();
while( !viewer.done() )
{
cam-setViewMatrixAsLookAt(
osg::Vec3(posx,posy,posz),
osg::Vec3(tposx,tposy,tposz),
osg::Vec3(0,0,1) );
Ximage-readPixels(100,100,640,480, GL_RGBA, GL_UNSIGNED_BYTE);
osgDB::writeImageFile(*Ximage,teste.bmp);
viewer.frame();
}
The image teste.bmp is black . I m trying the example osgScreenCapture but
some errors is appearing .
http://www.somarmeteorologia.com.br
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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. or g ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Hi John, I have pointed you in the right direction. You can do what you need to do using node masks and multiple node/buffers. Robert. On Fri, Jun 27, 2008 at 7:27 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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. or g ___ 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.or g ___ osg-users mailing list
Re: [osg-users] osgViewer help needed
Node Masks is the thing to look at using -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, June 27, 2008 2:28 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer help needed Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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. or g ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] osgViewer help needed
Gordon, When do you change the node masks? Also, node masks are limited by the number of bits they contain. In a simulation, we could have 1000 entities. Some are not selected, selected, highlighted etc in each view. We'd run out of bits pretty quickly. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Friday, June 27, 2008 2:39 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] osgViewer help needed Node Masks is the thing to look at using -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, June 27, 2008 2:28 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer help needed Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ 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. or g
Re: [osg-users] osgViewer help needed
On Fri, Jun 27, 2008 at 7:41 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Gordon, When do you change the node masks? Also, node masks are limited by the number of bits they contain. In a simulation, we could have 1000 entities. Some are not selected, selected, highlighted etc in each view. We'd run out of bits pretty quickly. You don't have 1000's of views do you? Please have a look at the osgstereimage example to see how camera cull masks and node masks can be used together. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Well you could do it many ways, it seems like you have 2 main states pickable/not pickable then you have your views, you would not have a seperate mask for every objects(If you want unique for every then you could encode an ID in the nodes/objects top node and store it in its name) So you have for 2 views Camera mask stays at 0xff Then each views would have a mask for the selection to say what is pickable in that view, so this would give you 15 views 0xfff (thedefault) coulc be say the not selectable mask in any view Selectable groups and nodevistors would then use something like 0x0001 the node would selectable in view 0 0x0010 the node would selectable in view 1 0x0100 the node would selectable in view 2 Etc etc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, June 27, 2008 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer help needed Gordon, When do you change the node masks? Also, node masks are limited by the number of bits they contain. In a simulation, we could have 1000 entities. Some are not selected, selected, highlighted etc in each view. We'd run out of bits pretty quickly. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Friday, June 27, 2008 2:39 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] osgViewer help needed Node Masks is the thing to look at using -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, June 27, 2008 2:28 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer help needed Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users
Re: [osg-users] How to take a picture of my scene?
You most likely do not have a valid Opengl Context as you doing this in the
main Application thread
You will need to make you application single threaded if you want to do it
this way
Or the traditional way would be with a post draw call back ( there are many
examples floating around )
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanches
Sent: Friday, June 27, 2008 2:07 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] How to take a picture of my scene?
My code :
osg::Image *Ximage;
osg::Camera* cam = new osg::Camera;
cam-setProjectionMatrixAsPerspective(20,1,20,100);
cam-setViewport(0,0,640,180);
cam-setClearColor(osg::Vec4(0.7,0.7,1,1));
osgViewer::Viewer viewer;
viewer.setSceneData( root );
viewer.setCameraManipulator(new
osgGA::TrackballManipulator);
//viewer.setCamera(cam);
viewer.addEventHandler( new
myKeyboardEventHandler );
viewer.realize();
while( !viewer.done() )
{
cam-setViewMatrixAsLookAt(
osg::Vec3(posx,posy,posz),
osg::Vec3(tposx,tposy,tposz),
osg::Vec3(0,0,1) );
Ximage-readPixels(100,100,640,480, GL_RGBA, GL_UNSIGNED_BYTE);
osgDB::writeImageFile(*Ximage,teste.bmp);
viewer.frame();
}
The image teste.bmp is black . I m trying the example osgScreenCapture but
some errors is appearing .
http://www.somarmeteorologia.com.br
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Glut/OSG occlusion
Hi, When I was playing around with the osgviewerGlut example, I realized that there was no actual interaction between the what I was drawing with openGL and with osg. It seems like whatever is drawn later occludes what is already there. When viewer-frame() is called, even what should be clear background blocks out already drawn objects. I've tried messing around with camera settings (and broken my application in many interesting ways), but I can't figure out how to avoid losing all of my already rendered stuff when I call viewer-frame. I would prefer to have the osg objects interact enough with the openGL drawing to render by depth, but even getting OSG to not occlude everything already drawn would be nice. Thanks for your help, Mark Henderson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Glut/OSG occlusion
Hello Mark, I've tried messing around with camera settings (and broken my application in many interesting ways), but I can't figure out how to avoid losing all of my already rendered stuff when I call viewer-frame. I would prefer to have the osg objects interact enough with the openGL drawing to render by depth, but even getting OSG to not occlude everything already drawn would be nice. Mixing straight OpenGL code with OSG is always a bit perilous as you leave yourself open to all kinds of issues with leftover state frm one side of the app affecting the other side. But to answer your question, viewer-getCamera()-setClearMask(0x0); will make it so that OSG does not clear either the depth buffer or the color buffer when it starts to render, so what was there before stays. That means that any information in the z-buffer and color buffer from your OpenGL render will stay there and be tested when OSG renders. If you need the opposite, then just don't call glClear() at the beginning of your OpenGL rendering. Note that you need at least one of the two paths to clear the depth and color buffers, the first one to render in a given frame (OpenGL or OSG) should be the one to do it. Also note that transparency / blending probably won't work right, since transparent objects will be drawn by OSG at the end of its drawing, then your OpenGL opaque objects will get drawn over them and then your own OpenGL transparent objects (or the opposite, OpenGL then OSG). Just another reason not to mix OpenGL and OSG. OSG takes care of that for you. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how osg quicktime plugin handle quicktime message?
Hi, I am working on quicktime real time streaming and hope can make it work as the osg plugin. But I cannot find any part that osg qt plugin handle quicktime message. For network streaming, I think quicktime need to contact with windows system to get message. Is that right? Thanks in advance Hui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to take a picture of my scene?
I made all of the osgWidget videos using Bugle; it's really the best thing I've found for this kind of thing. On Thu, 2008-06-26 at 14:09 -0400, Vican, Justin E. wrote: Hi Carlos, As Robert mentioned, there has been a lot of discussion about this topic recently. I posted a camera callback code update to the osgcompositeviewer example a few days ago (attached). It should do the trick for you. As far as stringing the frames together into a movie, in the past I have done this using FFMPEG. If you use an image naming scheme similar to the one in this code example, you should be able to reconstruct a movie in any format that you choose. I'm sure that there are numerous other tools that can accomplish this. If you're using something else, I'd be interested to hear what tools you've used, and how well they worked. Hope this helps, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 1:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] How to take a picture of my scene? On Thu, Jun 26, 2008 at 5:52 PM, Carlos Sanches [EMAIL PROTECTED] wrote: I m doing this : Ximage-readPixels(100,100,640,480, GL_RGBA, GL_UNSIGNED_BYTE); osgDB::writeImageFile(*Ximage,teste.bmp); but this is creating a black image :( You are likely just reading pixels from the wrong thread. Where abouts to you call the readPixles? Have you look at the osgscreencapture example in the SVN version of the OSG for inspiration. Robert. ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
