Materials ID in Collada export

unhandled

(Hny) #1

Hi,
I am using Rhino with v-ray and sometimes export files to collada to use the geometry in Lumion. It seems that something changed in an update somewhere, because i have increasingly run into issues where materials are not recognized by Lumion as the correct, but instead it seems they are named individual pr. mesh. The only fix i have found so far is that materials without bump seems to always go through, but material with bump assigned can sometimes go through.
I have recreated the issue on multiple computers with a lot of variations in the material definition, and there does not seem to be an apparent mistake i did recently, so it is general.


(Nathan 'jesterKing' Letwory) #2

Is this with v5 or v6?


(Hny) #3

This is in v5.
I have run through a lot of further test and have concluded that the issue most likely started with the V-ray 2 update which made it the standard to have bump texture “shown in viewport” as standard. In general a rather annoying addition, which many at work then disabled often manually. This has indirectly lead to the inconsistency i had in imports. But still weird that the bump-channel affect the export of collada (Or FBX for that matter). I think i will need to establish contact with ChaosGroup too, since the issue is even worse in V-ray 3.


(Nathan 'jesterKing' Letwory) #4

I think this material-per-object is fixed in v6. If you have a simple 3dm file that causes the issue in v5 for you please attach it here. I can verify if it is fixed in v6.


(Hny) #5

TEST_Of_a_new_world_Bad.3dm (1.1 MB)
I’m uncertain if the file would react the same without v-ray installed and access to our texture-files, but please give it a go.
Along the same line, i can drop a note that the collada export also fails if a material name contains an “&” and the same error happens if a linked texture file contains a “&” in the file name. In general this is also very poor naming etiquette, but those things happens in larger teams.


(Nathan 'jesterKing' Letwory) #6

This is the DAE I get from v6. Not sure what to expect exactly, but importing it in Blender gives for instance two boxes with the same material Wood_box (or actually named Material-_Wood_box), not with duplicate materials.

TEST_Of_a_new_world_Bad.dae (191.4 KB)

The ampersand bug I have logged as RH-45421.


(Hny) #7

I tried with your export, and it acts the same way as in Rhino 5.
The guys at Lumion has made me a Hot-fix which solves the issue for me personally, but the odd influence is still there for others.

Fine with the logget bug. It seems like a page i need to learn. I do find bugs from time to time.

Just out of curiosity, if it worked in the Rhino 6, would it not be fixed in Rhino 5, or has that now lost priority? It makes me a bit sad since i bought a Rhino 5 license in september. I tried to upgrade it before i finished my education to have Rhino 6 to play with at home, but never got a response from the danish re-seller.


(Nathan 'jesterKing' Letwory) #8

If it is the Lumion import that gives duplicate materials, then the error is probably with Lumion. Blender imports the materials as expected. The COLLADA file internally looks well formed as well, with only one material for the Wood_box as mentioned earlier:

  <library_materials>
    <material id="c0150db6-f49f-4946-ad8a-117652cabdc4" name="Material-_Rendered_wall">
      <instance_effect url="#fx-c0150db6-f49f-4946-ad8a-117652cabdc4" />
    </material>
    <material id="a0eeab78-4c76-4cc4-8cbc-56e735611ef7" name="Material-_Glass">
      <instance_effect url="#fx-a0eeab78-4c76-4cc4-8cbc-56e735611ef7" />
    </material>
    <material id="a0471e8c-a439-4f28-90b7-e59d8549c15f" name="Material-_Concrete_wall">
      <instance_effect url="#fx-a0471e8c-a439-4f28-90b7-e59d8549c15f" />
    </material>
    <material id="ba26b077-25b3-4783-9f08-e9bdf51b9997" name="Material-_Wood_Floor">
      <instance_effect url="#fx-ba26b077-25b3-4783-9f08-e9bdf51b9997" />
    </material>
    <material id="a7b3f540-2313-402c-9535-8f9971ed209a" name="Material-_Wood_Box">
      <instance_effect url="#fx-a7b3f540-2313-402c-9535-8f9971ed209a" />
    </material>
    <material id="ca97be10-3216-4f7f-bf35-6975d76b1d66" name="Material-_Maybe_brass_too">
      <instance_effect url="#fx-ca97be10-3216-4f7f-bf35-6975d76b1d66" />
    </material>
    <material id="e0cbe85c-fd62-479b-b22c-5cd6bcbad61f" name="Material-_Brass_death">
      <instance_effect url="#fx-e0cbe85c-fd62-479b-b22c-5cd6bcbad61f" />
    </material>
    <material id="cef51093-5072-483c-88b9-8578d89706b1" name="Material-_Rendered_wall">
      <instance_effect url="#fx-cef51093-5072-483c-88b9-8578d89706b1" />
    </material>
  </library_materials>

They probably should distribute the hotfix to their userbase.

There are no more updates to v5. v6 is the version containing fixes to issues also found in v5. You probably need to poke your danish reseller again and if that doesn’t work maybe contact sales@mcneel.com directly to see what is possible still.

I have been working on the ampersand issue, and I think I have a fix ready. The fix will actually allow even for accepted non-ASCII characters as well, meaning scandics should work, greek letters, cyrillic etc.


(Hny) #9

Interesting to see the inner workings of the file. It seems the material id is what sometimes gets mixed up with the name for some reason. And somehow the bump provocates this.
Good with the character-fix. Thought having those kind of letters is just asking for trouble later on.

I’ll try to give it an other shot with the license for Rhino 6.


(Brian Gillespie) #10

RH-45421 is fixed in the latest Service Release Candidate