khronosgroup / collada2gltf Goto Github PK

Consider using the popular desktop-application releases project, Nuts by GitBook.

There's even a free, one-click deploy recipe for Heroku.

COLLADA2GLTF.sln is missing

<effect id="clouds-effect">
      <profile_COMMON>
        <newparam sid="cloudsgrass_mask-surface">
          <surface type="2D">
            <init_from>cloudsgrass_mask</init_from>
          </surface>
        </newparam>
        <newparam sid="cloudsgrass_mask-sampler">
          <sampler2D>
            <source>cloudsgrass_mask-surface</source>
          </sampler2D>
        </newparam>
        <technique sid="common">
          <lambert>
            <emission>
              <color sid="emission">0 0 0 1</color>
            </emission>
            <ambient>
              <color sid="ambient">0 0 0 1</color>
            </ambient>
            <diffuse>
              <color sid="diffuse">0.8 0.8 0.8 1</color>
            </diffuse>
            <transparent opaque="A_ONE">
              <texture texture="cloudsgrass_mask-sampler"/>
            </transparent>
            <index_of_refraction>
              <float sid="index_of_refraction">1</float>
            </index_of_refraction>
          </lambert>
        </technique>
      </profile_COMMON>
    </effect>

converted to

"clouds-effect": {
            "name": "clouds",
            "technique": "technique1",
            "values": {
                "ambient": [
                    0,
                    0,
                    0,
                    1
                ],
                "diffuse": [
                    0.8,
                    0.8,
                    0.8,
                    1
                ],
                "emission": [
                    0,
                    0,
                    0,
                    1
                ]
            }
        }

There is no transparent property with texture.

Original issue: KhronosGroup/glTF#648

Hi,
I can not find the argument which can genera binary gltf format?
Do we support binary format with the “gltf” prefixion？

I want to generate b3dm, it is better if I can get the binary gltf
thanks for your advice

There are COLLADA exporters that insert additional tags into the material/technique definitions. And right now, COLLADA2GLTF crashes when it encounters a technique definition like this:

<technique sid="common">
  <phong>
    ...
    <shininess><float>128.0</float></shininess>
    <normal>
    </normal>
    <bump>
    </bump>
    <displacement>
    </displacement>
  </phong>
  <extra/>
</technique>

Particularly, this appears in a COLLADA file that was exported from http://www.makehuman.org/ (I opened a related issue there: http://bugtracker.makehumancommunity.org/issues/1084 ). Although, strictly speaking, these additional tags are not compliant to the COLLADA spec, I think that such tags should be handled more graciously.

I'm not very familiar with COLLADA, XML and COLLADA2GLTF right now, and thus made a very "pragmatic" fix that prevents the crash. Here is it as a unified diff, in case someone wants to have a look at it:

5f6d7ccf38fc5cefcda3eb19f518c28fde4d2ec0
 GLTF/GLTFExtraDataHandler.cpp | 45 +++++++++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/GLTF/GLTFExtraDataHandler.cpp b/GLTF/GLTFExtraDataHandler.cpp
index d4dcd88..bf82c00 100644
--- a/GLTF/GLTFExtraDataHandler.cpp
+++ b/GLTF/GLTFExtraDataHandler.cpp
@@ -37,9 +37,13 @@ namespace GLTF
 */

    //------------------------------
-    ExtraDataHandler::ExtraDataHandler() : mExtraTagType(EXTRA_TAG_TYPE_UNKNOWN)
+    ExtraDataHandler::ExtraDataHandler() : 
+        mTextBuffer(),
+        mExtraTagType(EXTRA_TAG_TYPE_UNKNOWN),
+        mCurrentElementUniqueId(),
+        mCurrentObject(),
+        _allExtras(new JSONObject())
    {
-        _allExtras = shared_ptr<JSONObject> (new JSONObject());
    }

    //------------------------------
@@ -67,23 +71,26 @@ namespace GLTF
     if ((bump == nullptr) || (textureAttributes == nullptr))
         return;

