Page MenuHome

Import/Export from/to Collada: issue with diffuse color/diffuse texture
Closed, InvalidPublic

Description

System Information
Tried on 2 different windows 10 computers with same result

Blender Version
Broken: 2.79

Import Export Bug

When you import/export from blender it only import/exports diffuse color or diffuse texture not both. I can confirm this 100% as I exported as a .dae file so could look inside and without a texture added to the material it shows the rgb and with a texture it only shows the texture name and no rgb value.

Details

Type
Bug

Event Timeline

simon cull (scull) updated the task description. (Show Details)
Sergey Sharybin (sergey) triaged this task as Needs Information from User priority.

Please follow bug report guidelines and provide simple file and exact steps needed to reproduce the error.

simon cull (scull) added a comment.EditedSep 14 2017, 2:40 PM

you don't need a file it happens with any blender export.

And the exact steps are to make an object change its diffuse color add a texture and export.

The result will be the exported file will be missing diffuse rgb values.
If you don't add a texture the result will be the export has diffuse rgb color values.
You can test this easily by exporting as a dae and opening it in a notepad app but it happens with other formats aswell.

File uploaded anyway saves you making a default model and material.

Am i right you're using Collada import/export ?

I did to test but 1st noticed the problem with fbx .
Collada is just easier to see the bug as you can open it in notepad.

Sergey Sharybin (sergey) raised the priority of this task from Needs Information from User to Normal.

@gaia, mind checking what's going on with Collada here?

@Bastien Montagne (mont29), you might also be interested to have a look here.

Making a report about 'import/export in Blender' is utterly confusing, all exporters handle data in different ways, since not a single file format shares same material capabilities. Please try to be accurate, and talk about a single issue per report.

Also assuming when you say 'object diffuse color' you are actually referring to 'object's material diffuse color'.

FBX always export all 'basic' material data, obviously including diffuse color, as well as texture assigned to diffuse color if there are some. If you think there is something wrong here, please make another report with detailed and specific case.

Bastien Montagne (mont29) renamed this task from Import Export Bug to Export to Collada issue with diffuse color/diffuse texture.
Bastien Montagne (mont29) renamed this task from Export to Collada issue with diffuse color/diffuse texture to Import/Export from/to Collada: issue with diffuse color/diffuse texture.
simon cull (scull) added a comment.EditedSep 14 2017, 4:00 PM

There is a problem 100% I cant explain it any better than I already have so I wont be making another report .If you cant be bothered to do a simple test as I have outlined above then I will just have to find another 3d app to use. All I wanted to do is bug report this not get loads of pedantic replies.

Check our reporting rules, one of them is 'one issue per report', and collada and FBX are definitively totally different issues. We cannot manage confusing reports, handling god ones already eats tremendous of time not spent on actually coding new useful stuff for Blender…

simon cull (scull) added a comment.EditedSep 14 2017, 4:07 PM

ok its an export issue then I just noticed it happens on import too that's all .
And was trying to give you all the info.

plus this is happening over several formats so its quite obviously a problem with how blender gives it exporters information.
That's why I included more than one so you can see its not the exporters but something else.

The exporters actually don't get prepared stuff from Blender, but cherry pick their information as necessary :) So if you see the same issue with FBX and Collada then this is most probably just a coincidence.

I will look at the Collada part.

If you are only going to look at one even thou both have the bug I would prefer you to look at fbx as that's the format I am using as I am uploading to sansar.

It looks like this problem has been in blender for a while I just found another report that I didn't find on my initial search here.

https://developer.blender.org/T51006#429995

Gaia Clary (gaiaclary) closed this task as Invalid.Jan 31 2018, 2:19 PM

The Collada specification allows for diffuse color either a texture or a solid color:

Collada 1.4 specification (common_color_or_texture_type)
Note: Exactly one of the child elements <color>, <param>, or <texture> must appear. They are
mutually exclusive.

This means we can neither export nor import the material color and its diffuse texture at the same time. And this means we have to decide which of the two we export. We followed the blender convention here:

If an object has a diffuse color and a diffuse image texture, then the image texture wins.

So, imho this is not a bug.

I've narrowed the diffuse color problem. When exporting the diffuse color from Blender the following happen and is definitely a bug.

Example: Original viewport object color is set to the following values: 1, 0, 1, 1
Exported result in the DAE file:

<diffuse>
    <color sid="diffuse">0.8 0 0.8 1</color>
</diffuse>

So instead of using 1 as the right value, you are using 0.8 e.g.

Tested in version 2.79.6 dated 2018-09-10.
Please fix this if possible. Other values are wrong too. A Blender color value of 0.5 result in a DAE value of 0.4 e.g.

Thank you
Chris

I believe you have kept the color intensity of your material at 0.8...

Ok, here is a bit of an explanation:

