[Imstk-developers] Assimp integration

[Alexis Girault]

Hi Nick,

My first thought is that we should really not be creating new things here
and there unless absolutely necessary, and I'm surprised that file formats
available right now won't work for us. However if there are clear
bottlenecks that could be handled by your suggestion, we would surely need
to talk about it. Maybe you can tell us more about it next Thursday with
some details?

Thank you,




Alexis Girault
R&D Engineer in Medical Computing
Kitware, Inc.

http://www.kitware.com
(919) 969-6990 x325

On Tue, Jan 3, 2017 at 2:48 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> 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>
> 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> 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
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170104/639343b1/attachment-0001.html>