[Imstk-developers] Assimp integration

Milef, Nicholas Boris milefn at rpi.edu
Tue Jan 3 14:48:02 EST 2017


The plan would work like this: File (.3ds, .dae, .obj, etc.)->Assimp loader/converter->.imstk->VTK/Vulkan

I came up with a file format that should work:

uint: version_num
uint: num_meshes
for each mesh:
uint: num_vertices
uint: num_triangles
uint: num_attributes
uint: num_bones
uint: num_textures
uint: parent_mesh_id
uint x num_attributes: code_for_attribute_type (e.g., 1 for position, 2 for normal, etc.)
for each attribute:
data
for each triangle:
index array
for each bone:
uint: parent_id
vec3: offset_matrix_from_parent
mat4: inverse_matrix
for each textures:
uint: type
uint: path_length
char[]: locations
This gives us the advantage to do things such as limit/normalize the number of weights per vertex beforehand or any of the other Assimp postprocessing commands. Also, there's no concept of texture type in file formats, but we can define a specific naming convention. Technically, diffuse textures need to be handled differently in OpenGL than the other texture types (such as normal maps) for accuracy in lighting. The data can be loaded directly into the VBO/poly data without any sort of interpretation (plus it's cache friendly).

What do you all think about this?
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org] on behalf of Milef, Nicholas Boris [milefn at rpi.edu]
Sent: Monday, January 02, 2017 1:35 PM
To: Alexis Girault; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Assimp integration

I was doing some research, and apparently game engines usually don't load common formats because it takes too long. I think that we should create our own file format and have Assimp save to that format. The other benefit is that we can format it similarly to the VBO so populating the vertex data will be quick. Any thoughts on this?

Sorry, I forgot to reply to the other message. I think I used point data for the bone indices and the bone weights, but I had to bypass much of the VBO class, so technically it would only work with the right data. I'm not sure how this could be done without that file becoming very large. Is there any way we can get rid of all those function calls?
________________________________
From: Alexis Girault [alexis.girault at kitware.com]
Sent: Thursday, December 15, 2016 10:06 PM
To: Milef, Nicholas Boris; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Assimp integration


Maybe you could send a message again on the vtk developers thread to ask if a project gatekeeper could tell you how to add a third party dependency to VTK and if Assimp license works with them. If there is any issue they'll let us know and we may move on.

On Thu, Dec 15, 2016, 21:54 Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
Do you think you could do it efficiently in VTK? If yes I'd do so, and store the vertex weights in the PointData that we could then map it to our structures.

How did you implement vertex weight in VTK in your previous work?

Alexis

On Thu, Dec 15, 2016, 21:44 Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
How should we proceed with this? It seems that there's someone interested in the VTK version. I'll need it for the Vulkan renderer to test out various things. And we'll need models that support vertex weights for both renderers.
_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto:Imstk-developers at imstk.org>
http://public.kitware.com/mailman/listinfo/imstk-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170103/00163d53/attachment.html>


More information about the Imstk-developers mailing list