[GEM-dev] modelloader plugins

[Antoine Villeret]

hello,

the only reason why I do not use VertexBuffer directly into
modelloader.h is because VertexBuffer might use some OpenGL calls, at
least it uses OpenGL variables.
In a thought of leaving all OpenGL stuff outside model plugins, I
avoid using VertexBuffer directly.
But it might not be a good reason...

Also this work is still in progress since material, color and some
other properties need to be ported to VertexBuffer too (in my
opinion).

Cheers
A
--
do it yourself
http://antoine.villeret.free.fr


2014-10-21 18:25 GMT+02:00 IOhannes m zmölnig <zmoelnig at iem.at>:
> hi all,
>
> thanks to antoine, we now have working modelloaders again (the default
> OBJ-loader, one based on the old assimp2 API and a shiny new one based
> on assimp3).
>
> cool!
>
> however, i'd like to make some more (minor, cosmetic) changes to the
> modelloader API, but wanted to discuss them beforehand:
> (this is mainly directed at antoine, but others should chime in).
>
> the current API (src/plugins/modelloader.h) looks like (simplified):
>
>    float* getVector(std::string);
>    VBOarray getVBOarray();
>
> with VBOarray being a stripped down version of gem::VertexBuffer
> (Gem/VertexBuffer.h), just containing the float-array and type.
> it's a custom type defined in modelloader.h
>
> is there any specific reason not to directly use gem::VertexBuffer for
> returning the data from the modelloader?
> the VertexBuffer contains all the data that is needed (float-array,
> type) plus some more that should actually be returned (dimension,
> stride) plus some that is not needed by the modelloader-API (e.g. vbo-ID)
>
> this might simplify the API slightly to:
>   VertexBuffer getVector(int type);
>   vector<VertexBuffer> getVectors();
>
> mfg.hj.iuo
> IOhannes
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> http://lists.puredata.info/listinfo/gem-dev
>