What steps will reproduce the problem?

1. Open "Test Case - Glass Wall and Boxes.max" under 3ds Max 2010
2. Export using OpenCollada
3. Import file from step 2 using OpenCollada
4. Notice light settings have been lost

What is the expected output? What do you see instead?
Exporting and re-importing a file should result in the original model.

What version of the product are you using? On what operating system?
OpenCollada 1.2.5 or 1.3.0 RC under 3ds Max 2010 64-bit mode.

Please let me know if you can reproduce the problem.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=70

earlier comments

opencollada said, at 2010-04-22T07:12:06.000Z:

Support for not supported during import. Will be included as soon as the custom extra tag handling is finalized for the OpenCOLLADA profile.

cowwoc%[email protected] said, at 2010-04-22T22:54:09.000Z:

Hi Sebastian,

Is there an issue number for the extra tag handling? Is this expected in the short or
long term?

Can't change UP direction throu export dialog.
(Very useful for content developing.)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=31

earlier comments

[email protected] said, at 2009-11-24T08:30:28.000Z:

Will be added in future.

1. Create biped object in 3ds max (Create->Systems->Biped)
2. Export scene using OpenCOLLADA exporter

In exported COLLADA file all of the scene nodes have type='NODE', but all
of them are 'JOINT's.
Only nodes used in skin controller(s) have type='JOINT'.

3ds max 9, Windows XP SP2

Migrated from http://code.google.com/p/opencollada/issues/detail?id=50

What steps will reproduce the problem?

1. In Maya, create and animate a box with two keyframes.
2. Create a namespace, and add the box to it.
3. Export the Collada file.

What is the expected output? What do you see instead?
Expected: Animation data that references the object definition in
<library_visual_scenes>.

Instead: The object name defined in <library_visual_scenes> contains the
namespace as part of its name (i.e. namespace_box1). However, the
animation data references the target object without the namespace pre-
pended to the name. (i.e. box1). This prevents box1 from receiving the
animation information.

What version of the product are you using? On what operating system?
From 'trunk' on 3/11/2010.
Using Windows x64.

Please provide any additional information below.

I was able to temporarily fix this by making the following change
in 'COLLADAMayaAnimationExporter.cpp' on line 1292:

Before:
else nodeId = mDocumentExporter->mayaNameToColladaName (
fnDagNode.name ().asChar ());

After:
else nodeId = mDocumentExporter->mayaNameToColladaName (
fnDagNode.name ().asChar (), false );

Migrated from http://code.google.com/p/opencollada/issues/detail?id=72

earlier comments

[email protected] said, at 2010-10-14T22:37:26.000Z:

we're running into a similar show-stopper. The name space is getting into our animation channels... and thus all of our animations are breaking.

Any updates on this?

We're using the latest release of OpenCollada, in Maya 2011 32bit.

[email protected] said, at 2011-09-28T20:49:24.000Z:

This is affecting us as well. If we commit the source change proposed by the op's, can that be integrated into the next build?

This issue is rather a feature request

What steps will reproduce the problem?

1. Exporting a Model with a normal map in 3ds max
2. Import it in your own framework using your own IWriter implementation
3. The normal map will appear in it's own OpenCollada-Max extra profile in
   the DAE file

What is the expected output? What do you see instead?

The normal map is being recognized and registered in the appropriate
(currently not existing) field of the Common Effect class.
Instead, the sampler is recognized in the image library, but it isn't
possible to link it from the appropriate material, as the required
SamplerID isn't existant in the EffectCommon class ( SamplerPointerArray ).

What version of the product are you using? On what operating system?

1.5, Visual C++ 08, Windows Vista x64

Please provide any additional information below.

A possible workaround is to store your normal maps in the emission field,
as it is not required for most applications. However, this is a rather
important feature.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=67

earlier comments

opencollada said, at 2010-04-12T18:14:13.000Z:

Candidate for an tag.

[email protected] said, at 2010-04-14T11:47:06.000Z:

See http://code.google.com/p/opencollada/issues/detail?id=59 for a patch which solves at least the export in extra tag problem (for normal maps as well for a couple of other maps).

Any idea when that patch gets applied and a new build is uploaded? It's inconvenient
to use custom builds for months.

[email protected] said, at 2011-01-19T15:38:21.000Z:

Probably fixed with issue 59. Please verify.

What steps will reproduce the problem?
Export a morph target mesh from Maya2010 using COLLADAMaya 1.2.2.674 exporter.

What is the expected output? What do you see instead?
It should deform such that the mesh is still consistent. Instead the mesh will deform and holes will show as it does.

What version of the product are you using? On what operating system?
Maya 2010, COLLADAMaya 1.2.2.674, Windows XP

Migrated from http://code.google.com/p/opencollada/issues/detail?id=95

What steps will reproduce the problem?

1. Load a Max model with notes in its global tracks
2. Export it

What is the expected output? What do you see instead?
A dae file with the notes attached to its animations.

What version of the product are you using? On what operating system?
XP, Max 2010, OpenCollada 1.2.3

Please provide any additional information below.
I don't know whether Collada supports it, but since Max doesn't support
multiple animations we used to use the notes to "label" the animtracks.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=10

Community request by Christophe

> Is there a stable developer version of opencollada i could use ?
> There seems to be a lot of validations in the last recent weeks (which is
a good thing!) but it would be nice to have in addition to release numbers
(r601, r602, r603, ...) stable version numbers...

and Erwin
> Do you plan on uploading some 'stable' source code release on
opencollada.googlecode.com in the Download section?
> And then include a hello-world example that just compiles, links and runs
out-of-the-box, using expat and no boost?
> (for example the StreamWriterSample and frameWorkLoaderNull you send me
earlier)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=3

earlier comments

[email protected] said, at 2010-03-07T11:02:48.000Z:

hi

is there any update on these requests? (currently looking into replacing our FCollada-
based pipeline with opencollada)

thanks for your efforts and kind regards,
simon

opencollada said, at 2010-03-07T11:09:45.000Z:

If you do not require the new Kinematics interfaces the current trunk (r736) is safe to use. No major API breaks will be committed in the near future.

[email protected] said, at 2011-11-12T22:55:17.000Z:

I'm thinking about adding opencollada to Gentoo, what should I use as snapshot target?

[email protected] said, at 2011-11-15T17:06:21.000Z:

i recently packaged r864 for a commercial app, no issues so far...

The OpenCOLLADA Max plugin does not export specular level.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=29

earlier comments

[email protected] said, at 2011-01-19T19:09:29.000Z:

FCollada/ColladaMax plugin did it this way: ...

In OpenCollada it's like this, without the level:

Please add support for this, thank you!

What steps will reproduce the problem?

1. Set loader object flags as below :
   int objectFlags =
   COLLADASaxFWL::Loader::SCENE_FLAG |
   COLLADASaxFWL::Loader::VISUAL_SCENES_FLAG |
   COLLADASaxFWL::Loader::LIBRARY_NODES_FLAG |
   COLLADASaxFWL::Loader::GEOMETRY_FLAG |
   COLLADASaxFWL::Loader::EFFECT_FLAG |
   COLLADASaxFWL::Loader::ANIMATION_FLAG |
   COLLADASaxFWL::Loader::IMAGE_FLAG |
   COLLADASaxFWL::Loader::MATERIAL_FLAG;
   saxLoader.setObjectFlags ( objectFlags );
2. Load a document A.dae which references a node in a document B.dae
   (external reference). B.dae has one <library_nodes> element which contains
   the referenced node. A.dae does not have any <library_nodes> element.

What is the expected output? What do you see instead?
writeLibraryNodes() should be called once when B.dae is parsed
But it is not. If saxLoader.setObjectFlags is not called, then
writeLibraryNodes is called

What version of the product are you using? On what operating system?
The latest trunk

Please provide any additional information below.
The problem seems to come from the class variable Loader::mParsedObjectFlags.
If i reset this variable to 0 just before the parsing of the second file,
then it works

Migrated from http://code.google.com/p/opencollada/issues/detail?id=41

earlier comments

[email protected] said, at 2009-12-18T10:06:56.000Z:

This mechanism to select which parts of a COLLADA should be loaded is not mature. It still requires some work. However, you code should also work, if do not set these flags. Their only purpose is to improve performance by not parsing Part that would be ignored by your software.

Since prior versions of SketchUp exported wrong values for transparency
into COLLADA files, the Max plug-in contains a workaround to fix thi son
import, evaluating the <creator> element and checking for "Google
SketchUp". In current versions of SketchUp this seems to be fixed, therefor
the version of the creating SketchUp needs to be evaluated in the workaround.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=26

I'm using the 3dsmax2009 plugin

the coordinate paramters of the material (UV offset and UV tiling, etc.)
does not get exported, unlike the fcollada colladamax exporter which
exports them correctly

so If you make a box, and define e material with 2.0 U tiling, and assign
it to the box, you won't have the correct data in the COLLADA file

Migrated from http://code.google.com/p/opencollada/issues/detail?id=14

earlier comments

[email protected] said, at 2009-10-20T09:18:31.000Z:

The information (UV offset and UV tiling, etc.) you are missing is not supported by COLLADA. The only way to export such information is within an extra tag. However, using extra tags is bad practice and therefore has very low priority for us. We might export this data later, but cannot tell if and when, yet.

[email protected] said, at 2009-10-23T17:02:29.000Z:

I don't agree that using extra tags is bad practice. Extensibility is a vitally important feature of COLLADA. See https://collada.org/mediawiki/index.php/Extension

opencollada said, at 2009-10-29T08:32:31.000Z:

I've to agree with Robert: the better way of exporting data would be to bake the tiling into the texture or the UV sets (or even better: not to use that functionality in max). We'll discuss that internally.

[email protected] said, at 2009-11-17T19:34:13.000Z:

perhaps you can leave the option to the user and add a button?

(UV tiling/offset baking or extras)

What steps will reproduce the problem?

1. create a character with a (source) animation clip
2. export with baked transforms option enabled
3. <animation_clip> tag for the clip does not instantiate the
   matrix curves

What is the expected output? What do you see instead?

the <animation_clip> only instantiates visibility curves, see below for why
it gets those and not the matrices.

What version of the product are you using? On what operating system?

ColladaMaya plugin r715 for Maya 2009 on Windows XP 32bit

Please provide any additional information below.

AFAICS there are two problems:

1. when baked transforms are enabled
   VisualSceneExporter::exportMatrixTransform places the matrix plug
   immediately in the AnimationSampleCache so that later when
   AnimationHelper::isAnimated() is called it never returns kISANIM_Character
   (since for animated items in the cache it always returns kISANIM_Sample).

To get around this I simply commented out the line
mDocumentExporter->getAnimationCache()->cachePlug(plug, true); in
exportMatrixTransform, but that is probably not the real solution here.

2. Now that the "matrix" plug is actually examined in isAnimated() it turns
   out that it never is part of a Maya Character set as they only contain
   keyable attributes and "matrix" is not keyable. The Character set contains
   the attributes from which "matrix" is ultimately derived ("translateX",
   "translateY", etc.), so when isAnimated() looks at getAnimatingNode(plug)
   it only gets a MObject::kNullObj and therefore never returns kISANIM_Character.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=45

Are there plans to migrate the Google Code issue list:
http://code.google.com/p/opencollada/issues/list

to github's issue tracker? There's an automated tool that can do this:
https://github.com/arthur-debert/google-code-issues-migrator

It would also be nice if the Google Code front page has a link to the github repostory. The issues list should probably be turned off as well if GitHub is going to be the new place to report issues.

What steps will reproduce the problem?

1. Compile debug build of dae2ogre with Visual Studio 2010
2. Try convert any dae file
   3.

What is the expected output? What do you see instead?
Crashes inside iterator cleanup in std::_Container_Base12::_Orphan_all().

What version of the product are you using? On what operating system?
Revision 750 compiled with Visual Studio 2010 in Windows 7

Please provide any additional information below.
Possible reason: New Visual Studio has added more error checking to std libs. It enables iterator cleanup when iterator debug level is 2. Which is now default in debug build. This adds iterator info to string and makes string destructor brake if it's illegally constructed or memcpyed.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=92

earlier comments

[email protected] said, at 2010-09-01T15:09:10.000Z:

The problems is in GeneratedSaxParserTemplateBase.h:318 The constructor of the object DataType cannot called by memcpy() or malloc(). The good way to do this is to use a "placement new" operator. The attached patch should do the trick.

[email protected] said, at 2010-10-09T16:19:36.000Z:

If confirmation is needed, yes, the bug is real and the patch fixes it.

And if two liner feels like overdesign, here's oneliner :)

[email protected] said, at 2010-11-12T08:35:09.000Z:

This probably happens somewhere else, I have the same issues but this fix doesn't change anything (this piece of code is not even called before the crash happens).

Going to take a quick look.

[email protected] said, at 2010-11-12T09:17:22.000Z:

Found the problem. In COLLADASaxFWLColladaParserAutoGen14Private.cpp:3284 :

const accessor__AttributeData accessor__AttributeData::DEFAULT = {0, 0, 0, 0, 1};
Initializing a struct containing a std::string (non-POD) as a POD struct.

Same probably applies to COLLADASaxFWLColladaParserAutoGen15Private.cpp

Easy workaround is to make a static function to create it, or add constructor/destructor to this class so that POD initialization is not needed anymore.

[email protected] said, at 2011-01-18T15:40:01.000Z:

Thanks for providing the patches.

I have applied the two liner in r807.

The issue concerning the non-POD struct requires adjustments to our generator, which needs to be postponed for now.

Community request by Christophe

> Is there a stable developer version of opencollada i could use ?
> There seems to be a lot of validations in the last recent weeks (which is
a good thing!) but it would be nice to have in addition to release numbers
(r601, r602, r603, ...) stable version numbers...

and Erwin
> Do you plan on uploading some 'stable' source code release on
opencollada.googlecode.com in the Download section?
> And then include a hello-world example that just compiles, links and runs
out-of-the-box, using expat and no boost?
> (for example the StreamWriterSample and frameWorkLoaderNull you send me
earlier)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=3

earlier comments

[email protected] said, at 2010-03-07T11:02:48.000Z:

hi

is there any update on these requests? (currently looking into replacing our FCollada-
based pipeline with opencollada)

thanks for your efforts and kind regards,
simon

opencollada said, at 2010-03-07T11:09:45.000Z:

If you do not require the new Kinematics interfaces the current trunk (r736) is safe to use. No major API breaks will be committed in the near future.

[email protected] said, at 2011-11-12T22:55:17.000Z:

I'm thinking about adding opencollada to Gentoo, what should I use as snapshot target?

[email protected] said, at 2011-11-15T17:06:21.000Z:

i recently packaged r864 for a commercial app, no issues so far...

Building dae23ds and dae2ogre exe (in debug mode, svn revision r652,
Windows 32bit, MSVC 2008)

run dae23ds cylinder_colladamaya_again.dae cylinder_colladamaya_again.3ds
and
dae2ogre cylinder_colladamaya_again.dae cylinder_colladamaya_again.ogre

results in nearly empty files.

Is export of triangle mesh, with animation not supported?
Or does the export break because of missing textures/materials in the
original file?

Thanks,
Erwin

Migrated from http://code.google.com/p/opencollada/issues/detail?id=23

earlier comments

[email protected] said, at 2009-11-09T13:17:48.000Z:

Hi Erwin,

the reason the mesh does not get imported is, that is instantiated via a controller
and both converters currently do not support controllers.

However, even when the geometry is instantiated directly using <instance_geometry>,
the .3ds file seems to be buggy. I will have a look at it.

Robert

[email protected] said, at 2009-11-09T14:41:37.000Z:

converting skinned skeleton animation would be very important feature: for simple textured meshes, people generally simply use .obj files, rather than COLLADA .dae :-)

Do you have any estimate how much work is needed to support skinned skeleton
animation/controllers, and fix this issue (in terms of days/weeks/months)?

Thanks a lot,
Erwin

[email protected] said, at 2009-11-09T15:38:57.000Z:

Yes, that is true. But please note that the dae2orge converter was originally written as an example program for the usage of OpenCOLLADA. It is by far not feature complete.

We have not yet an estimate how much work it is needed to support this in 3ds. This
would require a further analysis of the 3ds file format.

[email protected] said, at 2009-11-09T16:01:22.000Z:

To be honest, I would rather have a binding/conversion from OpenCollada to John Ratcliff's MeshImport library:

MeshImport library: http://code.google.com/p/meshimport
Example how to use MeshImport: http://code.google.com/p/meshimporttest/
Docs: http://docs.google.com/View?id=d5v2g3t_18csmgsxc7
BLOG with further info: http://www.codesuppository.blogspot.com

Any way to get a skinned animated skeleton from Maya into a game engine, through
OpenCollada would be great, and it seems John Ratcliff's MeshImport is a good
starting point for that (and MeshImport also uses the MIT license, so you are free to
copy the source code into your the OpenCollada project)

What steps will reproduce the problem?

1. select any animated object.
2. export it with 'Sampling' turned on.
3. view the .dae file, it does not contain any animation data in the file.
4. re-export again, but with 'Sampling' TURNED OFF, don't bother looking at
   dae file.
5. re-export a 3rd time, this time check the 'Sampling' box again (TURN IT ON).
6. examine the exported .dae file, it now contains animation data, where it
   did not in step 2 using the SAME SETTINGS. I can reproduce this many times
   consistenly.

What is the expected output? What do you see instead?
Expecting to see an animated model, no animation is present until you do an
export with sampling turned off, and then again with it turned back on.

What version of the product are you using? On what operating system?
Maya 2011
Windows 7
OpenCOLLADA 1.3.0 RC1

Thanks.

Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=80

I'm using the OpenCOLLADA plugin (1.2.2.674) for Maya 2010 (64bit).

It would seem that the vertex color export is broken: it systematically
defaults to 0, turning the whole object into whatever the first vertex's
color is. Here is the example (arranged in columns) of the following snipped:

   <triangles count="2" material="polygon-01-coloredChecker_SHD">
     <input semantic="VERTEX" source="#polygon_MSHShape-vertices"

offset="0"/>
<input semantic="NORMAL" source="#polygon_MSHShape-normals"
offset="1"/>
<input semantic="COLOR" source="#polygon_MSHShape-colorSet1"
offset="2"/>

(Vertex/Normal/Color)
0 0 0
3 1 0
2 2 0
0 3 0
1 4 0
3 5 0

As you can see, the last column is supposed to relate to the array of
vertex color, but instead it is only 0 all the way. Instead of being
something more like:

 0 0 0
 3 1 1
 2 2 2
 0 3 3
 1 4 4
 3 5 5 

Migrated from http://code.google.com/p/opencollada/issues/detail?id=64

earlier comments

[email protected] said, at 2010-08-13T14:35:43.000Z:

I second that. Same experience with Win 7 Maya 2011 64 bit, COLLADAMaya 1.3.0rc1, and 1.2.2. on OS X 10.6 Maya 2011 64 bit.

cheers,

h

[email protected] said, at 2010-11-17T21:53:37.000Z:

We're having the same issue (looks like its noted in bug IDs 88 and 100 as well).

We use your released version of the exporter and don't build our own, and thus we cannot take advantage of your patch fix noted in issue 100. Any estimate on a released fix for this one? It's basically a show stopper for us, as we use vertex colors extensively on our assets...

Thanks Julien!

[email protected] said, at 2010-11-19T15:48:24.000Z:

I have a fix for this I will be posting a new bug with the fix in it for the devs to integrate.

When searching for the OpenCollada Maya plugin in Maya / Window / Preferences
/ Plugin manager, it shows under COLLADAMaya.

That is a bit confusing, because everywhere else (this website, file format
etc) refers to 'OpenCollada'.

Can you please rename the plugin into OpenColladaMaya or something like that?
Thanks

Migrated from http://code.google.com/p/opencollada/issues/detail?id=20

Indeed, the specular exported from 3DSMAX should be modulated by the
spec_level.

You can verify easily in max interface, by using the material editor that
boosting the specular level make specular appears.
If we do not modulate the specular color, all objects (with a client
implementing correctly the spec) will get all its rendering too bright...

Migrated from http://code.google.com/p/opencollada/issues/detail?id=36

earlier comments

[email protected] said, at 2010-08-08T06:21:25.000Z:

Very true! They need to add support for exporting specular level from 3dsmax so the specular can be modulated. It actually associated glossiness in 3dsmax to shininess.

[email protected] said, at 2011-01-19T14:24:59.000Z:

relates to issue 29.

Dummy helper node size is to small. When importing a DAE file with
OpenCollada, it get way to small, it's not even possible to see it in the
viewport unless you zoom in on it...
I'm not sure how the size of the dummy node is/should be derived or if it's
set by the unit that's used for the scene, maybe the scene boudingbox?

Migrated from http://code.google.com/p/opencollada/issues/detail?id=27

The OpenCollada exporter should warn users when it encounters features that
it cannot convert to Collada format. For example, the 3ds Max 2010 built-in
converter warns when it encounters non-standard material types (such as
"Architectural") or when it has to cull entire geometries that cannot be
converted.

OpenCollada's exporter might produce better Collada files but it culls
geometries and materials silently forcing the user to report to trial and
error to figure out if anything got lost in the process.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=57

earlier comments

opencollada said, at 2010-02-16T07:02:59.000Z:

Important feature, right.

I'm using the OpenCOLLADA plugin (1.2.2.674) for Maya 2010 (64bit).

When trying to export a single polygon (a triangle), the geometry
description gets all confused with some "inputs" winding up in the
"vertices" section (instead of the "triangles" one):

   <vertices id="polygon_MSHShape-vertices"

name="polygon_MSHShape-vertices">
<input semantic="POSITION" source="#polygon_MSHShape-positions"/>
<input semantic="NORMAL" source="#polygon_MSHShape-normals"/>
<input semantic="COLOR" source="#polygon_MSHShape-colorSet1"/>
</vertices>
<triangles material="coloredChecker_SHDSG" count="1">
<input semantic="VERTEX" source="#polygon_MSHShape-vertices"
offset="0"/>
<input semantic="TEXCOORD" source="#polygon_MSHShape-map1"
offset="1" set="0"/>
<p>0 0 1 1 2 2</p>
</triangles>

But if I split this polygon in two (giving two triangles instead of one)
then everything is fine:

   <vertices id="polygon_MSHShape-vertices"

name="polygon_MSHShape-vertices">
<input semantic="POSITION" source="#polygon_MSHShape-positions"/>
</vertices>
<triangles material="coloredChecker_SHDSG" count="2">
<input semantic="VERTEX" source="#polygon_MSHShape-vertices"
offset="0"/>
<input semantic="NORMAL" source="#polygon_MSHShape-normals"
offset="1"/>
<input semantic="TEXCOORD" source="#polygon_MSHShape-map1"
offset="2" set="0"/>
<input semantic="COLOR" source="#polygon_MSHShape-colorSet1"
offset="3"/>
<p>0 0 0 0 3 1 3 0 2 2 2 0 0 3 0 0 1 4 1 0 3 5 3 0</p>
</triangles>

Now if I also use the "exportTexTangents=1" option, it gets even more
confused (the "NORMAL" element is still in the wrong section and the
"offset" numbers are wrong):

   <vertices id="polygon_MSHShape-vertices"

name="polygon_MSHShape-vertices">
<input semantic="POSITION" source="#polygon_MSHShape-positions"/>
<input semantic="NORMAL" source="#polygon_MSHShape-normals"/>
</vertices>
<triangles material="coloredChecker_SHDSG" count="1">
<input semantic="VERTEX" source="#polygon_MSHShape-vertices"
offset="0"/>
<input semantic="TEXCOORD" source="#polygon_MSHShape-map1"
offset="1" set="0"/>
<input semantic="COLOR" source="#polygon_MSHShape-colorSet1"
offset="2"/>
<input semantic="TEXTANGENT"
source="#polygon_MSHShape-textangents" offset="3" set="0"/>
<input semantic="TEXBINORMAL"
source="#polygon_MSHShape-texbinormals" offset="3" set="0"/>
<p>0 0 0 0 1 1 0 1 2 2 0 2</p>
</triangles>

Finally, when exporting just a single polygon (a triangle), invisible nodes
are also getting exported (even though the option "exportInvisibleNodes" is
set to 0).

Migrated from http://code.google.com/p/opencollada/issues/detail?id=63

OpenCOLLADA does not yet support the import of shaders. The should be
imported as part of the effect class.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=33

earlier comments

[email protected] said, at 2011-08-19T00:54:46.000Z:

Are there any plans to implement this feature in the near future?

"could you possibly add <double_sided>1</double_sided> under
extras.technique.double_sided for 3ds max in your next update"

Migrated from http://code.google.com/p/opencollada/issues/detail?id=54

earlier comments

[email protected] said, at 2011-02-27T02:54:43.000Z:

Yes please!

[email protected] said, at 2011-02-27T14:47:39.000Z:

Did not ColladaMax from feeling support this? I think this is very useful for game development, so one can tell when a mesh must be rendered double sided and when not..

What steps will reproduce the problem?

1. Open Maya, create a scene with an object with non-zero Y position
2. Put some animation keys for that object at different frame numbers, by only translating it over X and Z axes
3. Export with "Static Curve Removal" option on

What is the expected output? What do you see instead?
Channel Y of the animation is set to 0 for each exported key, which is incorrect.

What version of the product are you using? On what operating system?
OpenCOLLADA Maya 1.3.0, RC1
Maya 2011 x64 Hotfix 3 on Windows 7 x64 Professional (EN)

Please provide any additional information below.
Proposed solutions:

• Write the true value of a constant channel, even if it's constant, when the two other components are non-constant (preferred solution)
• Change the <channel> tag of exported animation so that it binds only the X and Z channels (supported by the specs but some importers may not like it)
• Export two separate animations for X and Z (works but creates larger files)

  Migrated from http://code.google.com/p/opencollada/issues/detail?id=99

What steps will reproduce the problem?

1. Import the file in the attached .zip into 3D Studio Max.
2. Notice that transparency doesn't work as intended on the plant.
3. Select the Opacity Map and set "Mono Channel Output" to "Alpha".
   Execute a render; this is how the model is intended to be viewed.
4. Export model using the OpenCOLLADA MAX exporter.
5. Bring the exported model back into MAX.
6. Notice that the transparency is still incorrect.

What is the expected output? What do you see instead?

Transparency should look correct on model.

What version of the product are you using? On what operating system?

3D Studio Max 2010 x64 on Windows 7 RC.
Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=25

earlier comments

[email protected] said, at 2009-11-12T09:14:43.000Z:

I could reproduce this.

However, the "Mono Channel Output" is not supported by COLLADA. The only way to store
this would be in an extra tag. We will reorganize and improve extra tag handling in
near future. After this, preservation of Max specific data will be possible.

[email protected] said, at 2009-11-12T17:52:04.000Z:

Preservation of MAX data would be nice, but I'm wondering if this could be easily solved by just making sure that "Mono Channel Output" is set on import if opaque is set to A_ONE. No extra data would be required. I don't see anyone wanting the current behavior.

What steps will reproduce the problem?

1. Export a model from SketchUp
2. Import into Maya
3. Maya transform nodes have multiple shape nodes

What is the expected output? What do you see instead?
I expect to see each shape node to have it's own individual transform node
as this is how Maya creates geometry by default.

Instead Maya transform nodes have multiple shape nodes which messes the
scene as it makes it almost impossible to select geometry inside of Maya.

I can run this MEL Script:

string $sel[] = ls -sl -dag -lf;
for ($each in $sel)
{
string $group = group -em -n ($each + "_transform");
parent -s $each $group;
}

But that will break the hierarchy of the original SketchUp scene.

What version of the product are you using? On what operating system?
Maya 2010x64, 1.2.2 Collada for Maya and Vista x64

Migrated from http://code.google.com/p/opencollada/issues/detail?id=60

What steps will reproduce the problem?

1. Create a simple mesh
2. Set Tangents/Binormals checkbox
3. See the output file how contains float arrays filled with 'NaN' strings

What is the expected output? What do you see instead?

Is my first time using OpenCollada 1.2.5, and i exported a simple object (a
cone) with his own UV set, when i open the *.dae file, i can see float
array of tangent and binormal tags with 'NaN' strings inside.

Never seen before with other exporters of Collada.

What version of the product are you using? On what operating system?

OpenCollada 1.2.5
3D Studio MAX 2010 (64 bit)
Windows 7 (64 bit)

Please provide any additional information below.

I will attach the resulting file, is simple, is a cone with UV set. at the
end of float arrays in tangents and binormal tags you can see 'Nan' strings
instead of a floating valor.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=30

earlier comments

[email protected] said, at 2009-11-24T08:31:26.000Z:

I can reproduce this behavior.

[email protected] said, at 2010-08-08T06:17:21.000Z:

yeap, It happened with one of my models too.

[email protected] said, at 2010-08-13T11:12:24.000Z:

Could the reason be that COLLADAFW::Mesh does not store MeshVertexData for these vertex attributes?

[email protected] said, at 2010-08-19T23:47:00.000Z:

I encountered this too. I always thought the NaNs occured, because it's impossible to calculate the tangents/binormals for the given texture coordinates.

What steps will reproduce the problem?

1. Load the attached file into Maya (I'm using Maya 2009)
2. Export the file as a DAE (Using the latest version of Open Collada)
3. Import/Open the DAE with any program including Maya and no animations on
   the locator named rightInnerFlapController will be there.

What is the expected output? What do you see instead?

I expected the animations to export on the locator named
"rightInnerFlapController". They don't export.

What version of the product are you using? On what operating system?

Maya 2009 OpenCOLLADA_Maya_1.3.0rc1

Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=85

earlier comments

[email protected] said, at 2010-06-01T23:40:38.000Z:

I forgot to mention that I created these nodes by importing an FBX file. If you need the fbx file I can supply it.

What steps will reproduce the problem?

1. My loader needs to retrieve the id/sid of collada elements
   2.
   3.

What is the expected output? What do you see instead?
The framework classes don't seem to expose sid attributes of elements after
parsing. This is a change compared to FCollada API which stores ids and
sids in the framework classes. In OpenCollada, the sids seem to be stored
in the class SidTreeNode (see class DocumentProcessor and FileLoader) but
the information is lost during post-processing stage because the class
FileLoader is destroyed after the file is loaded.

What version of the product are you using? On what operating system?
the latest trunk

Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=43

earlier comments

[email protected] said, at 2009-12-18T13:12:48.000Z:

The id of elements is provided as "originalId".

We will add an option to load sid. This will be configurable using a pre processor flag.
However, the only application for we see for this is extra data that references
elements via sid. Do you have any other applications?

[email protected] said, at 2009-12-18T14:10:56.000Z:

2 use cases :

1/ that references elements with ids and sids.
2/ importing a document and saving it again should keep the original id and sid
intact. It will ease the work of conditioners.

Is it a lot of work for you to do the change ?

The 2 only missing features that prevent me switching from FCollada to opencollada
are the import of <profile_GLSL> for materials and the ability to read sids.

Is it possible to have a status update for the import of elements for GLSL
materials ?

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o COLLADAValidator/bin/posix/x86_64/debuglibxml/OpenCOLLADAValidator
-static
COLLADAValidator/obj/posix/x86_64/debuglibxml/src/ValidationErrorHandler.o
COLLADAValidator/obj/posix/x86_64/debuglibxml/src/main.o
-LCOLLADABaseUtils/lib/posix/x86_64/debug
-Lcommon/libftoa/lib/posix/x86_64/debug
-Lcommon/libBuffer/lib/posix/x86_64/debug
-LCOLLADAFramework/lib/posix/x86_64/debug
-LExternals/MathMLSolver/lib/posix/x86_64/debug
-LExternals/UTF/lib/posix/x86_64/debug
-LCOLLADASaxFrameworkLoader/lib/posix/x86_64/debuglibxml
-LGeneratedSaxParser/lib/posix/x86_64/debuglibxml
-lOpenCOLLADASaxFrameworkLoader -lMathMLSolver -lOpenCOLLADAFramework
-lOpenCOLLADABaseUtils -lGeneratedSaxParser -lpcre -lftoa -lbuffer -lUTF -lxml2
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(nanohttp.o):
In function xmlNanoHTTPConnectHost': (.text+0x93d): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(nanohttp.o): In functionxmlNanoHTTPConnectHost':
(.text+0xa24): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileOpenW': (.text+0xed0): undefined reference togzopen64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileOpenW': (.text+0xefc): undefined reference togzdopen'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function __xmlParserInputBufferCreateFilename': (.text+0x103c): undefined reference togzdirect'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlFreeZMemBuff': (.text+0x1168): undefined reference todeflateEnd'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileClose': (.text+0x2b35): undefined reference togzclose'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileWrite': (.text+0x2b65): undefined reference togzwrite'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlIOHTTPCloseWrite': (.text+0x2ceb): undefined reference todeflate'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlIOHTTPWrite': (.text+0x3054): undefined reference todeflate'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlIOHTTPWrite': (.text+0x311a): undefined reference tocrc32'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileRead': (.text+0x31e5): undefined reference togzread'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlCreateZMemBuff': (.text+0x32ad): undefined reference todeflateInit2_'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlCreateZMemBuff': (.text+0x32c0): undefined reference tocrc32'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileOpen_real': (.text+0x1529): undefined reference togzdopen'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(xmlIO.o):
In function xmlGzfileOpen_real': (.text+0x1573): undefined reference togzopen64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(nanohttp.o):
In function xmlNanoHTTPFreeCtxt': (.text+0xd8a): undefined reference toinflateEnd'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(nanohttp.o):
In function xmlNanoHTTPRead': (.text+0xfcd): undefined reference toinflate'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib/libxml2.a(nanohttp.o):
In function xmlNanoHTTPMethodRedir': (.text+0x1cf8): undefined reference toinflateInit2_'
collect2: ld returned 1 exit status
scons: ***
[COLLADAValidator/bin/posix/x86_64/debuglibxml/OpenCOLLADAValidator] Error 1
scons: building terminated because of errors.

$ gcc --version
gcc (GCC) 4.5.0
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux bstation 2.6.33-ARCH #1 SMP PREEMPT Mon Apr 26 19:31:00 CEST 2010
x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux

Migrated from http://code.google.com/p/opencollada/issues/detail?id=75

earlier comments

[email protected] said, at 2010-05-03T01:49:18.000Z:

same issue on ubuntu 9.10 64bit with gcc 4.4

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o COLLADAValidator/bin/posix/x86_64/debuglibxml/OpenCOLLADAValidator -static
COLLADAValidator/obj/posix/x86_64/debuglibxml/src/ValidationErrorHandler.o
COLLADAValidator/obj/posix/x86_64/debuglibxml/src/main.o
-LCOLLADABaseUtils/lib/posix/x86_64/debug -Lcommon/libftoa/lib/posix/x86_64/debug
-Lcommon/libBuffer/lib/posix/x86_64/debug -LCOLLADAFramework/lib/posix/x86_64/debug
-LExternals/MathMLSolver/lib/posix/x86_64/debug
-LExternals/UTF/lib/posix/x86_64/debug
-LCOLLADASaxFrameworkLoader/lib/posix/x86_64/debuglibxml
-LGeneratedSaxParser/lib/posix/x86_64/debuglibxml -lOpenCOLLADASaxFrameworkLoader
-lMathMLSolver -lOpenCOLLADAFramework -lOpenCOLLADABaseUtils -lGeneratedSaxParser
-lpcre -lftoa -lbuffer -lUTF -lxml2
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(nanohttp.o): In
function xmlNanoHTTPConnectHost': (.text+0xe50): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(nanohttp.o): In function xmlNanoHTTPConnectHost':
(.text+0xf64): warning: Using 'gethostbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileOpenW': (.text+0xdb9): undefined reference to gzopen64'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileOpenW': (.text+0xddc): undefined reference to gzdopen'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
__xmlParserInputBufferCreateFilename': (.text+0xf44): undefined reference to gzread'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
__xmlParserInputBufferCreateFilename': (.text+0xf70): undefined reference to gzrewind'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlFreeZMemBuff': (.text+0x10b8): undefined reference to deflateEnd'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileClose': (.text+0x2a65): undefined reference to gzclose'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileWrite': (.text+0x2a95): undefined reference to gzwrite'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlIOHTTPCloseWrite': (.text+0x2c4b): undefined reference to deflate'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlIOHTTPWrite': (.text+0x2ffc): undefined reference to deflate'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlIOHTTPWrite': (.text+0x30c2): undefined reference to crc32'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileRead': (.text+0x3195): undefined reference to gzread'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlCreateZMemBuff': (.text+0x328d): undefined reference to deflateInit2_'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlCreateZMemBuff': (.text+0x32a0): undefined reference to crc32'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileOpen_real': (.text+0x1479): undefined reference to gzdopen'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(xmlIO.o): In function
xmlGzfileOpen_real': (.text+0x14c3): undefined reference to gzopen64'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(nanohttp.o): In
function xmlNanoHTTPFreeCtxt': (.text+0xa7a): undefined reference to inflateEnd'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(nanohttp.o): In
function xmlNanoHTTPRead': (.text+0xce3): undefined reference to inflate'
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/libxml2.a(nanohttp.o): In
function xmlNanoHTTPMethodRedir': (.text+0x1e31): undefined reference to inflateInit2_'
collect2: ld returned 1 exit status
scons: *** [COLLADAValidator/bin/posix/x86_64/debuglibxml/OpenCOLLADAValidator] Error 1
scons: building terminated because of errors.

$ svn info
Path: .
URL: http://opencollada.googlecode.com/svn/trunk
Repository Root: http://opencollada.googlecode.com/svn
Repository UUID: ec7ac696-a6cd-11de-b195-ab392a2a73f5
Revision: 741
Node Kind: directory
Schedule: normal
Last Changed Author: [email protected]
Last Changed Rev: 741
Last Changed Date: 2010-04-15 16:00:19 +0200 (Thu, 15 Apr 2010)

$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux bBook 2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 13:22:24 UTC 2009
x86_64 GNU/Linux

[email protected] said, at 2010-05-05T12:44:26.000Z:

I had to set this in SConstruct:

vars.Add(BoolVariable('SHAREDLIB', 'Set to build shared libraries instead of static
ones (untested).', 1))

What steps will reproduce the problem?
1.Open 3dsMax
2. Create some object
3. Open materials dialog
4. change material type from "standard" to DirectX
5. change material properties.
6. assign material
7. export
8. you will see only original MAX material properties.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=32

earlier comments

[email protected] said, at 2009-11-24T08:29:52.000Z:

We will add DirectX support in future.

[email protected] said, at 2011-01-19T13:52:45.000Z:

PS: I can code fix, if some one points me place in MaxAPI to watch :) it's non intuitive conserning extendent materials :\

[email protected] said, at 2011-01-19T16:21:01.000Z:

It would be nice if you could spend some time to code a fix.

Actually I am not an expert when Max materials are concerned, by I here are some information that might help to get into this topic.

In EffectExporter::exportSimpleEffect there is already a check if a material is a DirectX material:
IDxMaterial* dxm = static_cast<IDxMaterial*> ( baseMaterial->GetInterface( IDXMATERIAL_INTERFACE ) );

The IDxMaterial interface seems to be the right one to retrieve data from a directX material.

I have also found the following usages of this interface in the Max SDK samples:
samples\modifiers\uvwunwrap\unwrap.cpp
samples\utilities\collector\collector.cpp
samples\utilities\mappath\mappath.cpp

These might be helpful, too.

[email protected] said, at 2011-01-19T17:42:32.000Z:

seems i found right peace of code: http://svn.kwxport.org/kwxport/trunk/kwxport/exportmain.cpp

lines from:
"IParamBlock2 *fxpb = materials[i].first->GetMaxMaterial()->GetParamBlock(0);"

Do you still need my help? :)

What steps will reproduce the problem?

1. Create a scene with a targeted camera
2. Export using any version of OpenCollada
3. Check the camera -> extra -> technique -> target field

What I expect to find there is the ID of the node that stores target matrix. What I find is the name of the field, which I can't resolve with.

<library_cameras>
<camera id="Camera01-camera" name="Camera01">
<optics>
<technique_common>
<perspective>
....
</perspective>
</technique_common>
</optics>
<extra>
<technique profile="OpenCOLLADA3dsMax">
<target>#Camera01.Target</target>
</technique>
</extra>
</camera>
</library_cameras>

and

<node id="node-Camera01.Target" name="Camera01.Target">
<matrix>...</matrix>
</node>

This occurs on the latest stable build available for download via the website (1.2.5) and the latest download from Google Code (1.3.0rc).

Migrated from http://code.google.com/p/opencollada/issues/detail?id=98

earlier comments

opencollada said, at 2010-08-06T06:31:18.000Z:

Verified. The OpenCOLLADA3dsMax profile is no yet fully specified.

What steps will reproduce the problem?

1. Open Maya 2011 64bit.
2. Create joints, rig them so they controlled by objects with constrains.
3. Create animation on control objects (not on joints).
4. Try to export with "bake transforms".

What is the expected output? What do you see instead?

You will have no baked animation. Just the first frame.

What version of the product are you using? On what operating system?

Windows 7 64bit, Maya 2011 64bit, OpenCOLLADA_Maya_1.3.0rc1.

Please provide any additional information below.

Usuallu you see how currentTime indicator runs through time slider, bakeing all keyframes. Now it does not happening. And you dont have animation in dae-file after export.

script editor reads (paths deleted by *****):

file -force -options "bakeTransforms=1;relativePaths=0;copyTextures=0;exportTriangles=1;cgfxFileReferences=0;isSampling=1;curveConstrainSampling=0;removeStaticCurves=1;exportPolygonMeshes=1;exportLights=1;exportCameras=1;exportJointsAndSkin=1;exportAnimations=1;exportInvisibleNodes=0;exportDefaultCameras=0;exportTexCoords=1;exportNormals=1;exportNormalsPerVertex=1;exportVertexColors=1;exportVertexColorsPerVertex=1;exportTexTangents=1;exportTangents=1;exportReferencedMaterials=0;exportMaterialsOnly=0;exportXRefs=0;dereferenceXRefs=1;exportCameraAsLookat=0;cameraXFov=0;cameraYFov=1;doublePrecision=0;" -type "OpenCOLLADA exporter" -ea "D:/*/tanya.dae";
fileCmdCallback;
about -application;
// Result: maya //
about -product;
// Result: Maya 2011 //
about -version;
// Result: 2011 Hotfix 2 x64 //
about -cutIdentifier;
// Result: 201006030309-775258 //
about -osv;
// Result: Microsoft Windows 7 Ultimate Edition, 64-bit Windows 7 (Build 7600)
//
file -q -ns;
// Result: Pioneer_Animated_4 //
file -q -exn;
// Result: D:/**/tanya.mb //
currentUnit -q -linear -fullName;
// Result: meter //
file -q -ns;
// Result: Pioneer_Animated_4 //
// Error: Export of constraints not supported: bn_Head_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_l_Hand_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_l_Collar_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_r_Hand_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_r_Collar_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_l_Foot_01_orientConstraint1 //
// Error: Export of constraints not supported: bn_r_Foot_01_orientConstraint1 //
memory -he;
// Result: 620.914063 //
memory -fr;
// Result: 910.402344 //
memory -pf;
// Result: 713497 //
// Result: D:/****/tanya.dae //

Migrated from http://code.google.com/p/opencollada/issues/detail?id=96

What steps will reproduce the problem?

1. Parse any COLLADA file containing <polylist> geometry primitives
   2.
   3.

What is the expected output? What do you see instead?
A loaded <polylist> mesh primitive should have type
COLLADAFW::MeshPrimitive::POLYLIST
Instead, its reported type is COLLADAFW::MeshPrimitive::POLYGONS

What version of the product are you using? On what operating system?

Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=49

What steps will reproduce the problem?

1. Run Maya 2010 or 2011.
2. Set the units to 'meters' in the preferences.
3. Import 'test_LOD0.dae' from the attached .zip file via the OpenCollada
   importer.
4. Notice that only the building is visible. The ground and roads are
   missing.
5. Run Max 2010.
6. Import 'test_LOD0.dae' from the attached .zip file via the OpenCollada
   importer.
7. Notice that the entire building, the ground, and the road is visible.
   This is how it should look.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=86

What steps will reproduce the problem?

1. load a 1.4 document
   2.
   3.

What is the expected output? What do you see instead?
Expect no calls to IWriter::writeFormulas() or
IWriter::writeKinematicsScene(), consistent with others.

Instead PostProcessor::linkAndWriteFormulas() and
PostProcessor::createAndWriteKinematicsScene() always call writer function.

Please use labels and text to provide additional information.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=17

Community request by Christophe

> Is there a stable developer version of opencollada i could use ?
> There seems to be a lot of validations in the last recent weeks (which is
a good thing!) but it would be nice to have in addition to release numbers
(r601, r602, r603, ...) stable version numbers...

and Erwin
> Do you plan on uploading some 'stable' source code release on
opencollada.googlecode.com in the Download section?
> And then include a hello-world example that just compiles, links and runs
out-of-the-box, using expat and no boost?
> (for example the StreamWriterSample and frameWorkLoaderNull you send me
earlier)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=3

earlier comments

[email protected] said, at 2010-03-07T11:02:48.000Z:

hi

is there any update on these requests? (currently looking into replacing our FCollada-
based pipeline with opencollada)

thanks for your efforts and kind regards,
simon

opencollada said, at 2010-03-07T11:09:45.000Z:

If you do not require the new Kinematics interfaces the current trunk (r736) is safe to use. No major API breaks will be committed in the near future.

[email protected] said, at 2011-11-12T22:55:17.000Z:

I'm thinking about adding opencollada to Gentoo, what should I use as snapshot target?

[email protected] said, at 2011-11-15T17:06:21.000Z:

i recently packaged r864 for a commercial app, no issues so far...

Community request by Christophe

> Is there a stable developer version of opencollada i could use ?
> There seems to be a lot of validations in the last recent weeks (which is
a good thing!) but it would be nice to have in addition to release numbers
(r601, r602, r603, ...) stable version numbers...

and Erwin
> Do you plan on uploading some 'stable' source code release on
opencollada.googlecode.com in the Download section?
> And then include a hello-world example that just compiles, links and runs
out-of-the-box, using expat and no boost?
> (for example the StreamWriterSample and frameWorkLoaderNull you send me
earlier)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=3

earlier comments

[email protected] said, at 2010-03-07T11:02:48.000Z:

hi

is there any update on these requests? (currently looking into replacing our FCollada-
based pipeline with opencollada)

thanks for your efforts and kind regards,
simon

opencollada said, at 2010-03-07T11:09:45.000Z:

If you do not require the new Kinematics interfaces the current trunk (r736) is safe to use. No major API breaks will be committed in the near future.

[email protected] said, at 2011-11-12T22:55:17.000Z:

I'm thinking about adding opencollada to Gentoo, what should I use as snapshot target?

[email protected] said, at 2011-11-15T17:06:21.000Z:

i recently packaged r864 for a commercial app, no issues so far...

What steps will reproduce the problem?

1. COLLADAFWMesh.h and .cpp remap TEXCOORD semantic to UVCoords().
2. Mesh class appears to support UV and not texture, and cannot support both.
   3.

What is the expected output? What do you see instead?
In COLLADA, texture coordinates are not the same as UV coordinates. A mesh
can have both sets of semantics. Therefore the Mesh class should provide
storage and methods for both semantics. E.g.:

Mesh::getTexCoords() [rename current interface] should return data from
<input semantic="TEXCOORD">.

Mesh::getUVCoords() [reimplement] should return data from <input
semantic="UV"> and this is data that is rarely used (advanced applications
only).

Please use labels and text to provide additional information.
Also, each Mesh can have multiple sets of vertex attribute data. The Mesh
class currently supports only one of each semantic.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=39

earlier comments

[email protected] said, at 2009-12-15T11:13:54.000Z:

The code in this function is incorrect because texture coordinates cannot have InputSemantic::UV in COLLADA:

bool MeshLoader::loadTexCoordsSourceElement ( const InputShared& input )
{
    bool retValue = true;

    // Get the semantic of the current input element.
    InputSemantic::Semantic semantic = input.getSemantic ();
    if ( semantic != InputSemantic::UV && semantic != InputSemantic::TEXCOORD )
    {
        std::cerr << "The current input element is not a UV / TEXCOORD element!"

<< std::endl;
return false;
}

[email protected] said, at 2009-12-15T11:22:41.000Z:

This function is also wrong for the same reason.

bool MeshLoader::loadSourceElement ( const InputShared& input )
{
    bool retValue = false;

    // Get the semantic of the current input element.
    InputSemantic::Semantic semantic = input.getSemantic ();
    switch ( semantic )
    {

...
case InputSemantic::UV:
case InputSemantic::TEXCOORD:
retValue = loadTexCoordsSourceElement ( input );
break;
...
}

I suggest defining _HAS_ITERATOR_DEBUGGING=0 in both debug and release
project settings to improve performance

Since most people will do that anyway, it would be nice if it was
configured by default so we don't have to change the settings every time.

Note : beware that all projects must have the same flag (either 0 or 1).
You cannot have one libray with this flag off and another one with the flag
on. Otherwise it will crash

Migrated from http://code.google.com/p/opencollada/issues/detail?id=6

earlier comments

opencollada said, at 2009-10-06T09:37:58.000Z:

_HAS_ITERATOR_DEBUGGING is not evaluated in Release mode at all. We'll test against possible side effects first. Thanks for the hint.

[email protected] said, at 2009-10-06T12:16:10.000Z:

Yes you are right, _HAS_ITERATOR_DEBUGGING only applies to debug builds. In our applications, we noticed that the performance is hugely decreased when this flag is on. Since OpenCollada makes heavy use of STL vectors and maps, it should be best to turn it off so that developers can work faster.

In addition, i also recommend setting _SECURE_SCL=0 in both release and debug
builds. This is also a cpu eater.
Again, this flag should be consistent in all projects

[email protected] said, at 2010-07-27T20:55:22.000Z:

_SECURE_SCL=0 is the same if you are using /O2 compile setting. I believe a good idea to check that is to see /O2 internal configuration in Visual Studio.

[email protected] said, at 2010-07-27T20:58:42.000Z:

Aditional info from Microsoft: http://connect.microsoft.com/VisualStudio/feedback/details/524141/serious-bug-when-using-secure-scl-0-c

"Additionally, _SECURE_SCL defaults to 0 in release mode in VC10."

What steps will reproduce the problem?

1. Create mesh with bones, ik helpers and basic rigging.
2. Animate and export it.
3. Load the model in Papervision 3d with the DAE parser.

What is the expected output? What do you see instead?
I expect syncronized/acceptable animation. In my example I load a horse,
the front legs move very slow and the back legs move really fast, the front
legs look tilted about 30 degrees. So the whole animation looks very bad. I
rendered the animation in 3dsmax to video and the animation plays properly.

What version of the product are you using? On what operating system?

Windows 7 Ultimate 32-bits
3dsmax 2010
Open Collada 1.2.5
Papervision3D Rev. 939

Will it be better if I bake the animation to vertex level? I think that
will work but then the file size will be huge, thanks!
Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=66

It would be excellent if the importers supported updating of existing scene
files. By that I mean if there were an option to import a dae and state
that you wanted the contents of the dae to be used to either:

A. merge into the existing scene
B. update nodes where names are the same and add anything new that doesn't
already exist.
C. only update the current scene nodes and not add anything new to the
scene.

This can be an incredibly useful feature (specifically for animation)

Our primary focus is with 3dsmax.

Great project you guys have here.

Cheers

Kyle

Migrated from http://code.google.com/p/opencollada/issues/detail?id=76

earlier comments

[email protected] said, at 2011-01-20T09:07:53.000Z:

Seem to be a cool idea, but has very low priority for us.

What steps will reproduce the problem?
2. Import test_LOD0.dae into Maya 2010 using the OpenCollada Maya importer.
3. Notice the "Can't get the rotation, about we have a skew in the
transform matrix!" message in the "Output Window", and notice the
powerlines that are rotated 90 degrees relative to the correct orientation.

What is the expected output? What do you see instead?

1. Import test_LOD0.dae into Max 2010 using the OpenCollada Max importer.
2. Notice the powerlines look correct - the cables are properly connected
   from pole to pole.

What version of the product are you using? On what operating system?

OpenCollada Maya Importer 1.2.2, on Windows 7 x64.

Please provide any additional information below.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=42

I've put files under 2011, and I'm sure they are staying in appropriate folders. When I click "loaded" I get this error and plugin doesn't load:

// Error: dlopen(/Users/Shared/Autodesk/maya/2011/plug-ins/COLLADAMaya.bundle, 1): no suitable image found. Did find: /Users/Shared/Autodesk/maya/2011/plug-ins/COLLADAMaya.bundle: unknown required load command 0x80000022 (COLLADAMaya)

Migrated from http://code.google.com/p/opencollada/issues/detail?id=91

earlier comments

[email protected] said, at 2010-06-27T01:12:47.000Z:

to make sure I've downloaded following:

"OpenCOLLADA 1.3.0beta for Maya 2011 Mac OS X 10.6 available now! http://bit.ly/9j21FG"

Does this mean you won't support leopard anymore ?

[email protected] said, at 2010-06-27T19:26:46.000Z:

I've installed maya 2011 hotfix 2, nothing changed

[email protected] said, at 2010-07-31T17:21:43.000Z:

This is probably because the plugin was built for 10.6. I haven't tried it, but you can probably download the source code, change the target to 10.5 and recompile.

[email protected] said, at 2010-08-04T04:52:57.000Z:

Well, I've tried to compile this, but it just isn't happening. I changed every 2010 reference I could find in the project to 2011, but something is still trying to access 2010. Finally, I just created a symlink called 2010 to get around that. Then libtool kept throwing errors like: "file: -lxml2 is not an object file (not allowed in a library), so I've kinda given up. Any help compiling a 10.5.x version of this plugin would be great!

opencollada said, at 2010-08-04T06:46:43.000Z:

Attached is the latest XCode Project file that I used to build on 10.6. should build on 10.5, too. Take a look at the build instructions, too http://code.google.com/p/opencollada/source/browse/#svn/trunk/COLLADAMaya/COLLADAMaya.xcodeproj http://code.google.com/p/opencollada/source/browse/trunk/COLLADAMaya/BUILD_MAC.TXT

What steps will reproduce the problem?

1. import scene with an effect without explicitly set transparency
2. if this effect is a first one processed by the parser, it would
   interally have mOpaqueMode undefined (in release some random number, in
   debug it's 0xcdcdcdcd) as mOpaqueMode is not set in LibraryEffectsLoader
   constructor

What is the expected output? What do you see instead?
expected is that it would be set to UNSPECIFIED_OPAQUE

What version of the product are you using? On what operating system?
trunk, r736, win7-64, visual studio 2008

Please provide any additional information below.
patch would be to add
, mOpaqueMode( UNSPECIFIED_OPAQUE )
line to COLLADASaxFWLLibraryEffectsLoader.cpp after line 37

Migrated from http://code.google.com/p/opencollada/issues/detail?id=71

earlier comments

mikee%[email protected] said, at 2010-04-20T20:17:09.000Z:

i've found this issue when I've worked around a bug in GoogleSketchup, which by default sets transparency to 0 (instead of 1 as it should be for A_ONE) and does not indicated it with changed transparency mode can you also make the original transparency mode visible from the API for each effect? i know that all calculations regarding opacity are done inside the API, but if an exporter does not conform to the specifications than we have no option how to check this i.e. if I know that transparency mode is set to default and all objects in the scene have transparency 0, than I can pretty much safely say that the exporter is bugged and assume that the mode used was A_ZERO .. I am doing a similar thing right now (reverting transparency when numobjects_withTransparency_0 > numobjectswithTransparency_1), but as I said I can only assume that

[email protected] said, at 2011-01-19T16:33:35.000Z:

If have fixed the bug in r815.

Leaving this issue open due to the requested enhancement.

[email protected] said, at 2011-05-09T16:48:59.000Z:

OpaqueMode is fundamental information that needs to be exposed. Imagine that application imports With OpaqueMode hidden, application does not know where to read transparency from.

What steps will reproduce the problem?

1. Load up Daz studio V3 and max 2009.
2. Install opencollada plugin v 1.2.5 (32 or 64 bit gets same results)
3. load DAZ content such as Michael 4 or Victoria 4.2, and apply several
   morphs (or just one) to either his body or his face.
4. export to DAE file, including the morphs.
5. using OpenCollada, import into max.

What is the expected output? What do you see instead?
You would expect to see the 3D mesh of Michael 4 or Victoria 4.2 with a
Morph and Skin modifier applied to it. Each channel of that Morph modifier
would correspond to one of the morphs exported unbaked out of DAZ studio
V3.
Instead of seeing the full 3D model, with skin and morph information, you
only see the helpers that make up the skeleton for rigging. There is no 3D
mesh.

What version of the product are you using? On what operating system?
OpenCollada 1.2.5
Windows 7 64 bit
DAZ studio v3
3Ds Max 2009

Please provide additional information below.
Exporting from DAZ without the morphs gives a correct import into 3Ds Max:
it shows the full 3D mesh with a Skin modifier properly applied.

Migrated from http://code.google.com/p/opencollada/issues/detail?id=53

earlier comments

[email protected] said, at 2010-04-01T14:46:20.000Z:

This is a real blocker for us on a job at the moment.

If it's not easily (or imminently) fixable, is there any hacking we can do to the
.dae file - such as that hinted at in issue 11
[http://code.google.com/p/opencollada/issues/detail?id=11], which unfortunately
doesn't solve anything here - to make this work?

Many thanks