COLLADA exporter does not emit layer information. #56721

New Issue

John Nagle · 2018-09-08T09:34:14+02:00

John Nagle commented

2018-09-08 09:34:14 +02:00

System Information
Ubuntu 16.04 LTS x86 64-bit.

Blender Version
2.79

COLLADA exporter does not emit layer information.

The COLLADA spec for the element defines an attribute "layer". The spec says "layer ListOfNames: The names of the layers to which this node belongs. For example, a value of foreground glowing” indicates that this node belongs to both the layer named foreground and the layer named glowing. The default is empty, indicating that the node doesn’t belong to any layer. Optional".

So the current output,

    <node id="Plane" name="Plane" type="NODE">

should become

    <node id="Plane" name="Plane" type="NODE" layer="Layer0">

or, for user-named layers (a feature of a standard add-on)

  <node id="Plane" name="Plane" type="NODE" layer=Physics">

The "layer" attribute is "Optional", but the description of "Optional" at the beginning of Chapter 2 of the COLLADA spec indicates that if you have the feature in your program, it should show up in COLLADA output. Makes sense, and it's clear how this should work:

(At the beginning of Chapter 2, the COLLADA spec says: Each “Requirements” section details options that must be implemented completely by every compliant tool. One exception to this rule is when the specified information is not available within a particular application. An example is a tool that does not support layers, so it would not be required to export layer information (assuming that the export of such layer information is normally required); however, every tool that did support layers would be required to export them properly.)

(A use case for this is that it would allow solving a painful problem with the Second Life COLLADA importer, which currently requires a separate COLLADA file for visible and physics layers. When multiple files are created by exporting only the selection, they don't always have the same coordinate system, resulting in misalignment.)

Exact steps for others to reproduce the error
Export a file with two layers, preferably named ones, and examine the entries in the COLLADA file.

**System Information** Ubuntu 16.04 LTS x86 64-bit. **Blender Version** 2.79 **COLLADA exporter does not emit layer information.** The COLLADA spec for the<node> element defines an attribute "layer". The spec says *"layer ListOfNames: The names of the layers to which this node belongs. For example, a value of foreground glowing” indicates that this node belongs to both the layer named foreground and the layer named glowing. The default is empty, indicating that the node doesn’t belong to any layer. Optional".* So the current output, ``` <node id="Plane" name="Plane" type="NODE"> ``` should become ``` <node id="Plane" name="Plane" type="NODE" layer="Layer0"> ``` or, for user-named layers (a feature of a standard add-on) ``` <node id="Plane" name="Plane" type="NODE" layer=Physics"> ``` The "layer" attribute is "Optional", but the description of "Optional" at the beginning of Chapter 2 of the COLLADA spec indicates that if you have the feature in your program, it should show up in COLLADA output. Makes sense, and it's clear how this should work: (At the beginning of Chapter 2, the COLLADA spec says: Each “Requirements” section details options that must be implemented completely by every compliant tool. One exception to this rule is when the specified information is not available within a particular application. An example is a tool that does not support layers, so it would not be required to export layer information (assuming that the export of such layer information is normally required); however, every tool that did support layers would be required to export them properly.) (A use case for this is that it would allow solving a painful problem with the Second Life COLLADA importer, which currently requires a separate COLLADA file for visible and physics layers. When multiple files are created by exporting only the selection, they don't always have the same coordinate system, resulting in misalignment.) **Exact steps for others to reproduce the error** Export a file with two layers, preferably named ones, and examine the <node> entries in the COLLADA file.

John Nagle commented

2018-09-08 09:34:14 +02:00

Added subscriber: @Nagle

Bastien Montagne commented

2018-09-08 11:21:44 +02:00

Added subscribers: @GaiaClary, @mont29

Gaia Clary was assigned by Bastien Montagne

2018-09-08 11:21:44 +02:00

Bastien Montagne commented

2018-09-08 11:21:44 +02:00

@GaiaClary will let you handle that one. :)

Gaia Clary commented

2018-09-08 18:36:33 +02:00

yes, this is not a big issue to add to the collada exporter. Although the layer names would then actually be taken from the layer indices "0", "1", ... "31" I am not sure how we would support the creation of named layers here (blender does not support named layers in 2.79).

A related issue would be to assign named layers from a collada file to Blender layers during import. In that case we might need to create a map of imported named layers to blender layers to assign the named layers to the blender layer indices.

Now the only issue that remains is what to do when there are more than 32 named layers assigned to an imported Object. Also we might need to add a rule:

"if layername is a small integer < 32 then use the layer name as indication for the blender layer that should be used."

This would allow to import dae files to the same blender layers as from where they have been exported when the original export tool was blender. Well, there is one caveat still (mixed layer names and layer indices)

Last but not least we need to see how all of this matches into Blender 2.8 As far as i know the number of layers is unlimited in 2.8... Do we have named layers as well then?

@Nagle
Does SL support the import of physical layer and object layer in one file? Is it then necessary to use specific layer names? or just different layers for the model and the physics ? Is there a document from where we can learn how this needs to be implemented to make SL happy?

yes, this is not a big issue to add to the collada exporter. Although the layer names would then actually be taken from the layer indices "0", "1", ... "31" I am not sure how we would support the creation of named layers here (blender does not support named layers in 2.79). A related issue would be to assign named layers from a collada file to Blender layers during import. In that case we might need to create a map of imported named layers to blender layers to assign the named layers to the blender layer indices. Now the only issue that remains is what to do when there are more than 32 named layers assigned to an imported Object. Also we might need to add a rule: "if layername is a small integer < 32 then use the layer name as indication for the blender layer that should be used." This would allow to import dae files to the same blender layers as from where they have been exported when the original export tool was blender. Well, there is one caveat still (mixed layer names and layer indices) Last but not least we need to see how all of this matches into Blender 2.8 As far as i know the number of layers is unlimited in 2.8... Do we have named layers as well then? @Nagle Does SL support the import of physical layer and object layer in one file? Is it then necessary to use specific layer names? or just different layers for the model and the physics ? Is there a document from where we can learn how this needs to be implemented to make SL happy?

John Nagle commented

2018-09-08 20:37:54 +02:00

If the standard Layer Name addon is enabled, Blender has named layers, and the names appear in the Layer tab. By default, the names are "Layer0", "Layer1", etc., The user can rename them in the Layers tab.

If 2.8 has unlimited layers, they probably ought to be named.

What does SL need? Some way to distinguish the physics layer and multiple level of detail layers in the COLLADA file. Currently, this is done via workarounds.

Workaround 1:

http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Blender#LOD_meshes_.28with_Blender_2.49.29
This involves repeatedly reloading the Blender model, applying mesh reduction, and exporting multiple COLLADA files. The reduced mesh is not kept in Blender format at all.

Workaround 2:
Select the objects to be uploaded and only export the current selection. Repeat for the visual and physical models. This can create problems with the visual and physics models having a different origin, if the physics model was modeled separately. The models then line up in Blender, but not in SL.

All this is such a pain that it's rarely done. Most creators just upload a model with too many polys and let SL's (very bad) mesh reduction bang out some lower level of detail models by deleting triangles. The result is that SL is choked with high-poly models with nonexistent or terrible low-LOD models.

Some of us on the third party SL viewer side are looking at improving this situation. For that, it would help if one COLLADA file contained all the necessary info. Then we could tell users to create a few layers, "LOD0", "LOD1", "PHYS", etc. and the uploader could sort them out. **It would also help if you could export only the selected levels, all with the same origin.**That would work with current SL uploaders. Thanks.

The UE4 world has the same problem, but a different export format and set of workarounds. See https://answers.unrealengine.com/questions/416995/how-to-import-lods-as-one-fbx-blender.html

If the standard Layer Name addon is enabled, Blender has named layers, and the names appear in the Layer tab. By default, the names are "Layer0", "Layer1", etc., The user can rename them in the Layers tab. If 2.8 has unlimited layers, they probably ought to be named. What does SL need? Some way to distinguish the physics layer and multiple level of detail layers in the COLLADA file. Currently, this is done via workarounds. Workaround 1: http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Blender#LOD_meshes_.28with_Blender_2.49.29 This involves repeatedly reloading the Blender model, applying mesh reduction, and exporting multiple COLLADA files. The reduced mesh is not kept in Blender format at all. Workaround 2: Select the objects to be uploaded and only export the current selection. Repeat for the visual and physical models. This can create problems with the visual and physics models having a different origin, if the physics model was modeled separately. The models then line up in Blender, but not in SL. All this is such a pain that it's rarely done. Most creators just upload a model with too many polys and let SL's (very bad) mesh reduction bang out some lower level of detail models by deleting triangles. The result is that SL is choked with high-poly models with nonexistent or terrible low-LOD models. Some of us on the third party SL viewer side are looking at improving this situation. For that, it would help if one COLLADA file contained all the necessary info. Then we could tell users to create a few layers, "LOD0", "LOD1", "PHYS", etc. and the uploader could sort them out. **It would also help if you could export only the selected levels, all with the same origin.**That would work with current SL uploaders. Thanks. The UE4 world has the same problem, but a different export format and set of workarounds. See https://answers.unrealengine.com/questions/416995/how-to-import-lods-as-one-fbx-blender.html

Gaia Clary commented

2018-09-09 00:17:33 +02:00

The enhanced Layer management is an addon. However, we can not add a dependency between the collada exporter and any addon, so for the blender collada exporter we still must limit the features to what default blender has to offer. For blender 2.8 i do not know yet how the layers will be organized. so i need some time to look into this (which i will certainly do before 2.8 is released).

I believe that your request actually is much better placed in a separate addon that handles SL collada management in some way. For example the Avastar addon could easily be improved to make the SL collada management much easier compared to how it is right now. And indeed ideas for such an improvement are on our tasklist since a long time, although there was never a huge demand so far.

Do i understand correct, that actually there is no support for named layers in the sl viewers, but you plan to add such improvements and new features to third party viewers? I am open to support such new features within our own addon.

The enhanced Layer management is an addon. However, we can not add a dependency between the collada exporter and any addon, so for the blender collada exporter we still must limit the features to what default blender has to offer. For blender 2.8 i do not know yet how the layers will be organized. so i need some time to look into this (which i will certainly do before 2.8 is released). I believe that your request actually is much better placed in a separate addon that handles SL collada management in some way. For example the Avastar addon could easily be improved to make the SL collada management much easier compared to how it is right now. And indeed ideas for such an improvement are on our tasklist since a long time, although there was never a huge demand so far. Do i understand correct, that actually there is no support for named layers in the sl viewers, but you plan to add such improvements and new features to third party viewers? I am open to support such new features within our own addon.

John Nagle commented

2018-09-09 04:14:00 +02:00

I believe that your request actually is much better placed in a separate addon that handles SL collada management in some way.

That's been done. At least twice. There are two SL-specific COLLADA exporters for Blender, both written in Python:

  https://github.com/godotengine/collada-exporter

  https://meshlogic.github.io/listings/blender-addons/collada-exporter-sl/0.3/ColladaExporterSL.py.html

Avistar, a paid product, also seems to have its own COLLADA exporter.

Is it better to proliferate alternatives to Blender's own exporter rather than fix it? All I'm asking for is something that's defined in the COLLADA spec and should have been present already.

*I believe that your request actually is much better placed in a separate addon that handles SL collada management in some way.* That's been done. At least twice. There are two SL-specific COLLADA exporters for Blender, both written in Python: ``` https://github.com/godotengine/collada-exporter ``` ``` https://meshlogic.github.io/listings/blender-addons/collada-exporter-sl/0.3/ColladaExporterSL.py.html ``` Avistar, a paid product, also seems to have its own COLLADA exporter. Is it better to proliferate alternatives to Blender's own exporter rather than fix it? All I'm asking for is something that's defined in the COLLADA spec and should have been present already.

Gaia Clary commented

2018-09-09 08:35:10 +02:00

I already stated that we can add the layer attribute to the Blender collada exporter. I explained how i would do this and i explained what challenges i see to get this done properly. I also stated that i will add the layer attribute. So your request for adding this feature has been well heard and will be provided some time in the near future.

All i asked you was in which way SL does support multiple layers during importing objects. Unless i fully misunderstand, your answer indicates to me that the SL viewers do not support layers at all. That is all i wanted to know.

I already stated that we can add the layer attribute to the Blender collada exporter. I explained how i would do this and i explained what challenges i see to get this done properly. I also stated that i will add the layer attribute. So your request for adding this feature has been well heard and will be provided some time in the near future. All i asked you was in which way SL does support multiple layers during importing objects. Unless i fully misunderstand, your answer indicates to me that the SL viewers do not support layers at all. That is all i wanted to know.

John Nagle commented

2018-09-09 20:06:53 +02:00

Fair enough. Currently, SL viewers currently do not recognize layer info in COLLADA files. They want each layer in a separate file.

So a useful feature would be "export visible layers", or "export each layer to a separate file", in addition to the current "export selected" option. That would work with existing SL uploaders. That would make some SL users very happy.

That's a new feature request, though. It seemed more appropriate to ask merely that Blender implement the published COLLADA spec more fully. Less controversial.

There are plans underway to make some improvements to the SL Firestorm uploader. (Bigger preview window and more checking, at least. Maybe more.) So this is a good time to do Firestorm uploader improvements and simplify the uploading process. Thanks.

Fair enough. Currently, SL viewers currently do not recognize layer info in COLLADA files. They want each layer in a separate file. So a useful feature would be "export visible layers", or "export each layer to a separate file", in addition to the current "export selected" option. That would work with existing SL uploaders. That would make some SL users very happy. That's a new feature request, though. It seemed more appropriate to ask merely that Blender implement the published COLLADA spec more fully. Less controversial. There are plans underway to make some improvements to the SL Firestorm uploader. (Bigger preview window and more checking, at least. Maybe more.) So this is a good time to do Firestorm uploader improvements and simplify the uploading process. Thanks.

Joseph Davies commented

2019-03-09 01:42:33 +01:00

Added subscriber: @JosephDavies

Brendon Murphy commented

2019-06-10 13:06:21 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2019-06-10 13:06:21 +02:00

Changed status from 'Open' to: 'Archived'

Brendon Murphy closed this issue

2019-06-10 13:06:21 +02:00

Brendon Murphy commented

2019-06-10 13:06:21 +02:00

Archiving, @GaiaClary feel free to double check

Gaia Clary commented

2019-06-10 13:27:10 +02:00

i wonder if we can add layer information based on the new Blender layer system. However an item can be placed into several layers... hmmm that needs more thoughts i guess