Re: [osg-users] Please test OSG-2.8 in prep for 2.8.0-rc2

2009-02-06 Thread J.P. Delport

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

2009-02-06 Thread Valery A. Bickov
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

2009-02-06 Thread John Vidar Larring

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

2009-02-06 Thread Joseba
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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread MEDARD Christophe
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

2009-02-06 Thread Robert Osfield
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 :-))

2009-02-06 Thread Robert Osfield
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)

2009-02-06 Thread David Spilling
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

2009-02-06 Thread David Spilling
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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()

2009-02-06 Thread forest37

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

2009-02-06 Thread Melchior FRANZ
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

2009-02-06 Thread Serge Lages
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 :-)

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Paul Shabash
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

2009-02-06 Thread Robert Osfield
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()

2009-02-06 Thread Can T. Oguz
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?

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Luigi Calori

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

2009-02-06 Thread Quinn, Gary
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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Alexandre Amalric
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

2009-02-06 Thread Art Tevs
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

2009-02-06 Thread Joseba
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

2009-02-06 Thread Quinn, Gary
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Luigi Calori

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Joseba
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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Quinn, Gary
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Quinn, Gary
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

2009-02-06 Thread Cory Riddell




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

2009-02-06 Thread Robert Osfield
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 :-)

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Csaba Halász
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread frankmiller
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

2009-02-06 Thread alessandro terenzi
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Ed

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

2009-02-06 Thread J.P. Delport

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

2009-02-06 Thread Serge Lages
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Joseba
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Paul Melis

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Art Tevs
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread John Vidar Larring
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

2009-02-06 Thread Art Tevs
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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Csaba Halász
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

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Don Leich

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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Roger James




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

2009-02-06 Thread Paul Speed



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?

2009-02-06 Thread Sukender
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?

2009-02-06 Thread Jean-Sébastien Guay

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

2009-02-06 Thread Paul Martz
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?

2009-02-06 Thread Paul Martz
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?

2009-02-06 Thread Paul Martz
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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Robert Osfield
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?

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Paul Speed



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

2009-02-06 Thread Robert Osfield
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

2009-02-06 Thread Ryan Morris
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

2009-02-06 Thread Cedric Pinson

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

2009-02-06 Thread Wang Rui
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

2009-02-06 Thread sherman wilcox
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