Re: [osg-users] Building the Collada plugin
Randolph, The Collada plugin has only be used with the Collada DOM 2.1 library. DOM 2.2 was silently released two weeks ago, but I haven't tested it yet. There have been a few changes to the Cmake files since osg 2.6.1 so maybe the older version does not work right out of the box. -- Roland -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of R Fritz Sent: donderdag 18 december 2008 3:14 To: OpenSceneGraph Users Subject: [osg-users] Building the Collada plugin OSG 2.6.1, VS 2008. So far I've downloaded COLLADA_1.4.1_DOM_1.3.0.zip, built it, and got a slew of errors trying to build the plugin. (Collada DOM 2.2, which looks like it might be downward compatible, uses a different library structure, and I've no idea which files are still needed.) Which version of Collada is known to work? Does the plugin work at all with VS 2008? Randolph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Hi Roger,
I tested this code with a few models of the Collada test bank and not
all examples work like before. I did not take a look at the specific
code paths that these examples used.
Maybe it is wise that we set up a regression data set specifically
targeted at transparency.
--
Roland
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roger
James
Sent: vrijdag 12 december 2008 17:04
To: OpenSceneGraph Users
Subject: Re: [osg-users] The Collada plugin and transparency
Ok,
Here is where I am at the moment with the handling of
transparency etc. Being a developer I have pasted in the actual code. I
must admit the handling of the FX_OPAQUE_RGB_XXX stuff does not make
much sense to me, but then I have never seen it used. Comments welcome.
void daeReader::processTransparencySettings(
domCommon_transparent_type *ctt, domCommon_float_or_param_type
*pTransparency, osg::StateSet *ss, osg::Material *material )
{
if (NULL == ctt NULL == pTransparency)
return;
if (ctt ctt-getTexture() != NULL)
{
osg::notify( osg::WARN ) Currently no support for
texture in transparent channel. std::endl;
return;
}
// Fix up defaults acoording to 1.4.1 release notes
domFloat4 f4;
domFx_opaque_enum Opaque = FX_OPAQUE_ENUM_A_ONE;
if (NULL == ctt)
{
f4.append(0.0f);
f4.append(0.0f);
f4.append(0.0f);
f4.append(1.0f);
}
else
{
Opaque = ctt-getOpaque();
if (NULL != ctt-getColor())
{
f4 = ctt-getColor()-getValue();
}
else if ((NULL == ctt-getParam()) ||
!GetFloat4Param(ctt-getParam()-getRef(), f4))
{
f4.append(0.0f);
f4.append(0.0f);
f4.append(0.0f);
f4.append(1.0f);
}
}
domFloat Transparency;
if (NULL == pTransparency)
Transparency = 1.0f;
else
{
if (NULL != pTransparency-getFloat())
{
Transparency =
pTransparency-getFloat()-getValue();
if (m_AuthoringTool == GOOGLE_SKETCHUP) // Google
back to front support
Transparency = 1.0f - Transparency;
}
else if (NULL != pTransparency-getParam())
{
if
(GetFloatParam(pTransparency-getParam()-getRef(), Transparency))
{
if (m_AuthoringTool == GOOGLE_SKETCHUP) //
Google back to front support
Transparency = 1.0f - Transparency;
}
else
Transparency = 1.0f;
}
}
if (NULL != ctt || NULL != pTransparency)
{
// I assume that the presence of either a tansparent
or a transparency element
// means that the user may want some kind of alpha
blending
int SourceBlendFactor;
int DestBlendFactor;
bool HaveTranslucentDiffuseTexture = false;
bool SwitchOnTheBlender = false;
if ((NULL != ctt)
(GL_TRUE == ss-getTextureMode(0,
GL_TEXTURE_2D))
(NULL !=
dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE)))
(NULL !=
dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE))-getImage())
(dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE))-getImage()-isImageTranslucent()))
HaveTranslucentDiffuseTexture = true;
osg::Vec4 Diffuse;
if (material)
Diffuse =
material-getDiffuse(osg::Material::FRONT_AND_BACK);
// Determine whether or not to switch on the blender and
which blending factors to use.
// I switch the blender on if the supplied (or default)
transparent and transparency elements work out as non opaque,
// or if they work out opaque and I have a translucent
diffuse texture or a non opaque value in the diffuse colour
switch(Opaque)
{
/*
case FX_OPAQUE_ENUM_RGB_ONE:
if ((Transparency * f4[0] 0.99f)
(Transparency * f4[1] 0.99f)
(Transparency * f4[2]
Re: [osg-users] The Collada plugin and transparency
Hello Roger,
I did not make a study of the Collada transparency intricacies like you
did. The assumption I made was that a texture for diffuse specifies the
diffuse components to use in the texture. The fact that texture
coincidently was packed with an alpha channel (which of course happens a
lot) should not influence that.
When you consider the chain texturesamplersurfaceimage the
responsibilities are clearly dividided. It could be possible that
somebody decides to pack an ambient occlusion or specular value in the
alpha channel of an image. The semantics of the data source should be
specified by the texture elements in ambient, diffuse, specular, etc.
That's why I added code to only enable blending if a texture was
specified in the transparant element.
I've been very suprised to see suggested everywhere that the common
profile maps to the fixed function pipeline, but this easily falls short
if you need to support both blinn and phong. Well OpenGL FFP does not
even support phong shading. Gouraud is the closest we get with per
vertex lighting. I don't know how to map textures specified for both
ambient, diffuse, specular etc. to the Ogl FFP. Texture combiners might
bring us a little closer, but I hardly consider this the FFP. Besides
what happens if the surface contains a channels specification other that
rgb or rgba? It gets even worse if it is allowed to compose 3 channel
input for a diffuse texture combining components of three different
source images. I am not sure if this is allowed in the profile_COMMON.
Though very flexible, who is going to support this?
kind regards,
Roland
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roger
James
Sent: donderdag 11 december 2008 20:37
To: OpenSceneGraph Users
Subject: Re: [osg-users] The Collada plugin and transparency
Jason Daly wrote:
Roger James wrote:
if (transparent or transparency element present
in the technique)
{
// Turn on the OpenGL blender
Calculate a blending factor using
transparent and transparency according to the opaque mode in force.
// Decide whether to use GL_SRC_XXX or
GL_CONSTANT _XXX in the OpenGL blender
if (the calculated factor would mean opacity
when applied)
Use the relevant blend factor from the
incoming lit and textured fragment
else
Use the previously calculated blending
factor as a constant blend factor
}
I would appreciate any comments you have, time
permitting of course.
The only thing that worries me about this is that you're
using the transparent/transparency tags to decide when to enable
blending. I'd suggest you add one more check to see if your calculated
blending factor results in the surface being fully opaque before you
enable blending. I say this because I've made a lot of use of the
ColladaMAX plugin from Feeling Software, and every single model I've
exported with that plugin has transparent/transparency set on all of its
materials, even if they're actually fully opaque.
The problem I have is deciding if the surface is going to end up
fully opaque when there is a texture in the diffuse channel supplying
the incoming fragments alpha component. The best I can come up with is
this, but it is messy and does not take it account any modification of
the incoming frgaments alpha component by the application of the
lighting equation.
if (transparent or transparency element present in the
technique)
{
Calculate a blending factor using transparent and
transparency according to the opaque mode in force.
// Decide whether to use GL_SRC_XXX or GL_CONSTANT _XXX in
the OpenGL blender
if (the calculated factor would mean opacity when applied)
{
if (there is a translucent texture in the diffuse
channel)
{
Use the relevant blend factor from the incoming lit
and textured fragment
Turn on the OpenGL blender
}
else if (the calculated factor along with the alpha from
the constant diffuse colour woud result in a translucent colour)
{
Use the relevant blend factor from the incoming lit
and textured fragment
Turn on the OpenGL blender
}
}
else
{
Use the previously calculated blending factor as a
constant blend factor
Re: [osg-users] Attaching Nodes (Characters Objects)
Rusty, Here's my take on what you intend to do. You are using one of the latest developer versions of OSG or even the SVN version. Skinned mesh support is part of the osgAnimation nodekit which was recently integrated with OSG. OK, so you load an .osg or .ive model that contains skinned mesh information with animations. Just out of interest what tool/exporter did you use to generate the model? You need to find the node of interest probably by name (e.g. right hand). This is best done with a nodevisitor. See the FindNamedNodeVisitor in example osgplanets. This visitor will find the osgAnimation::Bone that you prepared for attachment. If the node is found you can simply attach your object (e.g. a weapon) by adding the model to attach as a child of that node. If this bone is the correct attachment point all is well, but possibly you need to apply an extra offset transform to correctly position the model w.r.t. the hand. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Morris Sent: woensdag 3 december 2008 0:01 To: OpenSceneGraph Users Subject: Re: [osg-users] Attaching Nodes (Characters Objects) It's a skinned mesh with bones. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attaching Nodes (Characters Objects)
Rusty, is your animated human using skinned mesh animation (with a bone hierarchy deforming a skin geometry) or is it composed of separate geometries (linked together by a hierarchy of osg::Transforms)? -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Morris Sent: dinsdag 2 december 2008 5:55 To: OpenSceneGraph Users Subject: Re: [osg-users] Attaching Nodes (Characters Objects) I have an animated human model. I want to attach something to the hand or head or foot, etc and have that object move with that part of the body. Apologies I should have been more clear! This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
Serge, I just changed the CMake files so I could develop the dae plugin in debug mode with a statically linked DOM. The CMake files still need to be changed so the user may specify the location of these dependencies (both debug and releas) by hand. Another possibility would be to automatically use the external-libs in the Collada DOM directory. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: maandag 1 december 2008 11:03 To: OpenSceneGraph Users Subject: Re: [osg-users] Request for testing Collada/dae plugin changes Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
If I link the DOM dynamically I don't need to set these targets here, right ? (like in the previous version of the CMakeList.txt) Hmm, not sure. I am also having links errors like that : 2daeReader.obj : error LNK2019: unresolved external symbol char const * const COLLADA_TYPE_INSTANCE_RIGID_BODY (?COLLADA_TYPE_INSTANCE_RIGID_BODY@@3PBDB) referenced in function public: bool __thiscall osgdae::daeReader::convert(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@osgdae@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@2@@std@@@Z) Linking statically solved this for me. I'll try to update my DOM to see if it works, it still depends on the 1.4.1 version, not the 1.5 ? The plugin is still using DOM 2.1 that supports Collada version 1.4.1 An official DOM for Collada 1.5 is not released yet and I don't think we want to use the SVN Head for 1.5 support. -- Roland On Mon, Dec 1, 2008 at 11:13 AM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Serge, I just changed the CMake files so I could develop the dae plugin in debug mode with a statically linked DOM. The CMake files still need to be changed so the user may specify the location of these dependencies (both debug and releas) by hand. Another possibility would be to automatically use the external-libs in the Collada DOM directory. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: maandag 1 december 2008 11:03 To: OpenSceneGraph Users Subject: Re: [osg-users] Request for testing Collada/dae plugin changes Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-threading bug related to Registry
Robert,
Note that Rick responded to your question although to the osg-users
Digest mail so it will probably not show as a follow up in your e-mail
box. See
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2
008-November/019505.html
Sorry for pushing you around, but I happen to be interested in the
outcome of this thread.
--
Roland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Robert Osfield
Sent: dinsdag 25 november 2008 15:08
To: OpenSceneGraph Users
Subject: Re: [osg-users] Multi-threading bug related to Registry
Hi Rick,
Just to confirm the issue, if you enable Registry caching of
imagery and use paged databases that have external image
files, then you get
the below crash. If you don't use the Registry cache what happens?
How reliably does this crash occur?
My hypothisis is that the object cache is being cleared by
another thread just at the wrong time for this particular
section of .ive plugin. If it is correct then use of
Registry::readImage(...) that returns a Registry::ReadResult
rather than a Image* would be safe as ReadResult uses
ref_ptr internally.
Robert.
On Tue, Nov 25, 2008 at 1:49 PM, Rick Appleton
[EMAIL PROTECTED] wrote:
Sorry for the delay on this.
Here's some more information. Below is a complete callstack
which should be similar to when the issue happened. Basically
we are loading a Paged terrain database which uses IVE files
for data, and DDS textures for images. A quick search in OSG
reveals that osgDB::readImageFile is called from many plugin
loaders, so I suspect they would have the same issue.
osg48-osgDBd.dll!osgDB::Registry::readImageImplementation(cons
t
std::basic_stringchar,std::char_traitschar,std::allocatorc
har fileName=textures/TxMosaic.dds, const
osgDB::ReaderWriter::Options * options=0x01f0ceb8) Line 1706C++
osg48-osgDBd.dll!osgDB::Registry::readImage(const
std::basic_stringchar,std::char_traitschar,std::allocatorc
har fileName=textures/TxMosaic.dds, const
osgDB::ReaderWriter::Options * options=0x01f0ceb8) Line 217
+ 0x14 bytes C++
osg48-osgDBd.dll!osgDB::readImageFile(const
std::basic_stringchar,std::char_traitschar,std::allocatorc
har filename=textures/TxMosaic.dds, const
osgDB::ReaderWriter::Options * options=0x01f0ceb8) Line 43 +
0x1d bytes C++
osgdb_ived.dll!ive::DataInputStream::readImage(std::basic_stri
ngchar,std::char_traitschar,std::allocatorchar
filename=textures/TxMosaic.dds) Line 950 + 0x44 bytesC++
osgdb_ived.dll!ive::DataInputStream::readImage(ive::IncludeIma
geMode mode=IMAGE_REFERENCE_FILE) Line 1003 + 0x2c bytes C++
osgdb_ived.dll!ive::DataInputStream::readImage()
Line 976 + 0xc bytes C++
osgdb_ived.dll!ive::Texture2D::read(ive::DataInputStream *
in=0x00dbec2c) Line 54 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readStateAttribute()
Line 1159 + 0xc bytesC++
osgdb_ived.dll!ive::StateSet::read(ive::DataInputStream *
in=0x00dbec2c) Line 173 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readStateSet()
Line 1066 C++
osgdb_ived.dll!ive::Node::read(ive::DataInputStream
* in=0x00dbec2c) Line 124 + 0x8 bytes C++
osgdb_ived.dll!ive::Geode::read(ive::DataInputStream
* in=0x00dbec2c) Line 67 C++
osgdb_ived.dll!ive::DataInputStream::readNode()
Line 1507 + 0x2d bytes C++
osgdb_ived.dll!ive::Group::read(ive::DataInputStream
* in=0x00dbec2c) Line 74 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readNode()
Line 1499 + 0xc bytes C++
osgdb_ived.dll!ReaderWriterIVE::readNode(std::basic_istreamch
ar,std::char_traitschar fin={...}, const
osgDB::ReaderWriter::Options * options=0x01f0ceb8) Line 98 +
0xb bytesC++
osgdb_ived.dll!ReaderWriterIVE::readNode(const
std::basic_stringchar,std::char_traitschar,std::allocatorc
har file=veluwe.ive, const
osgDB::ReaderWriter::Options * options=0x01efeb88) Line 69 +
0x23 bytes C++
osg48-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgD
B::ReaderWriter rw={...}) Line 1374 + 0x40 bytes C++
osg48-osgDBd.dll!osgDB::Registry::read(const
osgDB::Registry::ReadFunctor readFunctor={...}) Line 1527
+ 0x22 bytes C++
osg48-osgDBd.dll!osgDB::Registry::readImplementation(const
osgDB::Registry::ReadFunctor readFunctor={...}, bool
useObjectCache=true) Line 1596 + 0x13 bytes C++
osg48-osgDBd.dll!osgDB::Registry::readNodeImplementation(const
std::basic_stringchar,std::char_traitschar,std::allocatorc
har fileName=veluwe.ive, const
osgDB::ReaderWriter::Options * options=0x01efeb88) Line 1814
+ 0x57 bytes C++
osg48-osgDBd.dll!osgDB::Registry::readNode(const
std::basic_stringchar,std::char_traitschar,std::allocatorc
har
[osg-users] Request for testing Collada/dae plugin changes
Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] extracting heading, pitch, roll from rotation matrix...
Shayne,
After retrieving the Quat orientation with getRotate you can use this
snippet:
osg::Vec3d getHPRfromQuat(osg::Quat quat){
// From: http://guardian.curtin.edu.au/cga/faq/angles.html
// Except OSG exchanges pitch roll from what is listed on that
page
double qx = quat.x();
double qy = quat.y();
double qz = quat.z();
double qw = quat.w();
double sqx = qx * qx;
double sqy = qy * qy;
double sqz = qz * qz;
double sqw = qw * qw;
double term1 = 2*(qx*qy+qw*qz);
double term2 = sqw+sqx-sqy-sqz;
double term3 = -2*(qx*qz-qw*qy);
double term4 = 2*(qw*qx+qy*qz);
double term5 = sqw - sqx - sqy + sqz;
double heading = atan2(term1, term2);
double pitch = atan2(term4, term5);
double roll = asin(term3);
return osg::Vec3d( heading, pitch, roll );
}
--
Roland
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: zaterdag 22 november 2008 0:52
To: OpenSceneGraph Users
Subject: [osg-users] extracting heading, pitch, roll from
rotation matrix...
Is there any method or class in OSG that extracts heading,
pitch, and roll angles from a rotation matrix?
I've searched and haven't seen anything. I just want to make
sure there isn't anything out there before I embark on writing my own...
Thanks in advance,
-Shayne
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Normals and setScale
If your initial normals are correctly normalized you may also use GL_RESCALE_NORMALS. This will rescale the normals instead of the more expensive normalization that is done when GL_NORMALIZE is enabled. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: donderdag 20 november 2008 10:03 To: a.lagnier; OpenSceneGraph Users Subject: Re: [osg-users] Normals and setScale Hi, Just make a search on GL_NORMALIZE on this list and you'll get your answer. :) On Thu, Nov 20, 2008 at 10:00 AM, a.lagnier [EMAIL PROTECTED] wrote: Hi, When I call setScale() on an pat. Its normals seem to be affected. I want to keep normalization of normals. How can I solve this problem? I will appreciate any hints. Thanks you Créez votre adresse http://www.laposte.net électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Normals and setScale
osg/Transform defines it if not available #ifndef GL_RESCALE_NORMAL #define GL_RESCALE_NORMAL 0x803A #endif -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of a.lagnier Sent: donderdag 20 november 2008 10:18 To: OpenSceneGraph Users Subject: Re: [osg-users] Normals and setScale GL_RESCALE_NORMALS is undefined in gl.h ... Message du 20/11/08 10:09 De : Smeenk, R.J.M. (Roland) A : OpenSceneGraph Users Copie à : Objet : Re: [osg-users] Normals and setScale If your initial normals are correctly normalized you may also use GL_RESCALE_NORMALS. This will rescale the normals instead of the more expensive normalization that is done when GL_NORMALIZE is enabled. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: donderdag 20 november 2008 10:03 To: a.lagnier; OpenSceneGraph Users Subject: Re: [osg-users] Normals and setScale Hi, Just make a search on GL_NORMALIZE on this list and you'll get your answer. :) On Thu, Nov 20, 2008 at 10:00 AM, a.lagnier [EMAIL PROTECTED] wrote: Hi, When I call setScale() on an pat. Its normals seem to be affected. I want to keep normalization of normals. How can I solve this problem? I will appreciate any hints. Thanks you Créez votre adresse http://www.laposte.net électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html [ (pas de nom de fichier) (0.2 Ko) ] Créez votre adresse http://www.laposte.net électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slave views
Yes, the crash a known issue. As a quick workaround we might add switching to a singlethreaded threadingmodel automatically in the StatsHandler when activating the scene statistics. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Spilling Sent: woensdag 19 november 2008 14:26 To: OpenSceneGraph Users Subject: Re: [osg-users] Slave views Alberto, When compiling against SVN, the two are shown, but a crash happens when pressing 's' several times I think (someone correct me if I'm wrong) that this is a known issue, and something to do with the thread safety of the stats handler, and/or NVIDIA drivers. If the former is still the case, then running single-threaded might help. Try searching the archives for crash and stats. David This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-threading bug related to Registry
Hi Rick, it looks like Robert Osfield missed this post otherwise he already would have reacted to it. ;) -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Appleton Sent: maandag 17 november 2008 14:24 To: osg-users@lists.openscenegraph.org Subject: [osg-users] Multi-threading bug related to Registry There is a nasty multi-threading bug related to osgDB::DatabasePager and the _objectCache in osgDB::Registry. This is the situation. * Thread 2 stack (DatabasePager thread): ReaderWriter::ReadResult Registry::readImplementation ReaderWriter::ReadResult Registry::readImageImplementation ReaderWriter::ReadResult Registry::readImage osg::Image* osgDB::readImageFile osg::Image* DataInputStream::readImage(std::string filename) osg::Image* DataInputStream::readImage(IncludeImageMode mode) osg::Image* DataInputStream::readImage() void Texture2D::read(DataInputStream* in) .. - After reading in the file in Registry::readImplementation the refCount of the new Image is 1 (ReadResult contains a ref_ptr). - This Image is then inserted into Registry::_objectCache with the default timestamp (0.0), which increments the recCount to 2. - The ReadResult object is returned, so no net change in refCount, until the stack is unwound up to osgDB::readImageFile. - osgDB::readImageFile takes a normal pointer to the Image, which does not change the refCount. When osgDB::readImageFile returns, the ReadResult object goes out of scope, deleting a reference to the Image. refCount is now 1. - Stack unwinds until back in Texture2D::read at which point the normal Image* is passed into Texture2D::setImage which assigns the Image* to the internal ref_ptr. At this moment the refCount is increased back to 2. Imagine that somewhere during the stack unwind between osgDB::readImageFile and Texture2D::read a thread switch takes place. * Thread 1: The main thread then reaches DatabasePager::removeExpiredSubgraphs which does the following at the end of the function. - Calls Registry::updateTimeStampOfObjectsInCacheWithExternalReferences, which goes through the objects and increments the timestamp if the refCount1 (this is not true for just loaded Image, so timestamp remains 0.0). - Calls Registry::removeExpiredObjectsInCache, which goes through all the objects and compares the timestamp with the expiry time. Because the Image was added with timestamp 0.0 (and the timestamp was not updated), it is added to objectsToRemove. - Registry::removeExpiredObjectsInCache then removes all the objects in objectsToRemove from Registry::_objectCache. This causes the refCount on the Image to decrement to 0, causing the actual Image object to be freed. At this point Thread 2 has an Image* to freed memory, but does not realize the object has been freed. In our case this eventually led to crashes. There are two solutions to this: - Instead of using the default timestamp of 0.0, set the time explicitly to the current time. This makes sure the item is not immediately discarded from the Registry. Even if not all loads are finished before the new item times out, the item will have been acquired by some other place in the code, so the refCount will be larger than 1 when the timeout occurs. This requires the current time to be passed into readImplementation. A proper solution would be to pass in the timestamp of the DatabaseRequest into the read* functions. That requires modification of a lot of functions though. - Changing the return types of the sequence above so there aren't any normal osg::Image* passed around, but only ref_ptr. This makes sure that refCount never goes to during the loading process. This option also requires the modification of a large number of functions. We chose a slightly less proper solution following the first option. We've added a function to set the time in Registry once a frame, and call that just before DatabasePager::updateSceneGraph (which calls DatabasePager::removeExpiredSubgraphs). Please feel free to contact me for more info as needed, Rick This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PNG and Collada
I am currently refactoring the Collada plugin and ran into this problem
last week. I solved it, though not in a really satisfactory way.
Hopefully I will have the refactored plugin available for submission
coming week.
kind regards,
Roland Smeenk
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
alessandro terenzi
Sent: zaterdag 15 november 2008 12:09
To: OpenSceneGraph Users
Subject: [osg-users] PNG and Collada
I'm experiencing some problem with collada models and
transparency texture maps. I saw that in May someone had the same
problem but finally I couldn't find a solution. I tried with osg2.2.0
and 2.6.0 and it looks like that transparency doesn't work with collada
models and png texture maps.
I checked Robert's suggestion and converted to .osg to check if
GL_BLEND function was enabled or not and it looks like it is... here
follow a piece of the converted .osg file.
Geode {
name material10
nodeMask 0x
cullingActive TRUE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_BLEND ON
Material {
ColorMode OFF
ambientColor 0 0 0 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0.33 0.33 0.33 1
emissionColor 0 0 0 1
shininess 20
}
BlendFunc {
source CONSTANT_ALPHA
destination ONE_MINUS_CONSTANT_ALPHA
}
BlendColor {
constantColor 1 1 1 1
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file images/texture9.png
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter NEAREST_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
}
}
[...gemoterty data follow here...]
Is there something wrong with this file?
Someone talked about a problem in Sketchup with png files,
actually the models I'm dealing with come from Sketchup...is there
really a problem with Sketchup? Someone talked about a 'GoogleMode' in
the collada plugin but it looks like it is an option used for writing
collada files not for reading.
Thank you for any advice or direction.
Alessandro
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamically changing all textures in a scene
A long long time ago somebody posted source code for osgDepictions, which allows you to do a texture/stateset switch for a complete scene. I could not find it in the mailing list archives though... -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Linus Hilding Sent: woensdag 12 november 2008 10:55 To: OpenSceneGraph Users Subject: [osg-users] Dynamically changing all textures in a scene Hi, I would appreciate some advice on how to best use the osg functionality, in order to be able to dynamically change every single texture in a scene, depending on the view. Every view in the scene should have the possibility to either use original textures or alternative (infrared) versions. An approach where we do not have to use switches between duplicate scenes would be preferred. Greatful for any ideas. Regards, Linus Hilding ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hello Robbert, The SVN version is missing the changes (ReadQueue definition) to the Databasepager header file. -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: zondag 15 juni 2008 18:03 To: OpenSceneGraph Users Subject: Re: [osg-users] New Improved DatabasePager,now with even more threading! Please take a taste today :-) Hi Guys, While away on training last week, we came across the Windows debug build reporting problem in std::sort and find calls, and investigations into the issue suggested that it was down to the cull thread modifying the DatabaseRequest fields at the same time that those same fields were being used inside the std algorithms being run by the DatabasePager threads. The worst thing that would actually happen is that very occassionally the list would be sorted into incorrect order, but this in itself would only lead to a slightly sub-optimial ordering of loading tiles, it shouldn't actually break any app - so it's really more of an issue with the debugger being overly strict rather than having a serious race condition that would cause real problems. However, even having a benign, occasional, slightly sub-optimal ordering is a problem if end users under Windows are going to keep stumbling over this issue to due to compiler debugging screaming that there is a serious problem and crashing - so it's a community support problem rather than actual a real problem for proper applications, but having more support than we already have is an issue so I've gone ahead and found a solution. Now checked into SVN is an addition of a mutex lock on the current queue that a DatabaseRequest is a member inside the code that updates the DatabaseRequest parameters. This fix should prevent the problems appearing under VisualStudio debug build, it alas will also mean that all users will have to pay the cost of an non essential mutex lock. Could you guys do an svn update and let me know how things go. Robert. On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it
Re: [osg-users] Back online but hundreds of posts to go...
Paul, Actually I moved over the FAQ to the actual location and yes I do all of my editing as generic osg user. That's how I moved the tutorials into the wiki, added the list of environment variables, updated the job offers page, added the example screenshots, tabelized the plugins overview and changed the FAQ's recently. I am willing to start using my name as login. We should add a Wiki editing policy page that mentions this and other editing tips like adding a description when you change a page. However I believe that the step for editing the wiki should be kept as low as possible and account creating might increase it. It is more important to get it filled with usefull content first. -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: donderdag 8 mei 2008 9:51 To: OpenSceneGraph Users Subject: Re: [osg-users] Back online but hundreds of posts to go... I noticed that somebody (presumably Robert) moved the cleaned up FAQ in the sandbox to be the actual FAQ on the website. This is fine by me, as it was good enough compared to the previous version. But at least let me know you did this, whoever it was... Paul PS Having everybody edit the wiki under user osg doesn't help there. Perhaps we should allow account creation on the wiki? Mike Weiblen wrote: Haven't had a chance to review, but Thank You Very Much for moving this forward! -- mew Thanks :) I made some more changes, mostly edits and moving things around. I noticed the really nice page containing the file format overview! It's linked from the FAQ now. Here and there I added lines marked with XXX to indicate some stuff that needs to be expanded/clearified/etc. For some topics I feel I'm not the one with all the details. BTW, there's some different usage of OSG, OpenSceneGraph, the OpenSceneGraph, etc. Perhaps we should get these consistent. Would referring to The OpenSceneGraph be the best variant? Paul PS Updated FAQ is still in the sandbox for now On Wed, May 7, 2008 at 11:33 AM, Paul Melis [EMAIL PROTECTED] wrote: I did an initial restructuring in the wiki Sandbox. See http://www.openscenegraph.org/projects/osg/wiki/SandBox/FAQ Let me know what you think. Paul Robert Osfield wrote: Hi Paul, I must admit not having given the FAQ much attention in the last year. It would be good to start updating it/reorganising it. I'm fully open to suggestions on how to improve it and assistance with improving it. I'd suggest kicking out a separate thread for this. Robert. It seems that a percentage of the posts on the lists can be considered straight items from the FAQ on the website. I recently did a bit of editing on the FAQ as it isn't really the most readable piece on the site. Particularly, I updated some stuff that seemed to reference OSG versions when Producer was still used, deleted/replaced broken URLs and fixed some wording and spelling. However, I stil think it can be improved and hopefully make more people consult it before posting to the list. Things I had in mind: - Structure the items in a few sections (e.g. Introduction/Overview, Building/Installation, File formats, General development, Linux-specific, Windows-specific, etc) - Update the list of file formats to include information on read/write support of all plugins - osgViewer seems to be responsible for a fair amount of posts, perhaps it deserves its own section in the FAQ? Now, I don't have enough knowledge of every piece of OSG to edit all the entries, but I'd be happy to continue improving the FAQ. I didn't see an easy way for structuring, as currently an automatically generated overview of the questions is used. Any tips there? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap h.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegra ph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap h.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-opensce negraph.org This e-mail and its contents are
Re: [osg-users] Back online but hundreds of posts to go...
Paul, It's a good thing that people spend time to update the wiki, especially with up-to-date content, but I don't like somebody moving stuff purposely put in a preliminary location. I understand your feelings, but I think it is better to keep a single version of the same content even if it is in progress. Someone else might make the rest of the changes and it reduces the risk of all kinds of in progress pages dangling on the wiki. Furthermore it prevents the need for merging when in the meantime others start editing the original content. However I believe that the step for editing the wiki should be kept as low as possible and account creating might increase it. It is more important to get it filled with usefull content first. It should, but as more people start to edit the wiki using the same user account it will only become more difficult to keep track of who did what, or who is still working on what. True, but as you say this will become more relevant as more people start editing the wiki. When we have 10+ wiki edits a day it might require some more formalized way of allowing edits, but for now I don't see a problem here. Anyway I will be away for a week so I will not further participate in this discussion on wiki editing. I think editing the wiki itself is far more important than discussing it... warmest regards, Roland Smeenk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: donderdag 8 mei 2008 9:51 To: OpenSceneGraph Users Subject: Re: [osg-users] Back online but hundreds of posts to go... I noticed that somebody (presumably Robert) moved the cleaned up FAQ in the sandbox to be the actual FAQ on the website. This is fine by me, as it was good enough compared to the previous version. But at least let me know you did this, whoever it was... Paul PS Having everybody edit the wiki under user osg doesn't help there. Perhaps we should allow account creation on the wiki? Mike Weiblen wrote: Haven't had a chance to review, but Thank You Very Much for moving this forward! -- mew Thanks :) I made some more changes, mostly edits and moving things around. I noticed the really nice page containing the file format overview! It's linked from the FAQ now. Here and there I added lines marked with XXX to indicate some stuff that needs to be expanded/clearified/etc. For some topics I feel I'm not the one with all the details. BTW, there's some different usage of OSG, OpenSceneGraph, the OpenSceneGraph, etc. Perhaps we should get these consistent. Would referring to The OpenSceneGraph be the best variant? Paul PS Updated FAQ is still in the sandbox for now On Wed, May 7, 2008 at 11:33 AM, Paul Melis [EMAIL PROTECTED] wrote: I did an initial restructuring in the wiki Sandbox. See http://www.openscenegraph.org/projects/osg/wiki/SandBox/FAQ Let me know what you think. Paul Robert Osfield wrote: Hi Paul, I must admit not having given the FAQ much attention in the last year. It would be good to start updating it/reorganising it. I'm fully open to suggestions on how to improve it and assistance with improving it. I'd suggest kicking out a separate thread for this. Robert. It seems that a percentage of the posts on the lists can be considered straight items from the FAQ on the website. I recently did a bit of editing on the FAQ as it isn't really the most readable piece on the site. Particularly, I updated some stuff that seemed to reference OSG versions when Producer was still used, deleted/replaced broken URLs and fixed some wording and spelling. However, I stil think it can be improved and hopefully make more people consult it before posting to the list. Things I had in mind: - Structure the items in a few sections (e.g. Introduction/Overview, Building/Installation, File formats, General development, Linux-specific, Windows-specific, etc) - Update the list of file formats to include information on read/write support of all plugins - osgViewer seems to be responsible for a fair amount of posts, perhaps it deserves its own section in the FAQ? Now, I don't have enough knowledge of every piece of OSG to edit all the entries, but I'd be happy to continue improving the FAQ. I didn't see an easy way for structuring, as currently an automatically generated overview of the questions is used. Any tips there? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap h.org
Re: [osg-users] Load all 6 images from cubemap dds.
OK, will take a look at it this evening. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: woensdag 7 mei 2008 10:51 To: OpenSceneGraph Users Subject: Re: [osg-users] Load all 6 images from cubemap dds. Hi Joakim and Roland, On Mon, May 5, 2008 at 6:46 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Joakim, I sent in a submission last year for loading complete cubemaps from DDS files. That submission affects important parts of the osg core and therefore Robert put it on the stack, which in practice means that it won't be merged soon. This is a good reminder. Now we have stable release out of the way its not a bad time to start considering changes that might require more widespread changes. Roland could you have have a go at migrating your changes to 2.4/SVN and then resubmit. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG tutorials available
Franclin, Do you mean the tutorials in the Wiki? Please feel free to update/attach the sources in the Wiki to work with OSG 2.4. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franclin Foping Sent: woensdag 7 mei 2008 12:17 To: osg-users@lists.openscenegraph.org Subject: [osg-users] OSG tutorials available Hi, I am currently compiling some OSG tutorials for newbies. I think to be through next week. However, I would like to know how I can publish them on the official website so that every user can use them? Waiting for your answer. Regards, Franclin. __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : Re: OSG tutorials available
See http://www.openscenegraph.org/projects/osg/wiki/Community/WikiLogIn For login details. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franclin Foping Sent: woensdag 7 mei 2008 14:44 To: OpenSceneGraph Users Subject: [osg-users] RE : Re: OSG tutorials available Dear Roland, Thanks a lot for your hint. I will have a go at the wiki tomorrow. If I manage to find out how to upload the sources and tutorials, I will do it. Otherwise, I will post a message here on the forum. Regards, F. Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] a écrit : Franclin, Do you mean the tutorials in the Wiki? Please feel free to update/attach the sources in the Wiki to work with OSG 2.4. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franclin Foping Sent: woensdag 7 mei 2008 12:17 To: osg-users@lists.openscenegraph.org Subject: [osg-users] OSG tutorials available Hi, I am currently compiling some OSG tutorials for newbies. I think to be through next week. However, I would like to know how I can publish them on the official website so that every user can use them? Waiting for your answer. Regards, Franclin. __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load all 6 images from cubemap dds.
Joakim, I sent in a submission last year for loading complete cubemaps from DDS files. That submission affects important parts of the osg core and therefore Robert put it on the stack, which in practice means that it won't be merged soon. kind regards, Roland Smeenk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joakim Simonsson Sent: maandag 5 mei 2008 15:03 To: osg-users@lists.openscenegraph.org Subject: [osg-users] Load all 6 images from cubemap dds. Hi, I have a dds file containing a cube map, that is six images that are embedded in the file. However, when I read it: osg::ref_ptrosg::Image image = osgDB::readImageFile(cubemap.dds); the image returned is only the FIRST image of the embeded images. Is there a way to load the other 5 images? -- Joakim Simonsson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Feedback sought on osgViewer swap ready support forclusters
Hi Robert, we've been looking at clustering too. I've added the extension querying to the GraphicsWindowWin32 and GraphicsWindowX11 and a joinSwapGroup method to the GraphicsWindow. I had this code waiting for submission for a few weeks now, but due to this thread I feel urged to get the code out first. We still need to test our cluster properly (on Linux) and will probably be doing this in the coming weeks. Changes were done against OSG2.2. kind regards, Roland Smeenk From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: maandag 14 april 2008 11:40 To: OpenSceneGraph Users Subject: [osg-users] Feedback sought on osgViewer swap ready support forclusters Hi All, I'm looking for feedback from users who have worked on clusters that implement some forms of swap ready synchronization. In particular I'm looking at any hooks into osgViewer to allow users to implement their own swap ready implementation, also a software based swap ready could possibly be implemented as part of the core OSG as well. The hook to adding a swap ready barrier into the view would look something like: viewer.setSwapReadyOperation(myCustomSwapReadyOperation); Something like complicates the mater is that viewer on each slave of the cluster might have more than one graphics context that its rendering too, so in this case we'll have multiple graphics threads per slave, in which case these threads will need to join a barrier that treats each context like a separate machine or the barrier does a local synchronization of the threads on a machine before joining the cluster swap ready barrier. I want to come up with a scheme that supports both ways above, but really need a bit more feedback on what goes into users own swap ready codes, i.e. what would your MyCustomSwapReadyOperation look like, i.e. what does it look right now, this will help me better understand how the most appropriate integration into osgViewer could be done. Robert. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html osgViewer.rar Description: osgViewer.rar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.4 dev and VirtualPlanetBuilder-0.9.5dev releases tagged.
VPB-0.9.5 Details on: http://www.openscenegraph.org/projects/VirtualPlanetBuilder Robert, You forgot to upload the 0.9.5 zip file to the wiki. Anyway, enjoy your vacation. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
On the original subject - tutorials. There's a huge list of examples all needing maintenance already. Why not let the tutorials emerge from the community (like the NPS tutorial and others) and let them be maintained by the community. All it takes is a platform (like the Wiki) that is guaranteed to be available in the future. It seems to me one tends to keep things centralized and under control of few and therefore increasing the weight that those few shoulders need to carry. That's not what I see as a community effort. Distribute the weight so we can all contribute... Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: maandag 27 augustus 2007 11:15 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials On the hijacked tutorial subject - forum and/or email list A forum is an online activity whilst an email list is an offline activity, which means that I can get on with other things rather constantly watching a forum window for a critical reply - such as actually figuring out a solution for myself and learning something in the process. On the original subject - tutorials. My experience is that tutorials as far as possible should be part of the main source code, because they become the test harnesses of the main code - if they don't work then something is wrong and needs to be fixed. Also it keeps the tutorials refreshed and working with the evolving interfaces. The real trick is then to not to go wild on the production of new tutorials if existing tutorials can be extended to demonstrate new features, otherwise we could end up with even more of a maintenance headache. PhilT -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield Sent: 27 August 2007 09:59 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials Hi Rick, The forum vs mailing list issue has been done to death many times. Some people swear by forums, some detest them, some people swear by mailing lists, some others detest, others don't care. Having mailing lists *and* forums just splits the community and critically those delving out support. There is absolutely no way on earth I can afford my time to be stretched out any further, and my guess others are in a similar boat. For this reason you won't be finding me or many others on the forums or IRC channels, and without the driving forces being the OSG being one these channels of support they won't of little use. Since splitting damages the communities ability to provide support and to generally function, then one really has to keep community in one place, this should either be a mailing list OR a forum OR and this would be my ideal a system where users can choose to doing either use mailing list or a forum. Provision of such as system is not a trivial matter, and something than members of the community will have to step up to help provide as I don't have the expertise or the resources to provide it myself. Robert. On 8/27/07, Ricko 3D [EMAIL PROTECTED] wrote: Thanks for the quick response. Seems funny to say anything is here to stay related to any constantly evolving technology project, or anything related to the Internet. I was just offering my observations coming at this project fresh. My opinion was simply that the mailing list method seems outdated. I wasn't suggesting it is not effective, just comparing it to the features/benefits of newer community technologies I've used on other projects. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
I just copied all NPS tutorials into the Wiki. There's a number of things that still need editing: -Conversion to OSG2.0 -Addition of source zip files -Addition of screenshots -Addition of links to related stuff (Api reference, examples and User guides) Robert, I read in the Wiki that it is possible to automatically add syntax coloring if GNU Enscript or SilverCity (preferred) are installed. I would like to see this installed? Furthermore CamelCasing in the Trac Wiki has bitten me more than it helped me, because I had to disable all Wiki linking on StateSets, MatrixTransforms etc. Could this be turned off? Kind regards, Roland Smeenk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sullivan, Joseph (CDR) Sent: donderdag 23 augustus 2007 0:39 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials Hey All, Congrats and big thanks to those that have been adding documentation! I've been largely away from OSG for a while, but the work looks mighty impressive. I think Robert's question about different users is the key. The examples are absolutely fantastic and work great for some, not so great for others. Tutorials seem to be a helpful bridge. (The original goal of the NPS tutorial set was to get students w/out engineering background comfortable enough to dive into the examples.) Soo... What does it take to move the tutorials currently on the NPS web site over to the osg wiki site? Is there anybody that can spare some resources to help the effort? Thanks, Joe S. -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, August 22, 2007 11:55 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials On 8/22/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: Are the examples of no use to any one??? Shall I just do a svn rm examples ? No, they very much are. :) It's just that those of us that DO use the examples don't post here saying so... Its O.K. I'm not serious about to remove them, just frustrating my frustration at big chunks of work that is dedicated to helping new users being ignored. As far as example usefulness is concerned, no news is good news. Honestly, in contrast to the entire discussion at hand, I _rarely_ use documentation. I always just look at the code. Documentation in a formal sense makes me want to take a nap... In other projects I do occasionally look for documentation, but rarely does it help me more than a succinct code example. If you are experienced programmer than its the code that tells you everything. It would be interesting to do a profile of different users to see what types of assistance to get their programs written they find most effective. When I say assistance I mean documentation, mailing list archives, examples, code comments, code itself, class naming, method naming. I do wonder if too many developers these days are expecting to put in too little real effort for the amount of results they are wanting. Programming is hard. Real-time graphics is a BIG topic. To master them you have lavish lots of time. When I first started programming as a kid there was just practically nothing available relative to today, I didn't know any better, I enjoyed in a perverse way learning by myself how to code Z80 assembler. Yes it took weeks just to get a few coloured sprites animating across the screen, but I didn't go ranting at anyone for lack of guidance and docs, I just enjoyed figuring it out and getting the final result. Fast forward to today and the with 10 lines of code in the OSG you can create and load a terabyte sized 3D world and interact with it at a solid 60Hz. But yet some people seem to expect more much more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader and illumination
Try to output individual components first for debugging.
For instance output the normal x,y and z as colors.
--
Roland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Marcus Fritzen
Sent: maandag 20 augustus 2007 14:21
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] shader and illumination
Hello,
I have a quick question ;)
At the moment I am playing a little bit with lighting and
material and therefore I tried to use a shader. I set up a
simple shapeDrawable
(sphere) and a vertex and fragment program. The code for the
shaders I found in a tutorial. It is posted bellow. I also
enabled lighting und light0 and set up values for these. What
I get is really not phong. Just some real white and black.
Could there be a problem with the normals?
Greetings,
Marcus
VERT
varying vec3 normal;
varying vec3 v;
varying vec3 lightvec;
void main(void)
{
normal = normalize(gl_NormalMatrix * gl_Normal);
v = vec3(gl_ModelViewMatrix * gl_Vertex);
lightvec= normalize(gl_LightSource[0].position.xyz - v);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
FRAG
varying vec3 normal;
varying vec3 v;
varying vec3 lightvec;
void main(void)
{
vec3 Eye = normalize(-v);
vec3 Reflected = normalize( reflect( -lightvec, normal ));
//hat den selben effekt wie
//vec3 Reflected = normalize( 2.0 * dot(normal, lightvec) *
normal - lightvec);
vec4 IAmbient= gl_LightSource[0].ambient;
vec4 IDiffuse= gl_LightSource[0].diffuse * max(dot(normal,
lightvec), 0.0);
vec4 ISpecular = gl_LightSource[0].specular *
pow(max(dot(Reflected, Eye), 0.0), gl_FrontMaterial.shininess);
gl_FragColor = gl_FrontLightModelProduct.sceneColor
+ IAmbient
+ IDiffuse + ISpecular;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
