Page MenuHome

COLLADA exports often have wrong textures assigned to materials
Open, NormalPublic

Description

System Information
Windows !0, Radeon R7 200

Blender Version
Broken: 2.70

Short description of error

The COLLADA exporter has several issues, but the biggest I've got is that the textures assigned to materials are often wrong in the export file. Here's an example of a file which has gone wrong:

I have edited out the <technique> sections for brevity, The thing to note is that each material refers to a "tex_01_psd-surface" texture which is not used by any of the materials, and is not listed in the <library_images>. Each material _should_ be linked to the texture of the appropriate name, so "tex_panels2_psd", "tex_panels_psd", "tex_instruments_png", as appropriate.

(That's the way it appears in Blender's property editors and previews. That texture is an old texture that is long gone.)

It should NOT be using the same old missing "tex_01_psd-surface" texture for each material. But it is. The result is black models with missing textures.

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">

<asset>
  <contributor>
    <author>Blender User</author>
    <authoring_tool>Blender 2.70.0 commit date:2014-03-19, commit time:05:02, hash:19e627c</authoring_tool>
  </contributor>
  <created>2016-06-05T21:54:56</created>
  <modified>2016-06-05T21:54:56</modified>
  <unit name="meter" meter="1"/>
  <up_axis>Z_UP</up_axis>
</asset>
<library_images>
  <image id="tex_panels2_psd" name="tex_panels2_psd">
    <init_from>tex_panels2.png</init_from>
  </image>
  <image id="tex_panels2_n_png" name="tex_panels2_n_png">
    <init_from>tex_panels2_n.png</init_from>
  </image>
  <image id="tex_panels_psd" name="tex_panels_psd">
    <init_from>tex_panels.png</init_from>
  </image>
  <image id="tex_panels_n_png" name="tex_panels_n_png">
    <init_from>tex_panels_n.png</init_from>
  </image>
  <image id="tex_instruments_png" name="tex_instruments_png">
    <init_from>tex_instruments.png</init_from>
  </image>
</library_images>
<library_effects>
  <effect id="tex_panels2_n-effect">
    <profile_COMMON>
      <newparam sid="tex_01_psd-surface">
        <surface type="2D">
          <init_from>tex_01_psd</init_from>
        </surface>
      </newparam>
      <newparam sid="tex_01_psd-sampler">
        <sampler2D>
          <source>tex_01_psd-surface</source>
        </sampler2D>
      </newparam>
      <newparam sid="tex_panels2_n_png-surface">
        <surface type="2D">
          <init_from>tex_panels2_n_png</init_from>
        </surface>
      </newparam>
      <newparam sid="tex_panels2_n_png-sampler">
        <sampler2D>
          <source>tex_panels2_n_png-surface</source>
        </sampler2D>
      </newparam>
      <technique sid="common">
      ...
  </effect>
  <effect id="tex_panels_n-effect">
    <profile_COMMON>
      <newparam sid="tex_01_psd-surface">
        <surface type="2D">
          <init_from>tex_01_psd</init_from>
        </surface>
      </newparam>
      <newparam sid="tex_01_psd-sampler">
        <sampler2D>
          <source>tex_01_psd-surface</source>
        </sampler2D>
      </newparam>
      <newparam sid="tex_panels_n_png-surface">
        <surface type="2D">
          <init_from>tex_panels_n_png</init_from>
        </surface>
      </newparam>
      <newparam sid="tex_panels_n_png-sampler">
        <sampler2D>
          <source>tex_panels_n_png-surface</source>
        </sampler2D>
      </newparam>
      <technique sid="common">
        ...
  </effect>
  <effect id="tex_instruments-effect">
    <profile_COMMON>
      <newparam sid="tex_01_psd-surface">
        <surface type="2D">
          <init_from>tex_01_psd</init_from>
        </surface>
      </newparam>
      <newparam sid="tex_01_psd-sampler">
        <sampler2D>
          <source>tex_01_psd-surface</source>
        </sampler2D>
      </newparam>
      <technique sid="common">
       ...
          </effect>
</library_effects>

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Load the included "MER_parts.blend" file. A solar panel should be selected in the mars rover model. Export this panel to COLLADA using "Apply Modifiers", "Selection only", "Include Material Textures".."UV Textures", "Copy", "Triangulate" and "Sort by Object Name.". Leave "use object instances" and other options off.

Note that simple scenes and exports are often correct. I swear I've even had occasional 'suddenly better' exports that went bad again. Something is wrong deep in the material export functions.

Details

Type
Bug

Event Timeline

Jeremy Lee (JediJeremy) set Type to Bug.
Jeremy Lee (JediJeremy) created this task.
Jeremy Lee (JediJeremy) raised the priority of this task from to Needs Triage by Developer.
Sergey Sharybin (sergey) triaged this task as Normal priority.

@gaia, something you might want to have a look?

Ok, i admit that is a late response. But if possible could you redo the blend file and pack the textures into it so that i can check this issue ?

