My libraries about COLLADA/glTF

[recp]

I've published my libraries to Github:

AssetKit: 3D asset loader based on COLLADA 1.5/gltF specs
https://github.com/recp/assetkit

AssetKit-GL: Load contents loaded from AssetKit to OpenGL
https://github.com/recp/assetkit-gl

libgk: Node based renderer lib:
https://github.com/recp/libgk

cglm: 3D vector math lib for C89/C99
https://github.com/recp/cglm

But viewer application is still private

Build only works for Autotools:

Build deps:
sh ./build-deps.sh

Build assetkit:
sh ./autogen.sh
./configure
make

Change install names:
[optional] sh ./post-configure.sh

Actually it was working on Windows until add some sub libraries,
I'll share build for windows when finished

[Mick P.]

I don't know about this "asset" word. I wish people would avoid it. It bothers me truly

I bookmarked this post. So I can find your stuff. Although I don't understand why or how C survives outside of some very specific applications!

I kind of have an interest in 3-D math libraries. I've seen so many in my career, and they all kind of bother me. I tried to make my own some years ago for a quirky project, and the results were interesting:

http://svn.swordofmoonlight.net/code...er/Somvector.h

I've been trying to think how to rebrand it to work with COLLADA-DOM projects if necessary. Or the Daedalus project I am working on for that matter. What I like about it are 2 things: 1) math classes always use their own classes in a closed system. But this 1 file library maps to native C arrays. So "float v[4]" you can use it with that, or any type for that matter, and any size. It can also map to sub arrays inside of 2-D matrix arrays. So it can map to a 3x2 array anywhere inside "float m[4][4]" and it can map to pointers also if you tell it the sizes, although that's a little less type safe. The other thing, 2) that I don't like about vector/matrix libraries is they often use operator overloading, that makes it so "v1+v2" looks like it's adding two numbers at a glance. You cannot tell by looking the real nature of cost of the code. And you cannot tell scalar operations apart from vector ones, unless you know their types. That's why for vector/matrix math I prefer proper methods over operators, something that gives the idea that there is for-loop like procedures underway.

(The classes themselves are actually empty. They map to the address, and assume the vector/matrix starts at their address. And with "empty-base-optimization" you can instantiate a class that also has traditional x,y,z members.)

P.S. You know that 1.5 is rarely used for 3-D art applications. I mean it will eventually take hold if COLLADA survives, but right now COLLADA seems stuck in the past, and technically they are separate strains, but you just don't see many applications or files using 1.5.0. I'm told it's popular with roboticists. I guess for the IK feature set, but I don't know. I imagine if using a string reading framework then the differences would not be hard to code around. But strings are the bottom of the barrel from a maintainability point of view. Supporting both versions (and future versions) is quite a headache for COLLADA-DOM, precisely because it's a such better system than strings. But at the same time you cannot implement the same code twice for every version. You have to tackle the problems with C++'s templates, or in the generator. Ultimately I want to generate configuration files for "synthetic schemas" that will blend 1.4.1 and 1.5.0 and future versions, unless there is a big rift, into a single virtual schema.

[recp]

I don't know about this "asset" word. I wish people would avoid it. It bothers me truly

I'm not good at find good/cool names The first name was assetio then it changed to assetkit because it is not just io ops. Maybe I can find better name in the future.

You are right, 1.5 i rarely used also I've recently read 1.5 Release Notes, they said:

COLLADA 1.4.1 versus 1.5.0
Several changes in this schema release are not compatible with existing COLLADA 1.4.1 documents. However, migrating from 1.4.1 to 1.5.0 is not required and 1.4.1 remains current and valid. If you don’t need the features of 1.5.0, then continue to use the 1.4.1 schema. Please read these Release Notes carefully to decide whether you need the 1.5.0 features.

It suggests to continue with 1.4.1 not 1.5, it is weird! Maybe it is true for old documents not new docs, I don't know, somehow I need to map 1.4 to 1.5 or find common structure especially for images

It doesn't matter what C structues are, library will full support import/export 1.4 1.4.1 and 1.5+ collada verisons

[Mick P.]

There is a list of changes. Probably in the same section. But there are subtle differences. I think new software must support 1.5.0. There's just a lot of old software that was not maintained after 1.4.1. I.5.0 is definitely a better schema overall.

I would like to not support 1.4.1 but it has the most traction/real world legacy support. I looked over your library. You have good coding practices, I can tell you have experience, but it's still a heavy lift for me. I like to focus a lot of thought on the front end to design software that will save me time in the long run; ideally I try to come up with tentative "final solutions" that are, with the best information I have at the time, what I feel is as good as the software can possibly be, from now until the end of time...

When I was young I was very frustrated by C++. C just makes my skin crawl. I was practically ready to start over all of software from scratch. But C++ took a strange left turn when they started designing the STL and it totally changed the whole focus of the language and thought on design, and I like very much that it took a strong step back from object-oriented design, and now I am very pleased with C++. It has its flaws, and a few legacy things that you wish they'd just bite the bullet and change to make the language better for the next hundred or thousand years instead of fretting over legacy inertia; but all and all C++ is probably the closest thing to a true love in my life, and templates really solved all of the reservations I had about it in my twenties. I just don't think C is "final solutions" material. It's too inefficient.