[osg-users] Warnings in compiling...
Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warnings in compiling...
HI Adrian, This warning looks bogus to me, as the code is valid - the first iterator is within the scope of a for loop, so should not have any affect on any later use of another variable declared after the for loop. The compiler in this instance is issuing a warning on the assumption that the developers doesn't know what he's doing and that Standard C++ isn't really meant to properly scope variables... Regardless of the silliness of this warning I have gone ahead and renamed the iterator scoped in the for loop, I believe this should fix the warning, although I can't verify as gcc 4.x correctly doesn't issue an warning. Robert. On 9/24/07, Adrian Egli [EMAIL PROTECTED] wrote: Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored -- Adrian Egli ___ 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] Warnings in compiling...
It is a feature of Microsoft Visual Studio... In this case it is harmless, but annoying. Ciao! mario Robert Osfield wrote: HI Adrian, This warning looks bogus to me, as the code is valid - the first iterator is within the scope of a for loop, so should not have any affect on any later use of another variable declared after the for loop. The compiler in this instance is issuing a warning on the assumption that the developers doesn't know what he's doing and that Standard C++ isn't really meant to properly scope variables... Regardless of the silliness of this warning I have gone ahead and renamed the iterator scoped in the for loop, I believe this should fix the warning, although I can't verify as gcc 4.x correctly doesn't issue an warning. Robert. On 9/24/07, Adrian Egli [EMAIL PROTECTED] wrote: Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope Registry.cpp(571) : definition of 'itr' used Registry.cpp(564) : definition of 'itr' ignored -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Visualization Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] can I use multi thread for readNodeFile?
hi,all
I want to use multithread to read many small file , I test the following code,
but it seen as if some bugs in it.
help me! thanks!
class ReadNodeFileThread:public OpenThreads::Thread
{
public:
ReadNodeFileThread(void){
_fileName = ;
_loadOptions = 0;
_hadLoaded = false;
_done= false;
}
virtual void run()
{
while(true)
{
_mutex.lock();
if(_done) break;
if(!_hadLoaded)
{
_loadedModel =
osgDB::readNodeFile(_fileName,_loadOptions.get());
_hadLoaded = true;
}
_mutex.unlock();
OpenThreads::Thread::YieldCurrentThread();
}
}
void setParam(const std::string filename,const
osgDB::ReaderWriter::Options* options )
{
_mutex.lock();
_fileName = filename;
_loadOptions =
options?static_castosgDB::ReaderWriter::Options*(options-clone(osg::CopyOp::SHALLOW_COPY)):new
osgDB::ReaderWriter::Options;
_hadLoaded = false;
_mutex.unlock();
}
osg::Node* getLoadedModel()
{
osg::Node* node=0;
_mutex.lock();
if(_hadLoaded)
node = _loadedModel.get();
std::coutloadfinished_fileNamestd::endl;
_mutex.unlock();
return node;
}
void setDone(bool done)
{
_mutex.lock();
_done = true;
_mutex.unlock();
}
protected:
~ReadNodeFileThread(void){
}
osg::ref_ptrosg::Node
_loadedModel;
std::string
_fileName;
osg::ref_ptrosgDB::ReaderWriter::Options _loadOptions;
bool
_hadLoaded;
bool
_done;
OpenThreads::Mutex
_mutex;
};
Lilinx 2007
09 24
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users osgviewerQT
David/Robert, i am on mac. must be a mac issue. i have the same problem with the MDI demo that someone else on the list had posted. best jim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBO
Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] may be some bug in dds plugin
hi,all I use osgconv.exe convert some models to ive format. The images are compressed to dds format and include in the ivefile. I then vistor the ive file and write some images in dds format to the hard disk.I found that 64*64 pixels image cannot display with osgviewer --image xxx.dds any more. The other size is ok. This dds file can open by photoshop with nivida plugin for Photoshop. if we edit it in photoshop and save to a new one(eg, yyy.dds). we can view this use osgviewer --image yyy.dds. Lilinx ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] may be some bug in dds plugin
Hi Lilinx, There have been recently bug fixes to the dds plugin, I cannot say if they will have any affect on the problem you see, but there is a good chance that it will. Could you try the SVN version of the OSG? Robert On 9/24/07, Lilinx [EMAIL PROTECTED] wrote: hi,all I use osgconv.exe convert some models to ive format. The images are compressed to dds format and include in the ivefile. I then vistor the ive file and write some images in dds format to the hard disk.I found that 64*64 pixels image cannot display with osgviewer --image xxx.dds any more. The other size is ok. This dds file can open by photoshop with nivida plugin for Photoshop. if we edit it in photoshop and save to a new one(eg, yyy.dds). we can view this use osgviewer --image yyy.dds. Lilinx ___ 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] Please test SVN version of OpenSceneGraph
Compile fine on gentoo dual core 2 Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1) build fine, not really tested Adam Coates wrote: I started out with a recent SVN copy of 2.1.11; just updated it (got rev. 7640 of OpenThreads, and I think that was it...) Builds fine... AC On 9/24/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi All, I'm preparing to tag the 2.1.12 dev release. Could users svn users do and update and let me know how the build looks so I can fix any build issues before tagging. Thanks, 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 -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] may be some bug in dds plugin
hi,Robert Osfield I test the svn version of osg. The 64*64 dds image writing problem was not modified. The attach is the image write by osgDB::writeImageFile and compressed by winrar. lilinx 2009 09 24 C__003.rar 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] FBO
OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN version of OpenSceneGraph
Hi Guys, I have just made a bug fix to OpenThreads that I've tested and it compiles fine under pthreads, but as the bug will have existed in win32 and sproc I have rolled the same fix into these implementations as well, but since I dont' have these platforms to test I may have broken the build... So could use do another svn update just to be doubly sure that its working fine. The bug fix relates to destruction of threads that have just been started, a mutex is now used to marshal the start thread and thread destruction so they don't overlap. Thanks for you patience and help, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Hi Adam,
I have recreated the crash, and have applied a fix to
OpenThreads::Thread to resolve it. The fix involved added a Mutex to
Thread which is used to prevent the startThread and destructor running
in parallel. This certainly resolves the crash under Linux for my
tests. I have rolled exactly the same changes into the Win32 and
Sproc code too as these will have exhibited exactly the same problem.
Could you do a svn update and let me know how you get on.
Cheers,
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
I've attached the version I'm using that demonstrates the unusability
of the isRunning() flag.
The code pasted into the last e-mail is all that's necessary to
illustrate the crash, though it doesn't try to avoid it using the
'isRunning' flag. You shouldn't need to modify the OpenThreads
library.
I get the following error after running the attached code:
pure virtual method called
terminate called without an active exception
Aborted
presumably because thread-run() is being called on an object that has
been trashed.
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
Could you send the exact code that you can recreate the issue with.
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Ah - just double-checked. It'll crash just fine without adding the
usleep() to OpenThreads; I had my builds mixed up.
AC
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%) OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread
destructor
while the thread is running (even though I'm pretty sure they
intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the
thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up
flag
and the isRunning flag are false. One of these will have to be true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround and
submit it to you? Alternatively, I can just point out the break to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
Re: [osg-users] FBO
Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] more on Windows debugging
Has anyone had to do anything tricky to see OSG source code while debugging their application? I've been able to compile OSG debug, and to put the .pdb files where Visual Studio can see them. If I stop in my code, I can see OSG symbols on the stack trace. But I can't see the source code. I've added the directories I need to a list of debug source locations. Does anyone else know how I should be able to see into the OSG source in Visual Studio? thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThread leak ?
I have a leak but i don't know if it's justified or if it's a known issue, i googled a little on internet, and i did not find anything. So i ask on the mailing before searching deeper. For information i call the cancel method at the end of my program. ==18164== 152 bytes in 1 blocks are definitely lost in loss record 3 of 4 ==18164==at 0x4020848: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==18164==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so) ==18164==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so) ==18164==by 0x4F88A98: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so) ==18164==by 0x4D4A704: OpenThreads::Thread::start() (PThread.c++:624) ==18164==by 0x4D4A74A: OpenThreads::Thread::startThread() (PThread.c++:642) ==18164==by 0x8068C42: markneting::MarkNeting::update() (MarkNeting.cpp:219) ==18164==by 0x8057E39: markneting::MyFixturetest_updateHelper::RunTest(UnitTest::TestResults) (test-MarkNeting.cpp:137) ==18164==by 0x80588DE: markneting::TestMyFixturetest_update::RunImpl(UnitTest::TestResults) const (test-MarkNeting.cpp:124) ==18164==by 0x4D50FA3: UnitTest::Test::Run(UnitTest::TestResults) const (in /usr/lib/libunittest++.so.0.0.0) ==18164==by 0x4: ??? ==18164==by 0x4F7EFF3: (within /lib/libc-2.5.so) I try with an osg example (osgtext), and it seems to have the same leak ==18217== 152 bytes in 1 blocks are possibly lost in loss record 20 of 33 ==18217==at 0x4020848: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==18217==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so) ==18217==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so) ==18217==by 0x450FA98: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so) ==18217==by 0x402834E: OpenThreads::Thread::start() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6) ==18217==by 0x402839C: OpenThreads::Thread::startThread() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6) ==18217==by 0x448D065: osgViewer::Viewer::startThreading() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9) ==18217==by 0x448FED6: osgViewer::Viewer::setUpThreading() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9) maybe it's just a valgrind mistake :) if someone has more informations -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HDR 32bit
Hello, actually, your 6800 shouldn't be able to do linear interpolation on 32 bit floats textures... I think the cards from the GeForce 8 series were the first to do interpolation on 32 bit floats. If you're doing screen-sized hdr you won't need interpolation anyway. Have you got an up-to-date driver? Regards, Joachim I'm using a GeForce 6800, and I used a linear interpolation.. but I have tried with a nearest interpolation and the result is the same :s -- Joachim E. Vollrath University of Stuttgart Institute for Visualization and Interactive Systems (VIS) web: http://www.vis.uni-stuttgart.de/~vollrajm/ mail: [EMAIL PROTECTED] phone: 49.711.7816.403 fax: 49.711.7816.340 german postal address: Dipl. Inf. Joachim E. Vollrath Universitaet Stuttgart, Institutsverbund Informatik Institut fuer Visualisierung und Interaktive Systeme Universitaetstrasse 38 70569 Stuttgart GERMANY ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more on Windows debugging
I'm getting the right dll files, and the right .pdb files. Do the .pdb files specify the location of the source? Relative to what? I'm getting the dlls from one place (I copied them there), but am getting the pdb files and trying to get the source from another spot. Is there an issue where all these things need to be in the right locations relative to each other? I'm stopping in a callback and asking the stack trace for higher levels, which I think should do the same as what you suggest. It just tells me it can't find source, and doesn't ask for a location. I'll try what you suggest about trying to step into OSG, though I think it'll be the same. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Sent: Monday, September 24, 2007 11:10 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Usually, VS will prompt you for a file location if it cannot find a file. It sounds like your DLLs are being loaded from the correct place, but just in case, make certain that the DLLs you just recently built match the ones that are being loaded. It's been my experience that PDB files can be very picky (frustatingly so, sometimes). Check your output window for the DLL names. Also, set a breakpoint on some code that calls an OSG function. Step into that code and see what happens. The IDE should prompt you for a source filename if it cannot determine where it is. That's all that I can think of at the moment. Hope it helps, Brian On Mon Sep 24 10:39 , 'Andy Skinner' [EMAIL PROTECTED] sent: Has anyone had to do anything tricky to see OSG source code while debugging their application? I've been able to compile OSG debug, and to put the .pdb files where Visual Studio can see them. If I stop in my code, I can see OSG symbols on the stack trace. But I can't see the source code. I've added the directories I need to a list of debug source locations. Does anyone else know how I should be able to see into the OSG source in Visual Studio? thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HDR 32bit
What do you mean with screen-sized hdr? If I have the same resolution? I have a fixed resolution if it is the question... :s thanks for your answer 2007/9/24, Joachim E. Vollrath [EMAIL PROTECTED]: Hello, actually, your 6800 shouldn't be able to do linear interpolation on 32 bit floats textures... I think the cards from the GeForce 8 series were the first to do interpolation on 32 bit floats. If you're doing screen-sized hdr you won't need interpolation anyway. Have you got an up-to-date driver? Regards, Joachim I'm using a GeForce 6800, and I used a linear interpolation.. but I have tried with a nearest interpolation and the result is the same :s -- Joachim E. Vollrath University of Stuttgart Institute for Visualization and Interactive Systems (VIS) web: http://www.vis.uni-stuttgart.de/~vollrajm/ mail: [EMAIL PROTECTED] phone: 49.711.7816.403 fax: 49.711.7816.340 german postal address: Dipl. Inf. Joachim E. Vollrath Universitaet Stuttgart, Institutsverbund Informatik Institut fuer Visualisierung und Interaktive Systeme Universitaetstrasse 38 70569 Stuttgart GERMANY ___ 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] ive format and includeImageFileInIVEFile doesitlosereferences to same image?
I still don't understand how a 2.3Mb (uncompressed) dae file plus 0.3Mb of jpeg data ends up as a 20Mbyte ive file! Hello Don't know how you're going about getting it in to .ive, but doing artwork in 3dsMax and exporting using osgexp I can give some information you might find useful. In the exporter plugin for 3dsMax you must check a box called 'share duplicate states'. This cause duplicate materials to simply reference another objects material state (also can be other states). In and exported .osg file with this box checked (can't open .ive to check) In two objects using the same material the first object holds the material's properties, with the material having a unique ID say Material Unique ID = 4 state properties. The second object when you get to its Material State will simply read Material use unique ID 4, and that's all. You could also have to of the same objects were the geometry can be given a unique ID which can be referenced by the second. Have found as you say .ive files getting huge when embedding textures if this box is unchecked. Checking an .osg file with box unchecked file each object gets a full set of material properties including its textures. Guess would be that in the .ive your putting out as the exporter comes to a material listed, if not having the 'use unique id' it will simply embed any material listed even if used previously. So if you have a forest of 5000 trees all using the same texture, that texture will be embedded 5000 times. Hope that is of some use. Mr. D ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN version of OpenSceneGraph
Thanks for the feedback, ScopedLock now added and checked in. On 9/24/07, Andy Skinner [EMAIL PROTECTED] wrote: SVN built fine for me on our picky solaris build, but I had the same windows problem that J-S did. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 24, 2007 10:39 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Please test SVN version of OpenSceneGraph Hello Robert, I have just made a bug fix to OpenThreads that I've tested and it compiles fine under pthreads, but as the bug will have existed in win32 and sproc I have rolled the same fix into these implementations as well, but since I dont' have these platforms to test I may have broken the build... So could use do another svn update just to be doubly sure that its working fine. You need to add #include OpenThreads/ScopedLock to the top somewhere... I added it just above #include Win32ThreadPrivateData.h since that seems to be the order in the other OpenThreads source files. After that it builds. Not tested yet. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users 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.1.12 dev version released
Hi All,
I've just tagged the weekly dev release. Links as usual can be found
on the DeveloperReleases page:
http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases
* OpenSceneGraph-2.1.12, released on 24th September 2007. Main
changes this week were the addition of basic viewer configuration file
support, and new ParallelSplitShadowMap algorithm added to osgShadow.
Other changes include general build and big fixes.
source package : OpenSceneGraph-2.1.12.zip
svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.1.12
OpenSceneGraph
--
A quick note on the viewer configuration file support
--
What is checked in is just the beginning of full viewer configuration
file support - you can only load basic configurations right now, but
the ability of being able to save and load complex viewer setup will
be possible. The viewer configuration file support is also extensible
so you can just provide your own plugin like any normal OSG plugin, to
enable you to produce custom configuration support.
The configuration file support just checked in extends the standard
.osg ascii format to support Viewer/View::setUpView*() methods. Being
.osg we'll be able to actual do stuff like load models and embed them
in the viewer configuration, think distortion correction meshes etc.
:-)
To see what is possible right now have do a svn update on the
OpenSceneGraph-Data, or you can browse directly at:
http://www.openscenegraph.org/svn/osg/OpenSceneGraph-Data/trunk/Configuration/
To load just do:
osgviewer cow.osg -c OpenSceneGraph-Data/Configuration/SmallWindow.view
And SmallWindow.view right now simply looks like:
osgViewer::Viewer
{
setUpViewInWindow 100 200 600 400 0
}
You can also set up the OSG_CONFIG_FILE env var to point to a viewer
configuration file to automatically get osgviewer and other examples
to run.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Yup - builds fine, and it resolved the crash in my system as well.
Thanks for taking care of it!!
AC
On 9/24/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
I have recreated the crash, and have applied a fix to
OpenThreads::Thread to resolve it. The fix involved added a Mutex to
Thread which is used to prevent the startThread and destructor running
in parallel. This certainly resolves the crash under Linux for my
tests. I have rolled exactly the same changes into the Win32 and
Sproc code too as these will have exhibited exactly the same problem.
Could you do a svn update and let me know how you get on.
Cheers,
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
I've attached the version I'm using that demonstrates the unusability
of the isRunning() flag.
The code pasted into the last e-mail is all that's necessary to
illustrate the crash, though it doesn't try to avoid it using the
'isRunning' flag. You shouldn't need to modify the OpenThreads
library.
I get the following error after running the attached code:
pure virtual method called
terminate called without an active exception
Aborted
presumably because thread-run() is being called on an object that has
been trashed.
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
Could you send the exact code that you can recreate the issue with.
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Ah - just double-checked. It'll crash just fine without adding the
usleep() to OpenThreads; I had my builds mixed up.
AC
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%)
OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread
destructor
while the thread is running (even though I'm pretty sure they
intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the
thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up
flag
and the isRunning flag are false. One of these will have to be
true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround
and
submit it to you? Alternatively, I can just point out the break
to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up
we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] OpenThread leak ?
I'm not sure if this is the source but it's a possible issue anyway: Neither detach() nor join() are called on the thread, and it looks like threads are created in the joinable state. The thread package has to allocate some resources to the thread that are not automatically cleaned up when the thread exits (e.g., a place to hold its return value until another thread joins it). The thread's owner should probably call join() to wait for the thread to finish, or detach() to specify that the library is allowed to free this data. AC On 9/24/07, Cedric Pinson [EMAIL PROTECTED] wrote: I have a leak but i don't know if it's justified or if it's a known issue, i googled a little on internet, and i did not find anything. So i ask on the mailing before searching deeper. For information i call the cancel method at the end of my program. ==18164== 152 bytes in 1 blocks are definitely lost in loss record 3 of 4 ==18164==at 0x4020848: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==18164==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so) ==18164==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so) ==18164==by 0x4F88A98: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so) ==18164==by 0x4D4A704: OpenThreads::Thread::start() (PThread.c++:624) ==18164==by 0x4D4A74A: OpenThreads::Thread::startThread() (PThread.c++:642) ==18164==by 0x8068C42: markneting::MarkNeting::update() (MarkNeting.cpp:219) ==18164==by 0x8057E39: markneting::MyFixturetest_updateHelper::RunTest(UnitTest::TestResults) (test-MarkNeting.cpp:137) ==18164==by 0x80588DE: markneting::TestMyFixturetest_update::RunImpl(UnitTest::TestResults) const (test-MarkNeting.cpp:124) ==18164==by 0x4D50FA3: UnitTest::Test::Run(UnitTest::TestResults) const (in /usr/lib/libunittest++.so.0.0.0) ==18164==by 0x4: ??? ==18164==by 0x4F7EFF3: (within /lib/libc-2.5.so) I try with an osg example (osgtext), and it seems to have the same leak ==18217== 152 bytes in 1 blocks are possibly lost in loss record 20 of 33 ==18217==at 0x4020848: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==18217==by 0x4010568: allocate_dtv (in /lib/ld-2.5.so) ==18217==by 0x401060D: _dl_allocate_tls (in /lib/ld-2.5.so) ==18217==by 0x450FA98: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so) ==18217==by 0x402834E: OpenThreads::Thread::start() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6) ==18217==by 0x402839C: OpenThreads::Thread::startThread() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libOpenThreads.so.1.9.6) ==18217==by 0x448D065: osgViewer::Viewer::startThreading() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9) ==18217==by 0x448FED6: osgViewer::Viewer::setUpThreading() (in /home/mornifle/dev/tmp/osg-svn/OpenSceneGraph/lib/libosgViewer.so.2.1.9) maybe it's just a valgrind mistake :) if someone has more informations -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Hey, Robert, It looks like there's still a problem with the current setup. The Thread object itself can get deleted before the pthread actually gets to the lock (which, I guess is what you just added). While it looks like this doesn't cause a crash, the problem is evidenced by valgrind (reports uninitalized memory reads/writes to the lock -- which got freed by the Thread destructor). You seem like you're pretty busy, so if you want, I can take a crack at this -- I think the Thread code is simple enough, but I'll need to think a bit to figure out how to get around this. One (simple) solution is to just join() the thread from the ~Thread() destructor. Cheers, Adam ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PrimitiveSet lighting issues
Thank you Jean, I'm still new to all this. All I found on emissive color is the following: glMaterial Default Parameters GL_EMISSION (0.0, 0.0, 0.0, 1.0) emissive color of material Is this what you had in mind: osg::StateSet* state = geode-getOrCreateStateSet(); state -setMode(GL_COLOR_MATERIAL,osg::StateAttribute::ON); osg::ref_ptrosg::Material mat = new osg::Material; mat-setColorMode(osg::Material::EMISSION); state-setAttribute(mat.get() Thanks again -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 24, 2007 11:52 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] PrimitiveSet lighting issues Hello Nelson, I'm drawing osg::PrimitiveSet::LINES deep inside my node architecture. The lines come up the right color, but depending on the camera position, the line tends to turn black. I would like the line color to stay constant regardless of the camera position. If you want a constant color and no shading at all, you can just use the emissive color in the object's material. It is independent of view and lighting conditions. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users osgviewerQT
David,
I have an intel mac powerbook. i built using qmake. i created this
pro file:
--
TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += .
# Input
SOURCES += osgviewerQT.cpp
QT += opengl
DEFINES = USE_QT4
mac {
LIBS = -framework OpenThreads -framework osg -framework osgDB \
-framework osgGA -framework osgViewer -framework osgUtil \
-framework osgText
}
--
then i did
qmake -spec macx-xcode osgviewerQT.pro
this creates an xcode project which i then build and ran.
the window comes up with the model in it. from debugger i know that
QT events are happening and being passed to OSG's GraphicsWindow
The timer is firing and updategl is being called which calls the
paint method, which calls frame(). However nothing is changing in
the display. its like its ignoring the mouse, or the frame() call is
doing nothing. So perhaps the events are not being passed properly?
i notice that there is a graphicswindowcarbon in the osg source,
but no example seems to use it. should it be perhaps used to get
proper events to OSG?
thanks jim
2007/9/24, James E. Hopper james.e.hopper at gmail.com:
David/Robert,
i am on mac. must be a mac issue.
probably.
Other mac-user, have you the same problem?
i have the same problem with the
MDI demo that someone else on the list had posted.
MDI demo work well for me.
Which Qt4 version are you used ?
Can you give more info on you plateform ?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PrimitiveSet lighting issues
Hello Nelson, I'm still new to all this. All I found on emissive color is the following: glMaterial Default Parameters GL_EMISSION (0.0, 0.0, 0.0, 1.0) emissive color of material The OpenSceneGraph is a rather thin wrapper of OpenGL, so in most cases the OpenGL documentation will be useful to make sense out of what OSG does. In most cases, if you see a method name in OSG's doxygen reference, you can search for similar names in OpenGL and you will find out what it does. In this case, Chapter 5 - Lighting from the red book will be useful. http://www.glprogramming.com/red/chapter05.html At around 1/6th of the page, you will see: In addition to ambient, diffuse, and specular colors, materials have an emissive color, which simulates light originating from an object. In the OpenGL lighting model, the emissive color of a surface adds intensity to the object, but is unaffected by any light sources. Also, the emissive color does not introduce any additional light into the overall scene. To understand what the emissive color will give as a result, see around 5/6th of the page, where you will find the general lighting equation OpenGL uses: The color produced by lighting a vertex is computed as follows: vertex color = the material emission at that vertex + the global ambient light scaled by the material's ambient property at that vertex + the ambient, diffuse, and specular contributions from all the light sources, properly attenuated So if you just want your color independently of any lighting, you should set your color as the material's emissive color, and disable all other lighting in the scene (or at least for those nodes in the scene graph). Is this what you had in mind: osg::StateSet* state = geode-getOrCreateStateSet(); state -setMode(GL_COLOR_MATERIAL,osg::StateAttribute::ON); osg::ref_ptrosg::Material mat = new osg::Material; mat-setColorMode(osg::Material::EMISSION); state-setAttribute(mat.get() The problem there is that you don't set the emissive color. I think this should work, but untested... : osg::StateSet* state = geode-getOrCreateStateSet(); osg::ref_ptrosg::Material mat = new osg::Material; mat-setEmission(osg::Material::FRONT_AND_BACK, osg::Vec4(1.0, 1.0, 1.0, 1.0);// Set the color to whatever you want state-setMode(GL_LIGHTING, osg::StateAttribute::OFF); state-setAttribute(mat.get()); But you were definitely on the right track. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO
Hi Robert, in my application I have the scene graph in some variable, and a camera in another variable, then I attach it to viewer, in multi-document window. After I close the window, the scene graph the camera are still alive. The next time I want to attach them to a new window I get OpenGL error that the frame buffer object is not complete (and nothing is drawn), so I wanted to force the renderstage to re-create it, and achieved this by setting the rendering cache of the existing camera to NULL. I just wanted to know if there is another and better way to deal with this problem, and also if you know why the FBO was defected after the window was closed. thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 3:04 PM Subject: Re: [osg-users] FBO Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PrimitiveSet lighting issues
Henri, did you try JUST turning off the light for those lines? what you wrote about the color-material seems ok, it means that in the pipeline OpenGL will take the glColor value and use it as the emission in it's light equations. But if you turn off the light, the pipeline use glColor. so it's pretty much equivalent. just turning off the light have many benfits though: 1. it's faster to implement. 2. run time is better. 3. you can set diferrent color at each vertex, while using the material will set the same emission value to the whole line (or line strip, depends on your geometry). - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 2:12 AM Subject: Re: [osg-users] PrimitiveSet lighting issues Hello Nelson, I'm still new to all this. All I found on emissive color is the following: glMaterial Default Parameters GL_EMISSION (0.0, 0.0, 0.0, 1.0) emissive color of material The OpenSceneGraph is a rather thin wrapper of OpenGL, so in most cases the OpenGL documentation will be useful to make sense out of what OSG does. In most cases, if you see a method name in OSG's doxygen reference, you can search for similar names in OpenGL and you will find out what it does. In this case, Chapter 5 - Lighting from the red book will be useful. http://www.glprogramming.com/red/chapter05.html At around 1/6th of the page, you will see: In addition to ambient, diffuse, and specular colors, materials have an emissive color, which simulates light originating from an object. In the OpenGL lighting model, the emissive color of a surface adds intensity to the object, but is unaffected by any light sources. Also, the emissive color does not introduce any additional light into the overall scene. To understand what the emissive color will give as a result, see around 5/6th of the page, where you will find the general lighting equation OpenGL uses: The color produced by lighting a vertex is computed as follows: vertex color = the material emission at that vertex + the global ambient light scaled by the material's ambient property at that vertex + the ambient, diffuse, and specular contributions from all the light sources, properly attenuated So if you just want your color independently of any lighting, you should set your color as the material's emissive color, and disable all other lighting in the scene (or at least for those nodes in the scene graph). Is this what you had in mind: osg::StateSet* state = geode-getOrCreateStateSet(); state -setMode(GL_COLOR_MATERIAL,osg::StateAttribute::ON); osg::ref_ptrosg::Material mat = new osg::Material; mat-setColorMode(osg::Material::EMISSION); state-setAttribute(mat.get() The problem there is that you don't set the emissive color. I think this should work, but untested... : osg::StateSet* state = geode-getOrCreateStateSet(); osg::ref_ptrosg::Material mat = new osg::Material; mat-setEmission(osg::Material::FRONT_AND_BACK, osg::Vec4(1.0, 1.0, 1.0, 1.0);// Set the color to whatever you want state-setMode(GL_LIGHTING, osg::StateAttribute::OFF); state-setAttribute(mat.get()); But you were definitely on the right track. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