I've seen this. I don't think it's a COLLADA module problem per se. I think it indicates one of the primitives (maybe not necessarily a face) is somehow linked to an image via the UV Editor. I can't remember if the linked image is visible in Texture display mode. I don't think so. But what works is to Select All of the faces in Edit mode, and then Deselect by material to filter out materials, and finally assign the remaining selection (which may even appear to have nothing selected) and then either Delete, or assign to an image in the UV Editor, and optional Assign to a material

What is maybe a problem with the COLLADA module (maybe it's since been fixed) is the option to use Materials as the basis for the exported textures I've never had success with. I don't know if there is a structural conflict there or what. It isn't useful. It would be nice if it did work, since assigning images in the UV Editor is double-duty (but that's a Blender problem... just one of an endless list of problems that make work with Blender slow/arduous.)

@Mick Pearson (Mick-P) In blender 2.8 we only have materials. So the Collada Module must treat this reasonably. I have added material support in the 2.8 branch only a few days ago, and for now it only can treat diffuse color textures. However this is not yet well tested. And more material support is coming as soon as the principled BSDF Shader gets some planned improvement (transparency and emission).

I have also asked for "bake on the fly" so that we also could export baked images of more complicated materials based on procedural textures for example etc. While there is currently no plan for supporting this (needs additions to the node system as far as i know), i have not yet given up on it :)

@Jeremy Lee (JediJeremy) Since this report is rather old, i tend to put it to the archive for now. However if you can provide an updated blendfile with all the textures included, then i can check on this as soon as i get the blend file.

@Gaia Clary (gaiaclary) I think what Blender needs is a node system specifically oriented to Collada. If it is moving to an open-ended system, it could be a good opportunity to design something. Like in Blender I'm familiar with (2.8 looks like a departure) I know it has legacy Blender Render, and also Cycles, which looks completely separate. What Collada needs is its own separate node system, kind of like another flavor/alternative render system that can live in the Blend files, alongside the others. I struggle to imagine how COLLADA can be used in the future for anything, but I stick with it because we so desperately need open standards for 3D.

If we could just add nodes, manually, and link them to other data. Then that would be a way to explicitly build/represent a Collada document. It would be a better place to start, and a saner system.

@Gaia Clary (gaiaclary) I'm not sure what you mean by "updated blendfile with all the textures included". The .zip file I submitted contained all the textures in an external directory, because that's how the bug presented in this case, and given the intermittent nature of the bug, there's no guarantee that changing the structure of the example will preserve the issue.

I'm just trying the export again in 2.79... aaaand the bug is "gone". Honestly I'm not surprised, it was always finicky, only turning up in some circumstances. But you know the old saying "Things which suddenly start working by themselves, can suddenly stop again." If the underlying bug hasn't actually been fixed, I'm sure it will be back.

The idea of pre-baking materials would be cool, but apart from the bugs, the existing export was mostly good enough. If you'd like an idea of my use case, I was building assets for a Web-based 3D engine. (Basically think of it as exporting assets for use in an external game engine.) I made massive use of 'pre-baked' shadow and ambient occlusion maps, textures and models were built with the _specific_ intention of being exported, so I did not use any features (ie nodes materials) that did not correspond to COLLADA properties. I just used the subset of Blender editor features that COLLADA supported.

I don't need the COLLADA files to be exactly visually identical to the Blender view (I'm not even sure that's possible, since games engines must work in real time and the more pre-baked they are the better) but I do need the export to be _consistent_ and, obviously, correct.

If there was ONE feature I'd add to support all this, it would be a way to pre-define the set of export files and run them all in one go. Eg, with the Mars Rover model, each sub-part of the rover - panels, wheels, body - needs to be exported to a different COLLADA file, because each needs to be a separate asset that's assembled back together in the physics engine. Ie: the wheels turn separate to the body. Armature support seems to be there now which will handle _some_ of that, but even if armatures are fully supported there will always be cases where a 'scene' (eg. a kitchen) will contains objects that need to be separate for the game engine to deal with. (the coffee cup must be a separate asset from the kitchen bench so the player can pick it up, but modelling them all together is preferable so you can see how they fit)

It's a _real_ pain having to export half a dozen COLLADA files (potentially with different export options for each) every time you tweak the model.

The same issue crops up in using blender for 3D printing - you often want to export half a dozen STL files for each printable piece of the model, and having to do that manually after each design tweak is an error-prone pain in the ass.

I'm a scripting noob, so perhaps this is all easy as pie with python... in which case a few examples would be great for how to script this and bundle it with a single .blend file. (since a system-wide user script is pointless) I expect it's a very common need.

I am sorry, i overlooked that the textures are present in the zip file. I give it another look later. It may also well be the case that the issue has been resolved as i am steadily (and admittedly only very slowly) working on fixing the Collada exporter since about 4 years now. Also with Blender 2.8 everything changes :) The new Collada exporter is already in the 2.8 Beta but it has not yet been tested to the very details.

About your idea of separate files in one go: I think we should not put this directly into the Exporter itself. However this sort of batch processing could be done from within an Addon which then calls the exporter. The main work would be to find an easy way to define the sets. One first guess could be to use the Blender 2.8 Collections for separate exports... But this is just a very quick guess though :)