While writing my CDAE exporter/importer, I found a few things that aren’t clear to me, and where I would appreciate some more information Empty Colmeshes (Node)base00.start01.Colmesh-1.(Obj)Colmesh->meshes... contains lots of empty meshes (I believe 1 for each detail-struct?) besides the actual collision mesh, why? Also, (Detail)collision-1->objectDetailNum always points to one of the empty meshes? Keyframes CDAE has single vectors/arrays containing rotations/translations/scaling keyframes for all nodes, how is defined what node uses what block of keyframes? Naming How important is naming of Nodes.Objects and Details? Im assuming naming of Nodes and Objects is mostly ignored, but that it matters for Details?? (example: BeamNG always looks for (Detail)collision-1 to decide what mesh to use as colmesh).
I don’t know, but maybe it can help you https://torquegameengines.github.io...entation/Artist Guide/Formats/dts_format.html
Ok I figured it out. 1: The empty colli meshes are just a buffer for the other Detail Levels 2: Sequence contains bit-arrays that define whether animation data is used or not. 3: Node and Object names are irrelevant while Detail has indeed some magic names.
Blender foundation has decided to give long term support (LTS) for the dae exporter. The exporter is still an integral part of the latest Blender version. They even didn't made a plugin out of it. That means to me that we can continue to export our artworks to dae and BeamNG makes the job to convert it to cdae. "Legacy" doas not mean to throw it away, it means to keep it from the past but probably only do not further develope, imo. So why is that so important to you to have a exporter for the "damn" cdae format for blender?
By LTS you mean 4.5 right? Future versions of Blender like 5.0 will no longer support it. As for why cdae? Because I can (Though it sometimes makes me question my live choices...), but the addon also contains a DAE exporter, so people can use Blender 5.0 and still export classic Collada to BeamNG if they want. Compared to the built-in exporter, this addon also has some BeamNG specific features to make content creation easier. (like full support for material exports to json) For now, dae is even the main part of the addon, cdae support is still very experimental.
"By LTS you mean 4.5 right?" Yes. Many people thought it would be discontinued much sooner. So I was surprised that the 4.5 LTS still had it. "Future versions of Blender like 5.0 will no longer support it." But will provide it as a plugin then, I think. Cause why not and why did they kept it into 4.5? We'll see... "Compared to the built-in exporter, this addon also has some BeamNG specific features to make content creation easier. (like full support for material exports to json). For now, dae is even the main part of the addon, cdae support is still very experimental." Sounds great! Thanks for all your extensive work and research in that direction!
There will be no legacy Collada addon, DAE support was implemented as part of the core c++ Blender code, using the no longer maintained OpenCOLLADA library, thats why the Blender devs want to get rid of it in the first place.
DAE support was implemented as part of the core c++ Blender code,using the no longer maintained OpenCOLLADA library, thats why the Blender devs want to get rid of it in the first place. They want to get rid of it, not because it was in the core code, but because the library is no longer supported. That is a difference. It should be no too big thing to use the OpenCollada library for an addon addressed through py if wanted. The only question is: is it wanted by the Blender community? Apart from us BeamNG users, there seem to be few interested parties. A Blender dev [mont29/devtalk] wrote. "Having a Collada I/O add-on on our new extension platform would definitely be a possibility. However, ... it cannot be moved into its own independent add-on. So .. (it) .. would certainly require some work." That sounds really not like a statement like yours: "There will be no legacy Collada addon." However, I am very happy that you try to build a safe alternative bridge for us for the future regardless of other external decisions!
Yea thars what I meant OpenCOLLADA also has itself dependencies that are long outdated or even security vulnerabilities. Ok I correct to: There will be most likely no legacy Collada addon. It interesting that they are considering it, but i doubt much will come out of it, especially as you said there isn't much demand for it, most applications moved on to gltf. Keeping Collada around as a “official” addon is just additional work I don't think they wana put up with. gladly ^^, i also just pushed v5b4.5, Collada is now fully suported. Not sure if you want to bother with this, but I'm still needing feedback if everting works and if the workflow is good as it is or if it needs tweaking.
