From alexis.girault at kitware.com Sun Jan 1 13:35:11 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Sun, 01 Jan 2017 18:35:11 +0000 Subject: [Imstk-developers] A couple new MRs In-Reply-To: References: Message-ID: I'll look at it when I'm back, probably tomorrow. Thanks, Alexis On Sat, Dec 31, 2016, 21:35 Sreekanth Arikatla < sreekanth.arikatla at kitware.com> wrote: > Hi All, > One more: > https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/119 > > This MR adds laparoscopic tool controller required for the liver-tool > interaction example that I'm trying to get up and running soon. It would be > great if one of you guys can review. Thanks, > > On Thu, Dec 29, 2016 at 7:02 PM, Alexis Girault < > alexis.girault at kitware.com> wrote: > > Great, thanks! Will review on my way back. > > Alexis > > On Thu, Dec 29, 2016, 17:55 Sreekanth Arikatla < > sreekanth.arikatla at kitware.com> wrote: > > Hi All, > I have added another MR to the list. Here is the link: *https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118 > * > > In summary, this MR contains changes that fix all the major outstanding > issues with the physics module in iMSTK. Please see the description in the > link for more details. > > It would be great if you guys can review. I'll take a look at some of the > MRs that are waiting for review. > > Thanks. > > On Tue, Dec 20, 2016 at 7:02 AM, Alexis Girault < > alexis.girault at kitware.com> wrote: > > Hi devs, > > I have been spending a couple (too many) hours in planes and airports > (still in Dublin currently waiting for my flight to France), so I have had > the opportunity to work on a couple things in iMSTK: > > 1) Correct warnings: > https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/116 > 2) Skip compute bounds in VTK to speed up rendering: > https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/115 > 3) Adapt and rebase Hina work to the camera navigation branch to enable > the use of lambdas for custom event handling in the vtk interactor style, > (design concept that we discussed a little while back) : > https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117 > > If you are not yet on holidays you're welcome to review those. If I get > more travel time in my hands I'll look into render details / materials. > > @Hina: not sure if you're in the iMSTK developers mailing list. If not, > you can join it here : http://www.imstk.org/mailing-lists/ > > Best, > > Alexis > > _______________________________________________ > Imstk-developers mailing list > Imstk-developers at imstk.org > http://public.kitware.com/mailman/listinfo/imstk-developers > > > > > -- > Sreekanth Arikatla, Ph.D, > Senior R&D Engineer, > Kitware, Inc. , Carrboro, NC. > > > > > -- > Sreekanth Arikatla, Ph.D, > Senior R&D Engineer, > Kitware, Inc. , Carrboro, NC. > > _______________________________________________ > 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: From milefn at rpi.edu Mon Jan 2 13:35:51 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Mon, 2 Jan 2017 18:35:51 +0000 Subject: [Imstk-developers] Assimp integration In-Reply-To: References: , Message-ID: 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 > 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 > 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: From milefn at rpi.edu Tue Jan 3 11:43:47 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Tue, 3 Jan 2017 16:43:47 +0000 Subject: [Imstk-developers] Default renderer Message-ID: I'm almost done with the abstraction layer, but how should the default renderer be handled? Should the user explicity define the renderer they want or should VTK be the default? I'm just curious because there might be a case if the user doesn't want to download VTK since it takes some time to download/compile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andinet.enqu at kitware.com Tue Jan 3 11:56:55 2017 From: andinet.enqu at kitware.com (Andinet Enquobahrie) Date: Tue, 3 Jan 2017 11:56:55 -0500 Subject: [Imstk-developers] Default renderer In-Reply-To: References: Message-ID: VTK should be the default renderer. On Tue, Jan 3, 2017 at 11:43 AM, Milef, Nicholas Boris wrote: > I'm almost done with the abstraction layer, but how should the default > renderer be handled? Should the user explicity define the renderer they want > or should VTK be the default? I'm just curious because there might be a case > if the user doesn't want to download VTK since it takes some time to > download/compile. > > _______________________________________________ > Imstk-developers mailing list > Imstk-developers at imstk.org > http://public.kitware.com/mailman/listinfo/imstk-developers > -- Andinet Enquobahrie, Ph.D., MBA Assistant Director of Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x311 From alexis.girault at kitware.com Tue Jan 3 12:38:26 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Tue, 3 Jan 2017 12:38:26 -0500 Subject: [Imstk-developers] Default renderer In-Reply-To: References: Message-ID: Hi Nick, Indeed we'll have VTK as default, however the switch between VTK and Vulkan can be made at configuration time in CMake with a variable like 'USE_Vulkan` defaulted to OFF. Based on this cmake variable we can then download/compile VTK or Vulkan+dependencies and define pre-compilation variables to use VTK or Vulkan c++ code. I described the process a couple weeks ago on your merge request here: https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/111/diffs#9a2aa4db38d3115ed60da621e012c0efc0172aae_139_152 Best, Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Tue, Jan 3, 2017 at 11:56 AM, Andinet Enquobahrie < andinet.enqu at kitware.com> wrote: > VTK should be the default renderer. > > On Tue, Jan 3, 2017 at 11:43 AM, Milef, Nicholas Boris > wrote: > > I'm almost done with the abstraction layer, but how should the default > > renderer be handled? Should the user explicity define the renderer they > want > > or should VTK be the default? I'm just curious because there might be a > case > > if the user doesn't want to download VTK since it takes some time to > > download/compile. > > > > _______________________________________________ > > Imstk-developers mailing list > > Imstk-developers at imstk.org > > http://public.kitware.com/mailman/listinfo/imstk-developers > > > > > > -- > Andinet Enquobahrie, Ph.D., MBA > Assistant Director of Medical Computing > Kitware, Inc. > > http://www.kitware.com > (919) 969-6990 x311 > _______________________________________________ > 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: From milefn at rpi.edu Tue Jan 3 12:52:08 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Tue, 3 Jan 2017 17:52:08 +0000 Subject: [Imstk-developers] Default renderer In-Reply-To: References: , Message-ID: Hi Alexis, That makes sense. The problem was that I made a set of abstract classes that is currently decoupled from the VTK and the Vulkan renderers. The simulation manager used to have an imstkVTKRenderer class, and I removed that and replaced it with the abstract imstkRenderer class. I could use the CMake variables to change which renderer gets added to the Simulation Manager class. ________________________________ From: Alexis Girault [alexis.girault at kitware.com] Sent: Tuesday, January 03, 2017 12:38 PM To: Andinet Enquobahrie Cc: Milef, Nicholas Boris; imstk-developers at imstk.org Subject: Re: [Imstk-developers] Default renderer Hi Nick, Indeed we'll have VTK as default, however the switch between VTK and Vulkan can be made at configuration time in CMake with a variable like 'USE_Vulkan` defaulted to OFF. Based on this cmake variable we can then download/compile VTK or Vulkan+dependencies and define pre-compilation variables to use VTK or Vulkan c++ code. I described the process a couple weeks ago on your merge request here: https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/111/diffs#9a2aa4db38d3115ed60da621e012c0efc0172aae_139_152 Best, Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Tue, Jan 3, 2017 at 11:56 AM, Andinet Enquobahrie > wrote: VTK should be the default renderer. On Tue, Jan 3, 2017 at 11:43 AM, Milef, Nicholas Boris > wrote: > I'm almost done with the abstraction layer, but how should the default > renderer be handled? Should the user explicity define the renderer they want > or should VTK be the default? I'm just curious because there might be a case > if the user doesn't want to download VTK since it takes some time to > download/compile. > > _______________________________________________ > Imstk-developers mailing list > Imstk-developers at imstk.org > http://public.kitware.com/mailman/listinfo/imstk-developers > -- Andinet Enquobahrie, Ph.D., MBA Assistant Director of Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x311 _______________________________________________ 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: From alexis.girault at kitware.com Tue Jan 3 12:56:46 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Tue, 3 Jan 2017 12:56:46 -0500 Subject: [Imstk-developers] Default renderer In-Reply-To: References: Message-ID: That's perfect: we need the decoupled class for ease of use and testing, and you can instantiate a VTKRenderer or a VulkanRenderer based on preprocessor definitions, themselves defined based on the cmake variables. Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Tue, Jan 3, 2017 at 12:52 PM, Milef, Nicholas Boris wrote: > Hi Alexis, > > That makes sense. The problem was that I made a set of abstract classes > that is currently decoupled from the VTK and the Vulkan renderers. The > simulation manager used to have an imstkVTKRenderer class, and I removed > that and replaced it with the abstract imstkRenderer class. I could use the > CMake variables to change which renderer gets added to the Simulation > Manager class. > ------------------------------ > *From:* Alexis Girault [alexis.girault at kitware.com] > *Sent:* Tuesday, January 03, 2017 12:38 PM > *To:* Andinet Enquobahrie > *Cc:* Milef, Nicholas Boris; imstk-developers at imstk.org > *Subject:* Re: [Imstk-developers] Default renderer > > Hi Nick, > > Indeed we'll have VTK as default, however the switch between VTK and > Vulkan can be made at configuration time in CMake with a variable like > 'USE_Vulkan` defaulted to OFF. Based on this cmake variable we can then > download/compile VTK or Vulkan+dependencies and define pre-compilation > variables to use VTK or Vulkan c++ code. > > I described the process a couple weeks ago on your merge request here: > https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/111/diffs# > 9a2aa4db38d3115ed60da621e012c0efc0172aae_139_152 > > Best, > > Alexis Girault > R&D Engineer in Medical Computing > Kitware, Inc. > > http://www.kitware.com > (919) 969-6990 x325 > > On Tue, Jan 3, 2017 at 11:56 AM, Andinet Enquobahrie < > andinet.enqu at kitware.com> wrote: > >> VTK should be the default renderer. >> >> On Tue, Jan 3, 2017 at 11:43 AM, Milef, Nicholas Boris >> wrote: >> > I'm almost done with the abstraction layer, but how should the default >> > renderer be handled? Should the user explicity define the renderer they >> want >> > or should VTK be the default? I'm just curious because there might be a >> case >> > if the user doesn't want to download VTK since it takes some time to >> > download/compile. >> > >> > _______________________________________________ >> > Imstk-developers mailing list >> > Imstk-developers at imstk.org >> > http://public.kitware.com/mailman/listinfo/imstk-developers >> > >> >> >> >> -- >> Andinet Enquobahrie, Ph.D., MBA >> Assistant Director of Medical Computing >> Kitware, Inc. >> >> http://www.kitware.com >> (919) 969-6990 x311 >> _______________________________________________ >> 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: From milefn at rpi.edu Tue Jan 3 14:48:02 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Tue, 3 Jan 2017 19:48:02 +0000 Subject: [Imstk-developers] Assimp integration In-Reply-To: References: , , Message-ID: 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 > 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 > 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: From alexis.girault at kitware.com Wed Jan 4 09:35:19 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Wed, 4 Jan 2017 09:35:19 -0500 Subject: [Imstk-developers] Assimp integration In-Reply-To: References: Message-ID: 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 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 > 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 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: From alexis.girault at kitware.com Fri Jan 6 23:33:05 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Fri, 6 Jan 2017 23:33:05 -0500 Subject: [Imstk-developers] Custom events merged & VTK improvements ready Message-ID: After reviews and CDash, the custom event handling MR for interactions through the VTK interactor style is successfully merged in master! - https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117 Also, the VTK merge request for the new normals filter has been merged in vtk upstream, so I finalized its integration within iMSTK in a new MR which includes the following features: - Use of faster point normals filter + initial use of cell consistency filter - Option to display the framerate in the window (press `P`) while simulation is running - Option to switch the rendering to debug mode (allowing mouse interaction) while the simulation is running (press 'D') Hope this can be useful for some of you. Feel free to check-out the MR and review it if you get a chance to: https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/121/commits Best, Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Mon Jan 9 10:34:48 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Mon, 9 Jan 2017 15:34:48 +0000 Subject: [Imstk-developers] Light Types Message-ID: I was looking through the light class and I saw we have two light types: SCENE_LIGHT and HEAD_LIGHT. Is it possible for us to rename the SCENE_LIGHT to SPOT_LIGHT or POINT_LIGHT depending on how it's used? I understand VTK names them this way, but this isn't common practice. Usually in CG, there are three common light types: point lights, spot lights, and directional lights. A head light would just be a spotlight centered at the camera. Also, for implementing PBR, I will need to implement environmental light types, and that could get confused with scene lights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Thu Jan 19 15:33:20 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Thu, 19 Jan 2017 15:33:20 -0500 Subject: [Imstk-developers] weekly-meeting follow up Message-ID: Sorry we had to leave the room, I guess we took a long time talking about all those points. 1) If you have a question related to our latest discussion with Mohit please let us know so we can discuss it. I'll update the google doc/trello to keep track of his work and future improvements. 2) On my side, I'll finish the rendering MR next week with the triangulate filter in the reader, and work on integrating Sreekanth's MR for the controller and the Collision Detection. 3) Hina will get started on the peg transfer task next week and will look into integrating ODE for rigid body physics. I will help her on the architecture side of things related to the whole toolkit and cmake, and Sreekanth will sync with her on how to adapt the Physics module API to be able to use ODE solvers. If you have any topics, remarks, or questions you weren't able to bring up, please do so in this email thread. Thank you, Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Thu Jan 19 19:28:39 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Fri, 20 Jan 2017 00:28:39 +0000 Subject: [Imstk-developers] weekly-meeting follow up In-Reply-To: References: Message-ID: I made a document yesterday under the Rendering folder than outlines what I had in mind for the Material (render details) class. Please add more stuff if you think it's needed. ________________________________ From: Imstk-developers [imstk-developers-bounces at imstk.org] on behalf of Alexis Girault [alexis.girault at kitware.com] Sent: Thursday, January 19, 2017 3:33 PM To: imstk-developers at imstk.org Subject: [Imstk-developers] weekly-meeting follow up Sorry we had to leave the room, I guess we took a long time talking about all those points. 1) If you have a question related to our latest discussion with Mohit please let us know so we can discuss it. I'll update the google doc/trello to keep track of his work and future improvements. 2) On my side, I'll finish the rendering MR next week with the triangulate filter in the reader, and work on integrating Sreekanth's MR for the controller and the Collision Detection. 3) Hina will get started on the peg transfer task next week and will look into integrating ODE for rigid body physics. I will help her on the architecture side of things related to the whole toolkit and cmake, and Sreekanth will sync with her on how to adapt the Physics module API to be able to use ODE solvers. If you have any topics, remarks, or questions you weren't able to bring up, please do so in this email thread. Thank you, Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Mon Jan 23 15:41:36 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Mon, 23 Jan 2017 20:41:36 +0000 Subject: [Imstk-developers] Are geometric primitives deformable? Message-ID: Are primitives deformable? Right now, it doesn't appear that they are based on their respective Geometry classes (Sphere, Cube, etc.), but maybe I'm missing something. I'll help me with the implementation of those classes to know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Mon Jan 23 16:17:29 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Mon, 23 Jan 2017 16:17:29 -0500 Subject: [Imstk-developers] Are geometric primitives deformable? In-Reply-To: References: Message-ID: By deformable, which one do you mean: 1. changing the primitive geometry properties should change its render delegate 2. the primitives can experience physical deformations (soft bodies) I believe currently none of them are, but (1) shouldn't be much to implement, while I do not think (2) should be possible (use a mesh if you have soft bodies). We could have however utilities to convert primitives to meshes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Mon Jan 23 17:15:38 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Mon, 23 Jan 2017 22:15:38 +0000 Subject: [Imstk-developers] Are geometric primitives deformable? In-Reply-To: References: , , Message-ID: By deformable, I mean that the vertices can change by some non uniform factor (so like for soft bodies). What would be considered a primitive geometry change? Obviously, for a cube there's only so much you can do (scale, rotation, translation), but for a sphere could you change the resolution at runtime? Because that would change the geometric makeup. ________________________________ From: Alexis Girault [alexis.girault at kitware.com] Sent: Monday, January 23, 2017 4:17 PM To: Milef, Nicholas Boris Cc: imstk-developers at imstk.org Subject: Re: [Imstk-developers] Are geometric primitives deformable? By deformable, which one do you mean: 1. changing the primitive geometry properties should change its render delegate 2. the primitives can experience physical deformations (soft bodies) I believe currently none of them are, but (1) shouldn't be much to implement, while I do not think (2) should be possible (use a mesh if you have soft bodies). We could have however utilities to convert primitives to meshes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Tue Jan 24 16:38:06 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Tue, 24 Jan 2017 16:38:06 -0500 Subject: [Imstk-developers] Light Types In-Reply-To: References: Message-ID: Feel free to change up all this. We'll just have to add warnings when one of the modes you want to implement isn't part of VTK when using VTK rendering. You might also want to remove the vtkLight from the imstkLight and have a conversion instead of simply wrapping vtk. >From what you told me we could have directional (not in VTK?), point light (not in vtk?), spot light, head light (easy interface to spotlight on camera). -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Tue Jan 24 17:10:41 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Tue, 24 Jan 2017 22:10:41 +0000 Subject: [Imstk-developers] Light Types In-Reply-To: References: , Message-ID: Ok, I'll do that! All of those light types are in VTK, but the naming convention is what throws me off. The reason why I mentioned this is because there are other light sources besides those three that act very differently, yet still could logically be called scene lights. Basically, I would just like to use the common names for them. VTK has HeadLights (spotlight), SceneLights (spot/point lights), CameraLights (spot/point), and DirectionalLights (directional). I would do this: - Light + Directional + Point - Spot (could be implemented differently than point) + Head ________________________________ From: Alexis Girault [alexis.girault at kitware.com] Sent: Tuesday, January 24, 2017 4:38 PM To: Milef, Nicholas Boris Cc: imstk-developers at imstk.org Subject: Re: [Imstk-developers] Light Types Feel free to change up all this. We'll just have to add warnings when one of the modes you want to implement isn't part of VTK when using VTK rendering. You might also want to remove the vtkLight from the imstkLight and have a conversion instead of simply wrapping vtk. >From what you told me we could have directional (not in VTK?), point light (not in vtk?), spot light, head light (easy interface to spotlight on camera). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Wed Jan 25 07:32:51 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Wed, 25 Jan 2017 12:32:51 +0000 Subject: [Imstk-developers] Light Types In-Reply-To: References: Message-ID: If you need this for Vulkan, please have this as a separate branch to have a MR independent from Vulkan that we could merge before, so that your Vulkan MR can be based on it later on. On Tue, Jan 24, 2017, 17:10 Milef, Nicholas Boris wrote: > Ok, I'll do that! All of those light types are in VTK, but the naming > convention is what throws me off. The reason why I mentioned this is > because there are other light sources besides those three that act very > differently, yet still could logically be called scene lights. Basically, I > would just like to use the common names for them. > > VTK has HeadLights (spotlight), SceneLights (spot/point lights), > CameraLights (spot/point), and DirectionalLights (directional). I would do > this: > > - Light > + Directional > + Point > - Spot (could be implemented differently than point) > + Head > ------------------------------ > *From:* Alexis Girault [alexis.girault at kitware.com] > *Sent:* Tuesday, January 24, 2017 4:38 PM > *To:* Milef, Nicholas Boris > *Cc:* imstk-developers at imstk.org > *Subject:* Re: [Imstk-developers] Light Types > > Feel free to change up all this. We'll just have to add warnings when one > of the modes you want to implement isn't part of VTK when using VTK > rendering. You might also want to remove the vtkLight from the imstkLight > and have a conversion instead of simply wrapping vtk. > > From what you told me we could have directional (not in VTK?), point light > (not in vtk?), spot light, head light (easy interface to spotlight on > camera). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qid at rpi.edu Thu Jan 26 13:31:55 2017 From: qid at rpi.edu (Qi, Trudi) Date: Thu, 26 Jan 2017 18:31:55 +0000 Subject: [Imstk-developers] Desired features from iMSTK Message-ID: Hi all, We have listed all features we think are useful for our application development based on Imstk. Please find the list from here. We could discuss more in the meeting. Thanks, Trudi ... Di Trudi QI, Ph.D. Postdoctoral Research Associate Center for Modeling, Simulation and Imaging in Medicine (CeMSIM) Rensselaer Polytechnic Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: