Provide utility for data conversion? about cgltf HOT 9 CLOSED

My understanding is that right now this function should be on the order of 20 lines of code if we don't need to handle sparse data?

Re: "range of indices", I really do believe we should keep this API as simple as possible, hence my later suggestion about one-at-a-time. Function call overhead wouldn't matter in a typical single-file-use scenario where cgltf.h implementation is included into a single source file using it, and I'm not sure how substantial the reduction is if you just consider reading in short bursts (it's typical to read 2 floats per texcoord for example).

I'd suggest limiting the implementation to a single returned value in the interest of interface simplicity and checking the overhead with inlining disabled.

from cgltf.

I coded this up, I can make a PR after I add tests and support for sparse accessors.

from cgltf.

The idea is interesting. I'm wondering if it's better to do something like

void cgltf_accessor_read(const cgltf_accessor* accessor, size_t index, cgltf_float* out, size_t out_size);

so that the caller doesn't need to allocate a large buffer? Or maybe something like

cgltf_float cgltf_accessor_read_float(const cgltf_accessor* accessor, size_t index, size_t component);
cgltf_int cgltf_accessor_read_int(const cgltf_accessor* accessor, size_t index, size_t component);

This can then be used to parse index buffers, vertex buffers, bone indices etc. - it can return 0 on errors (all validation could happen in cgltf_validate). I definitely end up writing something along these lines whenever I need to parse GLTF files.

from cgltf.

@prideout Something like this would be very welcome.

@zeux's first suggestion (void cgltf_accessor_read(const cgltf_accessor*, size_t, cgltf_float*, size_t)) looks the most practical to me. It probably wouldn't be such a big difference from your implementation, @prideout?
The functions for reading one value at a time would presumably have quite a big function call overhead if you're handling lots of data.

from cgltf.

These are good ideas! Taking it a bit further, the API should perhaps take a range of indices, so that clients can either use them either way: one-at-a-time or a batch.

I also like the idea of providing a to-integer variant, which I had to write internally anyway in order to support sparse accessors.

from cgltf.

In my case the engine is already handling all of this, would it be possible to have this in a separate header, since it's not an essential functionality and thus would be a dead weight to some users?

It's not a problem with the existing cgltf_node_transform_world() etc. APIs, but here I can imagine it could grow pretty large. Especially considering future glTF versions are expected to have more complex data packing options, use of half-floats etc.

from cgltf.

Agreed with @zeux, this isn't much code and it gets optimized out if you don't use it. In fact supporting sparse accessors isn't a big deal. I'm not quite ready to make a PR because I haven't tested it well yet, but feel free to take a sneak peak at 61b4060.

from cgltf.

@zeux, I've come around to your point of view regarding index vs range. Simplicity rules! The only thing I'm unsure about is whether to return individual components (as I've done in my initial implementation) or to return the entire element (e.g. all 9 floats of a mat3) into an output pointer.

I'm leaning towards an output pointer; this is especially useful for the three padded matrix types and it would still be a very simple API (same number of args as before).

from cgltf.

I agree that it would be more convenient to output a complete element. Otherwise it would get kind of weird how you’d have to skip indices to skip the padding.

from cgltf.