-        size_t index = 0;
-        
-        const GeneratedSaxParser::xmlChar* attributeKey = attributes[index++];
-        const GeneratedSaxParser::xmlChar* attributeValue = 0;
-        while( attributeKey != 0 ) {
-            attributeValue = attributes[index++];
-            if( attributeValue != 0 ) {
-                bump->setString(attributeKey, attributeValue);
-            }
-            
-            if (strcmp(attributeKey, "texture") == 0) {
-                textureAttributes->textureSampler = attributeValue;
-            } else if (strcmp(attributeKey, "texcoord")) {
-                textureAttributes->texCoord = attributeValue;
-            }
-            attributeKey = attributes[index++];
-        }
+        if (attributes) {
+            size_t index = 0;
+
+            const GeneratedSaxParser::xmlChar* attributeKey = attributes[index++];
+            const GeneratedSaxParser::xmlChar* attributeValue = 0;
+            while (attributeKey != 0) {
+                attributeValue = attributes[index++];
+                if (attributeValue != 0) {
+                    bump->setString(attributeKey, attributeValue);
+                }
+
+                if (strcmp(attributeKey, "texture") == 0) {
+                    textureAttributes->textureSampler = attributeValue;
+                }
+                else if (strcmp(attributeKey, "texcoord")) {
+                    textureAttributes->texCoord = attributeValue;
+                }
+                attributeKey = attributes[index++];
+            }
+        }
    }

    //------------------------------

(As far as I know, it is a common (and important) "best practice" to initialize all members of a class in the constructor, exactly in the order in which they are declared in the header - see https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-complete and C.45, C.47 and C.49).

I'm not sure whether or not the pragmatic if (attributes) { is acceptable here, that's why I hesitate to make this a pull request. If this fix is OK and this should be a PR, just drop me a note.

It prevents the crash, and afterwards, COLLADA2GLTF generates a glTF file, but this glTF still has many other issues that I have not yet analyzed in detail.

Hello,

When I try to convert .dae files to gltf, I get "unsupported opaque mode:RGB_ZERO fallback to A_ONE"

Is there any solution for this? We get the same error for all our models. This is very critical for us. We have to solve this problem as soon as possible.

Thanks for help.

on windows. here's an example:

F:/unit-test/2017-1/Assets\Editor\Collada\pcbin\collada2gltf.exe -r -f C:/Users/remi/Desktop/tests/prop_barrel_01.dae -o C:\Users\remi\Desktop\tests\prop_barrel_01.gltf

this results in:
"buffer": "\Users\remi\Desktop\tests\prop_barrel_01",

and

