The fbx-importer does support it. The other importers does not have the support, sorry. Kim Am Mo., 11. Feb. 2019, 03:10 hat Risa Stenr risastenr@users.sourceforge.net geschrieben: Does assimp load blend shapes or shape keys from any format? I looked around a little bit and in the fbx code there is something to do with blend shapes, but couldn't find anything in the colada code. I would like to save a model with some blend shapes to a file from blender and use them in my application, not for animation...
As far as I understand you you have to do: Render the FBX at the position which you want, you can transform the model by setting the right transformation matrix in the root node of your FBX-model Get a jpeg from this ( for instance by render-to-texture and get the image from the VBO or back-buffer, based on your API ) Scale the image that it will fit into your main image Place it with 2D-transformation Then you shoud be done if I get you right. Kim
Normally the names used in the bones are the key to find he corresponding node in the node hierarchy.
VS2010 is not supported anymore. If you need support here we need to invest some more time. Kimmi
Hi, we made a change of the import for embeeded textures for FBX on the master. So you can try to update your library to that and try it again. Hopefully that helps to close the issue. If this issue is still there just open an issue report on our github-project-space: https://github.com/assimp/assimp Thanks! Kim
OK, thanks for the update.
Good question. Who is the maintainer for that package? Kim Geraldine Olivier golivier33@users.sf.net schrieb am Mi., 25. Okt. 2017, 11:54: Hi! I use assimp C++ lib as nuget package in a VisualStudio project. I would like to know when you will provide a double precision compiled version through NuGet. Thanks! double precision https://sourceforge.net/p/assimp/discussion/817654/thread/3a0e280f/?limit=25#1752 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/assimp/discussion/817654/...
See https://github.com/assimp/assimp/issues/1487 for tracking.
Not at the moment. But we shall be able to do so. I will add a feature-request for that.
Good point, See https://github.com/assimp/assimp/issues/1439
Assimp will generate vertices for rendering, that is the root cause for your different number of vertices. Textures for rendering have different attributes like diffuse color, position, normals or texture coordinates. The triangle for rendering will reference these vertices via the indices stored in the face of the mesh. For lightning for instance you can use a normal for face 1 and face 2. The normal is an attribute of the vertex. When face 1 and face 2 are referencing the same normal you will use...
Hm, could you provide the model in a bug report on our github-page? See https://github.com/assimp/assimp/issues Kim
I opened https://github.com/assimp/assimp/issues/1281 for this feature request. Thanks a lot for creating it. Kim
You need to use aiImportFileExWithProperties .
Depends on the material definition. Normally the root of the model is the root of the textures as well.
Not at the moment. I need to update the documentation for this! Thanks a lot for figuring this out. I opened https://github.com/assimp/assimp/issues/1238 to track this issue.
Hi, you can find the scaling as a transformation matrix in the corresponding node, which the mesh belogs to.
See http://www.assimp.org/lib_html/cmake_build.html https://learnopengl.com/#!Model-Loading/Assimp...
You need to select the Assimp-Viewer in the Solution explorer, press right mouse...
Thank you very much for figuring this out! The bug should be fixed on the latest...
Good idea, I need to think a little bit about it. I opened an issue on our github-page:...
Seems to be an error in your rendercode. Could you post the whole code, please? ...
Do you have a callstack? Kimmi
Please check https://github.com/assimp/assimp/issues/1197 for updates.
I guess we made some bugs in the latest development. I will try to look onto your...
Try this: aiTextureMapMode mapMode; GetTexture(aiTextureType_DIFFUSE , 0, &textureName,...
I guess this is a bug in the collada loader and not related to the cmake-environ...
Not at the moment, sorry.