Specifying the LODs in the same collada file

[LindaB Helendale]

If anyone would have a link to the specifications of the SL collada uploader, I would much appreciate... and while not having any reference, I continue asking if anyone would know

Collada lets you specify the LOD in the same file as a proxy for the node, as an example

<node id="NODE0"/>
<node id="NODE1"/>
<node id="NODE2"/>

<node id="LOD1">
  <instance_node url="#NODE1" proxy="#LOD2"/>
</node>
<node id="LOD2">
  <instance_node url="#NODE2"/>
</node>
<visual_scene>
  <node>
    <instance_node url="#NODE0" proxy="#LOD1">
  </node>
</visual_scene>

So mid LOD would be proxy of high LOD, low LOD proxy of mid LOD and lowest LOD proxy of low LOD. But collda specification does not say that the application must use the proxy as LOD, it's just a way it's often used.

Because the mechanism and use of this attribute are application defined, more information about how applications can decide which path to follow should be stored in the <extra> element of <instance_node>.

It's a bit work to make a script to bundle the LODs in this format just to test if it is supported, and if it is, likely the <extra> element should have some info to tell the uploader to take the LODs from the proxy-nodes.

Would anyone know if this is supported, and what <extra> it needs, and/or where to find the SL collada uploader specs?

 

[Drongle McMahon]

I am pretty sure there is no comprehensive document explaining the way different Collada constructs will be interpreted by the SL importer. They may get round to writing one, but for now it is still subject to change. So we will probably have to wait for it to reach a more stable state before anyone, inside or outside SL, finds it worth the effort of maintaining such a document. (There is a wiki description of the internal format, but it doesn't explain the translation process.) Maybe we all need to get together and assmble our own, together with the ways of producing the appropriate output from the main programs?

As far as this particular issue is concerned, all I know is essentially to be found in this thread. In summary, the <mesh>s in each LOD file are associated by the order of their containing <geometry> tags in the Collada files. This is a problem because 3D packages/exporters may not provide explicit control of this order. To solve this, they may make changes to base the association on a naming convention, or they may not. There is certainly scope for a simple stadalone script/application to allow re-ordering independently of authoring package, but once again, is it worth the effort while we can't be confident this will not be changed (after all, the role of ordering of <triangles> lists was recently changed).

As far as <extra> tags are concerned, I suspect this should be avoided because there is no simple way to control this from (at least some) authoring software. (You can do a bit in Blender, but it's very obscure and limited). Both this and many possible non-standard naming conventions have the disadvantage of being non-transportable.

 

[Drongle McMahon]

Further... Am I right in my impression that the proxy attribute was introduced in Collada 1.5? The original development of the SL uploader was against the Collada 1.4 specification, and some changes have been/are being made to bring compatibility with 11.4.1 stuff. I have not seen anything mentioned about 1.5.

[Nalates Urriah]

Drongle gave a good explanation... but to put it bluntly... what you do to the Collada data is far less relavant than what the Lab does to their Collada importer.

The Collada Specification...

SL Mesh Asset Format

[LindaB Helendale]

Thanks Drongle

I would think LL has to have a card of the current  specs for the collada importer,  to keep the software development in control (it can't be in the heads of the developers only, I hope...) and it would be win-win for LL and the user community to see the specs, instead of tedious and uncertain reverse engineering.

 

Natales Urriah wrote:

>Drongle gave a good explanation... but to put it bluntly... what you do to the Collada data is far less relavant
>than what the Lab does to their Collada importer.

I dont think you understood the question, there's collada specs and there's the internal mesh format but the question was about specs for the translation of the collada to the mesh asset.

In general I think what content creators do with collada data (they create the meshes) is not less relevant than  what  LL does with Collada importer, and knowing how the Collada importer translates the data to the mesh is a key to utilize the features LL provides.

 

[Luc Starsider]

This is all a bit too technical for me and a bit over my head. But what is the advantage of specifying all LODs in the same collada file?

- Luc -

[Drongle McMahon]

Whoops ... I answered the wrong question.

I think it's just a convenience.

[Luc Starsider]

Oh, right. Thanks Drongle.

Perhaps I'm mistaken, but Blender at least does not have any easy, convenient way of exporting one collada file with all LODs, so perhaps the time and effort it takes to make the complete collada file cancelles out the convenience? Other 3D programs might have export tools that takes care of this, but I don't know them. Just a thought...

- Luc -

[Drongle McMahon]

Well, in 2.49 it's easy enough to put all the LOD models in one file. You just select them all and uncheck the "export selected only" button. However, that will not be usable because the uploader will just treat them as separate objects. Some sort of convention, whether through names, ids or extra tags, would have to be added. To be useful, that convention would have to be easy to arrange in multiple authoring programs. I doubt if the deveopers would see that as worth the effort. I did make a jira suggesting something like this very early in the beta, but I now consider it was sensibly ignored.

[LindaB Helendale]

Yup it's just convenience, similar to having several mesh objects in the same file, but of course it is convenient only if the feature is supported in the 3d tools.

I don't know much about what Blender or other such tools offer readily, I make my meshes with math tools and write the collada files directly according to the collada specifications, so I'm just curious of which collada features work and how,  and which don't work. Definitely not worth suggesting a feature that people could not use.

 

[Gaia Clary]

Hi.

I think this thread is closely related to CTS-695 in the Jira.

Look at the first comment in that thread ;-) I also mentioned that if someone really would try to import a complete scene with several objects, each with 4 LODS, they would get kind of trouble to do that by hand... (think of a scene with 100 objects, each with 4 LODS). Now try to make the 4 export files for the 4 LOD's.

If the proposed solution in that thread gets implemented (or maybe it is already implemented ?) then putting all LOD's into the same file should be very easy doable too...

BTW i would want to keep all LOD's in the same file because this minimises mixing up wrong files. Somewhere its all a matter of organisation and having one project all together in one file should help ;-)

And actually i had such big projects in mind when proposing CTS-634

[Drongle McMahon]

"or maybe it is already implemented ?"

Yes. Prep's comment there is a bit confusing on that point. He seems to be suggesting that if the names of the meshes had been identical in the LOD files, he would have expected that to have overriden the ordering. Otherwise, why would he identify the name differences as relevant? On the other hand, he certainly doesn't say that. Maybe a clarification question at the next meeting would be good.

However, if they have to have the same name/id, that would preclude them being in the same file (strictly applies only to id, not name, bur in Blender 2.49 exporter they are the same). It would also need either hand editing or a change in the exporter as Blender can't have duplicate object names. Some sort of convention like the one you suggested would be necessary instead.

Meanwhile, here is a link to the old jira I left out of last post. Since that has been left for so long, I think the chances of action on this issue must be low.