khronosgroup/collada-cts

Welcome to the COLLADA Conformance Test Suite

collada-cts's Issues

Add licensing information

There should be a file called LICENSE in the root of the repository. It looks like most of the code has an MIT License header, so it would be nice to put this in a LICENSE file.

CTS running blender ends with memory error messages and erros logs.

As pointed out there: #13

Orthographic tests are in the wrong units per <asset><unit meter>

StandardDataSets\collada\library_cameras\camera\optics\orthographic and probably elsewhere have <xmag>50</xmag> which should be in centimeters to match the document's units, but are shown as if they are 50 meters in the reference images.

These are not angles, and technically neither are <zfar> and <znear> but as long as the clipping planes don't obscure the image those are not a problem.

Documentation Update Format

Related to issue #7, the documentation right now is in Word .doc format. Updating it is somewhat tedious and it won't be properly versioned in git, pull requests won't have diffs, etc.

Maybe they should be converted to some other format? HTML? RST? Markdown? Not sure on the best option.

Configuration files shouldn't be in repository

I think the config.txt file in the root of the repository should be renamed to something like config.example.txt. Generally, configuration files should not be checked in with their actual name, because then changing them in your checked out copy makes the file show as dirty, and people might accidentally commit changes to the default example config file.

spot_falloff_exponent_light.dae may have too small an exponent to matter

StandardDataSets\collada\library_lights\spot\spot_falloff_exponent_light

There is not a "blessed" image for this test. But it uses a <falloff_exponent> of 10. In results consistent with OpenGL this produces in a per-pixel shader a perfect or nearly perfect cutoff, that is identical to the other spotlight document's cutoff, which use an exponent of 1.

It's hard to say precisely if there is no difference between 1 or 10 (at this scale?) because OpenGL uses per-vertex blending, which certainly cannot distinguish between 1 and 10.

Setting the exponent to 100 produces a smaller and fuzzier spotlight boundary in the per-pixel shader. OpenGL's light model produces the same size light, but the fuzziness is the same because per-vertex blending produces about the same effect, corona wise.

missing offset in interleaved source

in the file: accessor/shared_array/shared_array.dae

the source "cube-map1" specifies some UVs interleaved with the vertex.
the accessor is specified as follow:

So the UV are implicitly located (via the param name) at index 4 and 5.
Per the spec it should be explicitly specified with the "offset" attribute instead. So something like:

the spec of accessor says:
The element describes access to arrays that are organized in either an interleaved or noninterleaved manner, depending on the offset and stride attributes.

Python version should be updated to at least 2.6

Agreed about that comment from Jeff Terrace:
"Oh, another thing: the manual says that the CTS was tested on Python 2.4. I think maintaining 2.4 compatibility is not a good idea at this point. 2.4 is 8 years old already, and almost all libraries have stopped supporting 2.4 and even 2.5 by now. Most libraries are only supporting 2.6 and 2.7 now, which I think would be a good idea for CTS."

Is the linear-attenuation light test acting over meters or centimeters?

I believe StandardDataSets\collada\library_lights\point\point_linear_attenuation_light\ is doing the linear attenuation calculation in terms of meters. (The light's inherited unit is centimeters. Like the rest of the CTS.)

The COLLADA manual only says it's done in terms of "distance" but does not define a unit. Normally distances are in the scale of the <asset> but is lighting meant to be an exception? It makes a difference if so. Managing scale factors for lights is difficult.

Nailing down a hard unit for lighting might be a good idea. But is this the idea? Or is it an accident?

Invalid Dae test files

In the COLLADA test files,
StandardDataSets/1_5/collada/library_kinematics_model/kinematics_model/technique_common/link/formula/formula.dae,
StandardDataSets/1_5/collada/library_kinematics_model/kinematics_model/technique_common/link/instance_formula/formula_in_kinematics/formula_in_kinematics.dae,
StandardDataSets/1_5/collada/library_kinematics_model/kinematics_model/technique_common/link/instance_formula/formula_in_library/formula_in_library.dae
the element "instance_formula" is not properly closed.

In the COLLADA test files,
StandardDataSets/1_5/collada/library_geometries/geometry/mesh/brep/surface/cylinder/cylinder.dae, StandardDataSets/1_5/collada/library_geometries/geometry/mesh/brep/surface/plane/plane.dae, StandardDataSets/1_5/collada/library_geometries/geometry/mesh/brep/surface/sphere/sphere.dae
"subject" and "title" elements should be placed before "unit" and "title" elements.

In the COLLADA test file,
StandardDataSets/1_5/collada/library_geometries/geometry/mesh/brep/surface/sphere/sphere.dae
the element "curve sid="geom_1.brep.curve-1"/" is not complete.

The COLLADA test files in
StandardDataSets/1_5/collada_other/library_cameras/, StandardDataSets/1_5/collada_other/library_effects/effect/profile_COMMON,
are still using 1.4.1 format.

Finally, is it normal to have "INSTAN1.DAE" and "INSTAN1.PY" in StandardDataSets/1_5/collada/library_visual_scenes/visual_scene/node/instance_geometry/bind_material/instance_material/instance_material_cube_with_6_materials espacially with "INSTAN~1.DAE" in 1.4.1 format ?

Invalid reference files

The following list of files have indices that go beyond the length of a source. Bug 528 from the bugzilla reported last September.

• StandardDataSets/collada/library_cameras/camera/_reference/_reference_optics_orthographic_zfar_znear/_reference_optics_orthographic_zfar_znear.dae
• StandardDataSets/collada/library_cameras/camera/_reference/_reference_optics_perspective_zfar_znear/_reference_optics_perspective_zfar_znear.dae
• StandardDataSets/collada/library_cameras/camera/id/id_dash/id_dash.dae
• StandardDataSets/collada/library_cameras/camera/id/id_period/id_period.dae
• StandardDataSets/collada/library_cameras/camera/id/id_underscore/id_underscore.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_xmag/optics_orthographic_xmag.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_xmag_aspect_ratio/optics_orthographic_xmag_aspect_ratio.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_xmag_ymag/optics_orthographic_xmag_ymag.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_ymag/optics_orthographic_ymag.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_ymag_aspect_ratio/optics_orthographic_ymag_aspect_ratio.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_zfar/optics_orthographic_zfar.dae
• StandardDataSets/collada/library_cameras/camera/optics/orthographic/optics_orthographic_znear/optics_orthographic_znear.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_xfov/optics_perspective_xfov.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_xfov_aspect_ratio/optics_perspective_xfov_aspect_ratio.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_xfov_yfov/optics_perspective_xfov_yfov.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_yfov/optics_perspective_yfov.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_yfov_aspect_ratio/optics_perspective_yfov_aspect_ratio.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_zfar/optics_perspective_zfar.dae
• StandardDataSets/collada/library_cameras/camera/optics/perspective/optics_perspective_znear/optics_perspective_znear.dae

Please rename default branch from 'master' to 'main' per Khronos policy

To repository owners: please rename the default branch of this repository from 'master' to 'main', using the Github renaming tool. This request is per policy set by the Khronos Promoters in May 2021, to follow Github community practice for respectful naming.

The Github renaming tool sets up URL redirections and retargets outstanding pull requests, so the impact on repository users is minimal. The most visible issue is that people with local repo clones will probably want to rename their clone's 'master' branch, following the popup instructions that will be seen when browsing the github repository after the change; or just delete 'master' and pull the new 'main', if it's purely a tracker with no local content.

You may wish to coordinate with @outofcontrol if you are doing auto-updates from this repository to another location, whether via push/pull mirroring or other mechanisms. The redirects setup by Github should accommodate most such uses transparently, but it's still good practice.

Based on experience with other KhronosGroup repositories which have undergone this renaming already, this is a reasonable approach:

• Agree on a date for the renaming within the Working Group or other owners of the repository, and document that date here.
  • Date can be adjusted to avoid interaction with major releases in flight.
• Provide notice to repository users outside Khronos, insofar as possible (adding a comment in the repo README with the switchover date is one way).
• Once the renaming is done, edit the new 'main' branch to replace hardwired references to 'master' with (preferably) 'default branch' or 'main'.
• Update the repo README to note the change.

If you have questions or issues about this, please raise them on Khronos internal gitlab 'khronos-general' issue 106 if possible. If not possible, you can @-tag me here.

While we will not force any WG into acting precipitously, this is our agreed policy. Please try to accommodate renaming relatively soon.

Note that this issue is automatically generated, due to the large number of KhronosGroup repositories it's being raised in.

Cubes don't match blessed images.

https://www.khronos.org/bugzilla/show_bug.cgi?id=1950

The cube examples (of which there are many) are incorrect. Blessed or not. Because they don't have lighting normals, while the Blessed images do. (They do have UVs, but not textures. Go figure.)

This makes the CTS unfit for grading software. Adding normal is post-processing. I cannot see a way to add that to the COLLADA-DOM reference implementation because it presents the data as-is and there isn't a post-processing facility built into it.

A CTS needs to be much broader than this one is. Perhaps there needs to be a CTS that takes things to the next-level. It's a good source of examples though. Finding information on what COLLADA wants out of is damn near impossible, much less examples :)