As far as i know Collada does not define color intensity. It only has diffuse_color. So, in blender we decided to export the color value as the product of diffuse_color value and the diffuse_intensity. So lets say:

diffuse_color = <1.0, 0.0, 1.0>
diffuse_intensity = 0.8

Then the final exported color is: <1.0, 0, 1.0>*0.8 = <0.8, 0, 0.8>

Upon Importing a color, there is a bit more to think of. Since all we have is the diffuse_color, we need to figure out how we should distribute this information between Blender's diffuse_color and diffuse_intensity. And we actually want to avoid having intensity > 0.8 if ever possible (to avoid fireflies in blender render).

So instead of blindly setting intensity to 1.0 to get this "fixed", the importer does something a little bit more clever:

  • first it finds out the maximum value of (r, g, b, 0.8) where r,g,b are the color components of the diffuse_color. This value is used as the color_intensity (diffuse_intensity=0.8)
  • then the diffuse_color is divided by the intensity: < 0.8/0.8, 0/0.8, 0.8/0.8 > = <1.0, 0.0, 1.0 >

So we end up with:

diffuse_color = <1.0, 0.0, 1.0>
diffuse_intensity = 0.8

Lets make another example:

diffuse_color = <0.5, 0.0, 0.5>
intensity = 0.5

exported color = <0.5, 0.0, 0.5>* 0.5 = <0.25, 0.0, 0.25>

imported intensity max(0.25, 0.0, 0.25, 0.8) = 0.8
imported color = <0.25, 0.0, 0.25> / 0.8 = <0.3125, 0.0, 0.3125>

and one final:

diffuse_color = <1.0, 0.0, 1.0>
intensity = 1.0

exported color = <1.0, 0.0, 1.0>

imported intensity max(1.0, 0.0, 1.0, 1.0) = 1.0
imported color = <1.0, 0.0, 1.0> / 1.0 = <1.0, 0.0, 1.0>

So while the imported colors and diffuse values are in general not the same as the exported ones, we still have got the colors right...

I admit this is not intuitive and it also is not optimal. However it is imposed by collada not having an intensity value and by blender render having trouble with high intensity values.

Having said this, we might change this particular behavior for Blender 2.8 since here we do no longer have the blender render and possibly the color definitions can be handled more intuitive (i have not yet looked at this, so i can only guess for now)

I can think of a Collada import option "optimize diffuse_intensity" which will:

  • when enabled: behave as described above
  • when disabled: use the imported data as color values and set diffuse_intensity to 1.0

Does that make sense?

OK... now I understand my problem.
I am always using Cycles nodes for all my material settings. To be honest I've never used the Blender Renderer in the history...
So I've checked the values for my material by switching to Blender Render... and voila! There are the settings set.

Is there a chance to interpret the Cycles materials for the DAE export too?

So it was my fault, but as I said: I never use the Blender sefault Materials...
X-D

supporting cycles is on the list. However since Blender 2.8 dropped blender render and comes with a much bigger challenge (more renderers beside Cycles), i decided to not rush and look into this for when the time comes for Blender-2.8 support. I already fear that moment :/

supporting cycles is on the list. However since Blender 2.8 dropped blender render and comes with a much bigger challenge (more renderers beside Cycles), i decided to not rush and look into this for when the time comes for Blender-2.8 support. I already fear that moment :/

I'm sure you will make it!
Thank you for your time.

Hi Gaia.

I've another question for Collada Export in Blender:
Is there a way to export Actions from NLA Editor to a Collada file too?

I've several animations in my scene I would like to find seperately inside one single collada file.

Thank you
Chris

FWIW here is what I recommend:

<library_effects>
  <effect id="blinn3-fx">
    <profile_COMMON>
      <newparam sid="file2-surface">
        <surface type="2D">
          <init_from>file2</init_from>
          <format_hint>
            <option>SRGB_GAMMA</option>
          </format_hint>                                    
        </surface>
      </newparam>
      <newparam sid="file2-x-color">      
        <semantic>COLOR0</semantic>        
        <sampler2D>
          <source>file2-surface</source>
        </sampler2D>
      </newparam>
      <newparam sid="file2-multiply">
        <semantic>COLOR1</semantic>
        <float4>0.95 0.85 0.85 1</float4>
      </newparam>                
      <technique sid="common">

Needless to say COLLADA is messed up in a lot of ways. But there is wiggle room, without amending the standards or resorting to "extensions" (that I feel ought to be limited to internal use cases) to develop community conventions, like this one. This usage is within the standard. I am trying to reintroduce COLLADA to communities that don't want to live under the shadow of AutoDesk et al. I have a few proposals that I wish Khronos would let me publish on its official webpage to address broken aspects of the standards, sometimes creatively, without altering the XML Schema documents.