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
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
On 10/21/2014 06:40 PM, Antoine Villeret wrote:
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...
no, it's a very good reason. as stated before, i strongly believe that any modelloader plugin MUST NOT know anything about openGL.
using VertexBuffer would have been save, as long as create/render/destroy are not used. but i agree, that this is fragile, and we should use a type for returning the data, that is guaranteed to not have anything openGL specific.
i'm thinking about a VertexData type, that is a stripped down version of VertexBuffer (without anything related to openGL). VertexBuffer would then simply have a member of this type (and some other types that handle the openGL stuff; these should probably be hidden in a PIMPL anyhow)
Also this work is still in progress since material, color and some other properties need to be ported to VertexBuffer too (in my opinion).
yes of course. i thought color was already there, but we need to add support for materials.
fgmrdsa IOhannes
-
Antoine Villeret -
IOhannes m zmölnig