Re: [osg-users] Downloading Binaries
Hi Christopher, On Mon, Jun 8, 2009 at 2:42 AM, Christopher Wangcwang7...@hotmail.com wrote: Hi, Sorry, its the binaries from this page. http://www.openscenegraph.org/projects/osg/wiki/Downloads I thought these are for cygwin - •i386 Linux packages built under Ubuntu 9.04, note, these are just simple tar.gz, which will need to be installed by hand, rather than debian .deb files. and these are for windows - •Windows Visual Studio 9 packages The i386 Linux packages are for linux, not cygwin. Have a look at http://www.openscenegraph.org/projects/osg/wiki/Community/PackageMaintainers for a list of package maintainers on different platforms. Noone has listed to build cygwin packages yet so for cygwin you will need to build it yourself. Building is generally an easy task and you will get plenty of example code to study. cheers Mattias ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13659#13659 ___ 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] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive opened by
osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not allowed to
give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe: Microsoft C++
exception: std::bad_alloc at memory location 0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x) Line 43 + 0xc
bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytesC++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764 + 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode geode={...})
Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor nv={...}) Line 39
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line 38
+ 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...}) Line
191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Re: [osg-users] CPU usage
Hi, Jean-Sébastien Guay wrote: Hi all, I doubt that's the case if he's just running cow.osg. More likely, VSync is not being properly detected on the ATI system, so the viewer is just running free and not waiting for the frame to be drawn on the screen. I think Jason's guess is right on the money. Check your frame rates, you'll probably see that the nvidia system is running at a steady 60/75 (whatever your refresh rate is) while the ATI system is going at several hundred frames per second (500 or more, most likely). V-sync and frame rate was the first thing I checked. I measured the frame rate on both systems using Fraps. The frame rate is at a constant 60 FPS on the ATI system and 75 FPS on the nVidia system. The different frame rates might be due to using different monitors. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
Update : this sound like a memory problem : when my MV is around 2.0Go, the
application crash. I'm not familiar with windows virtual Memory, so i'm not
sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same ...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without texture)
is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive opened by
osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not allowed to
give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe: Microsoft C++
exception: std::bad_alloc at memory location 0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x) Line 43 + 0xc
bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytesC++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764 + 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode geode={...})
Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor nv={...}) Line
39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node node={...})
Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...}) Line
72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group node={...}) Line
86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...}) Line
38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor nv={...}) Line
62 + 0x25 bytesC++
Re: [osg-users] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
hi Vincent,
Win32 has a 2GB limit on virtual adress space for any single process.
Microsoft decided for some reason to half down the available 4GB adress
space in 32 Bit.
There's some obscure workaround to up this limit to ~3GB, but it is only
working on some of the MS operationg systems. See the discussion on
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Better way now is to use a 64 Bit environment and a 64 bit build.
regards Ralph
Vincent Bourdier schrieb:
Update : this sound like a memory problem : when my MV is around 2.0Go,
the application crash. I'm not familiar with windows virtual Memory, so
i'm not sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same ...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without
texture) is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier
vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive opened
by osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not
allowed to give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe:
Microsoft C++ exception: std::bad_alloc at memory location 0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x) Line 43 +
0xc bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytesC++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764 + 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode
geode={...}) Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor nv={...})
Line 39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytes
Re: [osg-users] Texture coords
Hi Joseba; You should try to use GLSL to accomplish dynamic texture coordinate changing in pretty straightforward way. Regards. 2009/6/8 Joseba Rodriguez jrodrig...@landersimulation.com Hi, Im trying to do some texture animations in different objects (billboards). For this purpose im using Geometry::setTexCoordArray(unsigned int unit,Array*) in a Update callback. I found out that using this function is quite expensive, making my app slow down from 120 fps to 40 fps with 2000 billboards (quads). Is there any other cheaper way to dinamically change the texture coords? Thank you! Cheers, Joseba -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13668#13668 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
Hi Ralf,
I'm already using the /3GB option, that's why I don't understand the crash
...
Thanks.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
hi Vincent,
Win32 has a 2GB limit on virtual adress space for any single process.
Microsoft decided for some reason to half down the available 4GB adress
space in 32 Bit.
There's some obscure workaround to up this limit to ~3GB, but it is only
working on some of the MS operationg systems. See the discussion on
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Better way now is to use a 64 Bit environment and a 64 bit build.
regards Ralph
Vincent Bourdier schrieb:
Update : this sound like a memory problem : when my MV is around 2.0Go,
the application crash. I'm not familiar with windows virtual Memory, so
i'm not sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same ...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without
texture) is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier
vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive opened
by osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not
allowed to give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe:
Microsoft C++ exception: std::bad_alloc at memory location
0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x) Line 43 +
0xc bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytesC++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764 + 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode
geode={...}) Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor nv={...})
Line 39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41 bytesC++
Re: [osg-users] build errors with 2.8.1
Hi Jason, Your rant shows you didn't grasp the point of my earlier email. A couple of point that must be made clear. All support costs me time and therefore income - I don't get to charge anyone for the time it takes me to do public support, I don't get to charge anyone for making point releases, dev releases, release candidates. All the time I spend on general support like this is time I can't spend on paid work. Have a think about your salary per week, and then give away a half of this for this for support of other people, if you can do this then you'd be in stronger position to go about ranting at me not being grateful. Support for niche tools like out of date versions of CMake *directly* costs me time and money. Please remember that CMake 2.4.6 was the reference version that we used when we ported to CMake two and half years ago, so 2.4.5 was out of date even then. It's very much a luxury that we are able to support Cmake 2.4.5 at all. The case of CMake 2.4.5 is just one small example of the different build tool combinations we have to deal with, the more niche each of the tools is the less exposure it'll have from others testing against it, this in turn means that those who want the luxury of these niche tools absolutely have to engage much more pro-atively with testing. It's very much a case of use or or loose it. And it's good enough to start testing after the horse has bolted - i.e. after a stable release goes out, as the process of making stable release is very expensive in time and money for me and the rest of the community. Delaying a release by a day to get something right only costs me a days in salary, having to make another release costs me several weeks - it's not just a little bit more, it's an order of magnitude more expensive. Robert. On Sun, Jun 7, 2009 at 8:40 AM, Jason Dalyjd...@ist.ucf.edu wrote: Oh, boy. Where to begin. First of all, I don't have a clue how this discussion got out of hand. We started out with a simple issue that showed up on a CentOS box. It couldn't compile the recently released OSG 2.8.1 version. The issue came down to the fact that CentOS and Red Hat Enterprise Linux only have a 2.4.5 binary version available. There was friction between the community that said to just upgrade to 2.6, and the CentOS users and administrators that tried to explain that it is difficult to do that in a large enterprise environment. I jumped into this thread to try and help both parties understand the needs of the other. Instead of a calm resolution, I've now been subjected to a rant from the OSG czar who says I need to contribute more. Responses inline below: Robert Osfield wrote: The loss in perspective is that the illusion that RHEL/CentOS and all the other long term supported linux distributions can bundle not only the core operating systems but ten's of thousands of other open source tools as one single supported and consistent entity. No other operating system vendors attempt to do this - they just ship the operating systems and the all the rest of the tools are provided by extra separate entitities and typically provided by 3rd parties. Some of these third party apps might rev at the same rate as the underlying OS, but typically don't. I find it odd that someone who uses and advocates Linux as much as you would question the practice of bundling the OS and applications and supporting them. It's not just Red Hat and CentOS that do this. Pretty much every Linux distribution does it. In the case of the Enterprise distros, the support comes from paid contracts which help with security fixes, and addressing any critical problems that arise. In the case of the free distributions, the support comes from the community. In reality there's not much difference in software between Red Hat Enterprise and Fedora. RHEL 5 matches up almost exactly with Fedora 6, for example. The difference is in the frequency of releases, the continuous support with minor bug and security fixes (often back-ported from upstream revisions), and the ability to centrally manage updates of client systems (when new updates come out, you just log on to a web site and press Go, and all of your workstations are magically updated). Now it's very cool that linux distributions do attempt this almost impossible feat, but and it is humongous but there are problems with this approach of bundling practically everything together and rev's at the same rate is that in the 3rd party vendors can't be expected to pay for the support for this locked in versions of their software for the benefit of the linux distribution vendors. Of course not. The customers pay the distribution provider for that support. In turn, the distribution's own developers and engineers work with each 3rd party provider to integrate those packages into the distribution successfully. OSG is not part of RHEL, which is probably why you haven't heard from any of them. I'm
Re: [osg-users] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
Hi Vincent,
the problem with the /3GB option is that you also have to setup the
/LARGEADRESSAWARE linker flag and check pointer arithmetics in every
exe/dll of your app. There are some possible pitfalls on pointer
arithmetic because ptrdiff_t is signed 32 bit on Win32.
regards Ralph
Vincent Bourdier schrieb:
Hi Ralf,
I'm already using the /3GB option, that's why I don't understand the
crash ...
Thanks.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
mailto:usene...@rk-se.de
hi Vincent,
Win32 has a 2GB limit on virtual adress space for any single process.
Microsoft decided for some reason to half down the available 4GB adress
space in 32 Bit.
There's some obscure workaround to up this limit to ~3GB, but it is only
working on some of the MS operationg systems. See the discussion on
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Better way now is to use a 64 Bit environment and a 64 bit build.
regards Ralph
Vincent Bourdier schrieb:
Update : this sound like a memory problem : when my MV is around
2.0Go,
the application crash. I'm not familiar with windows virtual
Memory, so
i'm not sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new
barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same ...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without
texture) is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier
vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive
opened
by osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not
allowed to give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe:
Microsoft C++ exception: std::bad_alloc at memory location
0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x)
Line 43 +
0xc bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytes
C++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124
C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764
+ 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode
geode={...}) Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor
nv={...})
Line 39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node
node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor
nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node
node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor
nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
Re: [osg-users] Texture coords
Hi Joseba, On 8/6/09 9:42 AM, Joseba Rodriguez wrote: Im trying to do some texture animations in different objects (billboards). For this purpose im using Geometry::setTexCoordArray(unsigned int unit,Array*) in a Update callback. I found out that using this function is quite expensive, making my app slow down from 120 fps to 40 fps with 2000 billboards (quads). Is there any other cheaper way to dinamically change the texture coords? First of all, you can change the texture coordinates in-place i.e. just modify the existing array. You may need to dirty() the geometry after that. Secondly, if you're using display lists (which is the default) the geometry has to be recompiled after every dirty() or setTexCoordArray() (which calls dirty internally). This can be a slow process. Try to disable display lists and see what difference that makes. Thirdly, depending on the animation you're doing you could also use the texture matrix. This works well for scaling, translation, rotation. Hope this helps, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture coords
HI Joseba, I can't see any way that people will be able to point your in the right direction without you being more specific what you are doing with your texture coordinates - for what purpose are you modifying them? Using shaders are typically the best solution for dynamic tex coords but is it appropriate in your case?? Who knows. Robert. On Mon, Jun 8, 2009 at 9:20 AM, Joseba Rodriguezjrodrig...@landersimulation.com wrote: Hi, Thanks for your reply. I didnt want to make a shader justo for this, but if i dont have any other alternative, ill try it. Thank you, Joseba -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13672#13672 ___ 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] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
Hi Ralf,
I'm making a new compil with the /3GB and the /LARGEADRESSAWARE flag ... but
do you think I have to compile osg with the same flag ? the crash is in
readNodefile ...
Thanks for your help.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
Hi Vincent,
the problem with the /3GB option is that you also have to setup the
/LARGEADRESSAWARE linker flag and check pointer arithmetics in every
exe/dll of your app. There are some possible pitfalls on pointer
arithmetic because ptrdiff_t is signed 32 bit on Win32.
regards Ralph
Vincent Bourdier schrieb:
Hi Ralf,
I'm already using the /3GB option, that's why I don't understand the
crash ...
Thanks.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
mailto:usene...@rk-se.de
hi Vincent,
Win32 has a 2GB limit on virtual adress space for any single process.
Microsoft decided for some reason to half down the available 4GB
adress
space in 32 Bit.
There's some obscure workaround to up this limit to ~3GB, but it is
only
working on some of the MS operationg systems. See the discussion on
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Better way now is to use a 64 Bit environment and a 64 bit build.
regards Ralph
Vincent Bourdier schrieb:
Update : this sound like a memory problem : when my MV is around
2.0Go,
the application crash. I'm not familiar with windows virtual
Memory, so
i'm not sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new
barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same ...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without
texture) is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier
vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive
opened
by osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm not
allowed to give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe:
Microsoft C++ exception: std::bad_alloc at memory location
0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x)
Line 43 +
0xc bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytes
C++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124
C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764
+ 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode
geode={...}) Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor
nv={...})
Line 39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node
node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor
nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node
node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...})
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Robert,
thank you for have interest for my previous post, I'll try the latest svn
version as soon as possible.
2009/5/21 Robert Osfield robert.osfi...@gmail.com
HI Alexandre,
I've now had a chance to have a look at the reproducing the problems
using your modified example and data. The problem was due to a
double scaling of the projection matrices due to the unusual
combination of having an active master and slave combination, and
while the usage case in not really what osgViewer was designed for
it's still a bug.
The solution to this bug was applying the inverse of the master's
rescaling to the slave's projection offset. I applied this solution
and tested against your modified osgwindows example and it now behaves
fine, with the two cameras staying in sync. This fix is now checked
into svn/trunk.
Robert.
On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric
alex.pix...@gmail.com wrote:
Hi osg-users,
I apparently found something strange when adding slave camera to osg
viewer
and resizing window.
I'm using osg SVN version
I made a quick sample code to show community the weird behaviour.
Quick explanation : My goal is to render an object made from 2 cubes
(same
size), one is opaque and the other one is transparent. The first main
camera
render only the opaque part, and the second camera (a slave one) render
the
transparent part. When resizing the window the projection matrix isn't
well
computed for the slave camera.
So the transparent cube isn't the same aspect as the opaque cube.
I think I found the bug in GraphicsContext.cpp file at :
if (slave camera-getReferenceFrame()==osg::Transform::RELATIVE_RF)
{
switch(view-getCamera()-getProjectionResizePolicy())
{
case(osg::Camera::HORIZONTAL):
slave-_projectionOffset
*= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
case(osg::Camera::VERTICAL): slave-_projectionOffset
*=
osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
default: break;
}
}
I do not understand why we only update the projectionOffset from the
slave
camera and why we don't update the projection matrix itself.
Hope you'll understand my problem ;-)
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
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] KD tree, OSG 2.6.1, OSG 2.81 and osgExp
\o/
That works ! it uses more than 2.4Gb of memory but it finish with the
KDTree.
Sorry for the panic, it not an OSG bug.
Thanks for your help Ralf and Robert.
Regards,
Vincent.
2009/6/8 Vincent Bourdier vincent.bourd...@gmail.com
Hi Ralf,
I'm making a new compil with the /3GB and the /LARGEADRESSAWARE flag ...
but do you think I have to compile osg with the same flag ? the crash is in
readNodefile ...
Thanks for your help.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
Hi Vincent,
the problem with the /3GB option is that you also have to setup the
/LARGEADRESSAWARE linker flag and check pointer arithmetics in every
exe/dll of your app. There are some possible pitfalls on pointer
arithmetic because ptrdiff_t is signed 32 bit on Win32.
regards Ralph
Vincent Bourdier schrieb:
Hi Ralf,
I'm already using the /3GB option, that's why I don't understand the
crash ...
Thanks.
Regards,
Vincent.
2009/6/8 Ralph Kern usene...@rk-se.de
mailto:usene...@rk-se.de
hi Vincent,
Win32 has a 2GB limit on virtual adress space for any single
process.
Microsoft decided for some reason to half down the available 4GB
adress
space in 32 Bit.
There's some obscure workaround to up this limit to ~3GB, but it is
only
working on some of the MS operationg systems. See the discussion on
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Better way now is to use a 64 Bit environment and a 64 bit build.
regards Ralph
Vincent Bourdier schrieb:
Update : this sound like a memory problem : when my MV is around
2.0Go,
the application crash. I'm not familiar with windows virtual
Memory, so
i'm not sure of how to increase it.
I've trid to set the pagefile to 5Go and the RAM (with a new
barett) to
4.0Go (3.2Go for win XP 32bits) but the crash is still the same
...
Any idea ?
Does the KDTree builder eats a lot of MV ? the .ive file (without
texture) is about 450Mo ... so this is a very big model ...
Thanks for help.
Regards,
Vincent.
2009/6/8 Vincent Bourdier
vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi Robert,
ok for KDTree, but the question is : Why an osg2.6.1 file.ive
opened
by osg2.8.1 using KDtree make a crash ?
Sorry I cannot give the file, this is confidential data I'm
not
allowed to give you.
Crash : Unhandled exception at 0x7c812afb in Launcherd.exe:
Microsoft C++ exception: std::bad_alloc at memory location
0x00d9ec28..
This is the stack trace :
kernel32.dll!7c812afb()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
kernel32.dll!7c812afb()
osg55-osgd.dll!std::_Allocateosg::KdTree::KdNode(unsigned int
_Count=144230, osg::KdTree::KdNode * __formal=0x)
Line 43 +
0xc bytesC++
osg55-osgd.dll!std::allocatorosg::KdTree::KdNode::allocate(unsigned
int _Count=144230) Line 145 + 0xb bytesC++
osg55-osgd.dll!std::vectorosg::KdTree::KdNode,std::allocatorosg::KdTree::KdNode
::reserve(unsigned int _Count=144230) Line 607 + 0xf bytes
C++
osg55-osgd.dll!BuildKdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 124
C++
osg55-osgd.dll!osg::KdTree::build(osg::KdTree::BuildOptions
options={...}, osg::Geometry * geometry=0x35097a68) Line 764
+ 0x10
bytesC++
osg55-osgd.dll!osg::KdTreeBuilder::apply(osg::Geode
geode={...}) Line 817 + 0x25 bytesC++
osg55-osgd.dll!osg::Geode::accept(osg::NodeVisitor
nv={...})
Line 39 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 191 + 0x1c bytesC++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Node
node={...})
Line 72C++
osg55-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 86 + 0x13 bytesC++
osg55-osgd.dll!osg::Group::accept(osg::NodeVisitor
nv={...})
Line 38 + 0x41 bytesC++
osg55-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 62 + 0x25 bytesC++
osg55-osgd.dll!osg::NodeVisitor::traverse(osg::Node
Re: [osg-users] Texture coords
Hi all, Sorry for not providing much information about the interest of changing text coords. Im working on animating avatar impostors for which im using a billboard with a texture (sprite) of an avatar. With OSG its easy to implement a special kind of billboard for managing sprite animations depending of the point of view of the camera, but using setTexCoordArray is slow (perhaps, as you pointed out, im using compiled lists). At this moment i prefer not to use GLSL, as im already using other shaders on the nodes, but this is a possibility if i find out that there is an efficient alternative. Thans for your help. J. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13682#13682 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Downloading Binaries
Hi, Mattias is right, building OSG in Cygwin is easy. I'm doing it nearly all days, so if you have any problem, feel free to ask on the list. Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture coords
Hello All: I am not sure but it seems you could create a single texture with different positions of the Avatar. For sprite animation you can setup a normalized 0..1 tex coordinate then set the Texture Matrix to turn that into a window within that texture to use. The texture matrix is very light weight to modify values over time and on-the-fly. I honestly don't have experience in Avatar animation so others on the list may have a much better solution than this. It just seems if you don't want to use shaders then adjusting a texture matrix to setup the current scale and translation into the texture would be a feasible solution. Take care Garrett Potts On Jun 8, 2009, at 6:07 AM, Joseba Rodriguez wrote: Hi all, Sorry for not providing much information about the interest of changing text coords. Im working on animating avatar impostors for which im using a billboard with a texture (sprite) of an avatar. With OSG its easy to implement a special kind of billboard for managing sprite animations depending of the point of view of the camera, but using setTexCoordArray is slow (perhaps, as you pointed out, im using compiled lists). At this moment i prefer not to use GLSL, as im already using other shaders on the nodes, but this is a possibility if i find out that there is an efficient alternative. Thans for your help. J. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13682#13682 ___ 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] Texture coords
Hello: Oops, just saw a post on this previously from Ulrich suggesting the use of a texture matrix. Sorry for the repeat. Take care Garrett Potts On Jun 8, 2009, at 7:51 AM, Garrett Potts wrote: Hello All: I am not sure but it seems you could create a single texture with different positions of the Avatar. For sprite animation you can setup a normalized 0..1 tex coordinate then set the Texture Matrix to turn that into a window within that texture to use. The texture matrix is very light weight to modify values over time and on-the- fly. I honestly don't have experience in Avatar animation so others on the list may have a much better solution than this. It just seems if you don't want to use shaders then adjusting a texture matrix to setup the current scale and translation into the texture would be a feasible solution. Take care Garrett Potts On Jun 8, 2009, at 6:07 AM, Joseba Rodriguez wrote: Hi all, Sorry for not providing much information about the interest of changing text coords. Im working on animating avatar impostors for which im using a billboard with a texture (sprite) of an avatar. With OSG its easy to implement a special kind of billboard for managing sprite animations depending of the point of view of the camera, but using setTexCoordArray is slow (perhaps, as you pointed out, im using compiled lists). At this moment i prefer not to use GLSL, as im already using other shaders on the nodes, but this is a possibility if i find out that there is an efficient alternative. Thans for your help. J. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13682#13682 ___ 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] CPU usage
Hi Robert, On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote: Does anybody see less than 100% CPU utilization when running osgviewer cow.osg on an ATI card? I had just been accepting that as normal. 100% CPU is not normal at all. Yikes! I think there must be something seriously wrong with my system then. I updated my video drivers to the latest this morning and enabled vsync. Enabling vsync sent my framerate from 1200 fps to 15 fps! Vsync on or off made no difference on the cpu load- I always have 100% utilization on one core. I have a FireGL V7700 with 512 MB of RAM. I'm running the 8.603 drivers on quad core XP Pro machine. My one-and-only monitor is a 24" Dell panel at 1920x1200. I turned vsync back off. With it on, my cow looked like it was being rotated by a stepper motor. If you or anybody else has troubleshooting suggestions, I would be very happy to hear them. Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
I had my cpu monitor open while running osgviewer. I just noticed that after closing the cpu monitor, my vsync'd framerate immediately jumped to 60 (the monitor native rate). So, it seems that Heisenberg has struck again. I can't measure the thing with out radically changing it. Or perhaps I'm just not using the right tools. Does anybody have any suggestions for decent Windows performance analysis tools? I was using SysInternal's ProcessExplorer. Cory Cory Riddell wrote: Hi Robert, On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote: Does anybody see less than 100% CPU utilization when running osgviewer cow.osg on an ATI card? I had just been accepting that as normal. 100% CPU is not normal at all. Yikes! I think there must be something seriously wrong with my system then. I updated my video drivers to the latest this morning and enabled vsync. Enabling vsync sent my framerate from 1200 fps to 15 fps! Vsync on or off made no difference on the cpu load- I always have 100% utilization on one core. I have a FireGL V7700 with 512 MB of RAM. I'm running the 8.603 drivers on quad core XP Pro machine. My one-and-only monitor is a 24" Dell panel at 1920x1200. I turned vsync back off. With it on, my cow looked like it was being rotated by a stepper motor. If you or anybody else has troubleshooting suggestions, I would be very happy to hear them. Cory ___ 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] CPU usage
On Mon, Jun 8, 2009 at 3:59 PM, Cory Riddellc...@codeware.com wrote: Hi Robert, On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote: Does anybody see less than 100% CPU utilization when running osgviewer cow.osg on an ATI card? I had just been accepting that as normal. 100% CPU is not normal at all. Yikes! I think there must be something seriously wrong with my system then. I updated my video drivers to the latest this morning and enabled vsync. Enabling vsync sent my framerate from 1200 fps to 15 fps! Vsync on or off made no difference on the cpu load- I always have 100% utilization on one core. I have a FireGL V7700 with 512 MB of RAM. I'm running the 8.603 drivers on quad core XP Pro machine. My one-and-only monitor is a 24 Dell panel at 1920x1200. I turned vsync back off. With it on, my cow looked like it was being rotated by a stepper motor. If you or anybody else has troubleshooting suggestions, I would be very happy to hear them. Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Cory, I don't know whether you tried (neither know whether it's even possible at all) to profile the code? This may give you some hints, if it works. Ismail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
Hi Cory, In general I'd recommend doing all benchmarking with a system as near to final delivery as possible, so no external tools, definitely no debug build, run with vsync on etc. The OSG itself has some performance stats that you can use, for instance osgviewer has the StatsHandler added to the viewer which you can enable with pressing 's' successively to get different levels of stats reporting. Robert. On Mon, Jun 8, 2009 at 3:10 PM, Cory Riddellc...@codeware.com wrote: I had my cpu monitor open while running osgviewer. I just noticed that after closing the cpu monitor, my vsync'd framerate immediately jumped to 60 (the monitor native rate). So, it seems that Heisenberg has struck again. I can't measure the thing with out radically changing it. Or perhaps I'm just not using the right tools. Does anybody have any suggestions for decent Windows performance analysis tools? I was using SysInternal's ProcessExplorer. Cory Cory Riddell wrote: Hi Robert, On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote: Does anybody see less than 100% CPU utilization when running osgviewer cow.osg on an ATI card? I had just been accepting that as normal. 100% CPU is not normal at all. Yikes! I think there must be something seriously wrong with my system then. I updated my video drivers to the latest this morning and enabled vsync. Enabling vsync sent my framerate from 1200 fps to 15 fps! Vsync on or off made no difference on the cpu load- I always have 100% utilization on one core. I have a FireGL V7700 with 512 MB of RAM. I'm running the 8.603 drivers on quad core XP Pro machine. My one-and-only monitor is a 24 Dell panel at 1920x1200. I turned vsync back off. With it on, my cow looked like it was being rotated by a stepper motor. If you or anybody else has troubleshooting suggestions, I would be very happy to hear them. Cory ___ 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] osgManipulator.AntiSquish
I reconfirm this same issue in 2.8.1 The solution is simple (AntiSquish.cpp line 149) : // Position if (_usePosition) unsquished.postMult(_position); else unsquished.postMult(_pivot); should be // Position if (_usePosition) unsquished.postMultTranslate(_position); else unsquished.postMultTranslate(_pivot); if needed i can attach a complete file. have a good one, Rene 2009/2/23 Robert Osfield robert.osfi...@gmail.com Hi Jonathan, This is correct place to report bugs. I've just ran osgmanipulaor and see the that tabs rendering is indeed wrong. I have briefly looked at the svn logs and haven't spotted the cause of this regression yet. It's end of day here so I'll look into this tomorrow. Robert. On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan jle...@integrity-apps.com wrote: Hi, The behavior of osgManipulator::AntiSquish seems to have changed between releases 2.6.1 and 2.8.0. I'm not sure what is happening differently in the matrix math, but you can see the result on the TabBoxDragger by firing up the standard osgManipulator example. The dragger's corner tabs are no longer in the corners. As a test I replaced the v2.8 AntiSquish node with the v2.6.1 AntiSquish in the TabPlaneDragger, and things looked right again. Btw, is this the right place to put a bug report like this? Thanks, -Jonathan Lewis ___ 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] [3rdparty] how do you 'make'
'make' is a Unix command. As far as I know, there is no required way to organize your computer. Here's an article I wrote on setting up a Windows box to be an OSG dev platform, but it doesn't go into detail on the non-standard dependencies. I imagine you can put them anywhere you wish, then configure CMake to find them (that's how most OSG-related projects work). http://www.skew-matrix.com/bb/viewtopic.php?f=8t=3 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgManipulator.AntiSquish
HI Rene, Could you post the whole modified file, thanks, Robert. 2009/6/8 René Molenaar megamillerz...@gmail.com: I reconfirm this same issue in 2.8.1 The solution is simple (AntiSquish.cpp line 149) : // Position if (_usePosition) unsquished.postMult(_position); else unsquished.postMult(_pivot); should be // Position if (_usePosition) unsquished.postMultTranslate(_position); else unsquished.postMultTranslate(_pivot); if needed i can attach a complete file. have a good one, Rene 2009/2/23 Robert Osfield robert.osfi...@gmail.com Hi Jonathan, This is correct place to report bugs. I've just ran osgmanipulaor and see the that tabs rendering is indeed wrong. I have briefly looked at the svn logs and haven't spotted the cause of this regression yet. It's end of day here so I'll look into this tomorrow. Robert. On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan jle...@integrity-apps.com wrote: Hi, The behavior of osgManipulator::AntiSquish seems to have changed between releases 2.6.1 and 2.8.0. I'm not sure what is happening differently in the matrix math, but you can see the result on the TabBoxDragger by firing up the standard osgManipulator example. The dragger's corner tabs are no longer in the corners. As a test I replaced the v2.8 AntiSquish node with the v2.6.1 AntiSquish in the TabPlaneDragger, and things looked right again. Btw, is this the right place to put a bug report like this? Thanks, -Jonathan Lewis ___ 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] osgManipulator.AntiSquish
Sure,
here is the complete modified file osgManipulator/AntiSquish.cpp
from OpenSceneGraph-2.8.1
The bug is as described above:
The dragger's corner tabs are no longer in the corners.
this fix places the cornertabs back in the corners.
(the manipulator does not make sense otherwise).
Grtz,
René
2009/6/8 Robert Osfield robert.osfi...@gmail.com
HI Rene,
Could you post the whole modified file, thanks,
Robert.
2009/6/8 René Molenaar megamillerz...@gmail.com:
I reconfirm this same issue in 2.8.1
The solution is simple (AntiSquish.cpp line 149) :
// Position
if (_usePosition)
unsquished.postMult(_position);
else
unsquished.postMult(_pivot);
should be
// Position
if (_usePosition)
unsquished.postMultTranslate(_position);
else
unsquished.postMultTranslate(_pivot);
if needed i can attach a complete file.
have a good one,
Rene
2009/2/23 Robert Osfield robert.osfi...@gmail.com
Hi Jonathan,
This is correct place to report bugs. I've just ran osgmanipulaor and
see the that tabs rendering is indeed wrong. I have briefly looked at
the svn logs and haven't spotted the cause of this regression yet.
It's end of day here so I'll look into this tomorrow.
Robert.
On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan
jle...@integrity-apps.com wrote:
Hi,
The behavior of osgManipulator::AntiSquish seems to have changed
between
releases 2.6.1 and 2.8.0. I'm not sure what is happening differently
in
the
matrix math, but you can see the result on the TabBoxDragger by firing
up
the standard osgManipulator example. The dragger's corner tabs are no
longer in the corners.
As a test I replaced the v2.8 AntiSquish node with the v2.6.1
AntiSquish
in
the TabPlaneDragger, and things looked right again.
Btw, is this the right place to put a bug report like this?
Thanks,
-Jonathan Lewis
___
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
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
//osgManipulator - Copyright (C) 2007 Fugro-Jason B.V.
#include osgManipulator/AntiSquish
using namespace osgManipulator;
namespace
{
class AntiSquishCallback: public osg::NodeCallback
{
public:
AntiSquishCallback(AntiSquish* asq) : osg::NodeCallback(), _antiSquish(asq) {}
virtual ~AntiSquishCallback() {};
virtual void operator() (osg::Node*, osg::NodeVisitor* nv)
{
// Get the node path.
osg::NodePath np = nv-getNodePath();
// Remove the last node which is the anti squish node itself.
np.pop_back();
// Get the accumulated modeling matrix.
osg::Matrix localToWorld = osg::computeLocalToWorld(np);
// compute the unsquished matrix.
bool flag = false;
osg::Matrix _unsquishedMatrix = _antiSquish-computeUnSquishedMatrix(localToWorld, flag);
if (flag)
_antiSquish-setMatrix(_unsquishedMatrix);
}
protected:
AntiSquish* _antiSquish;
};
}
AntiSquish::AntiSquish() : _usePivot(true), _usePosition(false)
{
_asqCallback = new AntiSquishCallback(this);
setUpdateCallback(_asqCallback);
}
AntiSquish::AntiSquish(const osg::Vec3d pivot) : _pivot(pivot), _usePivot(true), _usePosition(false)
{
_asqCallback = new AntiSquishCallback(this);
setUpdateCallback(_asqCallback);
}
AntiSquish::AntiSquish(const osg::Vec3d pivot, const osg::Vec3d pos)
:
Re: [osg-users] build errors with 2.8.1
Robert Osfield wrote: Hi Jason, Your rant shows you didn't grasp the point of my earlier email. And your responses show that you didn't grasp the point of mine. You seem to still be under the impression that I expect you to continue supporting CMake 2.4.5, no matter what. Let me be clear here: *If you don't want to support CMake 2.4.5 anymore, then by all means don't support it* As I said, we don't have any money to pay you. If you consider it too expensive to maintain, then drop it. We'll be fine with 2.8.0 until we can get a newer version of CMake. I personally find it hard to believe that maintaining RHEL 5 support is any harder than maintaining, say, IRIX support, but I'm not the one doing the maintenance, so what I believe is irrelevant. If support for CMake 2.4.5 is contingent upon me alone testing every release that you put out, I cannot make any promises to do that. I'll do what I can, but I cannot guarantee anything. I like my job, and I intend to keep it. I've already said that I'll try to set up a CDash target for the trunk here in the lab. Hopefully that's enough to satisfy your needs. As far as gratitude, look, I'm not looking for a trophy or anything. I just think that your contributors should be given a little respect. I just thought you were out of line with the way you characterized me in your last e-mail. You made it sound like I'm taking OSG and using it and expecting you to handle all my needs without me giving anything back. Nothing could be farther from the truth, and I just didn't appreciate being painted in that light. I could say more, but I'd rather see this thread die. It's stressing me out. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
Hi Jason, On Mon, Jun 8, 2009 at 4:35 PM, Jason Dalyjd...@ist.ucf.edu wrote: And your responses show that you didn't grasp the point of mine. Um it was mostly a rant... You seem to still be under the impression that I expect you to continue supporting CMake 2.4.5, no matter what. Let me be clear here: *If you don't want to support CMake 2.4.5 anymore, then by all means don't support it* I have already said that if CMake 2.4.5 is possible without causing problem then I'm happy to see us support CMake 2.4.5. The key point is that if you want this support you (as in all users users using this out of date CMake version) have to be pro-active in making sure that there aren't any build regressions. As I said, we don't have any money to pay you. If you consider it too expensive to maintain, then drop it. It's only expensive because CMake 2.4.5 users aren't being pro-active in testing. It's repeated stable/release candidates that are really really expensive. When you don't test till after a stable release has gone out then it's very much in the really expensive bracket. The fact that stuff that could have easily been caught by end users testing in release candidates of 2.8.1 is what pisses me off, all my repeated calls for testing and the time I gave the community it seems wasn't enough. There are quite a few users who do make the effort, these are the hero's of the community, others who waited till it after the release are the ones who effectively casting all their efforts in vain, as we're reset back to square one with a new series of 2.8.2-rc's and final 2.8.2 now required. If support for CMake 2.4.5 is contingent upon me alone testing every release that you put out, I cannot make any promises to do that. I'll do what I can, but I cannot guarantee anything. I like my job, and I intend to keep it. We'll if you and others who want CMake 2.4.5 support can't afford to make sure the OSG releases build it then there is nothing I can do. If we don't know about problems we can't fix them. I've already said that I'll try to set up a CDash target for the trunk here in the lab. Hopefully that's enough to satisfy your needs. This will be a major step forward, having a nightly build of svn/trunk and the latest stable branch (OpenSceneGraph-2.8) is one of the most effectively ways of catching problems early. It's not a total replacement for actual human testing though, whether something compiles or not is only part of the story, we also need to know if the OSG actual runs well against peoples applications prior to releases. As far as gratitude, look, I'm not looking for a trophy or anything. I just think that your contributors should be given a little respect. I do appreciate your contributions, but that won't mean that I will shy away from calling out problems when I see them. The build problem was minor problem easily dealt with, but the lack of community testing prior to a release is a big problem here - as fixing problems after releases is far more expensive, both for me and all those who contribute to getting releases out the door. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
Robert Osfield wrote: Um it was mostly a rant... Then you didn't read it. There were quite a few intelligent points. Sure the first part was a rant (I'd call it a counter-rant to yours), but the rest were well-formed ideas. I have already said that if CMake 2.4.5 is possible without causing problem then I'm happy to see us support CMake 2.4.5. The key point is that if you want this support you (as in all users users using this out of date CMake version) have to be pro-active in making sure that there aren't any build regressions. And I've said that I will do what I can, but I can't guarantee that I'll be able to test each and every time you make a release. I'm sorry, my responsibilities at work come first. Maybe there really are only two of us on this list, and our schedules just don't line up all the time. This is the nature of OSS. You can't rely on anyone for certain. All I can say is that I'll do the best I can. I do appreciate your contributions, Even that little phrase means a lot coming from you. Thank you. but that won't mean that I will shy away from calling out problems when I see them. The build problem was minor problem easily dealt with, but the lack of community testing prior to a release is a big problem here - as fixing problems after releases is far more expensive, both for me and all those who contribute to getting releases out the door. I understand that. I'm just not sure how much more I can do than what I've already pledged. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ReaderWriter options for paged data
Hi, I have some paged data with DDS textures, which require the ReaderWriter's dds_flip option to be off, and some other data also with DDS textures that require dds_flip to be on. Here's the problem: The data can be loaded in any order, and if I e.g. - set dds_flip off - load the paged file - set dds_flip on - load the non-paged files, the paged data has its textures upside down, since they're not loaded until after dds_flip is back on. Is there any way to associate some ReaderWriter options with a specific file, or do something similar to allow paged data to load with different options than the global settings? Thanks, Max Bandazian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ReaderWriter options for paged data
Max Bandazian wrote on Monday, June 08, 2009 12:09 PM: Hi, I have some paged data with DDS textures, which require the ReaderWriter's dds_flip option to be off, and some other data also with DDS textures that require dds_flip to be on. Here's the problem: The data can be loaded in any order, and if I e.g. - set dds_flip off - load the paged file - set dds_flip on - load the non-paged files, the paged data has its textures upside down, since they're not loaded until after dds_flip is back on. Is there any way to associate some ReaderWriter options with a specific file, or do something similar to allow paged data to load with different options than the global settings? Thanks, Max Bandazian You can attach an osgDB::Options object with the appropriate options string to the PagedLOD that loads the textures (see osg::PagedLOD::setDatabaseOptions()). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Downloading Binaries
Hi, Thanks guys, I actually have. I've been working with C# from the last 2+ years, so I guess I'm pretty rusty with C++. I did my configure with OSG, ran fine. When I do my make I get OpenGL errors. Any ideas on how to setup my linking on it? Some of the may pages of errors: CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2a1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2b8): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2d2): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2f1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x30d): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x329): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x340): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x35c): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x391): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x3ad): more undefined references to `_glTexGeni' follow CMakeFiles/osg.dir/TexMat.o:TexMat.cpp:(.text+0x1a): undefined reference to `_glMatrixMode' Any newb help would be great! ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13713#13713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ReaderWriter options for paged data
That looks like exactly what I need; unfortunately my project isn't up to 2.8.1 yet, so I don't have that method. There's no way to plug in my own PagedLOD class, is there? On Mon, Jun 8, 2009 at 1:15 PM, Thrall, Bryan bryan.thr...@flightsafety.com wrote: Max Bandazian wrote on Monday, June 08, 2009 12:09 PM: Hi, I have some paged data with DDS textures, which require the ReaderWriter's dds_flip option to be off, and some other data also with DDS textures that require dds_flip to be on. Here's the problem: The data can be loaded in any order, and if I e.g. - set dds_flip off - load the paged file - set dds_flip on - load the non-paged files, the paged data has its textures upside down, since they're not loaded until after dds_flip is back on. Is there any way to associate some ReaderWriter options with a specific file, or do something similar to allow paged data to load with different options than the global settings? Thanks, Max Bandazian You can attach an osgDB::Options object with the appropriate options string to the PagedLOD that loads the textures (see osg::PagedLOD::setDatabaseOptions()). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.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
[osg-users] [forum] Ray tracing
Hi osg community, my problem is as follows: I will generate a time of flight camera with many rays in osg. Each ray measures the distance between the camera origin point and the terrain in the camera coordinate frame. Camera point and camera coordinate frame are moving with time. I have tried it with los and it is working well for one ray. Using more rays, the program is jerking. Now I have read, that it is possible and better to use raytracing instead, but I have not found any example code. Has anyone an example code for me!?! Regards, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13709#13709 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to apply LISPSM shadows to a scene with different shaders - Part 3
Sorry, that link just isn't working at all for me. Could you give me a different one or someone relay that information here? Thanks for your help, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13710#13710 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ImageStream with different sized images
Hi everyone, I'm thinking about how to implement an ImageStream that could display different images based on the status of the image. For example, displaying a Buffering image when data is being downloaded from Internet. I'm using the setImage() function to alter the data of the underlying image, and the issue I'm running into is that it resizes the image frames the size of the first frame I send to the ImageStream. For example, if I set a 256x256 image that says Loading... while the movie data is being download from the Internet, once the frames start coming in at say 640x480, they are all resized to 256x256 b/c that was the initial size of the image. I've looked at the osgimagesequence example and it does the same thing, all the images are resized to size of the first image. Is there a way to avoid this resize or am I going about this in a crazy way? :) Thanks, Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ReaderWriter options for paged data
Max Bandazian wrote: That looks like exactly what I need; unfortunately my project isn't up to 2.8.1 yet, so I don't have that method. There's no way to plug in my own PagedLOD class, is there? I'm not sure if this will work, but you might look into a ReadFileCallback (look in osgDB/Registry) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Downloading Binaries
Hi Christopher, I would like to ask you first for your building environment (OSG version, compiler version, operating system, etc) Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on geode and shared stateSet
I am struggling with the same/similar issue. I want to set the transparency level dynamically ( the user has a slider) of a group in my scene. My understanding is that apart from setting the state GL_BLEND etc it is required to traverse/visit all of the nodes of the sub-graph setting the alpha component of each color value encountered to the requested alpha value. It just seems like such a common requirement I am surprised that there is not a NodeVisitor to do this? Or am I missing something here. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13719#13719 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Downloading Binaries
Hi, Good question, I have windows XP. I'm using CYGWIN 1.5.25 GCC 3.4.4 and LibGlut 2.4.0 ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13720#13720 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on geode and shared stateSet
Andrew Cunningham wrote: I am struggling with the same/similar issue. I want to set the transparency level dynamically ( the user has a slider) of a group in my scene. My understanding is that apart from setting the state GL_BLEND etc it is required to traverse/visit all of the nodes of the sub-graph setting the alpha component of each color value encountered to the requested alpha value. It just seems like such a common requirement I am surprised that there is not a NodeVisitor to do this? Or am I missing something here. I don't think it's really that common. The easy way to do this is to organize your scene so that each object where you want to adjust transparency is contained in it's own subgraph. Then, you just put an osg::Material at the root of that subgraph and vary the Alpha component of that material. If you need to preserve the geometry colors, you can set the Material's color mode to DIFFUSE or AMBIENT_AND_DIFFUSE. If I remember correctly, the original poster had a specific issue where he couldn't do this, or I would have given him the same advice. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multiple render targets / cameras
Hi, thanks to the gurus for all the excellent guidance you provide to us lesser mortals.. I can likely mush my way through this but I wanted to ask the opinions of the osg gurus on my design approach before getting mired down in a less desirable approach. We have a geometry graph that we want to render to two separate places: (1) a bitmap image for additional automated analysis or use downstream in a shader (that will also render to a similarly sized memory image), and (2) the window context that can show the progress on the display, but not necessarily replicate exactly the underlying hi-resolution image in memory, for performance reasons. They'll probably have different resolutions, say 1024 x 1024 for the bitmap and whatever window size the user sets for the display. I'm thinking two separate cameras, and I've seen in the examples (osg distortion?) where the bitmap is setup, and I've also seen in other posts several discussions about multiple camera for multiple views. Then, I need to have these cameras under program control, say, iterating a rotation angle in 1 deg increments, and iterating the distance over some range and increment (or the corresponding camera position), drawing a frame of each (and ultimately processing the resulting image with downstream algorithms and code). Real time frame rates are probably not a reasonable expectation for this analyzer. I want the view version to give low-res feedback about the progress and correctness of the underlying hi-res memory image processing. My questions are currently: 1.What's the best way to connect the two cameras so they're the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? 2. What's the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? Is my design sound, or should I pursue some other approach? If the separate window context with different resolution is a problematic design, I can let go of that, but I think we're really pursuing the memory image processing approach, ultimately needing a shader program and then finally combining two memory bitmaps, respecting the transparency of one, analogous to some kind of specially programmed x-ray view, then extract the transparent parts and average the color of it. Thanks, Bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: My questions are currently: 1.What’s the best way to connect the two cameras so they’re the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? This sounds like a plain old osgViewer::Viewer with a slave camera is the way to go. You control the viewpoint with the master camera, and both cameras render wherever you need them. I think the osgsidebyside example may give you an idea how to set this up (it's not exactly what you're looking for, but a lot of the code is relevant). osgprerender might also be relevant. 2. What’s the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? The most straightforward way to do this is with an UpdateCallback. I think Paul Martz's OSG Quick Start Guide explains this pretty well. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] building 2.8.1 with dcmtk
On Sat, 6 Jun 2009, Robert Osfield wrote: Hi John, Try removing your OpenSceneGraph/CMakeCache.text file and the re-run ./configure to see if that kicks CMake into properly checking all the dependencies. Also try disabling the aggressive warnings to see if that prevents gcc spitting out errors when compiling against ITK. Robert. Hi, I did both cmakes in empty directories, so there was no cache file to erase. All other cmakes mentioned in this email were also run in empty directories. Both times I got the same errors in InsightToolkit. I reran the cmake that uses just DCMTK_DIR with an added OSG_USE_AGGRESSIVE_WARNINGS=OFF and it built successfully. OK! I admit that this is a bit of a surprise, at least to me, as I wasn't expecting compiler warnings to have an effect on compiler errors. I reran cmake again without DCMTK_DIR and with OSG_USE_AGGRESSIVE_WARNINGS=OFF and it also built successfully, so I'm not sure it DCMTK is ever used. So I ran cmake one more time, in a clean directory, with both DCMTK_DIR and OSG_USE_AGGRESSIVE_WARNINGS=OFF, and got the below in my CMake\* files. CMakeCache.txt finds DCMTK, but the dicom plugin still refers to InsightToolkit. Does this help resolve what's going on? Did I perhaps not install the DCMTK components that he dicom plugin needs? Thanks again, John find . -name CMake\* | xargs grep -i dcmtk ./CMakeCache.txt://Root of DCMTK source tree (optional). ./CMakeCache.txt:DCMTK_DIR:PATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x ./CMakeCache.txt:DCMTK_ROOT_INCLUDE_DIR:PATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/config/include ./CMakeCache.txt:DCMTK_config_INCLUDE_DIR:PATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/config/include/dcmtk/config ./CMakeCache.txt:DCMTK_dcmdata_INCLUDE_DIR:PATH=DCMTK_dcmdata_INCLUDE_DIR-NOTFOUND ./CMakeCache.txt:DCMTK_dcmdata_LIBRARY:FILEPATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/dcmdata/libsrc/libdcmdata.a ./CMakeCache.txt:DCMTK_dcmimgle_INCLUDE_DIR:PATH=DCMTK_dcmimgle_INCLUDE_DIR-NOTFOUND ./CMakeCache.txt:DCMTK_dcmimgle_LIBRARY:FILEPATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/dcmimgle/libsrc/libdcmimgle.a ./CMakeCache.txt:DCMTK_dcmnet_LIBRARY:FILEPATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/dcmnet/libsrc/libdcmnet.a ./CMakeCache.txt:DCMTK_imagedb_LIBRARY:FILEPATH=DCMTK_imagedb_LIBRARY-NOTFOUND ./CMakeCache.txt:DCMTK_ofstd_INCLUDE_DIR:PATH=DCMTK_ofstd_INCLUDE_DIR-NOTFOUND ./CMakeCache.txt:DCMTK_ofstd_LIBRARY:FILEPATH=/usr/local/HEV-beta/apps/dcmtk/dcmtk-3.x/ofstd/libsrc/libofstd.a ./CMakeCache.txt://Advanced flag for variable: DCMTK_DIR ./CMakeCache.txt:DCMTK_DIR-ADVANCED:INTERNAL=1 find . -name CMake\* | xargs grep -i insighttoolkit ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Review ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Patented ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities/vxl/core ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities/vxl/vcl ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities/DICOMParser ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities/NrrdIO ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Utilities/MetaIO ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/SpatialObject ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Numerics/NeuralNetworks ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Numerics/Statistics ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Numerics/FEM ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/IO ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Numerics ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/gdcm/src ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/expat ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Common ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/BasicFilters ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit/Algorithms ./src/osgPlugins/dicom/CMakeFiles/CMakeDirectoryInformation.cmake: /usr/include/InsightToolkit ./CMakeCache.txt:// root of the build tree, or PREFIX/lib/InsightToolkit for an ./CMakeCache.txt:ITK_DIR:PATH=/usr/lib/InsightToolkit
Re: [osg-users] multiple render targets / cameras
Hi, about the view and slave cameras, i got it, thanks. one is the lo-res view for the GUI and the other is the hi-res (prerender) view for the memory bitmap. does it matter for the master/slave status for prerender vs the displayed camera. Also, how does one turn these on/off? is that easy to control? ... Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13725#13725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Hi, regarding matrixmanipulators, almost all the example have TrackBallManipulator as the view's manipulator, separater from the cameras. So, if i have an update callback on a camera to set its (and its slave) position and orientation, how does that interact with a trackballmanipulator. can i remove it from the view and add it back? can i easily toggle on/off the trackballmanipulator, so i can control programmatic vs user control of these master/slave cameras? that would be really nice. Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13726#13726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to apply LISPSM shadows to a scene withdifferent shaders - Part 3
Michael, Sorry I am not sure whats going on but it looks like forum/osgmail server abbreviates this link somehow. I checked what I sent and it looks like part of link is missing. I attach this link as text file. I hope it will work now. If text attachment gets mangled: Address is following (replace COLON with : and each SLASH with / ) http COLON SLASH SLASH www.mail-archive.com SLASH osg-users@lists.openscenegraph.org SLASH msg26683.html I hope this goes right this time. Wojtek -- From: Michael Guerrero mjgue...@nps.edu Sent: Monday, June 08, 2009 6:45 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] How to apply LISPSM shadows to a scene withdifferent shaders - Part 3 Sorry, that link just isn't working at all for me. Could you give me a different one or someone relay that information here? Thanks for your help, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13710#13710 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Downloading Binaries
Hi, Side note, these are the steps I am to build it. How to build under Unices (MinGW and Cygwin users: see Windows) With CMake you can build the OSG libraries and executables in the source directory and have the files placed in the lib and bin directories, or you can build out of source. In this case the whole build system, intermediate files and final binaries are built in a separate directory. Building out of source is very useful when you need to build multiple targets, such as 32-bit and 64-bit or Release versus Debug. You can also share your source directories across the network and have several platform builds sitting alongside each other, as an out of source build keeps the source tree completely clean. In general, CMake strongly recommends and promotes building out of source. Note: If you do build in-source, changing your mind later to build out-of-source will require you to manually purge CMake cache files in your source tree, otherwise CMake will get confused. Using CMake on Unix is done from the command-line. Either use the command cmake, which just directly creates the build system, or use ccmake. The latter provides a text-based user interface that opens up in the console that allows you to adjust options. You can also use make edit_cache, once the build system is built if you wish. (Wiki editing note: what does edit_cache do?) Building out-of-source (recommended): # Assuming we're in the directory where the OSG sources # are unpacked (usually as the directory OpenScenGraph) mkdir build_OpenSceneGraph cd build_OpenSceneGraph ccmake ../OpenSceneGraph # Set build options in the user-interface # Press 'c' to configure, possible multiple times # Press 'g' to generate make-files make sudo make install cd .. It fails on the make step. ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13728#13728 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ArgumentParser issues on Windows?
The following code works on Linux/Mac but not Windows. Is there
something I should realize about ArgumentParser and ApplicationUsage?
Maybe it's some Windows/VS2008 thing I've missed?
-
#include osg/ArgumentParser
#include string
int main(int argc, char * argv[])
{
std::string name(Fred);
osg::ArgumentParser arguments(argc, argv);
osg::ApplicationUsage *au;
au = arguments.getApplicationUsage();
// the next two lines cause runtime errors on Window
au-setApplicationName(name);
std::string cmdLineName = arguments.getApplicationName();
return 0;
}
-
The au-setApplicationName(name) line gives the error:
Unhandled exception at 0x76bc42eb foo.exe MicrosoftC++ exception:
std::bad_alloc at memory location 0x0018f37c..
commenting that line out results in the next line producing:
arguments.getApplicationName() causes Unhandled Exception at
0xHexAddress in foo.exe 0xC005: Access violation reading location
0xccc0.
This is setup as a Windows Console App in VS2008.
I can set a breakpoint on the first line and see that argv[0] and argc
are set reasonably.
Stepping forward I note that the constructor for ApplicationUsage
doesn't initialize _applicationName. Visual Studio debugger notes Bad
Ptr on au-_applicationName before the call to:
au-setApplicationName(name)
Odd since _applicationName is declared:
std::string _applicationName;
Lee
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cygwin Compile Question OSG 2.8.1
Hi, I hope nobody minds me spawing another thread on this question, but I think I've moved onto a new question. I am trying to Compile OSG and I'm getting some OpenGL issues. My system: CYGWIN 1.5.25 GCC 3.4.4 LibGlut 2.4.0 some of the many pages of errors CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2a1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2b8): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2d2): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2f1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x30d): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x329): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x340): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x35c): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x391): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x3ad): more undefined references to `_glTexGeni' follow CMakeFiles/osg.dir/TexMat.o:TexMat.cpp:(.text+0x1a): undefined reference to `_glMatrixMode' I'm pretty rusty on C++. Any work around solutions? ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13730#13730 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on geode and shared stateSet
Adjusting the material color alpha will work for some geometries but I have other geometries where each vertex has a BIND_PER_VERTEX color ( think of a contour plot of a value), so I would still need to adjust the alpha of each vertex color. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13731#13731 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 2.8.1 Image::readPixels and packing.
Image::readPixels() resets the packing of it's Image to 1. It should either take a packing parameter or respect the existing packing by passing _packing to allocateImage -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13732#13732 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Layer Opacity using TexEnvCombine
Hi all, I'm trying to figure out a way to modify layer opacity using TexEnvCombine that takes into account the underlying alpha channel of a texture. The osgFX::MultiTextureControl does very close to what I'm looking to do, but doesn't take into account the fact that the underlying texture may contain transparency (like a road overlay). From my understanding of texenvcombine, I can either use a constant color or SRC_ALPHA as an operand, but not a combination of both. I really want a way to use SRC_ALPHA scaled by some user defined opacity value (0 to 1). Does anyone know of a way to accomplish this? I know how to accomplish this using a glsl shader, but can't quite figure out how to do it with texenvcombine. Thanks! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on geode and shared stateSet
Andrew Cunningham wrote: Adjusting the material color alpha will work for some geometries but I have other geometries where each vertex has a BIND_PER_VERTEX color ( think of a contour plot of a value), so I would still need to adjust the alpha of each vertex color. Actually you don't (unless you need a different alpha for each vertex). Normally, the material's settings will override the color array values. However, if you set the Material's color mode to some value other than NONE, the material color for that element (AMBIENT, DIFFUSE, AMBIENT_AND_DIFFUSE, SPECULAR, or EMISSION) will be replaced by the vertex color. Unless you doing something fancy, you can typically set the color mode to AMBIENT_AND_DIFFUSE, which lets you make use of your vertex colors, but vary the alpha as you need to. Look in the red book, or the glColorMaterial man page for more info. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: Hi, about the view and slave cameras, i got it, thanks. one is the lo-res view for the GUI and the other is the hi-res (prerender) view for the memory bitmap. does it matter for the master/slave status for prerender vs the displayed camera. I don't believe it will matter for what you've described so far. Depending on how your application will work, you might prefer to have one or the other view be the master. Also, how does one turn these on/off? is that easy to control? I believe you can turn cameras on/off by using their node mask (set to 0x for on, and 0x for off). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: Hi, regarding matrixmanipulators, almost all the example have TrackBallManipulator as the view's manipulator, separater from the cameras. So, if i have an update callback on a camera to set its (and its slave) position and orientation, how does that interact with a trackballmanipulator. Typically, you don't want to have both a manipulator and an update callback controlling the camera. can i remove it from the view and add it back? can i easily toggle on/off the trackballmanipulator, so i can control programmatic vs user control of these master/slave cameras? that would be really nice. If you look at the osgviewer source, there's an example of how to switch between manipulators on the fly using a KeySwitchMatrixManipulator. Instead of an update callback, you can also just write a simple matrix manipulator to control the camera in the way you described earlier. Then you'll be able to switch between them pretty easily. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
Christopher Wang wrote: Hi, I hope nobody minds me spawing another thread on this question, but I think I've moved onto a new question. I am trying to Compile OSG and I'm getting some OpenGL issues. My system: CYGWIN 1.5.25 GCC 3.4.4 LibGlut 2.4.0 some of the many pages of errors CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2a1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2b8): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2d2): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x2f1): undefined reference to `_glTexGendv' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x30d): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x329): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x340): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x35c): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x391): undefined reference to `_glTexGeni' CMakeFiles/osg.dir/TexGen.o:TexGen.cpp:(.text+0x3ad): more undefined references to `_glTexGeni' follow CMakeFiles/osg.dir/TexMat.o:TexMat.cpp:(.text+0x1a): undefined reference to `_glMatrixMode' I'm pretty rusty on C++. Any work around solutions? Did you install the OpenGL package when you installed Cygwin? All of the missing functions there are OpenGL functions. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Layer Opacity using TexEnvCombine
Jason Beverage wrote: Hi all, I'm trying to figure out a way to modify layer opacity using TexEnvCombine that takes into account the underlying alpha channel of a texture. Do you mean if unit 1's texture has transparency, you want that to show through to unit 0's texture? The osgFX::MultiTextureControl does very close to what I'm looking to do, but doesn't take into account the fact that the underlying texture may contain transparency (like a road overlay). From my understanding of texenvcombine, I can either use a constant color or SRC_ALPHA as an operand, but not a combination of both. It sounds like you need three parameters combined (2 texture colors and a user-defined parameter), so your only hope is the INTERPOLATE mode for the alpha values (INTERPOLATE is the only combiner operation that takes three parameters). Try this: tec-setSource0_RGB(osg::TexEnvCombine::TEXTURE0); tec-setSource1_RGB(osg::TexEnvCombine::TEXTURE1); tec-setCombine_RGB(osg::TexEnvCombine::MODULATE); tec-setConstantColor(osg::Vec4(1.0, 1.0, 1.0, userDefinedAlpha)); tec-setSource0_Alpha(osg::TexEnvCombine::TEXTURE0); tec-setSource1_Alpha(osg::TexEnvCombine::TEXTURE1); tec-setSource2_Alpha(osg::TexEnvCombine::CONSTANT); tec-setCombine_Alpha(osg::TexEnvCombine::INTERPOLATE); I just made this up, so I have no idea if it will work or not. It might not be the only possibility, either, but it's all I can think of right now. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
Hi, I did, I installed free glut. I got a small opengl program compiling. Perhaps something is missing from the configure script? ... Thank you! Cheers, Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13739#13739 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
On Mon, Jun 8, 2009 at 8:54 PM, Christopher Wang cwang7...@hotmail.comwrote: Hi, I did, I installed free glut. I got a small opengl program compiling. Perhaps something is missing from the configure script? ... I don't really use Cygwin much but I do have it installed here. Could you try the following... Instead of configure type $ ccmake --version (and tell us the version... then run) $ ccmake . Hit c to configure Hit t to toggle advanced mode Search down until you find OPENGL_INCLUDE_DIR, OPENGL_gl_LIBRARY, and OPENGL_glu_LIBRARY. What are their values? Mine are (respectively): /usr/include/w32api /usr/lib/w32api/libopengl32.a /usr/lib/w32api/libglu32.a -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
It's probably osgViewer::CompositeViewer that you want, not osgViewer::Viewer. There's an example in the source. That way you create two different osgViewer::Views, and each can have it's own manipulator. The control is up to you, but if you want automated rotations and panning, I usually use NodeTrackerManipulator instead of TrackBallManipulator. I just create a PositionAttitudeTransform somewhere in my scene that represents the camera position, and animate it in a callback like Jason suggests. -Mike Jason Daly wrote: Bob Youmans wrote: My questions are currently: 1.What’s the best way to connect the two cameras so they’re the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? This sounds like a plain old osgViewer::Viewer with a slave camera is the way to go. You control the viewpoint with the master camera, and both cameras render wherever you need them. I think the osgsidebyside example may give you an idea how to set this up (it's not exactly what you're looking for, but a lot of the code is relevant). osgprerender might also be relevant. 2. What’s the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? The most straightforward way to do this is with an UpdateCallback. I think Paul Martz's OSG Quick Start Guide explains this pretty well. --J ___ 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
