Re: [osg-users] New Stereo Format: Checkerboard
Hi Galen, can you explain how you tested it on a TV ? what do i need for testing it /regards 2007/8/23, Galen Faidley <[EMAIL PROTECTED]>: > > Hi Robert, > > Please find attached the modifications to get the new checkerboard > stereo format to work. It's a good thing I tested these on a TV > before submitting them since I did indeed have a bug. One thing I > did not test was to see how this would work in windowed mode. Does > the interlaced stereo code have support for 'absolute' positions? > For example a given pixel on the screen is always shown in a given > eye no matter where the graphics context is placed? > > Following up on your last e-mail I'm afraid I can't quite figure > our > how to attach the TV to this e-mail ;) > > On a more serious note your comment about content hit the nail > right > on the head. I see the lack of content as the largest hurdle for > adoption of stereo viewing in the home. There is some hope if the > game consoles come out with stereo support but we'll have to wait and > see if that's enough. > > Regards > Galen > > include/osg/DisplaySettings > > > src/osg/DisplaySettings.cpp > > > src/osgUtil/SceneView.cpp > > > src/osgViewer/View.cpp > > > src/osgWrappers/osg/DisplaySettings.cpp (I renamed this one in case > there were problems sending files with the same name) > > > > > On Aug 11, 2007, at 2:43 PM, Robert Osfield wrote: > > > Hi Galen, > > > > I've haven't heard of checkerboard arrangement for stereo before so > > one can sure the OSG doesn't support it out of the box yet. I would > > be straight forward to implement the stereo approach using the stencil > > buffer in the same way the the interlaced stereo is currently > > supported, all you'd need is a different mask. > > > > Robert. > > > > On 8/11/07, Galen Faidley <[EMAIL PROTECTED]> wrote: > >> Hello All, > >> > >> I got to talk to the Texas Instruments (TI) folks in the > >> emerging > >> technologies area at SIGGRAPH about stereo capable TVs using their > >> DLP technology. The format relies on the fact that they use > >> 'wobulation' to display a 1900x1080p60Hz signal by combining two > >> 950x1080p120Hz sub-frames. The sub-frames are arranged in a > >> checkerboard grid pattern: all the black squares would be displayed > >> in one sub frame and the whites in the next. So if you render two > >> 950x1080 images, one for each eye, and combine them into the > >> checkerboard you will be able to display a time sequential stereo > >> image. You then need a pair of shutter glasses synced to the > >> 'wobulation'. More and more TVs are now providing this sync signal. > >> For example all 2007 Samsung rear projections TV have a 3 pin stereo > >> emitter port on them. > >> > >> I haven't looked at the stereo code in OSG but in I would > >> hope this > >> new format could be included. I imagine ether a more traditional > >> stencil buffer approach or more modern rendering to two offscreen > >> buffers and combining them in a shader program would get the job > >> done. > >> > >> TI has more information available about 3D on DLPs on > >> their web > >> site: http://www.dlp.com/3d > >> > >> Regards > >> Galen > >> > >> > >> PS - I apologize if this has already been discussed. I have not been > >> as diligent as I once was at reading the list and my search did not > >> find anything. > >> ___ > >> 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 > > > -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Infrared Sensor Simulation?
Hi Yefei I believe JRM Technologies use OSG in their sensor work www.jrmtech.com Mark No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.2/966 - Release Date: 22-Aug-07 9:05 AM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Max OS X tutorial videos, broken links (was: RE: Tutorials)
D'oh. Are the files lost, or are the links just broken? Thanks, Eric On 8/22/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > Eric Wing has put a few very informative videos on the OSG wiki > > > regarding installing/using OSG on a Mac: > > > http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips > > > > Alas, all the videos on that page seem to point to broken > > links. Any chance > > of making them work again? > > Hm, that's unfortunate. They're great videos. > > Posting this with a different subject to raise visibility. >-Paul > > ___ > 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] Max OS X tutorial videos, broken links (was: RE: Tutorials)
> > Eric Wing has put a few very informative videos on the OSG wiki > > regarding installing/using OSG on a Mac: > > http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips > > Alas, all the videos on that page seem to point to broken > links. Any chance > of making them work again? Hm, that's unfortunate. They're great videos. Posting this with a different subject to raise visibility. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
I agree with you when i need doc i read the code and or example. Alberto Luaces wrote: > El Miércoles 22 Agosto 2007, Robert Osfield escribió: > >> Are the examples of no use to any one??? Shall I just do a >> >> svn rm examples >> >> ? >> > > Are you kidding? For me, the examples are the only source of information in > order to use the most parts of OSG. I think I could never get the knowledge > to use osgShadow from the doxygen reference and without having the examples. > The same applies for all the integration examples for QT, wxWidgets, etc. > > Please keep them in the repository, they are also good tests for finding bugs > in new releases, to give hints to new users, etc > > Alberto > ___ > 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] Tutorials
Hey All, Congrats and big thanks to those that have been adding documentation! I've been largely away from OSG for a while, but the work looks mighty impressive. I think Robert's question about different users is the key. The examples are absolutely fantastic and work great for some, not so great for others. Tutorials seem to be a helpful bridge. (The original goal of the NPS tutorial set was to get students w/out engineering background comfortable enough to dive into the examples.) Soo... What does it take to move the tutorials currently on the NPS web site over to the osg wiki site? Is there anybody that can spare some resources to help the effort? Thanks, Joe S. > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: Wednesday, August 22, 2007 11:55 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Tutorials > > On 8/22/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: > > > Are the examples of no use to any one??? Shall I just do a > > > > > > svn rm examples > > > > > > ? > > > > No, they very much are. :) It's just that those of us that DO use the > > examples don't post here saying so... > > Its O.K. I'm not serious about to remove them, just frustrating my > frustration at big chunks of work that is dedicated to helping new > users being ignored. > > > As far as example usefulness is concerned, "no news is good news." > > Honestly, in contrast to the entire discussion at hand, I _rarely_ use > > documentation. I always just look at the code. Documentation in a formal > > sense makes me want to take a nap... > > In other projects I do occasionally look for documentation, but rarely > does it help me more than a succinct code example. If you are > experienced programmer than its the code that tells you everything. > > It would be interesting to do a profile of different users to see what > types of assistance to get their programs written they find most > effective. When I say assistance I mean documentation, mailing list > archives, examples, code comments, code itself, class naming, method > naming. > > I do wonder if too many developers these days are expecting to put in > too little real effort for the amount of results they are wanting. > Programming is hard. Real-time graphics is a BIG topic. To master > them you have lavish lots of time. > > When I first started programming as a kid there was just practically > nothing available relative to today, I didn't know any better, I > enjoyed in a perverse way learning by myself how to code Z80 > assembler. Yes it took weeks just to get a few coloured sprites > animating across the screen, but I didn't go ranting at anyone for > lack of guidance and docs, I just enjoyed figuring it out and getting > the final result. Fast forward to today and the with 10 lines of code > in the OSG you can create and load a terabyte sized 3D world and > interact with it at a solid 60Hz. But yet some people seem to expect > more much more. > > 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
Re: [osg-users] Tutorials
> From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Paul Martz > > Eric Wing has put a few very informative videos on the OSG wiki > regarding > installing/using OSG on a Mac: > http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips > Alas, all the videos on that page seem to point to broken links. Any chance of making them work again? Thanks Frank ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
I would also add see Opengl Distilled ;) Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 571-265-2612 <-- Note New Number Telephone (Work): (+1) 703-437-7651 "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Martz Sent: Wednesday, August 22, 2007 6:05 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials > As the author, you > clearly see the relationship with OpenGL. For a newbie, this > relationship is not immediatly obvious. Good point, thanks for the reminder. I always try to be concise, sometimes to a fault. I could add a few extra sentences here and there saying "this is identical to OpenGL, see the OpenGL red book for more info" and I'll try to remember to do that. > Here's my proposal for putting together tutorials without > breaking the bank: YouTube Screen Casts. Eric Wing has put a few very informative videos on the OSG wiki regarding installing/using OSG on a Mac: http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips Your PHP cookies video shows this same technique can also be used for programming topics. -Paul ___ 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] Tutorials
> As the author, you > clearly see the relationship with OpenGL. For a newbie, this > relationship is not immediatly obvious. Good point, thanks for the reminder. I always try to be concise, sometimes to a fault. I could add a few extra sentences here and there saying "this is identical to OpenGL, see the OpenGL red book for more info" and I'll try to remember to do that. > Here's my proposal for putting together tutorials without > breaking the bank: YouTube Screen Casts. Eric Wing has put a few very informative videos on the OSG wiki regarding installing/using OSG on a Mac: http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips Your PHP cookies video shows this same technique can also be used for programming topics. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
These are all good topics and most are planned for inclusion into the future OSG Programming Guide. They will certainly be included in the intermediate to advanced OSG courses that Bob and I teach: http://www.skew-matrix.com/training.asp (Shameless plug: only a couple slots left in the Alabama course.) -Paul > 1) How does OpenSceneGraph deal with performance issues ? --> > explain the multithread configurations (how their divide > CULL/DRAW), the synchronization issues, in a sythetic and > comprehensible way... > 2) How are OpenSceneGraph internals designed for the culling issues ? > 2') How are OpenSceneGraph internals designed to attack OGL > pipeline (draw > calls) ? --> like developped above context > push/pop/inheritance ; constitution of the rendering list ; > orders of drawing for developpers of SFX with transparency > (bins, and so on) ; maybe also a word about the default > lighting equation using materials when no shader are set for > newbies to SFX development (example things like the use of > emissive, manners to set blending operation ie TexEnv vs or > plus TexEnvCombine, even if the latter is more here an OpenGL > problem)... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thread safety improvements and CullThreadPerCameraDrawThreadPerContext now working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Robert Osfield wrote: > Could users that have seen problems with crash on exit, or with the > CullThreadPerCameraDrawThreadPerContext threading model do a svn > update and let me know how you get on. > I have updated to the current HEAD and tested it. DrawThreadPerContext doesn't seem to hang anymore, at least I wasn't able to reproduce the hang so far. CullThreadPerCameraDrawThreadPerContext is still hanging right at the first frame for me, but the deadlock seems to occur at a different place. The backtrace looks as follows: Thread 1: #0 0xb7f197f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a4e206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7a800a8 in OpenThreads::Condition::wait (this=0x83300b8, mutex=0x83300b0) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7b025f1 in osgViewer::Viewer::renderingTraversals (this=0xbf80d07c) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:133 #4 0xb7b087e3 in osgViewer::Viewer::frame (this=0xbf80d07c, simulationTime=1.7976931348623157e+308) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:992 #5 0xb7b0893a in osgViewer::Viewer::run (this=0xbf80d07c) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:194 #6 0x0804b069 in main (argc=Cannot access memory at address 0x0 ) at /media/backup/osg/OpenSceneGraph/applications/osgviewer/osgviewer.cpp:148 Thread 2: #0 0xb7f197f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a4e206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7a7fc65 in OpenThreads::Barrier::block (this=0x8330194, numThreads=0) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadBarrier.c++:182 #3 0xb7e1df8f in osg::BarrierOperation::operator() (this=0x8330188, object=0x8058328) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:73 #4 0xb7e47547 in osg::OperationThread::run (this=0x8330720) at /media/backup/osg/OpenSceneGraph/src/osg/OperationThread.cpp:413 #5 0xb7a7f7e4 in OpenThreads::ThreadPrivateActions::StartThread (data=0x8330730) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:158 #6 0xb7a4a462 in start_thread () from /lib/i686/libpthread.so.0 #7 0xb766782e in clone () from /lib/i686/libc.so.6 Thread 3 #0 0xb7f197f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a4e206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7a800a8 in OpenThreads::Condition::wait (this=0x8059148, mutex=0x8059140) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7ae252f in osgViewer::Renderer::TheadSafeQueue::takeFront (this=0x8059138) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:42 #4 0xb7ae6501 in osgViewer::Renderer::draw (this=0x80590c0) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Renderer.cpp:306 #5 0xb7ae6fa8 in osgViewer::Renderer::operator() (this=0xfe00, context=0x80aee00) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Renderer.cpp:560 #6 0xb7e17a4f in osg::GraphicsContext::runOperations (this=0x80aee00) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsContext.cpp:654 #7 0xb7e1decd in osg::RunOperations::operator() (this=0x8330680, context=0x80aee00) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:134 #8 0xb7e1df37 in osg::GraphicsOperation::operator() (this=0x8330680, object=0x80aee00) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:50 #9 0xb7e47547 in osg::OperationThread::run (this=0x8330380) at /media/backup/osg/OpenSceneGraph/src/osg/OperationThread.cpp:413 #10 0xb7e1e079 in osg::GraphicsThread::run (this=0x8330380) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:38 #11 0xb7a7f7e4 in OpenThreads::ThreadPrivateActions::StartThread (data=0x8330390) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:158 #12 0xb7a4a462 in start_thread () from /lib/i686/libpthread.so.0 #13 0xb766782e in clone () from /lib/i686/libc.so.6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGzKZFn11XseNj94gRAilYAJ0eaEbLK9Og0ZGlTkMuj/kitmox4ACZAY96 PiqznkcuwveZ3UM0WBDhGyc= =t5Bl -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NEAR_PLANE_CULLING and FAR_PLANE_CULLING
I'm trying to understand how the NEAR_PLANE_CULLING and FAR_PLANE_CULLING actually work in the cull phase. In my own cull visitor, I'm grabbing the plane list out of the frustum from the culling set, and testing points against each of those planes. I realize CullVisitor does that for me, but I need to know the result of the cull test - it's for an adaptive mesh. What's a little confusing is that I seem to get far clip culling when I pass in NEAR_PLANE_CULLING to setCullingMode(). Not sure what's happening when I pass in FAR_PLANE_CULLING -- I haven't put in any cheats so I can tell if the near clip cull is working or not. Any ideas as to why this would be backwards? Thanks, Nathan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text - SCREEN_COORDS
Thanks for answer, Yes, with alphabetic text the distortion is not so obvious, that is why I choosed "+" char in the example (same width and height). In fact I am using custom ttf font to display pick point marks on geometry and the character has circular shape - so it is more obvious. I observed that the change in character ratio is somehow smaller then the change in viewer aspect ratio. I will inspect the Text.cpp code and let know. Martin - PŮVODNÍ ZPRÁVA - Od: "Robert Osfield" <[EMAIL PROTECTED]> Komu: osg-users@lists.openscenegraph.org Předmět: Re: [osg-users] Text - SCREEN_COORDS Datum: 22.8.2007 - 21:19:00 > On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > ... so nobody have ever faced problems with bad text > > proportion when > > > using SCREEN_COORDS for CharacterSize? > > The aspect ratio didn't look that wrong to me, but > then I haven't see > the sequence of aspect ratios. Feel free to dig in > the code to see > what might be need to be adjusted. > > As for heights, the character size is the size for > the maximum glyph > size, not just capitals that you had on screen so you > would expect > normal characters to be smaller than the overall CharacterSize. > > 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] Tutorials
> As far as example usefulness is concerned, "no news is good news." > Honestly, in contrast to the entire discussion at hand, I > _rarely_ use documentation. I always just look at the code. > Documentation in a formal sense makes me want to take a nap... Ironically, I agree with you, but don't tell anyone, it would ruin my reputation as a writer. :-) When I'm trying to learn some new aspect of OSG, I look for an existing example first, then I usually browse through related header files used by the example, then I dig into the source code if I need more info. Sometimes I resort to breakpoints in OSG while running an example to find out what's really going on. Printed documentation, I rarely read it cover to cover. I usually look at the TOC or index and jump to the section I'm interested in. And I've actually used the Quick Start Guide this way: If I'm trying to remember how to do something that I _know_ I covered in the QSG, I look it up in the TOC or index and read what I wrote. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text - SCREEN_COORDS
On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > ... so nobody have ever faced problems with bad text proportion when > using SCREEN_COORDS for CharacterSize? The aspect ratio didn't look that wrong to me, but then I haven't see the sequence of aspect ratios. Feel free to dig in the code to see what might be need to be adjusted. As for heights, the character size is the size for the maximum glyph size, not just capitals that you had on screen so you would expect normal characters to be smaller than the overall CharacterSize. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgpick error (window-mode)
On 8/22/07, Roni Rosenzweig <[EMAIL PROTECTED]> wrote: > > Hello > > I'm running the osgpick example in window mode (I added the > WindowsSizeHandler and pressed 'f', nothing special), but the pick is not > working correctly in this mode - sometimes an intersection is detected when > the mouse is OUTSIDE the model, and sometimes not detected when the mouse is > ON the model. > > Any ideas? Anyone had this problem? > (the only thing I added to the code was the windows size handler) I haven't seen this problem, I'll need to mod one of the examples to reproduce it and haven't had a chance to do this yet. I am surprised it doesn't just work, as the resize event should reset the various internals of osgViewer that the picking code should remain correct. Perhaps there is something hardwired in the osgpick example that misses the change in size, or perhaps something in the resize handler that isn't done properly, or perhaps just a plain bug. I'm afraid I have lots of my plate right now so can't look into it right away. Perhaps others might have something to add, but if they don't reply its probably like me that don't have any straight answers. 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 set the perspective
On 8/22/07, Paul Martz <[EMAIL PROTECTED]> wrote:
> > The fourth way is to attach a custom update callback to the camera.
>
> Good point. Because events are processed before the update traversal, this
> allows the app to override any camera manipulators.
My favoured curstom way is still just to set it in the main loop and
not register a camera manipulator i.e.
Viewer viewer;
viewer.setSceneData(readNodeFile("cow.osg"));
viewer.realize();
while(!viewer.done())
{
viewer.getCamera()->setViewMarix(myViewMatrix);
viewer.frame();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] s_serialize_readNodeFile_mutex in DatabasePager
Hi Adrian, On 8/22/07, Adrian Egli <[EMAIL PROTECTED]> wrote: > i did some further tests and the problem is in reading two IVE files in two > different threads. Then suddenly the system gets block, i don't know what > can cause to probleme, i will look depther into the plugin code Try putting a serialize into the readNodeFile in the IVE plugin. There is one in the OpenFlight plugins ReaderWriterFLT.cpp that you could copy. 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 set the perspective
> The fourth way is to attach a custom update callback to the camera. Good point. Because events are processed before the update traversal, this allows the app to override any camera manipulators. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
On 8/22/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote: > On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: > > Are the examples of no use to any one??? Shall I just do a > > > > svn rm examples > > > > ? > > No, they very much are. :) It's just that those of us that DO use the > examples don't post here saying so... Its O.K. I'm not serious about to remove them, just frustrating my frustration at big chunks of work that is dedicated to helping new users being ignored. > As far as example usefulness is concerned, "no news is good news." > Honestly, in contrast to the entire discussion at hand, I _rarely_ use > documentation. I always just look at the code. Documentation in a formal > sense makes me want to take a nap... In other projects I do occasionally look for documentation, but rarely does it help me more than a succinct code example. If you are experienced programmer than its the code that tells you everything. It would be interesting to do a profile of different users to see what types of assistance to get their programs written they find most effective. When I say assistance I mean documentation, mailing list archives, examples, code comments, code itself, class naming, method naming. I do wonder if too many developers these days are expecting to put in too little real effort for the amount of results they are wanting. Programming is hard. Real-time graphics is a BIG topic. To master them you have lavish lots of time. When I first started programming as a kid there was just practically nothing available relative to today, I didn't know any better, I enjoyed in a perverse way learning by myself how to code Z80 assembler. Yes it took weeks just to get a few coloured sprites animating across the screen, but I didn't go ranting at anyone for lack of guidance and docs, I just enjoyed figuring it out and getting the final result. Fast forward to today and the with 10 lines of code in the OSG you can create and load a terabyte sized 3D world and interact with it at a solid 60Hz. But yet some people seem to expect more much more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
El Miércoles 22 Agosto 2007, Robert Osfield escribió: > Are the examples of no use to any one??? Shall I just do a > > svn rm examples > > ? Are you kidding? For me, the examples are the only source of information in order to use the most parts of OSG. I think I could never get the knowledge to use osgShadow from the doxygen reference and without having the examples. The same applies for all the integration examples for QT, wxWidgets, etc. Please keep them in the repository, they are also good tests for finding bugs in new releases, to give hints to new users, etc Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: > Are the examples of no use to any one??? Shall I just do a > > svn rm examples > > ? No, they very much are. :) It's just that those of us that DO use the examples don't post here saying so... As far as example usefulness is concerned, "no news is good news." Honestly, in contrast to the entire discussion at hand, I _rarely_ use documentation. I always just look at the code. Documentation in a formal sense makes me want to take a nap... > On 8/22/07, Rizzen <[EMAIL PROTECTED]> wrote: > > Here is my noob point of view on this topic. > > > > Firstly Joe helped me a great deal just by providing us those fantastic > > tutorials (focusing on one feature at a time) he did for his students at > > the Navy Academy. Even though I am no guru in OpenGL, I know enough to > > create the needed results I needed, I managed to create a OSG scene > > quickly and how to manipulate the scene. For a long time Joe's work was > > really the only resource in learning OSG. Oh, forget about the generated > > API documentation, nothing much there to be of much help to a noob. > > > > The next good resource to hit the scene is Paul's QSG. This free book, > > really compliments Joe's work so far. Allowing a noob to have a speedier > > learning curve than without these two resources. > > > > As Paul has mentioned already, he is planning a series of OSG books to > > covering various aspects of OSG. From the quality of the QSG to the > > noobs, the series will surely fill in the plenty needed detail that is > > missing from the QSG. > > > > Robert himself has been very helpful in answering question put forward > > by the community. Often a search through the mail list yields many > > answers provided by many who have become experienced at using OSG. > > > > So I salute all those who have contributed to the current tutorial > > collection and first 2 books on OSG. > > > > Rizzen > > ___ > > 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] How to set the perspective
On 8/22/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > viewer.getCamera()->setProjectionMatrix(...); > > Hi Robert -- That's good for the projection matrix. If I can, I'd like to > explore setting the view matrix a little further. > > Seems like there are three ways an osgViewer-based app can set the view > matrix: > > 1) Attach a camera manipulator to the viewer. The camera manipulator owns > setting the view, the app need do nothing else. > > 2) Don't attach a camera manipulator. The app owns changing the view by > calling viewer->getCamera() and using the camera's many view-setting > methods. > > 3) Like 1) above, except the app can explicitly change the view by calling > into the camera manipulator (e.g., setByMatrix()). > > Is that a pretty good summary? Comments and corrections, please. The fourth way is to attach a custom update callback to the camera. Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
Rather than rant get off your arse, the website is a wiki YOU YES YOU can help arrange and contribute things. On 8/22/07, mkg <[EMAIL PROTECTED]> wrote: > The best kind of code documentation, for me at least, has always been > annotated online demo code, such as NeHe's OpenGL walkthroughs and > Irrlicht3D's online tutorials: > http://nehe.gamedev.net/ > http://irrlicht.sourceforge.net/tutorials.html > > The main problem with OSG's documentation isn't that there's not enough > of it, but that it's poorly presented on the website. You have to click > twice before finding the tutorials page, and then you're presented with > an undifferentiated forest of links that happen to include Joseph > Sullivan's excellent set of easy-to-browse tutorials, along with other > people's random mystery tarballs. > > Contrast this with irrlicht3d's presentation (see link above), where > there's one official tutorial page, linked directly off the main page, > with thumbnails for each tutorial. > > What would be best, in my opinion, is to get rid of that splash page > (!), and on the main page have the sidebar display "Downloads", > "Tutorials", "API", and "Other references" explicitly, at the top. I > would get rid of the first 6 items in the current sidebar and just move > them to the "About" page, because most people don't care (sorry) about > things like "Introduction" and "History". The tutorials should all be > webpages rather than tarballs, and be indexed with thumbnails on the > tutorials page, in rough order of difficulty (Joseph Sullivan has it > right). Oh, and why is there a splash page?? (Okay, ending rant.) > > *Wheeze, wheeze,* > -- Matt > ___ > 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] Tutorials
Are the examples of no use to any one??? Shall I just do a svn rm examples ? On 8/22/07, Rizzen <[EMAIL PROTECTED]> wrote: > Here is my noob point of view on this topic. > > Firstly Joe helped me a great deal just by providing us those fantastic > tutorials (focusing on one feature at a time) he did for his students at > the Navy Academy. Even though I am no guru in OpenGL, I know enough to > create the needed results I needed, I managed to create a OSG scene > quickly and how to manipulate the scene. For a long time Joe's work was > really the only resource in learning OSG. Oh, forget about the generated > API documentation, nothing much there to be of much help to a noob. > > The next good resource to hit the scene is Paul's QSG. This free book, > really compliments Joe's work so far. Allowing a noob to have a speedier > learning curve than without these two resources. > > As Paul has mentioned already, he is planning a series of OSG books to > covering various aspects of OSG. From the quality of the QSG to the > noobs, the series will surely fill in the plenty needed detail that is > missing from the QSG. > > Robert himself has been very helpful in answering question put forward > by the community. Often a search through the mail list yields many > answers provided by many who have become experienced at using OSG. > > So I salute all those who have contributed to the current tutorial > collection and first 2 books on OSG. > > Rizzen > ___ > 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] How to set the perspective
> To set the view and projection matrix simply be the Viewer's > Camera and set them. > > i.e. > > viewer.getCamera()->setProjectionMatrix(...); Hi Robert -- That's good for the projection matrix. If I can, I'd like to explore setting the view matrix a little further. Seems like there are three ways an osgViewer-based app can set the view matrix: 1) Attach a camera manipulator to the viewer. The camera manipulator owns setting the view, the app need do nothing else. 2) Don't attach a camera manipulator. The app owns changing the view by calling viewer->getCamera() and using the camera's many view-setting methods. 3) Like 1) above, except the app can explicitly change the view by calling into the camera manipulator (e.g., setByMatrix()). Is that a pretty good summary? Comments and corrections, please. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
The best kind of code documentation, for me at least, has always been annotated online demo code, such as NeHe's OpenGL walkthroughs and Irrlicht3D's online tutorials: http://nehe.gamedev.net/ http://irrlicht.sourceforge.net/tutorials.html The main problem with OSG's documentation isn't that there's not enough of it, but that it's poorly presented on the website. You have to click twice before finding the tutorials page, and then you're presented with an undifferentiated forest of links that happen to include Joseph Sullivan's excellent set of easy-to-browse tutorials, along with other people's random mystery tarballs. Contrast this with irrlicht3d's presentation (see link above), where there's one official tutorial page, linked directly off the main page, with thumbnails for each tutorial. What would be best, in my opinion, is to get rid of that splash page (!), and on the main page have the sidebar display "Downloads", "Tutorials", "API", and "Other references" explicitly, at the top. I would get rid of the first 6 items in the current sidebar and just move them to the "About" page, because most people don't care (sorry) about things like "Introduction" and "History". The tutorials should all be webpages rather than tarballs, and be indexed with thumbnails on the tutorials page, in rough order of difficulty (Joseph Sullivan has it right). Oh, and why is there a splash page?? (Okay, ending rant.) *Wheeze, wheeze,* -- Matt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
Here is my noob point of view on this topic. Firstly Joe helped me a great deal just by providing us those fantastic tutorials (focusing on one feature at a time) he did for his students at the Navy Academy. Even though I am no guru in OpenGL, I know enough to create the needed results I needed, I managed to create a OSG scene quickly and how to manipulate the scene. For a long time Joe's work was really the only resource in learning OSG. Oh, forget about the generated API documentation, nothing much there to be of much help to a noob. The next good resource to hit the scene is Paul's QSG. This free book, really compliments Joe's work so far. Allowing a noob to have a speedier learning curve than without these two resources. As Paul has mentioned already, he is planning a series of OSG books to covering various aspects of OSG. From the quality of the QSG to the noobs, the series will surely fill in the plenty needed detail that is missing from the QSG. Robert himself has been very helpful in answering question put forward by the community. Often a search through the mail list yields many answers provided by many who have become experienced at using OSG. So I salute all those who have contributed to the current tutorial collection and first 2 books on OSG. Rizzen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Infrared Sensor Simulation?
Hello, OSG'ers, I'm looking for information on real-time infrared sensor simulation. To put it plainly, to render night scenes in a way that an infrared camera may capture. This may not be directly related to OSG, but has any of you done this, or can provide pointers to how it is being done. I don't need a very accurate physics based model. However, it needs to be reasonable. To explain this, I'm trying to simulate the night vision systems on some cars in a driving simulation study. The moment an object becomes discernable in the simulated IR image should not deviate too much from the real world situation. Of course, I also need to make sure that the detection distances of various objects in the normally rendered night scenes are close to real world as well. Thanks, Yefei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to set the perspective
Hi Ryven, To set the view and projection matrix simply be the Viewer's Camera and set them. i.e. viewer.getCamera()->setProjectionMatrix(...); Robert. On 8/22/07, Ryven <[EMAIL PROTECTED]> wrote: > Hello, > > I'm trying to set a perpective and view matrix on the new osgViewer, > when using producer I could set it directly.. but with the new viewer > I have not figure it out. > How can I set the view matrix, and perspective, directly on the new osgViewer, > > thanks > > (sorr about the bad english) > ___ > 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] Tutorials
On 8/22/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote: > On Wed, 2007-08-22 at 06:14 -0400, Gordon Tomlinson wrote: > > Very well said Robert > > > > And Great Job Paul Martz and everyone who helps and contributes > > > > But can some one please press F5 for me, its just too much effort to have to > > compile things my self ;) > > Press F5!? Real men run make. No real men type make -j 4 And laugh at the build fly build. Then weep at the power bill :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_CULL_FACE && GL_BLEND && GL_DEPTH_TEST
Hi, I have to recommend that you browse the archives on this topic, there has been a huge amount said on this topic. Robert. On 8/22/07, blinkeye <[EMAIL PROTECTED]> wrote: > Hi Robert, > > thanks a lot for the prompt answer. I've been eagerly following the other > thread you mentioned, thanks. > > I'm looking at the src/osg/ShapeDrawable.cpp now, it sounds like I have to > do the same thing. > > I nevertheless attached a few screenshots to make it clear. The last two > images (inside1.jpg and inside2.jpg) show that the inside faces are not > drawn when the camera moves into the triangle. > > On Wed, August 22, 2007 15:12, Robert Osfield wrote: > > I'm not 100% sure what you are after, my best guess is that you want > > to renderer a transparent object that is a has front and back faces > > w.r.t the viewer, but depending on the view the front face sometimes > > occludes the back face preventing transparency from working correctly. > > > > I answered a question on transparent sorting yesterday so look this > > up. An extra trick you can apply for single geometries like > > spheres/cubes is enforce the required draw order for transparent > > objects (you must first draw the furthest faces and then the nearest), > > is to use cull face to cull back faces, and then use two sets of > > primitives within this geometry, the first set have their orientations > > pointing inwards, then the second have them pointing outwards. The > > src/osg/ShapeDrawable.cpp uses this trick. > > > > Robert. > > > > On 8/22/07, blinkeye <[EMAIL PROTECTED]> wrote: > >> Hello fellow osg users > >> > >> I've been trying for days to implement what I thought of as a simple > >> thing: > >> > >> A translucent figure like a dome, a cubus or a triangle where faces > >> behind > >> don't shine through and which inside faces are rendered when the camera > >> is > >> inside the figure. > >> > >> I've managed that by using GL_CULL_FACE > >> > >> osg::StateSet* states = new osg::StateSet(); > >> states->setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); > >> states->setRenderBinDetails( 2, "RenderBin" ); > >> states->setMode( GL_CULL_FACE, osg::StateAttribute::OVERRIDE | > >> osg::StateAttribute::ON ); > >> states->setMode( GL_BLEND, osg::StateAttribute::OVERRIDE | > >> osg::StateAttribute::ON ); > >> states->setMode( GL_DEPTH_TEST, osg::StateAttribute::OVERRIDE | > >> osg::StateAttribute::ON ); > >> > >> So far so good, but now the problem: If the camera is inside the > >> translucent figure I don't see the inside faces. > >> > >> Is there something I'm doing wrong or shouldn't now the inside faces be > >> drawn (but not the outside faces)? > >> > >> I know this is more an OpenGL issue but I can't seem to find the answer > >> anywhere. > >> > >> > >> > >> > >> > >> ___ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to set the perspective
Hello, I'm trying to set a perpective and view matrix on the new osgViewer, when using producer I could set it directly.. but with the new viewer I have not figure it out. How can I set the view matrix, and perspective, directly on the new osgViewer, thanks (sorr about the bad english) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help !!! Exampe osgViewerMFC Problem of fresh men
Hi, The MFC example seem to have changed lately. I suggest you grab the latest version from SVN and compile that. I'm not usre this will fix your problem, but worth try anyway. - Nick - From: ÕÔÃ÷ΰ <[EMAIL PROTECTED]> Reply-To: osg-users@lists.openscenegraph.org To: osg-users@lists.openscenegraph.org Subject: [osg-users] Help !!! Exampe osgViewerMFC Problem of fresh men Date: Wed, 22 Aug 2007 22:02:16 +0800 (CST) Hello All. when I runned the example osgViewerMFC in OSG 2.0 and in the vs2005. The Program can not terminate correctly. There are many Memory Leak message in the output windows. finally The program seems to be dead and locked. I don't know why and how to fixed that. I am not good at English. So I'm not sure can you understand what I said :-( Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Hotmail is the next generation of MSN Hotmail. Its fast, simple, and safer than ever and best of all its still free. Try it today! www.newhotmail.ca?icid=WLHMENCA146 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
On Wed, 2007-08-22 at 06:14 -0400, Gordon Tomlinson wrote: > Very well said Robert > > And Great Job Paul Martz and everyone who helps and contributes > > But can some one please press F5 for me, its just too much effort to have to > compile things my self ;) Press F5!? Real men run make. :) > __ > Gordon Tomlinson > > Email : [EMAIL PROTECTED] > YIM/AIM : gordon3dBrit > MSN IM : [EMAIL PROTECTED] > Website : www.vis-sim.com www.gordontomlinson.com > > __ > "Self defence is not a function of learning tricks > but is a function of how quickly and intensely one > can arouse one's instinct for survival" > -Master Tambo Tetsura > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Robert > Osfield > Sent: Wednesday, August 22, 2007 5:55 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Tutorials > > One thing we can be sure of is that they will *never* be enough > documentation for everybody. This isn't an OSG specific issue, it isn't a > closed source vs open source issue, it isn't even an IT specific issue, it > applies to everything in life. > > As Winston Churchil said (this is from memory so It might be little > mis-phrased): > > "One can please all of the people some of time, or some of the people all of > the time, but you can never please all the people all the time". > > -- > > I occasionally come across emails on osg-users from users that appear to me > to be almost asking for others to write their program for them, to teach > them every little detail of what they need to know. You write code and > publishing it for free and with an open license, you provide free support > and spend you time helping people out, yet this still isn't enough for some, > the mere act of giving a great deal seems to in somehow mean that you owe > others even more. > > So... I feel for Paul Martz, he's put a big effort into to getting the Quick > Start Guide, climbed a peak, taken a short rest, but now its a case of "well > actually that peak you climbed was just a foothill, you need to climb this > great mountain beyond, and oh BTW can you do it for free too". > > We are a community, so we don't walk alone, one must carry ones own weight > though, otherwise you can drag others back. We can all contribute in > different ways. Directly by helping write the books and tutorials. Or by > *purchasing* the books rather than just downloading the free pdf. > > 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 > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Help !!! Exampe osgViewerMFC Problem of fresh men
Hello All. when I runned the example osgViewerMFC in OSG 2.0 and in the vs2005. The Program can not terminate correctly. There are many Memory Leak message in the output windows. finally The program seems to be dead and locked. I don't know why and how to fixed that. I am not good at English. So I'm not sure can you understand what I said :-( Thanks___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > Here's my proposal for putting together tutorials without breaking the bank: > YouTube > Screen Casts. I recently learned a few PHP programming tricks from this > serie: > > >>> http://www.youtube.com/watch?v=Z5egpgAVxQI&mode=related&search= > > On the Mac, there are a few free solutions for doing this. There's no need > for a camera, since you are just capturing the screen. Then, you can post it > on YouTube, which saves you the bandwidth > distribution cost. Just an idea. Be prepared to volunteer your own time as well others :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_CULL_FACE && GL_BLEND && GL_DEPTH_TEST
I'm not 100% sure what you are after, my best guess is that you want to renderer a transparent object that is a has front and back faces w.r.t the viewer, but depending on the view the front face sometimes occludes the back face preventing transparency from working correctly. I answered a question on transparent sorting yesterday so look this up. An extra trick you can apply for single geometries like spheres/cubes is enforce the required draw order for transparent objects (you must first draw the furthest faces and then the nearest), is to use cull face to cull back faces, and then use two sets of primitives within this geometry, the first set have their orientations pointing inwards, then the second have them pointing outwards. The src/osg/ShapeDrawable.cpp uses this trick. Robert. On 8/22/07, blinkeye <[EMAIL PROTECTED]> wrote: > Hello fellow osg users > > I've been trying for days to implement what I thought of as a simple thing: > > A translucent figure like a dome, a cubus or a triangle where faces behind > don't shine through and which inside faces are rendered when the camera is > inside the figure. > > I've managed that by using GL_CULL_FACE > > osg::StateSet* states = new osg::StateSet(); > states->setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); > states->setRenderBinDetails( 2, "RenderBin" ); > states->setMode( GL_CULL_FACE, osg::StateAttribute::OVERRIDE | > osg::StateAttribute::ON ); > states->setMode( GL_BLEND, osg::StateAttribute::OVERRIDE | > osg::StateAttribute::ON ); > states->setMode( GL_DEPTH_TEST, osg::StateAttribute::OVERRIDE | > osg::StateAttribute::ON ); > > So far so good, but now the problem: If the camera is inside the > translucent figure I don't see the inside faces. > > Is there something I'm doing wrong or shouldn't now the inside faces be > drawn (but not the outside faces)? > > I know this is more an OpenGL issue but I can't seem to find the answer > anywhere. > > > > > > ___ > 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] Tutorials
Robert, By the way, the fact that it doesn't work like MFC is definitly not a criticisim. MFC had its share of problems. As I said, I prefer the approach taken by OSG. My only point for fellow newbies is to not give up and not expect to be up an running quickly because you know OpenGL. As the author, you clearly see the relationship with OpenGL. For a newbie, this relationship is not immediatly obvious. Here's my proposal for putting together tutorials without breaking the bank: YouTube Screen Casts. I recently learned a few PHP programming tricks from this serie: http://www.youtube.com/watch?v=Z5egpgAVxQI&mode=related&search= On the Mac, there are a few free solutions for doing this. There's no need for a camera, since you are just capturing the screen. Then, you can post it on YouTube, which saves you the bandwidth distribution cost. Just an idea. - Nick - From: "Robert Osfield" <[EMAIL PROTECTED]> Reply-To: osg-users@lists.openscenegraph.org To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials Date: Wed, 22 Aug 2007 09:38:07 +0100 Hi Nick, On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > I too have been programming OpenGL for while (10 years) and I find learning > OSG to be quite humbling: very few of my OpenGL skills are immediatly > transferable. OSG is very much like what the MFC ins to Win32, however, with > MFC, there's always a way to use Win32 calls directly anywhere in the code. > OSG does not allow this, which is more elegant, but makes it harder to > "transition" from direct OpenGL. I am curious about your experience. The OSG deliberately has quite a thin OO layer on top of OpenGL, the granularity of state is follows pretty closely to that of OpenGL, the naming convention of OpenGL has almost entirely been honoured so glTexGen is osg::TexGen etc. OpenGL modes are just a pass through and can be set directly on a StateSet. One of my intentions with this thin mapping was the ability to reuse OpenGL knowledge and documentation. The big difference between using the OSG and OpenGL really comes from the OSG being OO and having a retained model rather than immediate model like OpenGL, but its a scene graph so its rather comes with the territory. I would have thought of all the scene graphs in existence the OSG is probably the most OpenGL centric in its naming/granularity. So its it just the OO or scene graph aspect that is the stumbling point? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Hotmail is the next generation of MSN Hotmail. Its fast, simple, and safer than ever and best of all its still free. Try it today! www.newhotmail.ca?icid=WLHMENCA146 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin find behaviour
Hello Serge, > First thanks for your work ! It's my pleasure. Being one of the active Win32 people on this list and having written some of the docs on getting OSG compiled and installed, I felt I had to chip in to fix this so it works correctly (according to the OS specs). > And everything works well for my apps and > osgviewer (tested on several models). Great news. > I admit that looking for the > application folder first make me much more confident, I don't remember how > many times I had problems on my computer or on others because old plugins > were in the system folder, OSG loading them before the ones I deploy with my > apps. :/ Yes, that should work properly now, I thought it did before but hadn't used that usage pattern myself so hopefully now we honour the "real" load order that Windows should always use. > I think you can post your file to osg-submission. :) I'll wait for a few more items of feedback, if they come, but in any case if there isn't anything negative I'll send it in around noon EST (so in about 3:20 for you non-North-American people :-) ). Merci beaucoup d'avoir testé! J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL_CULL_FACE && GL_BLEND && GL_DEPTH_TEST
Hello fellow osg users I've been trying for days to implement what I thought of as a simple thing: A translucent figure like a dome, a cubus or a triangle where faces behind don't shine through and which inside faces are rendered when the camera is inside the figure. I've managed that by using GL_CULL_FACE osg::StateSet* states = new osg::StateSet(); states->setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); states->setRenderBinDetails( 2, "RenderBin" ); states->setMode( GL_CULL_FACE, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON ); states->setMode( GL_BLEND, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON ); states->setMode( GL_DEPTH_TEST, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON ); So far so good, but now the problem: If the camera is inside the translucent figure I don't see the inside faces. Is there something I'm doing wrong or shouldn't now the inside faces be drawn (but not the outside faces)? I know this is more an OpenGL issue but I can't seem to find the answer anywhere. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Thread safety improvements and CullThreadPerCameraDrawThreadPerContext now working
Hi All, Over the last two days I've been doing lots of working hunting down crash on exit that were occurring with certain threading models and viewer usages, my new quad core machine certainly has helped reveal more problems than my older dual core system. The upshot of this work is that I've tightened up the default thread safety of ref/counting for scene graph elements as well as various helper classes. This work is now checked in. Another part of my work was to get the CullTheadPerCameraDrawThreadPerContext threading model working properly. Again my new quad core system + dual Gfx cards proved invaluable in this quest. All that was required was a few minor tweaks to the threading set up in src/osgViewer/Viewer.cpp. Again these changes are now checked in to SVN. Could users that have seen problems with crash on exit, or with the CullThreadPerCameraDrawThreadPerContext threading model do a svn update and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
Also try being on Robert or Paul's end
{START SOAP BOX RANT}
Over the years( eek getting on for 20 ) were I have been active on GL,
Performer list, Vega, Vega Prime, OGL and OSG list among many providing
including providing FAQ's a vis-sim.com and else were etc
Regularly I get demands for help not request buts demands and which can get
actually quite abusive at time because I'm not willing to spend hours
writing applications, samples and examples or why I won't create this flight
file for someone, it amazes how people want you do do stuff for free so that
they can make money or a living of your time.
I'm sure Robert and other get their fair share of these things as well
Aghhh, never mind the replies when you tell them that yes I can help
on these time comsuing request, heres my rates .. If it was not so
annoying it might even be funny
{END SOAP BOX RANT}
__
Gordon Tomlinson
Email : [EMAIL PROTECTED]
YIM/AIM : gordon3dBrit
MSN IM : [EMAIL PROTECTED]
Website : www.vis-sim.com www.gordontomlinson.com
__
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
-Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Wednesday, August 22, 2007 5:55 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Tutorials
One thing we can be sure of is that they will *never* be enough
documentation for everybody. This isn't an OSG specific issue, it isn't a
closed source vs open source issue, it isn't even an IT specific issue, it
applies to everything in life.
As Winston Churchil said (this is from memory so It might be little
mis-phrased):
"One can please all of the people some of time, or some of the people all of
the time, but you can never please all the people all the time".
--
I occasionally come across emails on osg-users from users that appear to me
to be almost asking for others to write their program for them, to teach
them every little detail of what they need to know. You write code and
publishing it for free and with an open license, you provide free support
and spend you time helping people out, yet this still isn't enough for some,
the mere act of giving a great deal seems to in somehow mean that you owe
others even more.
So... I feel for Paul Martz, he's put a big effort into to getting the Quick
Start Guide, climbed a peak, taken a short rest, but now its a case of "well
actually that peak you climbed was just a foothill, you need to climb this
great mountain beyond, and oh BTW can you do it for free too".
We are a community, so we don't walk alone, one must carry ones own weight
though, otherwise you can drag others back. We can all contribute in
different ways. Directly by helping write the books and tutorials. Or by
*purchasing* the books rather than just downloading the free pdf.
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] Tutorials
Christophe I look forward to reading this once you have written it for use all __ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" -Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Wednesday, August 22, 2007 5:08 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials Hi all, Hoping to help outline the "not-so-easy-to-cope-with-points-with-OSG"... I'm in the very same case : being used to OpenGL and by-the -way having used a lot OpenGL Performer for example when designing a lot of special effects for real time simulators. The main difference between OpenSceneGraph and OpenGL is that (as Nick said) you don't directly invoke OpenGL calls when implementing your own NodeKits in OSG. Even in the basic bricks are logically the same (TexGen, Lights, Materials, and so on), there is an effort to do to understand how OpenSceneGraph in the background attacks the OGL rendering pipe (contexts push/pop, lists corresponding to OGL rendering orders, etc.). I think it's the point that Nicks points out. (Talking about that, it would be a good think to explain how stateattributes inheritance between nodes is performed underneath - for me it poses no real problem cos Performer was quite alike). But more, to resume my point of view, there are three points that would be interesting to document in a "programming guide manner" (maybe to add to the Skew Matrix Quick Start Guide ?) : 1) How does OpenSceneGraph deal with performance issues ? --> explain the multithread configurations (how their divide CULL/DRAW), the synchronization issues, in a sythetic and comprehensible way... 2) How are OpenSceneGraph internals designed for the culling issues ? 2') How are OpenSceneGraph internals designed to attack OGL pipeline (draw calls) ? --> like developped above context push/pop/inheritance ; constitution of the rendering list ; orders of drawing for developpers of SFX with transparency (bins, and so on) ; maybe also a word about the default lighting equation using materials when no shader are set for newbies to SFX development (example things like the use of emissive, manners to set blending operation ie TexEnv vs or plus TexEnvCombine, even if the latter is more here an OpenGL problem)... Those 3 points may be a pain even for non-beginner developpers and aren't really clear, looking only at as-is documentation and samples... Let's be serious, the API is really easy-to-use for users just needing a scene format ans and interactive scene graph to design interactive applications, without any own SFX need. But low-level features are to be perfecly known and understood for those developping their own NodeKits and there it needs effort : you just have to spent time looking the code to make your own idea about the whole thing... That's just an opinion. -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 22, 2007 10:38 AM Subject: Re: [osg-users] Tutorials > Hi Nick, > > On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: >> I too have been programming OpenGL for while (10 years) and I find >> learning >> OSG to be quite humbling: very few of my OpenGL skills are immediatly >> transferable. OSG is very much like what the MFC ins to Win32, however, >> with >> MFC, there's always a way to use Win32 calls directly anywhere in the >> code. >> OSG does not allow this, which is more elegant, but makes it harder to >> "transition" from direct OpenGL. > > I am curious about your experience. The OSG deliberately has quite a > thin OO layer on top of OpenGL, the granularity of state is follows > pretty closely to that of OpenGL, the naming convention of OpenGL has > almost entirely been honoured so glTexGen is osg::TexGen etc. OpenGL > modes are just a pass through and can be set directly on a StateSet. > One of my intentions with this thin mapping was the ability to reuse > OpenGL knowledge and documentation. > > The big difference between using the OSG and OpenGL really comes from > the OSG being OO and having a retained model rather than immediate > model like OpenGL, but its a scene graph so its rather comes with the > territory. I would have thought of all the scene graphs in existence > the OSG is probably the most OpenGL centric in its naming/granularity. > So its it just the OO or scene graph aspect that is the stumbling > point? > > Robert. >
Re: [osg-users] Tutorials
I also just want to say thank you to Paul, Robert and all the others. The QSG is a good point to start and for everything which goes further you have to read, search or ask the community! I was respectivly I am also quite new to OSG, but every day I get a little bit more further ;) > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Robert > Osfield > Sent: Wednesday, August 22, 2007 5:55 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Tutorials > > One thing we can be sure of is that they will *never* be enough > documentation for everybody. This isn't an OSG specific issue, it isn't a > closed source vs open source issue, it isn't even an IT specific issue, it > applies to everything in life. > > As Winston Churchil said (this is from memory so It might be little > mis-phrased): > > "One can please all of the people some of time, or some of the people all of > the time, but you can never please all the people all the time". > > -- > > I occasionally come across emails on osg-users from users that appear to me > to be almost asking for others to write their program for them, to teach > them every little detail of what they need to know. You write code and > publishing it for free and with an open license, you provide free support > and spend you time helping people out, yet this still isn't enough for some, > the mere act of giving a great deal seems to in somehow mean that you owe > others even more. > > So... I feel for Paul Martz, he's put a big effort into to getting the Quick > Start Guide, climbed a peak, taken a short rest, but now its a case of "well > actually that peak you climbed was just a foothill, you need to climb this > great mountain beyond, and oh BTW can you do it for free too". > > We are a community, so we don't walk alone, one must carry ones own weight > though, otherwise you can drag others back. We can all contribute in > different ways. Directly by helping write the books and tutorials. Or by > *purchasing* the books rather than just downloading the free pdf. > > 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 > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgpick error (window-mode)
Hello I'm running the osgpick example in window mode (I added the WindowsSizeHandler and pressed 'f', nothing special), but the pick is not working correctly in this mode - sometimes an intersection is detected when the mouse is OUTSIDE the model, and sometimes not detected when the mouse is ON the model. Any ideas? Anyone had this problem? (the only thing I added to the code was the windows size handler) Roni ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] s_serialize_readNodeFile_mutex in DatabasePager
Hi robert, i did some further tests and the problem is in reading two IVE files in two different threads. Then suddenly the system gets block, i don't know what can cause to probleme, i will look depther into the plugin code /adegli 2007/8/21, Alberto Luaces <[EMAIL PROTECTED]>: > > El Martes 21 Agosto 2007, Adrian Egli escribió: > > no i don't, the application doesn't crash ! > > I think you can attach the debugger to your running process in order to > get > the stack trace. With gdb, it is done so > > gdb program program_id > > with MSVC, IIRC there is an option in the Debug submenu. > > HTH, > > Alberto > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
Very well said Robert And Great Job Paul Martz and everyone who helps and contributes But can some one please press F5 for me, its just too much effort to have to compile things my self ;) __ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" -Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, August 22, 2007 5:55 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials One thing we can be sure of is that they will *never* be enough documentation for everybody. This isn't an OSG specific issue, it isn't a closed source vs open source issue, it isn't even an IT specific issue, it applies to everything in life. As Winston Churchil said (this is from memory so It might be little mis-phrased): "One can please all of the people some of time, or some of the people all of the time, but you can never please all the people all the time". -- I occasionally come across emails on osg-users from users that appear to me to be almost asking for others to write their program for them, to teach them every little detail of what they need to know. You write code and publishing it for free and with an open license, you provide free support and spend you time helping people out, yet this still isn't enough for some, the mere act of giving a great deal seems to in somehow mean that you owe others even more. So... I feel for Paul Martz, he's put a big effort into to getting the Quick Start Guide, climbed a peak, taken a short rest, but now its a case of "well actually that peak you climbed was just a foothill, you need to climb this great mountain beyond, and oh BTW can you do it for free too". We are a community, so we don't walk alone, one must carry ones own weight though, otherwise you can drag others back. We can all contribute in different ways. Directly by helping write the books and tutorials. Or by *purchasing* the books rather than just downloading the free pdf. 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] Tutorials
One thing we can be sure of is that they will *never* be enough documentation for everybody. This isn't an OSG specific issue, it isn't a closed source vs open source issue, it isn't even an IT specific issue, it applies to everything in life. As Winston Churchil said (this is from memory so It might be little mis-phrased): "One can please all of the people some of time, or some of the people all of the time, but you can never please all the people all the time". -- I occasionally come across emails on osg-users from users that appear to me to be almost asking for others to write their program for them, to teach them every little detail of what they need to know. You write code and publishing it for free and with an open license, you provide free support and spend you time helping people out, yet this still isn't enough for some, the mere act of giving a great deal seems to in somehow mean that you owe others even more. So... I feel for Paul Martz, he's put a big effort into to getting the Quick Start Guide, climbed a peak, taken a short rest, but now its a case of "well actually that peak you climbed was just a foothill, you need to climb this great mountain beyond, and oh BTW can you do it for free too". We are a community, so we don't walk alone, one must carry ones own weight though, otherwise you can drag others back. We can all contribute in different ways. Directly by helping write the books and tutorials. Or by *purchasing* the books rather than just downloading the free pdf. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
Hi all, Hoping to help outline the "not-so-easy-to-cope-with-points-with-OSG"... I'm in the very same case : being used to OpenGL and by-the -way having used a lot OpenGL Performer for example when designing a lot of special effects for real time simulators. The main difference between OpenSceneGraph and OpenGL is that (as Nick said) you don't directly invoke OpenGL calls when implementing your own NodeKits in OSG. Even in the basic bricks are logically the same (TexGen, Lights, Materials, and so on), there is an effort to do to understand how OpenSceneGraph in the background attacks the OGL rendering pipe (contexts push/pop, lists corresponding to OGL rendering orders, etc.). I think it's the point that Nicks points out. (Talking about that, it would be a good think to explain how stateattributes inheritance between nodes is performed underneath - for me it poses no real problem cos Performer was quite alike). But more, to resume my point of view, there are three points that would be interesting to document in a "programming guide manner" (maybe to add to the Skew Matrix Quick Start Guide ?) : 1) How does OpenSceneGraph deal with performance issues ? --> explain the multithread configurations (how their divide CULL/DRAW), the synchronization issues, in a sythetic and comprehensible way... 2) How are OpenSceneGraph internals designed for the culling issues ? 2') How are OpenSceneGraph internals designed to attack OGL pipeline (draw calls) ? --> like developped above context push/pop/inheritance ; constitution of the rendering list ; orders of drawing for developpers of SFX with transparency (bins, and so on) ; maybe also a word about the default lighting equation using materials when no shader are set for newbies to SFX development (example things like the use of emissive, manners to set blending operation ie TexEnv vs or plus TexEnvCombine, even if the latter is more here an OpenGL problem)... Those 3 points may be a pain even for non-beginner developpers and aren't really clear, looking only at as-is documentation and samples... Let's be serious, the API is really easy-to-use for users just needing a scene format ans and interactive scene graph to design interactive applications, without any own SFX need. But low-level features are to be perfecly known and understood for those developping their own NodeKits and there it needs effort : you just have to spent time looking the code to make your own idea about the whole thing... That's just an opinion. -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 22, 2007 10:38 AM Subject: Re: [osg-users] Tutorials > Hi Nick, > > On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: >> I too have been programming OpenGL for while (10 years) and I find >> learning >> OSG to be quite humbling: very few of my OpenGL skills are immediatly >> transferable. OSG is very much like what the MFC ins to Win32, however, >> with >> MFC, there's always a way to use Win32 calls directly anywhere in the >> code. >> OSG does not allow this, which is more elegant, but makes it harder to >> "transition" from direct OpenGL. > > I am curious about your experience. The OSG deliberately has quite a > thin OO layer on top of OpenGL, the granularity of state is follows > pretty closely to that of OpenGL, the naming convention of OpenGL has > almost entirely been honoured so glTexGen is osg::TexGen etc. OpenGL > modes are just a pass through and can be set directly on a StateSet. > One of my intentions with this thin mapping was the ability to reuse > OpenGL knowledge and documentation. > > The big difference between using the OSG and OpenGL really comes from > the OSG being OO and having a retained model rather than immediate > model like OpenGL, but its a scene graph so its rather comes with the > territory. I would have thought of all the scene graphs in existence > the OSG is probably the most OpenGL centric in its naming/granularity. > So its it just the OO or scene graph aspect that is the stumbling > point? > > 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] osgViewer + Fox Toolkit example
Hi Mario,
On 8/22/07, Mario Valle <[EMAIL PROTECTED]> wrote:
> Your proposed change solved one of the problems I had at osgviewerFOX exit.
> The change was in FOX_OSG_MDIView.cpp line 60
> FOX_OSG_MDIView::~FOX_OSG_MDIView()
> {
> getApp()->removeChore(this,ID_CHORE); // added
> }
> Could it be added to SVN?
Please post the complete changed file to osg-submissions, this way we
can be sure not to loose it or make mistakes in review/merge.
> Now I have a hang in the same example try to exit with ESC when stats are
> active. But I
> start another thread on this.
A quick solution to this might be just to deactivate the escape sets
done on the viewer. The proper solution is for the Fox code to pick
up on the done flag and close the associated window/viewer.
// to disable the escape sets done just set the key to 0.
viewer.setKeyEventSetsDone(0);
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FileCallbacks and multiple inheritance
Hi Mattias,
The problem you have is down to two osg::Referenced objects being
inherited into a single object via the multiple inheritance. The C++
solution is to make ReadFileCallback and WriteFileCallback using
virtual inheritance of osg::Referenced, this should allow you to use
multiple inheritance safely. I have just checked in this change to
SVN.
As for general design guidelines for single vs multiple inheritance,
in general single inheritance should be preferred, multiple
inheritance is best kept for providing multiple interfaces. The use
of object composition is also typically better than using inheritance
- object composition in your case would be to have the common helper
variables/methods factored out into its own class that the separate
callbacks share.
What is best for your app takes consideration of lots of factors, that
you alone know, so you just need to figure out your options how they
address the problem in hand and use a good dose of good taste to work
out whats best.
Robert.
On 8/22/07, Mattias Linde <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I need to do some special things when some files are loaded and written so
> I'm using
> osgDB::Registry::{Read,Write}FileCallback - so far all good. There are some
> common functionality in the code I don't want to repeat, so the callback stuff
> is put into one class.
>
> This causes problems with osg beacuse when MyCallback inherits from both
> ReadFileCallback
> and WriteFileCallback there 'll be two osg::Referenced. If normal pointers
> are used, one
> can get the code that uses MyCallback to compile, but crashes are bound to
> happen...
> If ref_ptr is used, the compiler find the problem.
>
> >From this I suggest that both osgDB::Registry::{Read,Write}FileCallback use
> >virtual
> inheritance from osg::Referenced.
>
> Or if there is any good reason not to put all the callback stuff in the same
> class I'd
> be happy to hear about it.
>
> / Mattias
>
>
>
>
>
>
> ___
> 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] Tutorials
Hi Nick, On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > I too have been programming OpenGL for while (10 years) and I find learning > OSG to be quite humbling: very few of my OpenGL skills are immediatly > transferable. OSG is very much like what the MFC ins to Win32, however, with > MFC, there's always a way to use Win32 calls directly anywhere in the code. > OSG does not allow this, which is more elegant, but makes it harder to > "transition" from direct OpenGL. I am curious about your experience. The OSG deliberately has quite a thin OO layer on top of OpenGL, the granularity of state is follows pretty closely to that of OpenGL, the naming convention of OpenGL has almost entirely been honoured so glTexGen is osg::TexGen etc. OpenGL modes are just a pass through and can be set directly on a StateSet. One of my intentions with this thin mapping was the ability to reuse OpenGL knowledge and documentation. The big difference between using the OSG and OpenGL really comes from the OSG being OO and having a retained model rather than immediate model like OpenGL, but its a scene graph so its rather comes with the territory. I would have thought of all the scene graphs in existence the OSG is probably the most OpenGL centric in its naming/granularity. So its it just the OO or scene graph aspect that is the stumbling point? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin find behaviour
On 8/21/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
>
> Hello Robert, Roger, Serge,
>
> > Just post the changes when you are happy.
>
> Here's a version that seems to work as intended. I would appreciate it
> if some Win32 people could test this out (Roger and Serge in
> particular, please).
>
>
> Please test this by replacing the file in src/osgDB, recompiling,
> running the INSTALL target, and then doing whatever you want with it
> (you could recompile your app, or use the stock osgviewer). I
> recommend you set OSG_NOTIFY_LEVEL=DEBUG before running an app to test
> this, so that you can see which paths are tried and which path the DLL
> is finally loaded from.
>
> If you get too much text from OSG_NOTIFY_LEVEL=DEBUG and you don't
> have a chance to see what it says, you can run the executable from the
> command line and redirect the output to a file with "> file.txt" and
> then open the file. The plugin loading is really at the beginning of
> the output, and there is constant output afterwards, so it's not long
> before it fills the scrollback buffer.
>
>
> On my side, I tested this using osgviewer cow.osg (which needs the
> osgdb_osg.dll and osgdb_rgb.dll plugins) in three scenarios:
>
> 1. Run osgviewer in the bin directory of my OSG directory, using the full
> path
> to the executable. This found the plugins in bin\osgPlugins-2.1.6,
> which is
> expected (see item 1 below in the search order).
>
> 2. Run osgviewer without specifying the path, which uses the OSG\bin
> directory
> specified in my PATH. Again, the correct plugins were found.
>
> 3. Copy osgviewer.exe to a directory on my desktop called "test", and
> osgdb_osg.dll and osgdb_rgb.dll to "test\osgPlugins-2.1.6", and then
> run
> osgviewer from that directory (with test as the current directory, and
> from
> another directory using a relative path). The plugins in
> "test\osgPlugins-2.1.6" were used (and not those in my OSG source
> tree).
>
> I have also printed the path list, and all the correct paths are in
> the correct order. So I think this should work as intended in all
> foreseeable cases.
>
>
> For reference, I followed the search order that is given in
> http://msdn2.microsoft.com/en-us/library/ms682586.aspx with
> SafeDllSearchMode enabled (just alters the order, does not remove any
> paths or anything). I then added those directories to the list as
> usual, so they will have osgPlugins-version appended to them as is
> policy.
>
> So the order is:
>
> 1. The directory from which the application loaded.
> 2. The system directory. (C:\Windows\System32 by default, gotten using
> the
>GetSystemDirectory function)
> 3. The 16-bit system directory. (C:\Windows\System by default, gotten
> by
>adding "\System" to the path gotten in the next step...)
> 4. The Windows directory. (C:\Windows by default, gotten using the
>GetWindowsDirectory function)
> 5. The current directory. (".")
> 6. The directories that are listed in the PATH environment variable.
> (as
>before)
>
> This is also extensively commented in the modified source file.
>
>
> Finally, I have also fixed the problem where a trailing semicolon in
> the PATH would add an empty string to the path list, which would in
> effect make it search the current directory for plugins. This was
> inconsistent behaviour, kind of an unpredicted side-effect really, and
> the current directory is searched anyways (see 5 above).
>
>
> I will wait for other reports on this before sending it to
> osg-submissions.
>
>
Hi JS,
First thanks for your work ! And everything works well for my apps and
osgviewer (tested on several models). I admit that looking for the
application folder first make me much more confident, I don't remember how
many times I had problems on my computer or on others because old plugins
were in the system folder, OSG loading them before the ones I deploy with my
apps. :/
I think you can post your file to osg-submission. :)
Thanks again !
--
Serge Lages
http://www.magrathea-engine.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer + Fox Toolkit example
Your proposed change solved one of the problems I had at osgviewerFOX exit.
The change was in FOX_OSG_MDIView.cpp line 60
FOX_OSG_MDIView::~FOX_OSG_MDIView()
{
getApp()->removeChore(this,ID_CHORE); // added
}
Could it be added to SVN?
Now I have a hang in the same example try to exit with ESC when stats are
active. But I
start another thread on this.
Thanks!
mario
Markus Hein wrote:
> Hi Robert,
>
>
>> I don't know how you the threading model to something other than
>> SingleThreaded, as there is threading model event handler registered.
> The default osgViewer::Viewer settings should work fine.
>
> I think that problems arised for me mostly because I played with
> osgFoxViewer & multiple Viewer Windows (context's) rendering the same
> scene, instead of the Single Viewer Window in (the original
> osgFoxViewer example) .
>
> It was mostly to compare different strategies of rendering multiple
> views inside a FoxGui-Application. Something has changed since osg-2.0
> or it is because I changed the NVidia Driver version to the latest release.
>
>> I don't know if the FOX viewer was ever thread safe. It runs just
>> fine on my machine, running SingleThreaded, but still hangs on exit.
>
> based on osg-2.0 I saw no output in the console (under Linux) onExit.
> Since I updated to a OSG-SVN Version, yes I also got reported some
> problems onExit (linking FOX-1.7. I'm not working on this machine now).
>
> Even with :
>
> getApp()->removeChore(this,ID_CHORE);
>
> in FOX_OSG_MDIView::~FOX_OSG_MDIView destructor. I think this was
> important to stop execution of the onChore Event when the MDI Viewer
> Window already is closed by the user.
>
>
> thanks for reply, Markus
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
Ing. Mario Valle
Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FileCallbacks and multiple inheritance
Hi,
I need to do some special things when some files are loaded and written so I'm
using
osgDB::Registry::{Read,Write}FileCallback - so far all good. There are some
common functionality in the code I don't want to repeat, so the callback stuff
is put into one class.
This causes problems with osg beacuse when MyCallback inherits from both
ReadFileCallback
and WriteFileCallback there 'll be two osg::Referenced. If normal pointers are
used, one
can get the code that uses MyCallback to compile, but crashes are bound to
happen...
If ref_ptr is used, the compiler find the problem.
>From this I suggest that both osgDB::Registry::{Read,Write}FileCallback use
>virtual
inheritance from osg::Referenced.
Or if there is any good reason not to put all the callback stuff in the same
class I'd
be happy to hear about it.
/ Mattias
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the NodeMask used during intersection computation?
Hi Terry The Intersectvisitor, like all Nodevisitors, has a look at the node masks higher in the scene graph too. Before traversing a node, the node mask is checked with the NodeVisitor::validNodeMask() method. Each NodeVisitor has a traversal mask, so you can define which nodes to traverse and which not. Greez helb Terry Welsh wrote: > Does anyone know a way to get the NodeMask in use by an object when it > is intersected by IntersectVisitor? > hitlist.front().getGeode()->getNodeMask() returns the NodeMask of the > exact geode being intersected (by default 0x), but not the > NodeMask inherited from higher in the scenegraph that is actually used > during computation of the intersection. > - Terry > ___ > 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
