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 <[email protected]>: > 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 > [email protected] > http://lists.puredata.info/listinfo/gem-dev > _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