"shaders": {
"\Users\remi\Desktop\tests\prop_barrel_010FS": {
"type": 35632,
"uri": "\Users\remi\Desktop\tests\prop_barrel_010FS.glsl"

only the images are correct
"images": {
"_2be69b1584d71e048a393fff2ef0a80d": {
"name": "prop_barrel_01_sg",
"uri": "textures/Textures/Props/prop_barrel_01_sg.png"

Each AppVeyor build takes about 30 minutes. Each PR/commit triggers two of them, so we have to wait ~1 hour before merging. Most of that time is being spent inside OpenCOLLADA sources.

@lasalvavida
Is it possible to cache dependencies to not build them each time from scratch?

@pjcozzi, there are now valid configurations for Travis and Appveyor on this repo, we just need to flip the switch. This is done by signing into travis-ci.org with an account that has admin access to this repo and enabling it for CI. Then, sign into ci.appveyor.com and create a new project for this repo. After that, CI should automatically build for windows and linux on the next commit.

The command 'collada2gltlf' has to be 'collada2gltf', at Usage.
Just a minor typo

Thanks for this amazing tool!
Samuel

Add a version flag to the GLTF::Options object for 1.0. Each GLTF namespaced object has a writeJSON method that defines how its data gets serialized. Add a switch for the new version flag so that the new converter architecture can write out glTF 1.0. For most classes this will be trivial, but GLTF::Asset::writeJSON will need a bit of extra work to print out dictionaries instead of arrays. This will deprecate the current 1.0 implementation as 1.0-legacy.

It looks like the OpenCollada dependencies were not moved from the old repo to this one.
CMake errors out when it cannot find the CMakeLists file for OpenCollada.

I was able to work around it and run CMake by using the files I had lying around in an old fork:
https://github.com/KhronosGroup/OpenCOLLADA/tree/fedad28dcd23282d4f0ffc78f2cba14ea6ab9744

Not sure if these files were just missing or explicitly removed when moving the repo?

Hi.

Recently I realized about the new converter from collada to GLTF2.0 format available at:
https://github.com/KhronosGroup/COLLADA2GLTF/releases

I have tried 32bit and 64bit for Windows platform and in both I am experiencing the same issue.

COLLADA2GLTF-2.0-windows-Release-Win32.zip
COLLADA2GLTF-2.0-windows-Release-x64.zip

When I convert a collada file to GLTF2.0 I am loosing the real names shown in the product structure of the DAE file. Instead of these names I get:

• geom --> for meshes
  -mesh --> for containers

In the converter I was previously using (1.0) this was not the case.

Could you please fix this issue, I would like to make use of the new GLB 2.0 format due to the obvious advantages but this is really a problem.

Best regards

I don't have any WebAssembly or Emscripten experience, but I suspect this will be difficult given the complexity of this project and all the third-party dependencies.

It would be a great research project if someone has the bandwidth.

This Issue has been separated from KhronosGroup/glTF-Sample-Models#83 (comment)

I tried the simple skinning animation model below.
EmaSimpleSkin.dae : This is a COLLADA file exported from Maya using OpenCOLLADA 2016. This sample was donated by @emadurandal
I converted it into glTF 2.0 format using COLLADA2GLTF.

The following is the display result by Three.js. As animation movement the glTF 1.0 model is more correct.
Because WalkingLady.dae has also been exported from Maya, I think that it includes the same problem.

Three.js + glTF 1.0 model result:

Three.js + glTF 2.0 model result:

I think that models including skinning animation have not been converted correctly.

using collada2gltf@cf6371beb0bdc18ba603378d5e40c966da53d385

When using the converter from a folder different than the path specified in the -o parameter, the path reference is stored with the files. For example, in this scenario:

/current folder
  /input
  /output

If you do:

collada2gltf -f input/asset.dae -o output/asset

will generate both output/asset.gltf and output/asset.bin. In the asset.gltf the reference to the asset file is:

"buffers": {
  "output/asset": {
    "byteLength": 999,
    "type": "arraybuffer",
    "uri": "output/asset.bin"
  }
}

The "common" use case is to have the .bin file in the same folder as the .gltf file, so you normally want this file references free of any path.

i.e., the output should be always like this:

"buffers": {
  "asset": {
    "byteLength": 999,
    "type": "arraybuffer",
    "uri": "asset.bin"
  }
}

But I guess the current behaviour is also desired for some. So what about adding a flag? something like:
-ol -> remove all paths in file references

Title is self-explanatory. Here is a test file and the output.

test-cude.dae
test-cude.gltf

It seems that COLLADA2GLTF will output one animation entry for each affected node. This causes side effects: KhronosGroup/glTF#1052 and KhronosGroup/glTF-Sample-Models#108 (comment). For example, the Monster model contains 32 animations (1 for each bone) and the viewer must play all of them at once in order to see the "walking" animation properly.

By default, I believe COLLADA2GLTF should merge all of these channels into one animation entry, unless the COLLADA asset explicitly provides multiple actions.

KhronosGroup/glTF#535
KhronosGroup/glTF#678
KhronosGroup/glTF#756

if (NOT WIN32)
#http://www.guyrutenberg.com/2014/01/05/enabling-c11-c0x-in-cmake/
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
if(COMPILER_SUPPORTS_CXX11)
	set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
    message("-- C++11 Enabled")
elseif(COMPILER_SUPPORTS_CXX0X)
	set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
    message("-- C++0x Enabled")
else()
        message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
endif()
endif()

This snippet causes configuration to abort on my Linux machine when using clang (clang --version returns the following:

clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

).

However Clang is absolutely a C++11 compliant compiler, and I can manually pass it the -std=c++11 flag without incident.

As stated in the title. I have attached a zip file containing the source model, and the output from collada2gltf. The input has 8 triangles sharing 6 vertices and 5 normals, whereas the output has the same 8 tris with 24 vertices and 24 normals. Clearly this is sub-optimal.

nameplate.zip

I'm going to attempt to dig into this myself, but it's gonna be a lengthy process to adequately understand the code. Any help the original developers can provide would be appreciated.

Schema
https://github.com/KhronosGroup/glTF/blob/2.0/extensions/Khronos/KHR_materials_pbrSpecularGlossiness/schema/glTF.KHR_materials_pbrSpecularGlossiness.schema.json#L39

Source
https://github.com/KhronosGroup/COLLADA2GLTF/blob/2.0/GLTF/src/GLTFMaterial.cpp#L178-L183

When converting a Collada file with vertex colors (exported from blender, verified to work with three.js), the color buffer comes through, is listed correctly as a bufferview/accessor/mesh attribute, but the contents of the buffer are zeroed out.

You can see this in the .bin file in the attached zip at byte offset 13608, which is where the color buffer in the .gltf file points. The corresponding buffer in the Collada file is on line 127.

Command used to convert: collada2gltf -k -f playermeter.dae

Sample models: playermeter.zip

Dear programmers,
I need to run this converter on windows 8.1; already installed the CMake but I have no idea about the next steps; I kindly ask you to provide me some step-by-step information for running the converter.
Thanks

When attempting to convert this file, 2D.dae.zip, it produces a segmentation fault. This was created in blender and exported. The command line tool seems to work fine for other files, but not this one.

macOS Sierra 10.12.2
Blender 2.78 (2016-10-24)

Currently getAllAccessors uses std::set to avoid duplicates when traversing. Unfortunately this creates a non-deterministic accessor ordering, which is a bit of an issue for glTF-Sample-Models, since it means that the buffer for a regeneration of a sample model may change because of re-ordering even though the data itself didn't change. This should be fixed to help keep bloat to a minimum.

Hello,

1- Can I use kmz, kml for model? I tried but I couldn't see on map.

2- I am triying to convert over 1GB dae projects to gltf. but it couldn't complete succesfully. Converting broken always and always. It is sama with obj to gltf too. What can I do?

Thanks

When I convert OpenCollada model to gltf using COLLADA2GLTF, I found a precision loss problem.
For example, the number 570500.625 in DAE turns into 570501 in the GLTF, and the number 3160898.5 in DAE turns into 3.1609e+006 in the GLTF.
How to solve this? Thanks.

I have a blender animation that has joint translations. When I export it to collada and send it through collada2gltf, it seems like all the translations get ignored.

Here's how it looks in blender:

And here's how it looks in Sandcastle:

Note that Cesium Man's hips don't move up and down in the gltf version. I tried parenting the animation skeleton to a "scene" bone in case collada2gltf was just ignoring the root transformations, but that didn't seem to fix the problem. I've also tried re-importing the collada to blender in case it was a problem with blender's exporter, but that seems to be just fine.

I've attached the collada file and output embedded gltf below. I can also provide blender files if needed.

CesiumManGo.zip

This converter is using a year and and half old version of the Khronos openCOLLADA library.

Since glTF 1.1 is incompatible with 1.0, converter should support only newer version or provide a way to specify desired format.

The project repository not contain any xcode project file. Was OS X installation steps should be changed?

LINE_STRIPS, TRIANGLE_STRIPS and TRIANGLE_FANS do not appear to be supported.

Suprisingly, Converter Limitations Wiki does not mention the lack of supported types.

The converter currently supports LINES, TRIANGLES, POLYLIST, and POLYGONS primitive types where the last two are converted to TRIANGLES. See convert/meshConverter.cpp.

LINES was the most recently added type when this project was under glTF project (KhronosGroup/glTF#302) and can be used as a guide to add other types.

It is trivial to allow LINE_STRIPS but most of the work seems to be in helpers/geometryHelpers.cpp to support splitting the primitive's mesh into separate meshes when source mesh is too big (limit num indices to < 65536). On investigation, I believe this method contains bugs such as primitiveCompleted is set to true to close a sub mesh at the end of the loop but never reset to false so additional sub meshes will closed with very little data in them.

I was going to add full support for the missing types but I have no confidence in making changes without unit tests or even a set of COLLADA models and expected glTF output files to compare the result.

Hi,

I tried to convert model with two circles lines.dae.zip but output file contains points.

Not really a concern right now, but in the future (when 2.0 is merged) releases should be versioned.

Currently I am thinking v{glTF Specification Version}.{Release Version}.

The first releases will be v2.0.0 and v1.0.0.

build_boat_dragonhead_01.zip

[ 81%] Linking CXX executable bin/collada2gltf
Undefined symbols for architecture x86_64:
  "_libiconv", referenced from:
      _xmlIconvWrapper in libxml2.a(encoding.o)
  "_libiconv_close", referenced from:
      _xmlFindCharEncodingHandler in libxml2.a(encoding.o)
      _xmlCharEncCloseFunc in libxml2.a(encoding.o)
  "_libiconv_open", referenced from:
      _xmlFindCharEncodingHandler in libxml2.a(encoding.o)
  "_lzma_auto_decoder", referenced from:
      _xz_make in libxml2.a(xzlib.o)
  "_lzma_code", referenced from:
      _xz_decomp in libxml2.a(xzlib.o)
  "_lzma_end", referenced from:
      ___libxml2_xzclose in libxml2.a(xzlib.o)
  "_lzma_properties_decode", referenced from:
      _xz_make in libxml2.a(xzlib.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/collada2gltf] Error 1
make[1]: *** [CMakeFiles/collada2gltf.dir/all] Error 2
make: *** [all] Error 2

I suspect you need to call find_library for lzma and iconv in the CMake configuration, and add them to the target link libraries.

I built branch 2.0, but when I tried to convert different models they used GLTF 1.0.
What am I do wrong?

Normal Maps are Not Working:

GLTF2NormalMapsTest.zip

• Maya 2014 x64
• Plugin For Export from Maya to Collada COLLADA-MAYA-PC-2014 v1.6.58
• Collada2Gltf COLLADA2GLTF-2.0-windows-Release-x64

Somewhere in the Asset Conversion Pipeline there is an error due to which Normal Maps are not working in gLTF! Can someone check what needs to be done to fix that? I have provided all the files for checking!

E.g., glTF/2CylinderEngine.gltf#L1706.

See other cases here:
https://travis-ci.org/KhronosGroup/glTF-Sample-Models/builds/235813517#L191

Use valgrind or something similar to find memory leaks in the executable. This is not a huge priority, since most people just run this as a one-off executable, but if a longer-running application were using this as a library, they could have issues.

Hello,
I am trying to convert from collada to gltf using the tool COLLADA2GLTF.
However, I need to preserve the latitude and longitude information in the converted file (I think I should use CESIUM_RTC tag of Cesium). Can I do it with the tool? If i can, how can I do it. I have been trying for long time but I had no success.

Thank you very much for your reply and help.
Regards
Martin.

Would it be possible to update the binaries on the Releases page?

(This Wiki page says to look there.)

2.0

• Backport 1.0 support #69
• Merge #37 to master, park current master onto a 1.0 branch
• Ongoing response to 2.0 bug reports

1.0

• Respond to questions or converter issues
• Third-party pull requests for issues are welcome, but unless the issue is one of security, we should be focused more on #69 than trying to fix the old converter

Misc

• Add OS X build to Travis CI #72
• Proper C++11 detection #55
• Improve CI build speed #54 #75
• asm.js support #58
• Memory leaks #70
• Texture conversion #73

Hi,
I was trying out the 2.0 branch. The reorganized code looks really good and clean. Great job!

Somehow I have problem building with experimental::filesystem. I was wondering if the CMakeList.txt is up-to-date or I should do any configuration on my side.

The error is undefined reference to <experimental/filesystem>
I'm using g++ 5.4.1. I tried to use c++1z instead of c++11 but it doesn't work.

Thanks.

The shader generation in commonProfileShaders.cpp currently contains the line

fragmentShader->appendCode("color = vec4(color.rgb * diffuse.a, diffuse.a * %s);\n", "u_transparency");

which causes the fragment shader to set the fragment color to

color = vec4(color.rgb * diffuse.a, diffuse.a * u_transparency);
gl_FragColor = color;

The multiplication of the rgb components with the diffuse.a is probably supposed to be an alpha-premultiplication. But to my understanding, this is not right. If the color is intended to be prmultiplied, then this multiplication should also take the u_transparency into account.

As an example, consider color.rgb to be (1,1,1), and diffuse.a to be 1.0, and u_transparency to be 0.5. Then the resulting gl_FragColor will be (1,1,1,0.5). If the u_transparency is 0.0, then the resulting gl_FragColor will be (1,1,1,0.0). Different sources (1, 2, 3, 4 ) consider a color in pre-multplied form to be "invalid" when either any RGB component is greater than the alpha component, or "ill-formed" when an RGB component is nonzero for an alpha of 0.0 (but finding a definite statement in the specs seems to be difficult).

So the question is:

Is everybody sure that this implementation of the transparency handling is correct?

Apologies for being so insistive, and although it already has become embarassing, I'd like to bring it up here, one last time (I promise), and if the answer to this issue is

"Everything is fine there, you are doing it wrong"

then I'll re-read everything that I have read so far, until the penny eventually drops.

It seems only jpg, png, gif are support.

I have a 3D model exported from Blender to Collada. It looks well and as expected in any collada preview application, but with problems after conversion to GLTF in Three.js. The follow link contains an archive with the .dae file and movies which show how it looks in collada preview and in browser rendered by Three.js.
gltf_bug_report.zip
The blue shell around the person is ice which should moves only in freezing sequence of the animation, but it somehow moves with another bones which weren't binded to that mesh and not moves in the freezing sequence (you can see freezing effect at 0:06 in shooter_gltf_bug.mov), but bones of the shell are moves correctly (I added green dots which represent the real position of the bones). You can compare it with how it should work in .dae file.
Therefore it looks like the bindings mesh vertices to bones somehow worked erroneously during conversion process.

I don't know how to install it, please if you have any tutorial for install it send me