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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev