Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi, I checked out 2.8: svn checkout https://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph rev 9676. Ran ccmake and selected I want CDASH output, I did not select release build. did a make Experimental, the results are on the dashboard here: http://www.cdash.org/CDashPublic/buildSummary.php?buildid=8995 I got a lot of: cc1plus: warning: -Wuninitialized is not supported without -O g++ -v gcc version 4.3.3 (Debian 4.3.3-3) on Debian Sid 32-bit. jp Robert Osfield wrote: Hi All, I've made several check-in's to OpenSceneGraph-2.8 since rc1, so these all now need testing. Could you please try out the 2.8 in svn and let me know how you get on. I want to know about success + failures. I've also checked in some experimental VS versioning of libs into the svn/trunk version of the OSG, so it's already diverted a bit from OSG-2.8, so a failure on svn/trunk won't necessarily map to problems with OSG-2.8. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
Hello. Are you building for Windows? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk (2.8) + VPB trunk: Terrain elevation artifacts
Thanks Christophe, Thanks for testing and sending the screenshot! You saved my day:) I'll update to gdal 1.6 straight away and test again... Best regards, John christophe loustaunau wrote: Hi John, I have build the database with your command line and vpb svn rev: 953 osg svn rev: 9658 But I have gdal 1.6 and not 1.5.1 The database looks normal, as you can see on screenshots attached. Maybe a gdal 1.5.1 bug ? I don't know, but it's not osg or vpb. Regards. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Load uniform sampler2D in shader from .osg file
Hi all, I'm trying to load a texture into a shader using a osg::Uniform. This shouldnt be a problem, but when i load a model (cow.osg for example) and i try to use a shader on it, the texture doesnt get loaded on the shader. Here is the code for setting up the Uniform on the drawable's state set: Code: void GlowEffect::setShaderOnGeode(osg::Geode* geode) { for(int i=0; i geode-getNumDrawables(); ++i) { osg::Geometry* geom = static_castosg::Geometry* (geode-getDrawable(i)); if(geom) { osg::ref_ptrosg::StateSet ss = geom-getOrCreateStateSet(); osg::StateSet::TextureAttributeList textList = ss-getTextureAttributeList(); if(textList.size() != 0) { osg::ref_ptrosg::Texture2D tex = dynamic_castosg::Texture2D*( ss-getTextureAttribute( 0, osg::StateAttribute::TEXTURE ) ); if (tex) { //ss-addUniform(new osg::Uniform(baseMap, 0)); ss-setTextureAttribute(0,tex); osg::ref_ptrosg::Uniform textureUniform = new osg::Uniform(); textureUniform-setName(baseMap); textureUniform-setType(osg::Uniform::SAMPLER_2D); textureUniform-set(0); ss-addUniform(textureUniform.get()); } } ss-setAttributeAndModes(colorMultProgram, osg::StateAttribute::ON); } } } Here is the osg::Program: Code: osg::ref_ptrosg::Program colorMultProgram = new osg::Program; colorMultProgram-setName(MultColor); osg::ref_ptrosg::Shader verShader = new osg::Shader( osg::Shader::VERTEX ); osg::ref_ptrosg::Shader fragShader = new osg::Shader( osg::Shader::FRAGMENT ); verShader-loadShaderSourceFromFile(./Data/Shaders/vp_glow_alpha.glsl); fragShader-loadShaderSourceFromFile(./Data/Shaders/fp_glow_alpha.glsl); colorMultProgram-addShader(verShader); colorMultProgram-addShader(fragShader); And the shaders (very simple): Code: // Vertex Shader varying vec2 Texcoord; void main( void ) { gl_FrontColor = gl_Color; gl_Position = ftransform(); Texcoord= gl_MultiTexCoord0.xy; } // Fragment shader uniform sampler2D baseMap; varying vec2 Texcoord; void main( void ) { gl_FragColor = vec4(texture2D( baseMap,gl_TexCoord[0].st).xyz, 0.0); } I just get the model in black (but with its alpha value to '0' so the shader works. Any suggestion?? Thanks, J. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6051#6051 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: particle/threads
Melchior FRANZ wrote: * Melchior FRANZ -- Tuesday 03 February 2009: Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. Linux 2.6.28.3, P4/32bit, gcc 4.3.1, osg r9631, FlightGear. (The warnings in #20 and #21 are strange. Haven't seen that before.) Can you create a self-contained code example that shows the problem? As small as possible would be preferred. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ParticleSystem and alignment = BILLBOARD
I will try with the 2.8.0 (and check at its code for my information). Thanks ! Christophe --- Message d'origine --- De : Robert Osfield robert.osfi...@gmail.com À : OpenSceneGraph Users osg-users@lists.openscenegraph.org Sujet : Re: [osg-users] ParticleSystem and alignment = BILLBOARD Date : jeu 05 fév 2009 19:13:48 CET HI Christophe, Could you please try the OSG-2.8.0-rc1 as there was a fix for this issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vec3dArray - when is it useful
HI Reed, Vec3dArray's role is more for enabling loaders like the shapefile loader to load there data in doubles, once it's loaded you can then process it to get it into a local coordinate system with an Vec3fArray that is appropriate for rendering and other operations. FYI, OpenGL does accept doubles, but it converts them all to floats before passing to the graphics card so performance really is appalling compared to float arrays. Performance is so bad is that it's not worth considering trying to use Vec3dArray based geometries for rendering. Robert. On Thu, Feb 5, 2009 at 7:20 PM, Reed McKenna rmcke...@intelisum.com wrote: The Vec3dArray was introduced in OSG 2.6 (or 2.4, I forget). The reason, as I recall it, was to support creation of earth-size datasets. OpenGL does not accept doubles, IntersectVisitors don't seem to support doubles, etc. How are developers using Vec3dArrays effectively? I did not find any use of double arrays in the examples. ___ 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] segfault: particle/threads (was: Re: svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-))
Hi Melchior, The code in osgParticle::ParticleSystemUpdater has changed very little over the past two years, so I think it's unlikely to be a specific problem with osgParticle in OSG2.8/svn/trunk, or if it is a problem in osgParticle then it's been hidden away for a long time. Unfortunately this means we don't have some clear code changes that we could review with the assumption that these changes are problematic. I have just done a search on the web for discussion of the Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab. error and it looks like it's a gdb issue. Whether this error is occuring because there is some data corruption going on, or a bug in gdb I can't answer. If there is some kind of data corruption then it could be why the ScopedWriteLock(ReadWriteMutex mutex) fails. Given there is so little go in terms of homing in on what actual cause of the failure might be I think one has to start trying other systems to see if they can reproduce the error. Also try other threading models so see if that gives any different characteristics. Also try the OSG examples with particle systems such as osgparticleeffects, osgparticle and osgcatch. Robert. On Thu, Feb 5, 2009 at 7:21 PM, Melchior FRANZ melchior.fr...@gmail.com wrote: * Melchior FRANZ -- Tuesday 03 February 2009: Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. Linux 2.6.28.3, P4/32bit, gcc 4.3.1, osg r9631, FlightGear. (The warnings in #20 and #21 are strange. Haven't seen that before.) m. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb678b6f0 (LWP 9931)] osgParticle::ParticleSystemUpdater::traverse (this=0x887a668, n...@0x89fa9c0) at /home/m/fgfs/osg/include/OpenThreads/ReadWriteMutex:103 103 ScopedWriteLock(ReadWriteMutex mutex):_mutex(mutex) { _mutex.writeLock(); } (gdb) bt #0 osgParticle::ParticleSystemUpdater::traverse (this=0x887a668, n...@0x89fa9c0) at /home/m/fgfs/osg/include/OpenThreads/ReadWriteMutex:103 #1 0xb7dc0520 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x887a668) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #2 0xb7f2c791 in osgParticle::ParticleSystemUpdater::accept (this=0x887a668, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osgParticle/ParticleSystemUpdater:44 #3 0xb7bb64fa in osg::Group::traverse (this=0xd491b40, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #4 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0xd491b40) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #5 0xb7bb7f2f in osg::Group::accept (this=0xd491b40, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/Group:38 #6 0xb7bb64fa in osg::Group::traverse (this=0xcfc4340, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #7 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0xcfc4340) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #8 0xb7bb7f2f in osg::Group::accept (this=0xcfc4340, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/Group:38 #9 0xb7bb64fa in osg::Group::traverse (this=0x105066d0, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #10 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x105066d0) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #11 0xb7bb7f2f in osg::Group::accept (this=0x105066d0, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/Group:38 #12 0xb7bb64fa in osg::Group::traverse (this=0x10506840, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #13 0xb7db9f7b in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x10506840) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #14 0xb7bdd299 in osg::LightSource::accept (this=0x10506840, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/LightSource:38 #15 0xb7bb64fa in osg::Group::traverse (this=0x8885558, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #16 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x8885558) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #17 0xb7bb7f2f in osg::Group::accept (this=0x8885558, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/Group:38 #18 0xb7c4804f in osg::Switch::traverse (this=0x105074d8, n...@0x89fa9c0) at /home/m/fgfs/osg/src/osg/Switch.cpp:40 #19 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x105074d8) at /home/m/fgfs/osg/include/osg/NodeVisitor:191 #20 0xb7db87aa in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x105074d8) at /home/m/fgfs/osg/src/osgUtil/CullVisitor.cpp:1097 warning: (Internal error: pc 0xb7c495ee in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab.) #21 0xb7c495ee in osg::Switch::accept (this=warning: (Internal error: pc 0xb7c495a0 in read in psymtab, but not
Re: [osg-users] osgPango (Stop Worrying Love The Bomb)
Jeremy, Thanks for that. I must admit I am a little bit confused between the various things that have been mentioned for text rendering, and would appreciate a one liner explanation of what the difference between osgPango and osgCairo is. Plus I've seen other libraries mentioned in this context (Poppler?). I guess my question is, in the end, is osgPango meant as a replacement for osgText? Thanks, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Joseba, Shouldn't this: gl_FragColor = vec4(texture2D( baseMap,*gl_TexCoord[0]*.st).xyz, 0.0); be this? gl_FragColor = vec4(texture2D( baseMap,*TexCoord*.st).xyz, 0.0); David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Thu, Feb 5, 2009 at 9:35 PM, Csaba Halász csaba.hal...@gmail.com wrote: On Thu, Feb 5, 2009 at 10:16 PM, Csaba Halász csaba.hal...@gmail.com wrote: Rev 9397 is the first non-working revision. Looks like a lot of int-long changes, which seems to agree with your 64 bit theory. Except it is broken on 32 bit too. LOL, it is one for Sukender's list :) for(int i=0; i4; ++i) { *dest_ptr = *src_ptr; } Can you spot the error? :) No pointer increments!! God what I dumbo I can be sometimes... Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Date of 2.8 tag
Hi Paul, Well spotted, copy and paste anti-pattern strikes again... Now fixed... hopefully... Robert. On Thu, Feb 5, 2009 at 10:21 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- At the main wiki page with the headline news, I noticed a cut and paste error; the 2.8 tag new item is dates October 2008. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem with setNumMultiSamples()
hi all, when I use setNumMultiSamples(16),It is ok on my computer.But when the program is executed on some other computers.If the computer doesn't support mulsampling with 16,The display window will expanded to full screen(This is not I want). If I want the best antialiasing effect on every machine,how should I set the multisamples num? Thanks for any hint best regards forest ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: particle/threads
Hi, * Robert Osfield -- Friday 06 February 2009: The code in osgParticle::ParticleSystemUpdater has changed very little over the past two years, so I think it's unlikely to be a specific problem with osgParticle in OSG2.8/svn/trunk, I didn't claim that it's a particle bug -- just that it regularly happens in the particle code. The bt implies that it's a threading bug. Also try the OSG examples with particle systems such as osgparticleeffects, osgparticle and osgcatch. I'm a lazy bum and just let valgrind's threading debugger helgrind run over osgparticleeffects. Result attached (from osg r9676). Summary: $ valgrind --tool=helgrind ./osgparticleeffects ==31276== Helgrind, a thread error detector. [...] ==31276== Thread #1: lock order 0x58F499C before 0x58F494C violated [...] ==31276== Thread #1: lock order 0x58F6A9C before 0x58F6AEC violated [...] ==31276== ERROR SUMMARY: 512 errors from 2 contexts (suppressed: 0 from 0) m. ==31276== Helgrind, a thread error detector. ==31276== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et al. ==31276== Using LibVEX rev 1883, a library for dynamic binary translation. ==31276== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==31276== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework. ==31276== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==31276== For more details, rerun with: -v ==31276== ==31276== Thread #1 is the program's root thread ==31276== ==31276== Thread #1: lock order 0x58F499C before 0x58F494C violated ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4D4C: OpenThreads::ReadWriteMutex::readUnlock() (ScopedLock:31) ==31276==by 0x45C2BBE: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:90) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43DF36E: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:469) ==31276==by 0x43E6FF3: osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1251) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43E811D: osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) (RenderStage.cpp:845) ==31276==by 0x43EB505: osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1108) ==31276== Required order was established by acquisition of lock at 0x58F499C ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4DE4: OpenThreads::ReadWriteMutex::readLock() (ScopedLock:31) ==31276==by 0x45C2AFA: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:89) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43DF36E: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:469) ==31276==by 0x43E6FF3: osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1251) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43E811D: osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) (RenderStage.cpp:845) ==31276==by 0x43EB505: osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1108) ==31276== followed by a later acquisition of lock at 0x58F494C ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4DFD: OpenThreads::ReadWriteMutex::readLock() (ReadWriteMutex:37) ==31276==by 0x45C2AFA: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:89) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*)
Re: [osg-users] Sketchup rendering
Thanks Guillaume, The page you've spotted give nearly the same result as osgFX::Cartoon, what I would like is to have all the edged (when adjacent 2 faces are not coplanar) visible. I'll try to make something mixing this effect with something more custom to try to achieve it. On Thu, Feb 5, 2009 at 8:13 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same look and feel than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Thu, Feb 5, 2009 at 7:38 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Oh come on. Aren't you pushing this a bit too far? We're not playing anyone's game, just using a tool that allows us to compile code on a given platform. This platform choice (which is only one option, we support Linux too, but cannot go away from Windows completely) is dictated by our clients and past history. That's what's locking us into using that tool, not the tool itself. I'm not suggesting dropping windows support, I'm just saying that you keep all the platform specific hacks as far away from general code as possible. You keep is as localised as possible, this is the key to cross platform development - it's why the OSG is so portable. Adding obscure platform specific hacks to all header files is totally wrong for this project, and make it less maintainable. It would be a backwards step that I won't merge. Even if I were working on personal projects only, I would still advocate for OSG to support VS in the best way possible. It's too big a market and a user base to push to the wayside and have half-baked support for. Not supporting the MS pet way of doing things isn't providing poor windows support. The OSG supports VS just fine. Using CMake you can disable the Export pragma's, you have complete control. If you want to then isolate the warnings from OSG headers yourself then again you have complete control to do so. Rather than stuff macro's or extra includes why not in your own application just have your own macro such as: #define INCLUDE(header) / #pragma (warning(push)) / #pragma (warning(disable : a b c d)) / #includeheader / #pragma (warning(pop)) Then in your own code you just have: INCLUDE(osg/Node) Like the ScopedLock trick we use for Mutex management - it's an design pattern that ensures robust resource management and far more maintainable than need to enclose everything carefully with lines that are only relevant to a single platform. But then even OSG's headers will generate warnings. A library should not generate warnings, but should not obscure the warnings in your own code. Period. Do you at least agree with that? I really stove for the ideal of the OSG header not generating any warnings so not requiring the pragma's, I wrote just this as my goal, but we've falling short, and through lack of effort. The reality is that modern compilers at high warning levels produce lots of false positives on perfectly correct code. As Matthew said, this could be replaced by macros in a single header, or something else. As I said, I was trying to suggest something, anything, in the hope we could go forward in some way. Just arguing back and forth doesn't help anything, so I think I'll stop replying about this subject if we don't go forward at least a bit. Mathew's suggest is marginally better, but still a horrible hack. What happens if I forget to add #endif to the end of a header to close the include guards? That's not standard C++ either, just common practice, and no one really fights that. The #ifdef #endif around headers is a back that we all have to employ across all platforms. If someone missing it out we have a good chance of catching it on the any platform. It's a pain but it is at least maintainable without too much effort or likely-hood of introducing mistakes. Contracts this we push/pop macro/include errors - the code would still compile even under VisualStudio, no one would know about a problem until someone starting looking for errors that were being accidentally suppressed. If you code typically doesn't generate warnings, and continues not to generate warnings you'll happily assume everything is dandy... but it's not, it's broken, but... where o lots of headers to go through. Well, since you don't even see the VS warnings, and don't see errors related to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone (probably me, lucky as I am) will compile on Windows, see the error, track it to the missing end marker (whatever that may be) and submit the fix, the same as a missing OSG_EXPORT. For the number of times a new header is added to OSG, I think it's really minor. The OSG_EXPORT issues is a pain, but at least if they are missing someone eventually picks up the error and the error report you get pinpoints the problem precisely. The push/pop is a very different beast - its an untraceable and largely un-noticable error. The OSG_EXPORT also provides a function to the binaries, doesn't add any extra lines of code to the headers and is well understood by most developers. So it's more functional, and less intrusive and more maintainable than the proposed push/pop macro/headers. This certainly won't make help code portability and maintainability. Let's just suppress all warnings in osg/Export then, and see if users like that. (I'm only partly joking) Anyways, the basic premise I'm maintaining is
[osg-users] painting into Qt widgets on Mac
Hello, Has anyone succeeded in using OSG to paint into Qt widgets on Mac OS X? On Windows it works without any problems if I do this: Producer::Camera *cam-getRenderSurface()-setWindow(QWidget::winId()). On Mac, however, this only works if the QWidget is a toplevel widget. If a QWidget is inside another widget, though, the window never gets repainted. I've tried using QWidget::handle() instead, but that only returns the same thing as winId for that widget's toplevel ancestor. I'm using Leopard 10.5.6. But both OSG and Qt are old versions: OSG 1.2 and Qt 3.3.8. Sorry, but I can't upgrade now. Thanks Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi J.P, Thanks for the testing. I'l just removed the -Wuninitialized that I made yesterday - it didn't produce any warnings or errors for me, not even any ones that helped spot any uninitialized variables so removing it's any great loss. Robert. On Fri, Feb 6, 2009 at 8:00 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi, I checked out 2.8: svn checkout https://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph rev 9676. Ran ccmake and selected I want CDASH output, I did not select release build. did a make Experimental, the results are on the dashboard here: http://www.cdash.org/CDashPublic/buildSummary.php?buildid=8995 I got a lot of: cc1plus: warning: -Wuninitialized is not supported without -O g++ -v gcc version 4.3.3 (Debian 4.3.3-3) on Debian Sid 32-bit. jp Robert Osfield wrote: Hi All, I've made several check-in's to OpenSceneGraph-2.8 since rc1, so these all now need testing. Could you please try out the 2.8 in svn and let me know how you get on. I want to know about success + failures. I've also checked in some experimental VS versioning of libs into the svn/trunk version of the OSG, so it's already diverted a bit from OSG-2.8, so a failure on svn/trunk won't necessarily map to problems with OSG-2.8. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with setNumMultiSamples()
Hi, May be it's not the proper way but I'll tell what I do : I set GraphicsContext::Traits::samples to 4 before creating the context and if GraphicsContext::createGraphicsContext() returns NULL, I retry with the default value. Regards, Can 2009/2/6 forest37 fores...@163.com hi all, when I use setNumMultiSamples(16),It is ok on my computer.But when the program is executed on some other computers.If the computer doesn't support mulsampling with 16,The display window will expanded to full screen(This is not I want). If I want the best antialiasing effect on every machine,how should I set the multisamples num? Thanks for any hint best regards forest -- 网易邮箱,中国第一大电子邮件服务商 http://www.yeah.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull time doubled?
Hi Alex, There shouldn't be a performance drop if everything is compiled correctly. What platform are you working on? Is full compile optimization enabled? Is the atomic reference counting being compiled in correctly? Could the CPU thread management causing problems? Try out different threading models to see what happens. Robert. On Fri, Feb 6, 2009 at 12:28 AM, Pecoraro, Alexander N alexander.n.pecor...@lmco.com wrote: I've recently upgraded an old 3d viewer that was using OSG API version 1.2 to version 2.6.1. Oddly enough some databases that I was using with the old viewer actually perform worse with the new version of the API. For some reason the cull time on these databases is 1.5 to 2 times higher on version 2.6.1 than it was on version 1.2. The scene graph node structure is exactly the same, but the culling time has increased. Why would that happen? Has anyone else seen this? I can provide a small test case if anyone is interested in seeing what I mean. Thanks. Alex ___ 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] -2.8 branch, testing-- vs71
Robert Osfield ha scritto: Hi Luigi, Thanks for the testing. Curious how each different version of VS is generating a different sets of warnings. The new warnings are down to a combination of pruning #prgrama warning disables from include/osg/Export and upping the default warning level. At this late in the game the we can either suppress the warning or lower the warning level. In this case I've gone from suppressing the specific warnings that were causing your problems, changes now checked into the OSG-2.8 branch. I ' ve updated and started a rebuild. Is currently running, Most warnings seems gone, one still remain. Ill' send the output when finished or do I try to submit experimental CDash build? The compile error with the tiff plugin only occurred for the debug build, the release build ran fine so it does suggest a mis-match in the build of the tiff library. Are you able to recompile this from source? Sorry... The debug was run with unpatched source, the release with my old patch. I had it submitted long ago but never checked in. I currently compile tiff library and all the other basic dep (tiff, jpeg , png, zlib, freetype, curl) with a cmake script. I tried co compile them statically as so I do not need other .dll around. I do not know if is my way of build or if is the static build, but I get link error in tiff plugin if I do not link also with jpeg and zip lib. I understand that you do not want to add unnecessary extra linking. Is feasable to add a specific VS7.1 case, Another way could be to add special case to the Find3rdPartyDependencies. I' m setting ACTUAL_3DPARTY_DIR to specify my dependency install path Other MSVC builds are using this way to find dep or the linux Findxxx stuff? It is hard to tell from the dashboards. Thanks Luigi Robert. On Fri, Feb 6, 2009 at 9:42 AM, Luigi Calori l.cal...@cineca.it wrote: I'm currently building 2.8 trunk under Windows XP Visual Studio 7.1 I'm getting quite a lot of warning, I know this has been discussed before, just want to make sure it is an expected result and not something due to my build setup: I attach the debug and release output zipped Looking at the dasboard entries of other VC builds on VC 8 and VC Express it seems they have much few warnings: it is a compiler issue or there is a better way to build? expecially the c:\programmi\microsoft visual studio .net 2003\vc7\include\xtree(1121) : warning C4702: unreachable code is really noisy and seem VC related If there is interest in supporting VC 71, I can try to arrange for a nigthly test platform. I had also an error in building tiff plugin, probably related to my libtiff lib that is built as static. Thanks in advance Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Index: src/osgPlugins/tiff/CMakeLists.txt === --- src/osgPlugins/tiff/CMakeLists.txt (revision 9682) +++ src/osgPlugins/tiff/CMakeLists.txt (working copy) @@ -2,7 +2,7 @@ SET(TARGET_SRC ReaderWriterTIFF.cpp ) -SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) - +#SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) +SET(TARGET_LIBRARIES_VARS TIFF_LIBRARY ZLIB_LIBRARY JPEG_LIBRARY) end var setup ### SETUP_PLUGIN(tiff) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVidia Drivers Release 181.20
Hi Jeremy, Ryan. For info, I installed 181.22 on two Windows XP PCs with PNY 9800GTX's. One PC blue screened every night, and the other PC produced random noise on screen that looked like snow when panning around a commercial 3d application we use. Reverting to 181.20 solved both those problems. Gary. I don't know if this is pertinent information or not, but all of the games I play regularly (Bioshock, Fallout 3, Steam games, WOW) all were totally hosed on 181.20 with my GTX 280 card; graphical anomalies, weird crashes, you name it. I upgraded to 181.22 and the problems went away... On Thu, 2009-02-05 at 12:46 -0600, Kawicki, Ryan H wrote: I was curious to see if anyone else was seeing the same problems that I am seeing with the latest GeForce and Quadro drivers. With the Quadro drivers ( on a Quadro 3450 ), I am not seeing any crashes, but I am seeing patches of the terrain either displaying a black texture or not rendering sections to the frame buffer. I even saw what looks like a point or two rendering at infinity. With the GeForce drivers ( on a GeForce 7600 GT ), I am seeing the terrain render fine, but randomly the graphics driver will popup a dialog indicating that the driver has performed an illegal operation and has requested that the application be terminated. There have been many reports related to driver instability for the GeForce cards related to this driver, so I expect that Nvidia is in the process of correcting this. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Hi Robert, Paul Melis wrote: Robert Osfield wrote: I've tweaked the FindXUL.cmake to make the pkgconfig usage optional - required as not all platforms have pkgconfig available. The block now looks like below segment. The modified FindXUL.cmake is attached, could you try this out? Yep, seems to work fine. A question: I think I saw you mention somewhere that XUL 1.9 is not supported, that 1.8 is the version to use. Is this correct? I'm having some trouble getting 2.8 to compile on an FC10 system (after having to hack the CMake XUL module, as it uses different pkg-config names for the XUL packages). Specifically, src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h, which on the FC10 system, is located in a subdirectory widget/ of the XUL include directory and therefore can't be found using the current include directories set from the CMake module. Looking further into this it seems that that header (nsIBaseWindow.h) is nowhere to be found in any of the 1.8 official distributions from Mozilla! (e.g. http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/) So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] -2.8 branch, testing-- vs71
Hi Luigi, Home come you need to compile in the jpeg and zlip libraries into libtiff? Does you build of libtiff use these but not link them in itself? The fact that others are able to compile and link the tiff plugin under Windows suggest there is something different about your 3rd party libs. So rather patch the OSG to build your particular combination I'd suggest working about why other builds work fine, then map this across to your build of the dependencies. Robert. On Fri, Feb 6, 2009 at 11:08 AM, Luigi Calori l.cal...@cineca.it wrote: Robert Osfield ha scritto: Hi Luigi, Thanks for the testing. Curious how each different version of VS is generating a different sets of warnings. The new warnings are down to a combination of pruning #prgrama warning disables from include/osg/Export and upping the default warning level. At this late in the game the we can either suppress the warning or lower the warning level. In this case I've gone from suppressing the specific warnings that were causing your problems, changes now checked into the OSG-2.8 branch. I ' ve updated and started a rebuild. Is currently running, Most warnings seems gone, one still remain. Ill' send the output when finished or do I try to submit experimental CDash build? The compile error with the tiff plugin only occurred for the debug build, the release build ran fine so it does suggest a mis-match in the build of the tiff library. Are you able to recompile this from source? Sorry... The debug was run with unpatched source, the release with my old patch. I had it submitted long ago but never checked in. I currently compile tiff library and all the other basic dep (tiff, jpeg , png, zlib, freetype, curl) with a cmake script. I tried co compile them statically as so I do not need other .dll around. I do not know if is my way of build or if is the static build, but I get link error in tiff plugin if I do not link also with jpeg and zip lib. I understand that you do not want to add unnecessary extra linking. Is feasable to add a specific VS7.1 case, Another way could be to add special case to the Find3rdPartyDependencies. I' m setting ACTUAL_3DPARTY_DIR to specify my dependency install path Other MSVC builds are using this way to find dep or the linux Findxxx stuff? It is hard to tell from the dashboards. Thanks Luigi Robert. On Fri, Feb 6, 2009 at 9:42 AM, Luigi Calori l.cal...@cineca.it wrote: I'm currently building 2.8 trunk under Windows XP Visual Studio 7.1 I'm getting quite a lot of warning, I know this has been discussed before, just want to make sure it is an expected result and not something due to my build setup: I attach the debug and release output zipped Looking at the dasboard entries of other VC builds on VC 8 and VC Express it seems they have much few warnings: it is a compiler issue or there is a better way to build? expecially the c:\programmi\microsoft visual studio .net 2003\vc7\include\xtree(1121) : warning C4702: unreachable code is really noisy and seem VC related If there is interest in supporting VC 71, I can try to arrange for a nigthly test platform. I had also an error in building tiff plugin, probably related to my libtiff lib that is built as static. Thanks in advance Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Index: src/osgPlugins/tiff/CMakeLists.txt === --- src/osgPlugins/tiff/CMakeLists.txt (revision 9682) +++ src/osgPlugins/tiff/CMakeLists.txt (working copy) @@ -2,7 +2,7 @@ SET(TARGET_SRC ReaderWriterTIFF.cpp ) -SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) - +#SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) +SET(TARGET_LIBRARIES_VARS TIFF_LIBRARY ZLIB_LIBRARY JPEG_LIBRARY) end var setup ### SETUP_PLUGIN(tiff) ___ 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] NVidia Drivers Release 181.20
Hi osg-users, I installed 181.22 nvidia drivers a weeks ago and everything is working fine on my 9800GX2 with Vista. I have at least 3 application running with last osg svn and old osg 1.2. But I set 3D card parameters as default. Maybe setting some advanced parameters produce weird behaviour... 2009/2/6 Quinn, Gary g.qu...@tees.ac.uk Hi Jeremy, Ryan. For info, I installed 181.22 on two Windows XP PCs with PNY 9800GTX's. One PC blue screened every night, and the other PC produced random noise on screen that looked like snow when panning around a commercial 3d application we use. Reverting to 181.20 solved both those problems. Gary. I don't know if this is pertinent information or not, but all of the games I play regularly (Bioshock, Fallout 3, Steam games, WOW) all were totally hosed on 181.20 with my GTX 280 card; graphical anomalies, weird crashes, you name it. I upgraded to 181.22 and the problems went away... On Thu, 2009-02-05 at 12:46 -0600, Kawicki, Ryan H wrote: I was curious to see if anyone else was seeing the same problems that I am seeing with the latest GeForce and Quadro drivers. With the Quadro drivers ( on a Quadro 3450 ), I am not seeing any crashes, but I am seeing patches of the terrain either displaying a black texture or not rendering sections to the frame buffer. I even saw what looks like a point or two rendering at infinity. With the GeForce drivers ( on a GeForce 7600 GT ), I am seeing the terrain render fine, but randomly the graphics driver will popup a dialog indicating that the driver has performed an illegal operation and has requested that the application be terminated. There have been many reports related to driver instability for the GeForce cards related to this driver, so I expect that Nvidia is in the process of correcting this. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Hi Joseba, in your code you do this: Code: osg::ref_ptrosg::Texture2D tex = dynamic_castosg::Texture2D*( ss-getTextureAttribute( 0, osg::StateAttribute::TEXTURE ) ); hence you assume that your texture is bound to the stateset of the geode's drawable. However this is not true in all cases, so this could be problematic in some cases. If you can always assume that the texture is a 2D texture, then I would just add a uniform to the stateset of the corresponding geode or drawable liek this: Code: osg::Uniform* texUnitofrm = new osg::Uniform(osg::Uniform::SAMPLER_2D, baseMap); texUniform-set(0); ss-addUniform(texUniform); So you do not have to make all the checks you made before. Ah, and check that your OSG_FILE_PATH is set correctly. It could be that when loading the cow.osg the texture could not just be found ;) cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6074#6074 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Here is an small complete example (didnt check the headers and so): Code: #include osg/GLExtensions #include osg/Node #include osg/Geometry #include osg/Notify #include osg/MatrixTransform #include osg/Texture2D #include osgGA/TrackballManipulator #include osgGA/FlightManipulator #include osgGA/DriveManipulator #include osgUtil/SmoothingVisitor #include osgDB/Registry #include osgDB/ReadFile #include osgDB/WriteFile #include osgViewer/Viewer #include osgViewer/ViewerEventHandlers #include iostream //#include glowEffect.h //#include findNodeVisitor.h #include osg/NodeVisitor #include osg/Node #include osgSim/DOFTransform #include iostream #include vector class findNodeVisitor : public osg::NodeVisitor { public: findNodeVisitor(); findNodeVisitor(const std::string searchName) ; virtual void apply(osg::Node searchNode); void setNameToFind(const std::string searchName); osg::Node* getFirst(); typedef std::vectorosg::Node* nodeListType; nodeListType getNodeList() { return foundNodeList; } private: std::string searchForName; nodeListType foundNodeList; }; // Default constructor - initialize searchForName to and // set the traversal mode to TRAVERSE_ALL_CHILDREN findNodeVisitor::findNodeVisitor() : osg::NodeVisitor(TRAVERSE_ALL_CHILDREN), searchForName() { } // Constructor that accepts string argument // Initializes searchForName to user string // set the traversal mode to TRAVERSE_ALL_CHILDREN findNodeVisitor::findNodeVisitor(const std::string searchName) : osg::NodeVisitor(TRAVERSE_ALL_CHILDREN), searchForName(searchName) { } //The 'apply' method for 'node' type instances. //Compare the 'searchForName' data member against the node's name. //If the strings match, add this node to our list void findNodeVisitor::apply(osg::Node searchNode) { if (searchNode.getName() == searchForName) { foundNodeList.push_back(searchNode); } traverse(searchNode); } // Set the searchForName to user-defined string void findNodeVisitor::setNameToFind(const std::string searchName) { searchForName = searchName; foundNodeList.clear(); } osg::Node* findNodeVisitor::getFirst() { return *(foundNodeList.begin()); } osg::Node *findNode(osg::Node *from, std::string name) { findNodeVisitor v(name); from-accept(v); if(v.getNodeList().size()) return v.getNodeList().front(); return NULL; } int main( int argc, char **argv ) { // use an ArgumentParser object to manage the program arguments. osg::ArgumentParser arguments(argc,argv); osg::setNotifyLevel(osg::INFO); // construct the viewer. osgViewer::Viewer viewer(arguments); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 50; traits-y = 50; traits-width = 640; traits-height = 480; traits-windowDecoration = false; traits-doubleBuffer = false; traits-windowDecoration = true; traits-doubleBuffer = true; traits-pbuffer = false; traits-sharedContext = 0; osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); if (gc.valid()) { osg::notify(osg::INFO) GraphicsContext has been created successfully.std::endl; } else { osg::notify(osg::NOTICE) GraphicsContext has not been created successfully.std::endl; } osg::ref_ptrosg::Camera camera = viewer.getCamera(); camera-setGraphicsContext(gc.get()); camera-setViewport(new osg::Viewport(0,0, traits-width, traits-height)); // add stats viewer.addEventHandler( new osgViewer::StatsHandler() ); // add the record camera path handler viewer.addEventHandler(new osgViewer::RecordCameraPathHandler); // add the threading handler viewer.addEventHandler( new osgViewer::ThreadingHandler() ); // if user request help write it out to cout. if (arguments.read(-h) || arguments.read(--help)) { arguments.getApplicationUsage()-write(std::cout); return 1; } unsigned int tex_width = 1024; unsigned int tex_height = 512; unsigned int samples = 0; unsigned int colorSamples = 0; // load the nodes from the commandline arguments. osg::Node* loadedModel = osgDB::readNodeFiles(arguments); // if not loaded assume no arguments passed in, try use default mode instead. if (!loadedModel) loadedModel = osgDB::readNodeFile(cessna.osg);//cow.osg); if (!loadedModel) { return 1; } osg::ref_ptrosg::Node loadedModel2 = osgDB::readNodeFile(cow.osg); osg::ref_ptrosg::Program colorMultProgram = new osg::Program;
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Robert. Thanks for your reply. I also suspect the drivers are causing some of the problems. Unfortunately, the exe's don't seem to want to run on other machines right now, so testing is going to be difficult. I'll try to compile on a different PC for testing next time. I'm using PNY 9800 GTX's on NVidia's 181.20 driver. I had problems with 181.22 so rolled back. Gary. -- Message: 12 Date: Fri, 6 Feb 2009 10:57:20 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902060257o513c3e1n647d6b84ac982...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Gary, Thanks for the testing and report. I'm just about to download your spelling errors/bar file changes and will do a review of these. W.r.t. some of the example not producing the correct results, this sounds like OpenGL drivers might be playing up. What hardware and drivers are you using? Do you have anything other systems on which to check the results? Robert. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Hi Cesaba, I've now fixed the problem changeType4 function and hey presto I can load your .lwo without problems. This fix is now checked into svn trunk. Ironically the new code base with the changes from using long to unit actually loads the model, while the 2.7.7 code base didn't work on my 64bit machine. Could you please try out the svn/trunk or OSG-2.8 branch to double check that the lwo plugin is now behaving itself. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] -2.8 branch, testing-- vs71
Hi Luigi, Thanks for the testing. Curious how each different version of VS is generating a different sets of warnings. The new warnings are down to a combination of pruning #prgrama warning disables from include/osg/Export and upping the default warning level. At this late in the game the we can either suppress the warning or lower the warning level. In this case I've gone from suppressing the specific warnings that were causing your problems, changes now checked into the OSG-2.8 branch. The compile error with the tiff plugin only occurred for the debug build, the release build ran fine so it does suggest a mis-match in the build of the tiff library. Are you able to recompile this from source? Robert. On Fri, Feb 6, 2009 at 9:42 AM, Luigi Calori l.cal...@cineca.it wrote: I'm currently building 2.8 trunk under Windows XP Visual Studio 7.1 I'm getting quite a lot of warning, I know this has been discussed before, just want to make sure it is an expected result and not something due to my build setup: I attach the debug and release output zipped Looking at the dasboard entries of other VC builds on VC 8 and VC Express it seems they have much few warnings: it is a compiler issue or there is a better way to build? expecially the c:\programmi\microsoft visual studio .net 2003\vc7\include\xtree(1121) : warning C4702: unreachable code is really noisy and seem VC related If there is interest in supporting VC 71, I can try to arrange for a nigthly test platform. I had also an error in building tiff plugin, probably related to my libtiff lib that is built as static. Thanks in advance Luigi ___ 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] 2.8: XUL not completely found
Hi Paul, I'm compiling against xulrunner 1.8.1.16: pkg-config xulrunner-xpcom --modversion 1.8.1.16 Ubuntu repositories have both 1.8 and 1.9 available, but there are under different names. libxul gets you 1.8.x, while xulrunner gets you 1.9. Perhaps there is another component you need to install for 1.8.1 to get everything you need to compile. At your end could you see if you can the gecko plugin compiling against 1.9. Given what Callum wrote about the likihood of an easy port I do wonder if it might not through up quite a few issues. One thing on our side is that I deliberately didn't patch gecko like mozilla source normally did for UBrowser, this meant that some of the UBrowser functionality couldn't be exposed by our gecko plugin, but for us it might also mean that we are less exposed to changes between 1.8 and 1.9. Robert. On Fri, Feb 6, 2009 at 12:17 PM, Paul Melis p...@science.uva.nl wrote: Robert Osfield wrote: On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote: A question: I think I saw you mention somewhere that XUL 1.9 is not supported, that 1.8 is the version to use. Is this correct? Our gecko plugin is based on Ubrowser + XUL 1.8.x. I exchange a number of emails with Callum Prentice, the author of Ubrowser, about porting to to XUL 1.9 and he said that their are number of changes between the two version that include removal of functionality UBrowser relied upon, and the mozilla developer mailing lists were very unhelpful in helper guide others trying to use the API and the lack of docs meant that it would have been a lot of work to guess how to proceed with a port. Callum is now concentrating on Qt + WebKit integration that isn't yet released but should be some time in the spring. I guess it might event be a part of Qt 4.5. Callum has now moved on from looking at the gecko side as it was just too hard to get working well. I went for the gecko route purely because all the other solutions out there required modifying webkit sources and compiling it's oneself. There are at least xulrunner 1.8 still available on some platforms off the shelf. This won't be a long term thing though... 1.9 is replacing it... Hmm, I haven't looked at webkit in detail but heard mostly good things about it, too bad it's not usable at this point yet. I'm having some trouble getting 2.8 to compile on an FC10 system (after having to hack the CMake XUL module, as it uses different pkg-config names for the XUL packages). Specifically, src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h, which on the FC10 system, is located in a subdirectory widget/ of the XUL include directory and therefore can't be found using the current include directories set from the CMake module. The gecko/CMakeLists.txt does have an entry for the widget subdirectory: ${XUL_INCLUDE_DIR}/widget pkg-config libxul --cflags on this FC10 system reports: -fshort-wchar -I/usr/include/xulrunner-sdk-1.9/stable -I/usr/include/nspr4 and so XUL_INCLUDE_DIR gets set to /usr/include/xulrunner-sdk-1.9/stable by CMake. However, the directories widget/ and such are not subdirecories of the stable/ dir but are siblings! It seems that the files in stable/ are some sort of backwards-compatible 1.8 API, that are not present in the official 1.9 SDK. Looking further into this it seems that that header (nsIBaseWindow.h) is nowhere to be found in any of the 1.8 official distributions from Mozilla! (e.g. http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/) Forgot to mention that the header IS included in 1.9, but you probably guessed Ar building on shifting sand We perhaps should check wether there have been any successful builds of the gecko plugin against xulrunner 1.8. I have a hunch everybody is using 1.9 these days :) So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9? We could try to port to 1.9, but... it could well take a while. I think that we already use 1.9 everywhere, simply because the plugin shouldn't compile against 1.8 without errors. On an old FC4 system I *do* see the nsIBaseWindow.h header, but there it is part of mozilla-1.7.13. So it's quite a big jungle where those headers the gecko plugin uses comes from :-/ Did you not say that you got things working yesterday? What haw changed since then? That I'm now compiling on a different system (FC10 instead of Gentoo). I'm not very motivated to keep track and handle all different XUL installations out there. I guess on the long run porting to 1.9 (or taking another look at webkit) might be the best way forward. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list
Re: [osg-users] -2.8 branch, testing-- vs71
Robert Osfield ha scritto: Hi Luigi, Home come you need to compile in the jpeg and zlip libraries into libtiff? Does you build of libtiff use these but not link them in itself? It seems a problem in libtiff build, as forcing linking to jpeg and zlib seem solve the problem Thanks a lot Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Gary, You spelling fixes and changes to osgShell.bat are now merged with OSG-2.8 branch. I did simplify the osgShell.bat a bit more though, I removed the path to the plugins directory and the OpenSeneGraph-Data subdirectories as these shouldn't be required any more as the OSG searches automatically for it's versioned plugin directory. On Fri, Feb 6, 2009 at 10:47 AM, Quinn, Gary g.qu...@tees.ac.uk wrote: osgAutoTransform seems to have a problem on a dualview display (2x 1280x1024 displays, NOT horizontal span), where the text seems to flicker (even when the camera isn't moving) and text randomly appears in random places across the screen. This is a limit of osg::AutoTransform - it can't face two directions at once. osgGeometry... The yellow geometry remains stationary when the model is moved - is this correct ? This is correct. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osggeometry.jpg osgfxBrowser... The description text sits over the help text which looks untidy. Looks like the fonts must be larger on your system. Once could spend time tweaking to get perfect on your system, but I wouldn't be able to do that given I don't have your fonts. Perhaps if you had nothing else to do with your time you could have tweak. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgfxbrowser.jpg osgKeyboard... When I press the Alt-Gr key, the display shows the Left-CTRL key as being pressed. Do others under Windows see this? osgPrecipitation... Looks good when the camera is static, but the precipitation moves in the opposite direction to the camera. The transition from a static camera to a moving camera creates an abrupt change in the precipitation which looks odd. I don't know whether this is down to your drivers or perceptions, or lag on your monitor - do have an LCD? The PreciptiationEffect uses shaders to produce an motion blur effect - with the particles being stretched out across the start and end positions that particle will occupy on adjacent frames. osgShaders... Only the bottom row of models are shaded. Is this correct ? See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgShaders.jpg The top three shouldn't be blank,. Are you getting any OpenGL errors reported? Do you have an up to date OpenSceneGraph-Data? osgviewer glsl_mandelbrot.osg crashes on exit with a NULL pointer reference. Could you please provide a stack trace. osgstereoimage produces a black screen, no visible model. Again I wonder if you don't have an up to date OpenSceneGaph-Data on your path. Or perhaps no jpeg plugin to load the images. osgScribe seems to incorrectly draw some of the back faces in wireframe. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExample.jpg and http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExampleCropped.jpg This could be a driver issue, or perhaps a polygonoffset issue. Neither of which is a bug on the OSG side. Finally, I vaguely remember the examples in a much earlier release all having a h hotkey for help, which showed how to save the scene, do a screen dump, etc. But none of the 2.8.0 examples seem to have this. This is normal in 1.x osgProducer::Viewer provided everything including the kitchen sink by default. While osgVIewer::Viewer doesn't provide any event handlers save for a fallback of the TrackballManipulator if nothing else is registered before the call to viewer.run. Run osgviewer and you'll find 'h' works, and have a look at the code for it too to see how the various functionality is added. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Robert Osfield wrote: Hi Paul, I'm compiling against xulrunner 1.8.1.16: pkg-config xulrunner-xpcom --modversion 1.8.1.16 Ubuntu repositories have both 1.8 and 1.9 available, but there are under different names. libxul gets you 1.8.x, while xulrunner gets you 1.9. Perhaps there is another component you need to install for 1.8.1 to get everything you need to compile. At your end could you see if you can the gecko plugin compiling against 1.9. The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 (but is in 1.8), and I see some API incompabilities leading to errors, so compiling against pure 1.9 won't work. I really wonder where the stuff that isn't in 1.8 but that IS used by the gecko plugin comes from (like nsIBaseWindow.h). Can you check on your end? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Hi Paul, My nsIBaseWindow.h is in /usr/include/xulrunner/widget/nsIBaseWindow.h /usr/include/xulrunner$ find . -name nsIBaseWindow.h ./widget/nsIBaseWindow.h I have attached the file. Doing a grep for nsIBaseWindow there are couple more instances that reference it: grep nsIBaseWindow */* docshell/nsCDocShell.h:#ifndef __gen_nsIBaseWindow_h__ docshell/nsCDocShell.h:#include nsIBaseWindow.h webbrwsr/nsCWebBrowser.h:#ifndef __gen_nsIBaseWindow_h__ webbrwsr/nsCWebBrowser.h:#include nsIBaseWindow.h Given that we are unlikely to be able to port to 1.9.x for 2.8 we'll need to change the FindXUL.cmake to only match 1.8.x. Any thoughts on how to do this? Also what version of libxul/xulrunner do you have available? Is it just 1.9 on Fedora10, or can you get 1.8 as well. When you got the gecko plugin working the other day what platform was this, and which xulrunner version was it? Robert. Robert. On Fri, Feb 6, 2009 at 1:02 PM, Paul Melis p...@science.uva.nl wrote: Robert Osfield wrote: Hi Paul, I'm compiling against xulrunner 1.8.1.16: pkg-config xulrunner-xpcom --modversion 1.8.1.16 Ubuntu repositories have both 1.8 and 1.9 available, but there are under different names. libxul gets you 1.8.x, while xulrunner gets you 1.9. Perhaps there is another component you need to install for 1.8.1 to get everything you need to compile. At your end could you see if you can the gecko plugin compiling against 1.9. The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 (but is in 1.8), and I see some API incompabilities leading to errors, so compiling against pure 1.9 won't work. I really wonder where the stuff that isn't in 1.8 but that IS used by the gecko plugin comes from (like nsIBaseWindow.h). Can you check on your end? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org /* * DO NOT EDIT. THIS FILE IS GENERATED FROM nsIBaseWindow.idl */ #ifndef __gen_nsIBaseWindow_h__ #define __gen_nsIBaseWindow_h__ #ifndef __gen_nsISupports_h__ #include nsISupports.h #endif #ifndef __gen_nsrootidl_h__ #include nsrootidl.h #endif /* For IDL files that don't want to include root IDL files. */ #ifndef NS_NO_VTABLE #define NS_NO_VTABLE #endif class nsIWidget; typedef void * nativeWindow; /* starting interface:nsIBaseWindow */ #define NS_IBASEWINDOW_IID_STR 046bc8a0-8015-11d3-af70-00a024ffc08c #define NS_IBASEWINDOW_IID \ {0x046bc8a0, 0x8015, 0x11d3, \ { 0xaf, 0x70, 0x00, 0xa0, 0x24, 0xff, 0xc0, 0x8c }} /** * The nsIBaseWindow describes a generic window and basic operations that * can be performed on it. This is not to be a complete windowing interface * but rather a common set that nearly all windowed objects support. */ class NS_NO_VTABLE nsIBaseWindow : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IBASEWINDOW_IID) /* [noscript] void initWindow (in nativeWindow parentNativeWindow, in nsIWidget parentWidget, in long x, in long y, in long cx, in long cy); */ NS_IMETHOD InitWindow(nativeWindow parentNativeWindow, nsIWidget * parentWidget, PRInt32 x, PRInt32 y, PRInt32 cx, PRInt32 cy) = 0; /* void create (); */ NS_IMETHOD Create(void) = 0; /* void destroy (); */ NS_IMETHOD Destroy(void) = 0; /* void setPosition (in long x, in long y); */ NS_IMETHOD SetPosition(PRInt32 x, PRInt32 y) = 0; /* void getPosition (out long x, out long y); */ NS_IMETHOD GetPosition(PRInt32 *x, PRInt32 *y) = 0; /* void setSize (in long cx, in long cy, in boolean fRepaint); */ NS_IMETHOD SetSize(PRInt32 cx, PRInt32 cy, PRBool fRepaint) = 0; /* void getSize (out long cx, out long cy); */ NS_IMETHOD GetSize(PRInt32 *cx, PRInt32 *cy) = 0; /* void setPositionAndSize (in long x, in long y, in long cx, in long cy, in boolean fRepaint); */ NS_IMETHOD SetPositionAndSize(PRInt32 x, PRInt32 y, PRInt32 cx, PRInt32 cy, PRBool fRepaint) = 0; /* void getPositionAndSize (out long x, out long y, out long cx, out long cy); */ NS_IMETHOD GetPositionAndSize(PRInt32 *x, PRInt32 *y, PRInt32 *cx, PRInt32 *cy) = 0; /** * Tell the window to repaint itself * @param aForce - if true, repaint immediately * if false, the window may defer repainting as it sees fit. */ /* void repaint (in boolean force); */ NS_IMETHOD Repaint(PRBool force) = 0; /* [noscript] attribute nsIWidget parentWidget; */ NS_IMETHOD GetParentWidget(nsIWidget * *aParentWidget) = 0; NS_IMETHOD SetParentWidget(nsIWidget * aParentWidget) = 0; /* attribute nativeWindow parentNativeWindow; */ NS_IMETHOD GetParentNativeWindow(nativeWindow *aParentNativeWindow) = 0; NS_IMETHOD SetParentNativeWindow(nativeWindow aParentNativeWindow) = 0; /* attribute boolean visibility; */ NS_IMETHOD GetVisibility(PRBool *aVisibility) = 0; NS_IMETHOD SetVisibility(PRBool aVisibility) = 0; /* attribute
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Yes, i was just trying to check if the tex coords were ok. The problem is not that, i tried both possibilities, generating the tex coords on VS and passs them to th FS and grabbing them directly in the fragment shader... J. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6066#6066 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Robert Osfield wrote: My nsIBaseWindow.h is in /usr/include/xulrunner/widget/nsIBaseWindow.h /usr/include/xulrunner$ find . -name nsIBaseWindow.h ./widget/nsIBaseWindow.h Just found some enlightenment (http://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/23257b1e3315a11f/c136034a7e04aeef): Andrew Gough wrote: Is it supposed to be theoretically possible to embed XulRunner 1.8.1.3 at all? I am trying (once again) to make this work, so I downloaded the SDK runtime for xulrunner-1.8.1.3, and attempted to compile against it. The SDK only contains *frozen* interfaces and headers. It is currently not possible to usefully embed gecko using only frozen interfaces: you will have to use internal interfaces such as nsIBaseWindow as well. So if the question is Is it possible to embed XULRunner 1.8.1.3 by compiling against the SDK? the answer is no. If the question is Is it possible to embed XULRunner 1.8.1.3? the answer is yes. But you'll need to obtain the nonfrozen headers/interfaces from the source tarball. So that header is part of an internal API that might change and explains why your 1.8 installation contains headers that are not in the SDK. And explains why the gecko plugin builds there as well. I have attached the file. Doing a grep for nsIBaseWindow there are couple more instances that reference it: grep nsIBaseWindow */* docshell/nsCDocShell.h:#ifndef __gen_nsIBaseWindow_h__ docshell/nsCDocShell.h:#include nsIBaseWindow.h webbrwsr/nsCWebBrowser.h:#ifndef __gen_nsIBaseWindow_h__ webbrwsr/nsCWebBrowser.h:#include nsIBaseWindow.h Given that we are unlikely to be able to port to 1.9.x for 2.8 we'll need to change the FindXUL.cmake to only match 1.8.x. Any thoughts on how to do this? pkg-config supports version requirements, which the CMake pkg-config calls support as well. From /usr/share/cmake/Modules/FindPkgConfig.cmake: # pkg_check_modules (GLIB2 glib-2.0=2.10) # requires at least version 2.10 of glib2 and defines e.g. # GLIB2_VERSION=2.10.3 I would expect = to work as well, instead of = Also what version of libxul/xulrunner do you have available? Is it just 1.9 on Fedora10, or can you get 1.8 as well. Installed: xulrunner.i3861.9.0.6-1.fc10 installed xulrunner-devel.i386 1.9.0.6-1.fc10 installed Available: xulrunner-devel-unstable.i386 1.9.0.6-1.fc10 updates xulrunner-python.i386 1.9.0.6-1.fc10 updates xulrunner-python-devel.i3861.9.0.6-1.fc10 updates So only 1.9.0.6 on FC10. When you got the gecko plugin working the other day what platform was this, and which xulrunner version was it? That was my home machine, which runs gentoo, where xulrunner 1.8.1.19 and 1.9.0.5 are available and both are installed. CMake detected 1.8 there, as xulrunner-1.9 uses libxul and mozilla- for its pkg-config files. 1.8 uses xulrunner. So you can use the latter one in FindXUL.cmake. Paul Robert. Robert. On Fri, Feb 6, 2009 at 1:02 PM, Paul Melis p...@science.uva.nl wrote: Robert Osfield wrote: Hi Paul, I'm compiling against xulrunner 1.8.1.16: pkg-config xulrunner-xpcom --modversion 1.8.1.16 Ubuntu repositories have both 1.8 and 1.9 available, but there are under different names. libxul gets you 1.8.x, while xulrunner gets you 1.9. Perhaps there is another component you need to install for 1.8.1 to get everything you need to compile. At your end could you see if you can the gecko plugin compiling against 1.9. The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 (but is in 1.8), and I see some API incompabilities leading to errors, so compiling against pure 1.9 won't work. I really wonder where the stuff that isn't in 1.8 but that IS used by the gecko plugin comes from (like nsIBaseWindow.h). Can you check on your end? 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake error on trunk HEAD
I am getting the following error in Cmake after updating to the latest truink (9687). .src/OpenThreads/PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in does not exist. Is this a temporary situation or something not been checked in. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash questions
Hi J.P., * If I keep doing exp build will it keep on creating new entries? I thought they would at least be grouped by Site? * Can I delete entries? From what I've seen in the past few days (since I started submitting builds myself) they're removed from the list every night automatically. As you can see Sukender's Experimental builds from yesterday are not there anymore and I personally haven't found out how to remove an entry, so I deduce that they're removed automatically each night. * If I click on the build name, there is no info for compiler name and compiler version. How do I get cmake to fill in these? * There is no indication on the site of build options selected, e.g. Release/Debug, Examples on/off. Can this be added in some way, or must I submit it manually? Maybe we should submit CMakeCache.txt to the notes? I'll have to defer to someone else for these questions, I'm a CDash user too like yourself, and don't know much about how it works. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Robert. OpenSceneGraph 2.8.0-rc1, Windows XP SP3, Vis Studio 2008. no errors, no warnings when compiling. There are some spelling errors/typos in the text output from various examples. I haven't had time to go through them all, but the ones I've found are listed in http://vr3.tees.ac.uk/osg280rc1/OSG280rc1SpellingErrors.txt osgShell.bat seems to be broken, I guess it's been moved up or down a directory level since the last time I tried it. I've uploaded a modified version to http://vr3.tees.ac.uk/osg280rc1/osgShell.bat which assumes that the data 3rdparty directories are both inside the OpenSceneGraph-x.x.x directory. osgAutoTransform seems to have a problem on a dualview display (2x 1280x1024 displays, NOT horizontal span), where the text seems to flicker (even when the camera isn't moving) and text randomly appears in random places across the screen. This is at its worst when the model is spread across the two screens. If I can find a way to screen grab this, I will - but no promises. osgGeometry... The yellow geometry remains stationary when the model is moved - is this correct ? See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osggeometry.jpg osgfxBrowser... The description text sits over the help text which looks untidy. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgfxbrowser.jpg osgKeyboard... When I press the Alt-Gr key, the display shows the Left-CTRL key as being pressed. osgPrecipitation... Looks good when the camera is static, but the precipitation moves in the opposite direction to the camera. The transition from a static camera to a moving camera creates an abrupt change in the precipitation which looks odd. osgShaders... Only the bottom row of models are shaded. Is this correct ? See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgShaders.jpg osgviewer glsl_mandelbrot.osg crashes on exit with a NULL pointer reference. osgstereoimage produces a black screen, no visible model. osgScribe seems to incorrectly draw some of the back faces in wireframe. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExample.jpg and http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExampleCropped.jpg Finally, I vaguely remember the examples in a much earlier release all having a h hotkey for help, which showed how to save the scene, do a screen dump, etc. But none of the 2.8.0 examples seem to have this. Gary. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Hi Joseba, Your mistake seems to be in your shaders. Let's examine: // Vertex Shader varying vec2 Texcoord; void main( void ) { gl_FrontColor = gl_Color; gl_Position = ftransform(); Texcoord = gl_MultiTexCoord0.xy; } So here you're putting your texture coordinates into a varying called Texcoord (that should be gl_TextureMatrix[0] * gl_MultiTexCoord0 by the way). // Fragment shader uniform sampler2D baseMap; varying vec2 Texcoord; void main( void ) { gl_FragColor = vec4(texture2D( baseMap,gl_TexCoord[0].st).xyz, 0.0); } Here you don't use your Texcoord varying, but instead use gl_TexCoord[0] which has not been set by the vertex shader. That's probably why you're getting a bad result, you're using an undefined variable. Instead, you could forget using an varying and just do this in the vertex shader: gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; And leave your fragment shader as it is. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Thanks Robert. Just to update you... osgshaders... I hadn't noticed before, but when the models are on the left hand (primary) monitor, osgshaders fails as per the image at http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgShaders.jpg, but the shaders work if I move the camera so the models are on the right hand (secondary) monitor. There are some error messages... FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram blocky FAILED FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram eroded FAILED FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram marble FAILED Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) osgstereoimage says Warning GraphicsWindowWin32::grabFocus() - Failed grabbing the focus. The PC becomes very sluggish, but does allow me to exit from osgstereoimage without any problem. The NULL pointer error with the mandlebrot set doesn't want to repeat itself :-( I'm using the 2.6.0 version of OpenSceneGraph-Data. Gary. -- Message: 8 Date: Fri, 6 Feb 2009 12:42:19 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902060442x6a9af42dr99606e8eb68cf...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Gary, You spelling fixes and changes to osgShell.bat are now merged with OSG-2.8 branch. I did simplify the osgShell.bat a bit more though, I removed the path to the plugins directory and the OpenSeneGraph-Data subdirectories as these shouldn't be required any more as the OSG searches automatically for it's versioned plugin directory. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sketchup rendering
Please post your results. I'm also very curious about how to achieve this affect. Thanks, Cory Serge Lages wrote: Thanks Guillaume, The page you've spotted give nearly the same result as osgFX::Cartoon, what I would like is to have all the edged (when adjacent 2 faces are not coplanar) visible. I'll try to make something mixing this effect with something more custom to try to achieve it. On Thu, Feb 5, 2009 at 8:13 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same "look and feel" than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Hi Paul, Good detective work. So we need to do two things - make sure we don't pick up on 1.9, and make sure that nsIBaseWindow.h is available. I have just tried out the following changes to FindXUL.cmake: IF(PKG_CONFIG_FOUND) INCLUDE(FindPkgConfig) pkg_check_modules(XULRUNNER_XPCOM xulrunner-xpcom=1.8.9) pkg_check_modules(XULRUNNER_JS xulrunner-js) pkg_check_modules(XULRUNNER_NSPR xulrunner-nspr) pkg_check_modules(XULRUNNER_NSS xulrunner-nss) ENDIF(PKG_CONFIG_FOUND) # Added check to make sure that nsIBaseWindow.h is available, as it's not a standard part the of 1.8.x SDK FIND_PATH(NSIBASEWINDOW_INCLUDE_DIR widget/nsIBaseWindow.h PATHS ${XULRUNNER_XPCOM_INCLUDE_DIRS} $ENV{OSG_DIR}/include/xulrunner $ENV{OSG_DIR}/include Could you please try this out on your system, hopefully it'll not register XUL as being found on your system. While not perfect, it will at least mean you won't have a broken build. Robert. FindXUL.cmake Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Sigh. I have worked my bollocks off trying to reduce the number of suppressed warnings in include/osg/Export. We have got as far as we are going to get without holding back the release for many more weeks, and without modifying many hundreds of files, needless changes too, then won't actually fix any bugs, it just compilers over zealous warnings we are suppressing via code changes to code that is typically perfectly correct in the first place. One thing I never suggested (even remotely) is holding back the 2.8 release because of warnings. Worst case, we could go back to the situation as it was before, OSG_USE_AGGRESSIVE_WARNINGS to off by default on Windows and no one notices. There's no reason to spend the major part of your work hours on OSG trying to fix Windows warnings, when it can be done gradually over a couple weeks after the release, so as to not get fed up with it as you seem to be now. Out of curiosity, I just diffed osg/Export between revision 9235 (Nov. 24, 2008, before the warnings blitz) and the trunk to see what had been removed. There were 8 disables before, now there are 4. So I guess it's progress, at least. If nothing else comes up, it's a good middle ground. I was just trying to see if we could satisfy the users who have come by the list in the past, saying why does OSG disable warnings in my own code?. It's happened a few times IIRC. So my hope was to be able to get 0 warning disables in osg/Export, not 50% of what we had... But it doesn't seem possible. Me, I don't care, other than having an ideological stance that doesn't help anyone. What is far far more important is testing and fixing real bugs. Fixing real bugs benefits everybody. Well said. I'll get back to work now. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Gary, I very much sounds like your OpenGL driver is coping with the dual heads well. Could you set the evn var OSG_SCREEN to 0 or 1 then run the problem examples to see if this resolves the problems. Robert. On Fri, Feb 6, 2009 at 2:00 PM, Quinn, Gary g.qu...@tees.ac.uk wrote: Thanks Robert. Just to update you... osgshaders... I hadn't noticed before, but when the models are on the left hand (primary) monitor, osgshaders fails as per the image at http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgShaders.jpg, but the shaders work if I move the camera so the models are on the right hand (secondary) monitor. There are some error messages... FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram blocky FAILED FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram eroded FAILED FRAGMENT glCompileShader FAILED VERTEX glCompileShader FAILED glLinkProgram marble FAILED Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) osgstereoimage says Warning GraphicsWindowWin32::grabFocus() - Failed grabbing the focus. The PC becomes very sluggish, but does allow me to exit from osgstereoimage without any problem. The NULL pointer error with the mandlebrot set doesn't want to repeat itself :-( I'm using the 2.6.0 version of OpenSceneGraph-Data. Gary. -- Message: 8 Date: Fri, 6 Feb 2009 12:42:19 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902060442x6a9af42dr99606e8eb68cf...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Gary, You spelling fixes and changes to osgShell.bat are now merged with OSG-2.8 branch. I did simplify the osgShell.bat a bit more though, I removed the path to the plugins directory and the OpenSeneGraph-Data subdirectories as these shouldn't be required any more as the OSG searches automatically for it's versioned plugin directory. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... I've now changed the offending part of the src/OpenThreads/CMakeLists.txt to: IF(MSVC) SET(OPENTHREADS_VERSIONINFO_RC ${PROJECT_BINARY_DIR}/PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc) CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in ${OPENTHREADS_VERSIONINFO_RC}) ENDIF(MSVC) Could you do an svn update and see if the problem is now fixed. Thanks, Robert. On Fri, Feb 6, 2009 at 1:39 PM, Roger James ro...@beardandsandals.co.uk wrote: I am getting the following error in Cmake after updating to the latest truink (9687). .src/OpenThreads/PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in does not exist. Is this a temporary situation or something not been checked in. Roger ___ 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] LWO loading problem
On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield robert.osfi...@gmail.com wrote: Could you please try out the svn/trunk or OSG-2.8 branch to double check that the lwo plugin is now behaving itself. Hi Robert, Apparently both versions now load the model, thank you. There is only the original issue with multitexturing remaining, as reported by Marco in november. That mail thread seems to have died without ever receiving a reply from the author of the change causing the breakage (Bob). -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Robert, osgKeyboard... When I press the Alt-Gr key, the display shows the Left-CTRL key as being pressed. Do others under Windows see this? I just checked. I assume Alt-Gr is the right alt key, is that correct? - Left Alt works - Right Alt doesn't do anything, though the console prints osgGA::GUIEventAdapter::MODKEY_RIGHT_ALT =32 at that moment. So it sees the key as pressed but doesn't display anything on the on-screen keyboard when it happens. - Both Ctrl and shift keys work - The left Super is my Windows key and works - The right Menu is my context menu key and works - I have no right Windows key so can't test the right Super - What's Switch? Is that what the right Alt key should map to? Anyways, seems to me the right Alt doesn't do anything on my machine but that's the only problem I can see. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sketchup rendering
You should also take a look at http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter15.html and the osgdepthpeeling example. Looks like its close to what you want. Frank On Fri, Feb 06, 2009 at 10:45:35AM +0100, Serge Lages wrote: Thanks Guillaume, The page you've spotted give nearly the same result as osgFX::Cartoon, what I would like is to have all the edged (when adjacent 2 faces are not coplanar) visible. I'll try to make something mixing this effect with something more custom to try to achieve it. On Thu, Feb 5, 2009 at 8:13 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same look and feel than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
Roger, are there also some changes that we should make to build collada plugin on Mac? I'm experiencing some problem when building collada plugin on Mac OS X (10.5). I'm quite new to Mac's developinng environment (as well as Unix and Linux), so maybe it is my fault and I apologize if I make silly questions, anyway here is what I did: 1) I built Collada DOM 2.2 (resulting in Collada14Dom.dylib) 2) I set OSG's cmake parameters for COLLADA in order to point to the just built Collada14Dom.dylib and to Collada DOM's headers too 3) I tried to build OSG using Xcode project as generated by cmake, but building failed So, I manually added the path to boost headers (that was a problem) and compiling was successful, but linking failed becuase it looks like that the collada lib is still not found (even though I also added the path to Collada14Dom.dylib). Please can you tell me if there are some steps to follow in order to build dae plugin against DOM 2.2? By the way I'm using OSG 2.7.9? Thanks. Alessandro On Fri, Feb 6, 2009 at 2:10 PM, Roger James ro...@beardandsandals.co.ukwrote: Matt Fair wrote: I am trying to get collada compiled into OSG and am having some trouble. It looks like collada-dom comes with boost and statically links to it, I have another version of boost on my system also, but how the make files are setup it is using the provided copy. When I compile OSG I get: Matt, To build against 2.2 on Windows I had to mod the CMake generated build files as follows:- 1. Added a path for boost to the additional include directories. 2. Added BOOST_ALL_NO_LIB to the preprocessor defines. 3. Added a path for boost to the linker additional library directories. 4. Added libboost_system-d.lib to the linker additional dependencies. However you can still build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/domwithout making any changes. I suppose these changes should realy go into CMake, but I find CMake somewhat opaque :-) Roger ___ 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] CDash questions
Hi Casba, No, they aren't really removed, of course. The default page only shows the entries for the current day, but all entries can be accessed via the menu (calendar-previous-current-next). Yes of course, I meant they're not visible on the main dashboard page. I should have been more precise. I think J.P. was worried that the list on that page would grow endlessly... Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Robert Osfield wrote: Hi Paul, Good detective work. So we need to do two things - make sure we don't pick up on 1.9, and make sure that nsIBaseWindow.h is available. I have just tried out the following changes to FindXUL.cmake: IF(PKG_CONFIG_FOUND) INCLUDE(FindPkgConfig) pkg_check_modules(XULRUNNER_XPCOM xulrunner-xpcom=1.8.9) pkg_check_modules(XULRUNNER_JS xulrunner-js) pkg_check_modules(XULRUNNER_NSPR xulrunner-nspr) pkg_check_modules(XULRUNNER_NSS xulrunner-nss) ENDIF(PKG_CONFIG_FOUND) # Added check to make sure that nsIBaseWindow.h is available, as it's not a standard part the of 1.8.x SDK FIND_PATH(NSIBASEWINDOW_INCLUDE_DIR widget/nsIBaseWindow.h PATHS ${XULRUNNER_XPCOM_INCLUDE_DIRS} $ENV{OSG_DIR}/include/xulrunner $ENV{OSG_DIR}/include Could you please try this out on your system, hopefully it'll not register XUL as being found on your system. While not perfect, it will at least mean you won't have a broken build. On Gentoo this (still) correctly detects 1.8 and the gecko plugin gets built. On FC10 this correctly fails to detect 1.9 and the gecko plugin is NOT built. Looks good! Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi All, Are we good to go on OSG-2.8-rc2? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
When do you anticipate a final release fo OSG-2.8? Ed Robert Osfield wrote: Hi All, Are we good to go on OSG-2.8-rc2? 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] CDash questions
Hi, Jean-Sébastien Guay wrote: Hi Casba, No, they aren't really removed, of course. The default page only shows the entries for the current day, but all entries can be accessed via the menu (calendar-previous-current-next). Ah, OK. I did not realise the page was for a single day. Yes of course, I meant they're not visible on the main dashboard page. I should have been more precise. I think J.P. was worried that the list on that page would grow endlessly... Yes, indeed I was :) jp Thanks, J-S -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sketchup rendering
Thank you Frank, it's indeed close to what I want, I'll give it a closer look ! On Fri, Feb 6, 2009 at 4:04 PM, frankmil...@jhmi.edu wrote: You should also take a look at http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter15.html and the osgdepthpeeling example. Looks like its close to what you want. Frank On Fri, Feb 06, 2009 at 10:45:35AM +0100, Serge Lages wrote: Thanks Guillaume, The page you've spotted give nearly the same result as osgFX::Cartoon, what I would like is to have all the edged (when adjacent 2 faces are not coplanar) visible. I'll try to make something mixing this effect with something more custom to try to achieve it. On Thu, Feb 5, 2009 at 8:13 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same look and feel than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
On Fri, Feb 6, 2009 at 3:28 PM, Ed o...@celticblues.com wrote: When do you anticipate a final release fo OSG-2.8? That all depends upon how well OSG-2.8.0-rc2 goes down with end users across platforms. rc2 could be the 2.8.0 version we distribute. Personally I'd like to tag OSG-2.8.0 this week so I can got on with the rest of my work next week, I'd expect the community would be happy to be off release testing duty as well :-) However, if there code is broken, then it's worth waiting an extra day or two. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
On Fri, Feb 6, 2009 at 3:18 PM, Paul Melis p...@science.uva.nl wrote: On Gentoo this (still) correctly detects 1.8 and the gecko plugin gets built. On FC10 this correctly fails to detect 1.9 and the gecko plugin is NOT built. That's a relief, these changes are now checked into OSG-2.8 and svn/trunk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Robert, Are we good to go on OSG-2.8-rc2? I think so from here. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Thanks for the tip Art, This still doesn't work. I can load the model withouth problems, but when i attach a osg::Program to it, i still cant pass the texture to the shader (although i can get the texture by code and see tha it has been loaded in the Texture Unit 0). I also dont see much difference between the code you posted and mine (I also create the osg::Uniform). This is very odd Thanks, J. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6079#6079 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Hi Paul, On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote: A question: I think I saw you mention somewhere that XUL 1.9 is not supported, that 1.8 is the version to use. Is this correct? Our gecko plugin is based on Ubrowser + XUL 1.8.x. I exchange a number of emails with Callum Prentice, the author of Ubrowser, about porting to to XUL 1.9 and he said that their are number of changes between the two version that include removal of functionality UBrowser relied upon, and the mozilla developer mailing lists were very unhelpful in helper guide others trying to use the API and the lack of docs meant that it would have been a lot of work to guess how to proceed with a port. Callum is now concentrating on Qt + WebKit integration that isn't yet released but should be some time in the spring. I guess it might event be a part of Qt 4.5. Callum has now moved on from looking at the gecko side as it was just too hard to get working well. I went for the gecko route purely because all the other solutions out there required modifying webkit sources and compiling it's oneself. There are at least xulrunner 1.8 still available on some platforms off the shelf. This won't be a long term thing though... 1.9 is replacing it... I'm having some trouble getting 2.8 to compile on an FC10 system (after having to hack the CMake XUL module, as it uses different pkg-config names for the XUL packages). Specifically, src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h, which on the FC10 system, is located in a subdirectory widget/ of the XUL include directory and therefore can't be found using the current include directories set from the CMake module. The gecko/CMakeLists.txt does have an entry for the widget subdirectory: ${XUL_INCLUDE_DIR}/widget Looking further into this it seems that that header (nsIBaseWindow.h) is nowhere to be found in any of the 1.8 official distributions from Mozilla! (e.g. http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/) Ar building on shifting sand So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9? We could try to port to 1.9, but... it could well take a while. Did you not say that you got things working yesterday? What haw changed since then? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
Robert Osfield wrote: On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote: A question: I think I saw you mention somewhere that XUL 1.9 is not supported, that 1.8 is the version to use. Is this correct? Our gecko plugin is based on Ubrowser + XUL 1.8.x. I exchange a number of emails with Callum Prentice, the author of Ubrowser, about porting to to XUL 1.9 and he said that their are number of changes between the two version that include removal of functionality UBrowser relied upon, and the mozilla developer mailing lists were very unhelpful in helper guide others trying to use the API and the lack of docs meant that it would have been a lot of work to guess how to proceed with a port. Callum is now concentrating on Qt + WebKit integration that isn't yet released but should be some time in the spring. I guess it might event be a part of Qt 4.5. Callum has now moved on from looking at the gecko side as it was just too hard to get working well. I went for the gecko route purely because all the other solutions out there required modifying webkit sources and compiling it's oneself. There are at least xulrunner 1.8 still available on some platforms off the shelf. This won't be a long term thing though... 1.9 is replacing it... Hmm, I haven't looked at webkit in detail but heard mostly good things about it, too bad it's not usable at this point yet. I'm having some trouble getting 2.8 to compile on an FC10 system (after having to hack the CMake XUL module, as it uses different pkg-config names for the XUL packages). Specifically, src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h, which on the FC10 system, is located in a subdirectory widget/ of the XUL include directory and therefore can't be found using the current include directories set from the CMake module. The gecko/CMakeLists.txt does have an entry for the widget subdirectory: ${XUL_INCLUDE_DIR}/widget pkg-config libxul --cflags on this FC10 system reports: -fshort-wchar -I/usr/include/xulrunner-sdk-1.9/stable -I/usr/include/nspr4 and so XUL_INCLUDE_DIR gets set to /usr/include/xulrunner-sdk-1.9/stable by CMake. However, the directories widget/ and such are not subdirecories of the stable/ dir but are siblings! It seems that the files in stable/ are some sort of backwards-compatible 1.8 API, that are not present in the official 1.9 SDK. Looking further into this it seems that that header (nsIBaseWindow.h) is nowhere to be found in any of the 1.8 official distributions from Mozilla! (e.g. http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/) Forgot to mention that the header IS included in 1.9, but you probably guessed Ar building on shifting sand We perhaps should check wether there have been any successful builds of the gecko plugin against xulrunner 1.8. I have a hunch everybody is using 1.9 these days :) So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9? We could try to port to 1.9, but... it could well take a while. I think that we already use 1.9 everywhere, simply because the plugin shouldn't compile against 1.8 without errors. On an old FC4 system I *do* see the nsIBaseWindow.h header, but there it is part of mozilla-1.7.13. So it's quite a big jungle where those headers the gecko plugin uses comes from :-/ Did you not say that you got things working yesterday? What haw changed since then? That I'm now compiling on a different system (FC10 instead of Gentoo). I'm not very motivated to keep track and handle all different XUL installations out there. I guess on the long run porting to 1.9 (or taking another look at webkit) might be the best way forward. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Gary, Thanks for the testing and report. I'm just about to download your spelling errors/bar file changes and will do a review of these. W.r.t. some of the example not producing the correct results, this sounds like OpenGL drivers might be playing up. What hardware and drivers are you using? Do you have anything other systems on which to check the results? Robert. On Fri, Feb 6, 2009 at 10:47 AM, Quinn, Gary g.qu...@tees.ac.uk wrote: Hi Robert. OpenSceneGraph 2.8.0-rc1, Windows XP SP3, Vis Studio 2008. no errors, no warnings when compiling. There are some spelling errors/typos in the text output from various examples. I haven't had time to go through them all, but the ones I've found are listed in http://vr3.tees.ac.uk/osg280rc1/OSG280rc1SpellingErrors.txt osgShell.bat seems to be broken, I guess it's been moved up or down a directory level since the last time I tried it. I've uploaded a modified version to http://vr3.tees.ac.uk/osg280rc1/osgShell.bat which assumes that the data 3rdparty directories are both inside the OpenSceneGraph-x.x.x directory. osgAutoTransform seems to have a problem on a dualview display (2x 1280x1024 displays, NOT horizontal span), where the text seems to flicker (even when the camera isn't moving) and text randomly appears in random places across the screen. This is at its worst when the model is spread across the two screens. If I can find a way to screen grab this, I will - but no promises. osgGeometry... The yellow geometry remains stationary when the model is moved - is this correct ? See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osggeometry.jpg osgfxBrowser... The description text sits over the help text which looks untidy. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgfxbrowser.jpg osgKeyboard... When I press the Alt-Gr key, the display shows the Left-CTRL key as being pressed. osgPrecipitation... Looks good when the camera is static, but the precipitation moves in the opposite direction to the camera. The transition from a static camera to a moving camera creates an abrupt change in the precipitation which looks odd. osgShaders... Only the bottom row of models are shaded. Is this correct ? See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_osgShaders.jpg osgviewer glsl_mandelbrot.osg crashes on exit with a NULL pointer reference. osgstereoimage produces a black screen, no visible model. osgScribe seems to incorrectly draw some of the back faces in wireframe. See http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExample.jpg and http://vr3.tees.ac.uk/osg280rc1/osg280rc1_scribeExampleCropped.jpg Finally, I vaguely remember the examples in a much earlier release all having a h hotkey for help, which showed how to save the scene, do a screen dump, etc. But none of the 2.8.0 examples seem to have this. Gary. ___ 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] OpenSceneGraph-2.8.0-rc2 tagged, please test
Hi All, We've all been busy testing out 2.8.0-rc1 and uncovered a few more bugs, build problems and warnings that our now fixed - testing really is paying dividends ;-) Things have settled down on the issues reporting and fixes, I'm a happy bunny, so have tagged rc2. You can find download details on the download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads Which basically says... Stable Release 2.8.0, release candidate 2, released 6th February 2009. Further information... ¶ Please test this release candidate, and report success/failure to the osg-users mailing list. Source Code: ¶ source package : OpenSceneGraph-2.8.0-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc2 OpenSceneGraph Please test, test test ;-) In particular I'd like to hear from users on the lesser used platforms - OSX IRIX Solaris HP-Ux AIX We have builds under FreeBSD, Windows and Linux being logged our CDash page, and lots of traffic on the list about Windows and Linux so I guess we are probably standing pretty good on these platforms. Many thanks in advance for your time and patience on testing, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Hi Joseba, Jean, no the shader seems to be ok (or do you have changed it after submitting the message?). Nevertheless, the problem is in the wrong stateset. If you take a look into cow.osg, then you see, that the Geode with the name cow.osg has a stateset with applied texture. However the strange thing is, that when you call getOrCreateStateSet() from this geode, a new stateset is created. Even worse, if you just call getStateSet() then you will retrieve NULL back, which is of course wrong. Hence when a new stateset is created, you of course does not have any texture applied to it. And therefor you get just black from your shaders. The main things is now to find out, why the StateSet is NULL although it is defined in the cow.osg. It could be that there is a bug in the .osg loader, however the bug could be also in the given example. I am looking forward to solve it ;) Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6105#6105 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Hi Art, The main things is now to find out, why the StateSet is NULL although it is defined in the cow.osg. It could be that there is a bug in the .osg loader, however the bug could be also in the given example. I am looking forward to solve it ;) Perhaps the osgUtil::Optimizer is removing the stateset because it's redundant? If it contains all the same states as the parent node then it would do that. (note that I didn't check the code to see if the optimizer is actually being run - if not please disregard this suggestion as totally useless :-) ) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk (2.8) + VPB trunk: Terrain elevation artifacts
For the record: Upgrading from gdal-1.5.1 to gdal-1.6.0 fixed the terrain problem. Thanks!! -- John Vidar John Vidar Larring wrote: Thanks Christophe, Thanks for testing and sending the screenshot! You saved my day:) I'll update to gdal 1.6 straight away and test again... Best regards, John christophe loustaunau wrote: Hi John, I have build the database with your command line and vpb svn rev: 953 osg svn rev: 9658 But I have gdal 1.6 and not 1.5.1 The database looks normal, as you can see on screenshots attached. Maybe a gdal 1.5.1 bug ? I don't know, but it's not osg or vpb. Regards. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Best regards, John WeatherOne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Could you post some small example here, showing your problem? cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6080#6080 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
Matt Fair wrote: I am trying to get collada compiled into OSG and am having some trouble. It looks like collada-dom comes with boost and statically links to it, I have another version of boost on my system also, but how the make files are setup it is using the provided copy. When I compile OSG I get: Matt, To build against 2.2 on Windows I had to mod the CMake generated build files as follows:- 1. Added a path for boost to the additional include directories. 2. Added BOOST_ALL_NO_LIB to the preprocessor defines. 3. Added a path for boost to the linker additional library directories. 4. Added libboost_system-d.lib to the linker additional dependencies. However you can still build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom without making any changes. I suppose these changes should realy go into CMake, but I find CMake somewhat opaque :-) Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] -2.8 branch, testing-- vs71
On Fri, Feb 6, 2009 at 12:08 PM, Luigi Calori l.cal...@cineca.it wrote: I do not know if is my way of build or if is the static build, but I get link error in tiff plugin if I do not link also with jpeg and zip lib. Yes, that is normal with static tiff (even on linux). I have reported it here and on the cmake list but no solution yet. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc2 tagged, please test
Hi Robert, Things have settled down on the issues reporting and fixes, I'm a happy bunny, so have tagged rc2. I've just built 2.8.0-rc2 here, built fine, only the PDB warnings remain, and I've tested a few examples which all ran fine. Vista SP1 32-bit, vc8sp1. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Robert Osfield wrote: Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... Hi Robert, Looks OK now. Just kicked off a build. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
alessandro terenzi wrote: Roger, are there also some changes that we should make to build collada plugin on Mac? I'm experiencing some problem when building collada plugin on Mac OSX (10.5). I'm quite new to Mac's developinng environment (as well as Unix and Linux), so maybe it is my fault and I apologize if I make silly questions, anyway here is what I did: 1) I built Collada DOM 2.2 (resulting in Collada14Dom.dylib) 2) I set OSG's cmake parameters for COLLADA in order to point to the just built Collada14Dom.dylib and to Collada DOM's headers too 3) I tried to build OSGusingXcode project as generated by cmake, but building failed So, I manually added the path to boost headers (that was a problem) andcompiling was successful, but linking failed becuase it looks like that the collada lib is still not found (even though I also added the path toCollada14Dom.dylib). Please can you tell me if there are some steps to follow in order to build dae plugin against DOM 2.2? By the way I'm usingOSG 2.7.9? Thanks. Alessandro On Fri, Feb 6, 2009 at 2:10 PM, Roger James ro...@beardandsandals.co.uk wrote: Matt Fair wrote: I am trying to get collada compiled into OSG and am having some trouble. It looks like collada-dom comes with boost and statically links to it, I have another version of boost on my system also, but how the make files are setup it is using the provided copy. When I compile OSG I get: Matt, To build against 2.2 on Windows I had to mod the CMake generated build files as follows:- 1. Added a path for boost to the additional include directories. 2. Added BOOST_ALL_NO_LIB to the preprocessor defines. 3. Added a path for boost to the linker additional library directories. 4. Added libboost_system-d.lib to the linker additional dependencies. However you can still build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom without making any changes. I suppose these changes should realy go into CMake, but I find CMake somewhat opaque :-) Roger Alessandro, I suspect you will have to make similar changes to the Xcode build files to successfully link against the Collada DOM api version 2.2. However there is really not much to gain from linking against this version rather than the 2.1 version. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Roger James wrote: Robert Osfield wrote: Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... Hi Robert, Looks OK now. Just kicked off a build. Roger Robert, I spoke too soon. The build fails because it cannot find afxres.h. I had quick look at the resource files you were trying to include and looks like you have a load of old MS appstudio stuff in there which I don't think you need. I have attached examples of how we include version resources in our products. We only split out the stuff into environversion.h because that file gets automatically updated with a new build number every time we do a release build. Roger // 108 #define FILE_VERSION1,3,2,108 #define PRODUCT_VERSION 1,3,2,108 #define FILE_VERSION_STR 1, 3, 2, 108\n #define PRODUCT_VERSION_STR 1, 3, 2, 108\n #ifndef _MAC / // // Version // #include environversion.h VS_VERSION_INFO VERSIONINFO FILEVERSION FILE_VERSION PRODUCTVERSION PRODUCT_VERSION FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 080904b0 BEGIN VALUE Comments, \0 VALUE CompanyName, Virtual Outlooks Ltd.\0 VALUE FileDescription, Environ Communicator\0 VALUE FileVersion, FILE_VERSION_STR VALUE InternalName, Environ Communicator\0 VALUE LegalCopyright, Copyright © 2003,2004,2005,2006,2007\0 VALUE LegalTrademarks, \0 VALUE OriginalFilename, EnvironCommunicator.exe\0 VALUE PrivateBuild, \0 VALUE ProductName, Virtual Outlooks Ltd. Environ Communicator\0 VALUE ProductVersion, PRODUCT_VERSION_STR VALUE SpecialBuild, \0 END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x809, 1200 END END #endif// !_MAC ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] painting into Qt widgets on Mac
Hi Paul, I don't have the old versions you mention around anymore, but there's a recent change to QOSGWidget.cpp that might help. Appearently, QtWidget::winId() returns a value which can be used as a window pointer under Windows and Linux but not under OSX. generic version (original code): traits-inheritedWindowData = new WindowData(winId()); replaced with this for OSX only: traits-inheritedWindowData = new WindowData(HIViewGetWindow((HIViewRef)winId())); the near equivalent Qt code: traits-inheritedWindowData = new WindowData(qt_mac_window_for(this)); The fix assumes that OSG has been built for Carbon and not X11 windowing. When built for X11 there's a seperate OSG rendering window in addition to Qt's. -Don Leich Hello, Has anyone succeeded in using OSG to paint into Qt widgets on Mac OS X? On Windows it works without any problems if I do this: Producer::Camera *cam-getRenderSurface()-setWindow(QWidget::winId()). On Mac, however, this only works if the QWidget is a toplevel widget. If a QWidget is inside another widget, though, the window never gets repainted. I've tried using QWidget::handle() instead, but that only returns the same thing as winId for that widget's toplevel ancestor. I'm using Leopard 10.5.6. But both OSG and Qt are old versions: OSG 1.2 and Qt 3.3.8. Sorry, but I can't upgrade now... Thanks Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Hi Roger, Sorry to hear it's still broke. I'm not the original author of version additions, just the integrator. Would it be possible for you to tweak the version support now checked in and get it working. Cheers, Robert. On Fri, Feb 6, 2009 at 7:14 PM, Roger James ro...@beardandsandals.co.uk wrote: Roger James wrote: Robert Osfield wrote: Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... Hi Robert, Looks OK now. Just kicked off a build. Roger Robert, I spoke too soon. The build fails because it cannot find afxres.h. I had quick look at the resource files you were trying to include and looks like you have a load of old MS appstudio stuff in there which I don't think you need. I have attached examples of how we include version resources in our products. We only split out the stuff into environversion.h because that file gets automatically updated with a new build number every time we do a release build. Roger // 108 #define FILE_VERSION1,3,2,108 #define PRODUCT_VERSION 1,3,2,108 #define FILE_VERSION_STR 1, 3, 2, 108\n #define PRODUCT_VERSION_STR 1, 3, 2, 108\n #ifndef _MAC / // // Version // #include environversion.h VS_VERSION_INFO VERSIONINFO FILEVERSION FILE_VERSION PRODUCTVERSION PRODUCT_VERSION FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 080904b0 BEGIN VALUE Comments, \0 VALUE CompanyName, Virtual Outlooks Ltd.\0 VALUE FileDescription, Environ Communicator\0 VALUE FileVersion, FILE_VERSION_STR VALUE InternalName, Environ Communicator\0 VALUE LegalCopyright, Copyright (c) 2003,2004,2005,2006,2007\0 VALUE LegalTrademarks, \0 VALUE OriginalFilename, EnvironCommunicator.exe\0 VALUE PrivateBuild, \0 VALUE ProductName, Virtual Outlooks Ltd. Environ Communicator\0 VALUE ProductVersion, PRODUCT_VERSION_STR VALUE SpecialBuild, \0 END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x809, 1200 END END #endif// !_MAC ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Robert Osfield wrote: Hi Roger, Sorry to hear it's still broke. I'm not the original author of version additions, just the integrator. Would it be possible for you to tweak the version support now checked in and get it working. Cheers, Robert. Robert, Modified template resources attached. Roger 1 VERSIONINFO FILEVERSION ${OPENSCENEGRAPH_MAJOR_VERSION}, ${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION}, ${OPENSCENEGRAPH_SOVERSION} PRODUCTVERSION ${OPENSCENEGRAPH_MAJOR_VERSION}, ${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION}, ${OPENSCENEGRAPH_SOVERSION} FILEFLAGSMASK 0x17L #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x4L FILETYPE 0x0L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE FileDescription, OpenSceneGraph Binary VALUE FileVersion, ${OPENSCENEGRAPH_MAJOR_VERSION}, ${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION}, ${OPENSCENEGRAPH_SOVERSION} VALUE InternalName, OSG VALUE LegalCopyright, Copyright (C) 2009 VALUE OriginalFilename, VALUE ProductName, OpenSceneGraph VALUE ProductVersion, ${OPENSCENEGRAPH_MAJOR_VERSION}, ${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION}, ${OPENSCENEGRAPH_SOVERSION} END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200 END END 1 VERSIONINFO FILEVERSION ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION} PRODUCTVERSION ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION} FILEFLAGSMASK 0x17L #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x4L FILETYPE 0x0L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE FileDescription, OPENTHREADS Binary VALUE FileVersion, ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION} VALUE InternalName, OSG VALUE LegalCopyright, Copyright (C) 2009 VALUE OriginalFilename, VALUE ProductName, OPENTHREADS VALUE ProductVersion, ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION} END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200 END END ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Robert Osfield wrote: On Thu, Feb 5, 2009 at 9:35 PM, Csaba Halász csaba.hal...@gmail.com wrote: On Thu, Feb 5, 2009 at 10:16 PM, Csaba Halász csaba.hal...@gmail.com wrote: Rev 9397 is the first non-working revision. Looks like a lot of int-long changes, which seems to agree with your 64 bit theory. Except it is broken on 32 bit too. LOL, it is one for Sukender's list :) for(int i=0; i4; ++i) { *dest_ptr = *src_ptr; } Can you spot the error? :) No pointer increments!! God what I dumbo I can be sometimes... Robert, I wonder if there is a VS warning that would have found this... /me ducks for cover ;) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Robert, OpenGL 3 specs says that nothing has been removed (just features that become deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new features)... isn't it? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 06 Feb 2009 10:22:20 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: HI Adrian, Writing the core scene graph is something that is likely to be required to handle multiple backends, so rather than just OpenGL 2.0, we'd need OpenGL 3.0 and OpenGL-ES and a mixture of OpenGL/OpenCL. Currently we only map to OpenGL + extensions, we can't handle wholesale changes to the API being used at the backend. Another issue is that current scene graph API is built around fixed function pipeline, with a few tweaks to be able to handle shader, but it's still fundamentally a design for a fixed function pipeline. With a pure OpenGL 3.0 or OpenGL ES 2.0 implementation there is no fixed function pipeline at all, so the way we manage state w.r.t. uniforms/vertex attributes + shader composition will have to change. Now it may be possible to evolve the current API gradually to meet the above challenges, but... we have to entertain the possibility that at some point we have to make a large leap to be able to meet these challenges. It might be that we can evolve some parts of the API but not others. In an ideal world we'd be able make the leap to the new way of doing things without too much re-factoring of end users application code, but would such an ideal compromise that underlying scene graph in the process. Right now nothing is set in stone. The OSG.2.x has lots of life left in it yet. The idea behind an API breaking OSG-3.x series is just that, an idea, not a single line of code has been written on it, no white papers have been written proposing what a new scene graph structure would be like. All I can say for sure is that there are some big challenges ahead if we wish to make the most of new API's and new hardware technologies. Robert. On Thu, Feb 5, 2009 at 7:59 PM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi all, i don't understand why we should rewrite the whole openscenegraph core? Is the good old openGL and openscenegraph that faraway from openGL CL/openGL ES/.. How long does it take to port the whole greate functionality from osg2 to osg3? And how would it be possible to port the application form osg2 to osg3 or should we restart our development once we get osg3 because the osg2's API so different from osg3? I don't understand all of the problem. is the openGL close to death and we have to restart the greate osg2 lib. rewrite the core means, what will happen with osg2 applications, new features will no longer be added to the API (in long term view) and than the osg based application have to die, and the new application has to become new written. or what will the graphic industry do in near and long term future. i am not as close as some of the community are in the graphic community, i am closer to computer vision :-( :-) I undestand that we may have to overthink some part of the core to support new ideas in the graphic world. RealTimeRayTracer, ... ,... ,.. ,.. But openscenegraph is one of the best graphic engine currently in the world of computer graphics render engine. /sorry that i don't really understand the question and the problem we will get with osg2 adrian 2009/2/5 Cedric Pinson morni...@plopbyte.net Anyway i will help to host if it helps Cheers, Cedric Sukender wrote: Hi JS and Cédric, I'm a bit more in favor of what JS says. I agree that when the Forge is down it's really annoying, but centralizing all OSG related projects seem worth using a kind of forge (or something else). We really should avoid them dying by helping people maintaining them. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 17:49:57 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Cedric, In theory the idea is cool but if people dont fill the current wiki why they will take energy to fill a forge ? I think it requires no more energy than hosting your project on your own site, or a site like SourceForge or Google Code. The difference is that it would be centralized, with an easy way to add maintainers, to generate interest in projects, to search, etc. A list of nodekits on the wiki, where links become broken and there is no way of knowing if a project is actually any good, doesn't help at all. And personnally if there is no support for git/mercurial i prefer to host the project where i can use those tools. You could always host your own version control repository, and use the forge's version control as a mirror. Plus I think some of the software supports Mercurial at least (mozdev does, why not others?) I think the main problem
Re: [osg-users] 3.0 or 2.10?
Hi Sukender, OpenGL 3 specs says that nothing has been removed (just features that become deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new features)... isn't it? Relying on deprecated features is bad practice, since by definition deprecated features may be removed at any time. So I think the goal is to move forward in order to eventually use no deprecated features in the core OSG and main nodekits. Luckily, there is now (in OpenGL 3) a way to create a forward-compatible context where the deprecated features are disabled. This makes testing that you are not relying on deprecated features easy (and OSG 2.x would of course totally fail on this). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Number of contributors
Hi Robert -- I'm updating the Quick Start Guide for 2.8, and would like the most up-to-date number you have for the total number of OSG contributors. Currently, I have Over 250 developers contributed to OSG v2.0. If you have a more recent number, please post it. Thanks. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
OpenGL 2.x apps will run unmodified on OpenGL 3.0. However, the 3.1 spec will be released shortly, and I bet you'll see all 3.0-deprecated functionality removed in 3.1. An OSG 3 will have to avoid use of all deprecated functionality. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender Sent: Friday, February 06, 2009 1:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 3.0 or 2.10? Hi Robert, OpenGL 3 specs says that nothing has been removed (just features that become deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new features)... isn't it? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 06 Feb 2009 10:22:20 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: HI Adrian, Writing the core scene graph is something that is likely to be required to handle multiple backends, so rather than just OpenGL 2.0, we'd need OpenGL 3.0 and OpenGL-ES and a mixture of OpenGL/OpenCL. Currently we only map to OpenGL + extensions, we can't handle wholesale changes to the API being used at the backend. Another issue is that current scene graph API is built around fixed function pipeline, with a few tweaks to be able to handle shader, but it's still fundamentally a design for a fixed function pipeline. With a pure OpenGL 3.0 or OpenGL ES 2.0 implementation there is no fixed function pipeline at all, so the way we manage state w.r.t. uniforms/vertex attributes + shader composition will have to change. Now it may be possible to evolve the current API gradually to meet the above challenges, but... we have to entertain the possibility that at some point we have to make a large leap to be able to meet these challenges. It might be that we can evolve some parts of the API but not others. In an ideal world we'd be able make the leap to the new way of doing things without too much re-factoring of end users application code, but would such an ideal compromise that underlying scene graph in the process. Right now nothing is set in stone. The OSG.2.x has lots of life left in it yet. The idea behind an API breaking OSG-3.x series is just that, an idea, not a single line of code has been written on it, no white papers have been written proposing what a new scene graph structure would be like. All I can say for sure is that there are some big challenges ahead if we wish to make the most of new API's and new hardware technologies. Robert. On Thu, Feb 5, 2009 at 7:59 PM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi all, i don't understand why we should rewrite the whole openscenegraph core? Is the good old openGL and openscenegraph that faraway from openGL CL/openGL ES/.. How long does it take to port the whole greate functionality from osg2 to osg3? And how would it be possible to port the application form osg2 to osg3 or should we restart our development once we get osg3 because the osg2's API so different from osg3? I don't understand all of the problem. is the openGL close to death and we have to restart the greate osg2 lib. rewrite the core means, what will happen with osg2 applications, new features will no longer be added to the API (in long term view) and than the osg based application have to die, and the new application has to become new written. or what will the graphic industry do in near and long term future. i am not as close as some of the community are in the graphic community, i am closer to computer vision :-( :-) I undestand that we may have to overthink some part of the core to support new ideas in the graphic world. RealTimeRayTracer, ... ,... ,.. ,.. But openscenegraph is one of the best graphic engine currently in the world of computer graphics render engine. /sorry that i don't really understand the question and the problem we will get with osg2 adrian 2009/2/5 Cedric Pinson morni...@plopbyte.net Anyway i will help to host if it helps Cheers, Cedric Sukender wrote: Hi JS and Cédric, I'm a bit more in favor of what JS says. I agree that when the Forge is down it's really annoying, but centralizing all OSG related projects seem worth using a kind of forge (or something else). We really should avoid them dying by helping people maintaining them. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 17:49:57 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Cedric, In theory the idea is cool but if people dont fill the current wiki why they will take energy to fill a forge ? I think it requires no more energy than hosting your project on your own site, or a site like SourceForge or Google Code. The difference is that it
Re: [osg-users] 3.0 or 2.10?
Will there be (or should there be) an OSG-3 branch in svn to allow development to commence? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Fri, Feb 6, 2009 at 7:47 PM, Paul Speed psp...@progeeks.com wrote: I wonder if there is a VS warning that would have found this... /me ducks for cover ;) No .. but it was my attempt at fixing a gcc warning that introduced this bug... Basically every change you make to the code is prone to error, and no matter how thorough you try to be, compiler errors never give know when the algorithm is wrong, just the syntax. The vast majority of programming errors are algorithm related like this one, it's one only code reviews and code testing that actually catch the vast majority of errors. This particular bug is a good example of the double edge sword of attempting warning fixes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Number of contributors
Hi Paul, On Fri, Feb 6, 2009 at 8:32 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- I'm updating the Quick Start Guide for 2.8, and would like the most up-to-date number you have for the total number of OSG contributors. Currently, I have Over 250 developers contributed to OSG v2.0. If you have a more recent number, please post it. Thanks. The OSG-2.8 press release has a link to the contributors for 2.8, the AUTHORS.txt also contains it. The total number now stands at 365, so your 250 figure for 2.0 rather falls short ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Paul, On Fri, Feb 6, 2009 at 8:37 PM, Paul Martz pma...@skew-matrix.com wrote: Will there be (or should there be) an OSG-3 branch in svn to allow development to commence? I think this is premature. I'd rather see us highlight areas that need research and then have a set of mini projects that go out scoping these areas. Once we've scoped out a bit more, perhaps written a few white papers outlining what approach would be an ideal modern scene graph then we could start discussing what exact should be in this next gen scene graph and how we might work towards this, either evolving the current code base or setting up a new sister project for an OSG-3 branch. If we do go the OSG-3 branch route then we need to look at how to maintain the two projects, for instance helping evolve the OSG-2 branch in such a way as in closes the gap to OSG-3 to make the leap easier so that appliication developers currently working with OSG-2 won't be stuck. Another approach all together would be to say just start a new next gen scene graph project and not care what so ever about backwards compatibility with the existing code base, and look for new users and contributors to coalesce around it. Such an approach would see a lot of re-inventing the wheel, stuff like loaders and viewers that constitute a great deal of effort and knowledge would be lost. Personally I think a lot of the existing OSG code base can be carried across to a next gen scene graph. There is also the community that is one of our key assets is crucial - if you split the community between existing and next gen scene graph efforts both would suffer. The easier porting from OSG-2.x to OSG-3.x is the quicker you'd be able to migrate the community across to the new API, a challenge will be marrying the needs of a next gen scene graph and ease of porting. For starters I'd like to have a fair idea of what an ideal next gen scene graph would look like so we can all subscribe to our final destination, so we can all a tune to the same north barring. Once we get this common baring then when we start heading out along the uncharted path with each daily engineering decisions we make from here on out guided by this barring so that each day we get near to this goal. Lots of arm waving... of course... but now it's time to start thinking about what we feel should go into this next gen scene graph - what problems (i.e. what types of software/hardware) should it address, then how might one address this disparate set of problems, what existing examples can we learn from. Perhaps we need to instigate a poll of the wider graphics community of what they want from scene graphs in the next ten years, what software they see being needed to be developed, what hardware/OS's they expect to be of importance. Once polled one could look for themes that can be distilled into key deliverables that we can sign up to. There is also scratching the itch - we just have to find things that just are so compelling that we can't help ourselves - we just have to tackle it, because it's fun to do and because in the end we can see it being useful. The OSG just started with a little itch... then kinda got out of hand over the next decade.. :-) I guess this last paragraph is suggesting to me that perhaps over analysing this stuff is not what will get it done, it's going to be a handful of engineers that just get to it and create the beginnings of something beautiful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Robert Osfield wrote: On Fri, Feb 6, 2009 at 7:47 PM, Paul Speed psp...@progeeks.com wrote: I wonder if there is a VS warning that would have found this... /me ducks for cover ;) No .. but it was my attempt at fixing a gcc warning that introduced this bug... Basically every change you make to the code is prone to error, and no matter how thorough you try to be, compiler errors never give know when the algorithm is wrong, just the syntax. The vast majority of programming errors are algorithm related like this one, it's one only code reviews and code testing that actually catch the vast majority of errors. This particular bug is a good example of the double edge sword of attempting warning fixes. Robert. Totally. I was just seeing if I could here a scream in the key of Scottish brogue from all the way across the Atlantic. ;) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
On Fri, Feb 6, 2009 at 9:38 PM, Paul Speed psp...@progeeks.com wrote: Totally. I was just seeing if I could here a scream in the key of Scottish brogue from all the way across the Atlantic. ;) Aye, if Robert Burns we alive noo and working for his sins as programmer, what great prose would he write about stuff like this... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
Well I'm glad to help (?) if in fact that's what I did. I would like to get more involved as I start to understand OSG better. If you would like someone to test the new exporter I'm your guy! -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
Hi, I just upgrade the blender exporter: - improve material export (fixed some bug related to texture) - added support of multi uv layer export - added export of instance object - merge duplicate vertices (this part has been rewrite completely) Note the gui is not up to date, some work will be need to add option use in command line. If you notice bug, i recommand to set the variable DEBUG to True in osgdata.py to have more information in log file you can get the exporter here: http://hg.plopbyte.net/osgexport Cheers, Cedric Ryan Morris wrote: Well I'm glad to help (?) if in fact that's what I did. I would like to get more involved as I start to understand OSG better. If you would like someone to test the new exporter I'm your guy! -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Number of contributors
Hi Paul, I'm ready to translate the updated book into Chinese again, if it still free for OSG developers. :-) Wang Rui 2009/2/7 Paul Martz pma...@skew-matrix.com Hi Robert -- I'm updating the Quick Start Guide for 2.8, and would like the most up-to-date number you have for the total number of OSG contributors. Currently, I have Over 250 developers contributed to OSG v2.0. If you have a more recent number, please post it. Thanks. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
On Fri, Feb 6, 2009 at 1:41 PM, Roger James ro...@beardandsandals.co.uk wrote: Robert Osfield wrote: Hi Roger, Sorry to hear it's still broke. I'm not the original author of version additions, just the integrator. Would it be possible for you to tweak the version support now checked in and get it working. Cheers, Robert. Robert, I tried building the svn head version of OSG using the files you attached to this thread with no success. I received RC1000 errors along with macro definition too big - What compiler are you using? I tried with VS2005 SP1. Could you re-send the rc files to me in a direct email zipped? I'll try again. Could be that my browser is mangling the files. Anyone else have a go at this? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org