From alexis.girault at kitware.com  Mon Oct  3 11:39:41 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 3 Oct 2016 11:39:41 -0400
Subject: [Imstk-developers] iMSTK front documentation
Message-ID: <CAG1Y6mBNEbArx5o-bxqHqHZFREE97s8g9-Ou=yQni9DTnCcs0w@mail.gmail.com>

Hi everyone,

First email on the developers list... hurray!

I have been working on starting the initial documentation for the git
project README. My draft is here @
https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/95

Feel free to pitch in so we can improve it and add it to the git project.

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: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161003/0c441ed0/attachment.html>

From milefn at rpi.edu  Mon Oct  3 12:02:04 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 3 Oct 2016 16:02:04 +0000
Subject: [Imstk-developers] How are Doxygen files generated?
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D2AC7@ex14mb4.win.rpi.edu>

Are Doxygen files generated by building iMSTK? Or is there a program you need to run manually? I've used Doxygen in Linux by command-line where you had to do it manually I think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161003/a89182fd/attachment.html>

From milefn at rpi.edu  Mon Oct  3 17:00:11 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 3 Oct 2016 21:00:11 +0000
Subject: [Imstk-developers] Minimum System Requirements
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D2B16@ex14mb4.win.rpi.edu>

What are the minimum requirements for iMSTK?

GPU VR: generally the GTX 970 is the default minimum requirement. This is recommended for HTC Vive:
https://www.vive.com/us/ready/. There are many reasons for this (including needing 90 FPS), but it's not going to go much lower than that.

GPU non-VR: that's much tougher. Is there some sort of baseline that's been determined?

CPU: it's tough because this application is more multi-threaded than many games, so it would seem that some sort of 4 virtual core CPU might be a good minimum, or something along those lines. Since iMSTK is very modular, it may be the case that the CPU minimum can be even lower.

Memory: we can test this. I don't think this will be a huge issue since today everything is loaded with extra RAM, but we can see the average for the simplest simulation and multiply it by some constant.

OS: I guess that's already listed on the ReadMe.

Really, the best way to test this is to use the minimum hardware and try running on that:
http://gamedev.stackexchange.com/questions/437/how-do-i-determine-my-games-minimum-hardware-software-requirements
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161003/23abd044/attachment.html>

From alexis.girault at kitware.com  Mon Oct  3 17:08:52 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 3 Oct 2016 17:08:52 -0400
Subject: [Imstk-developers] How are Doxygen files generated?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D2AC7@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D2AC7@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mCYahd3F9y1f2RaWHBukK=b8O7ZpdHHQvUzp6+1JmB39A@mail.gmail.com>

They are not yet, but I plan to do this as a target being part of the
superbuild, like VTK:
http://www.vtk.org/Wiki/VTK/BuildingDoxygen

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

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

On Mon, Oct 3, 2016 at 12:02 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Are Doxygen files generated by building iMSTK? Or is there a program you
> need to run manually? I've used Doxygen in Linux by command-line where you
> had to do it manually I think.
>
> _______________________________________________
> 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/20161003/3efaf6f0/attachment.html>

From alexis.girault at kitware.com  Mon Oct  3 17:12:53 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 3 Oct 2016 17:12:53 -0400
Subject: [Imstk-developers] Minimum System Requirements
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D2B16@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D2B16@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mDDpMxRYaCcRsC8as0i+xxsLpyKvQb5gm-CQw7g9_g52Q@mail.gmail.com>

It's going to be hard to judge this before we do the minimum performance
improvements and optimizations. I think we should wait until we start using
iMSTK for our applications at which point we can look more into what it can
handle. I don't think we need to define the requirements that early.

Thoughts?

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

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

On Mon, Oct 3, 2016 at 5:00 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What are the minimum requirements for iMSTK?
>
> GPU VR: generally the GTX 970 is the default minimum requirement. This is
> recommended for HTC Vive:
> https://www.vive.com/us/ready/. There are many reasons for this
> (including needing 90 FPS), but it's not going to go much lower than that.
>
> GPU non-VR: that's much tougher. Is there some sort of baseline that's
> been determined?
>
> CPU: it's tough because this application is more multi-threaded than many
> games, so it would seem that some sort of 4 virtual core CPU might be a
> good minimum, or something along those lines. Since iMSTK is very modular,
> it may be the case that the CPU minimum can be even lower.
>
> Memory: we can test this. I don't think this will be a huge issue since
> today everything is loaded with extra RAM, but we can see the average for
> the simplest simulation and multiply it by some constant.
>
> OS: I guess that's already listed on the ReadMe.
>
> Really, the best way to test this is to use the minimum hardware and try
> running on that:
> http://gamedev.stackexchange.com/questions/437/how-do-i-
> determine-my-games-minimum-hardware-software-requirements
>
> _______________________________________________
> 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/20161003/a57e8bfe/attachment.html>

From sreekanth.arikatla at kitware.com  Mon Oct  3 20:25:37 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 3 Oct 2016 20:25:37 -0400
Subject: [Imstk-developers] Minimum System Requirements
In-Reply-To: <CAG1Y6mDDpMxRYaCcRsC8as0i+xxsLpyKvQb5gm-CQw7g9_g52Q@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D2B16@ex14mb4.win.rpi.edu>
 <CAG1Y6mDDpMxRYaCcRsC8as0i+xxsLpyKvQb5gm-CQw7g9_g52Q@mail.gmail.com>
Message-ID: <CAJFrbFK5SXzPcpFUjM=St9Ozno5iB9e4Xiyxwb2UReb0-uW_xQ@mail.gmail.com>

Sure, we can only test if we know for sure we are doing the best in terms
of algorithmic performance. Even then I think the only thing we can say is
the minimum configuration need to run all the examples that come with the
code.

Beyond that the users are expected to know the requirements based on
computational load for the application they intend to build using iMSTK.



On Mon, Oct 3, 2016 at 5:12 PM, Alexis Girault <alexis.girault at kitware.com>
wrote:

> It's going to be hard to judge this before we do the minimum performance
> improvements and optimizations. I think we should wait until we start using
> iMSTK for our applications at which point we can look more into what it can
> handle. I don't think we need to define the requirements that early.
>
> Thoughts?
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x325
>
> On Mon, Oct 3, 2016 at 5:00 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> What are the minimum requirements for iMSTK?
>>
>> GPU VR: generally the GTX 970 is the default minimum requirement. This is
>> recommended for HTC Vive:
>> https://www.vive.com/us/ready/. There are many reasons for this
>> (including needing 90 FPS), but it's not going to go much lower than that.
>>
>> GPU non-VR: that's much tougher. Is there some sort of baseline that's
>> been determined?
>>
>> CPU: it's tough because this application is more multi-threaded than many
>> games, so it would seem that some sort of 4 virtual core CPU might be a
>> good minimum, or something along those lines. Since iMSTK is very modular,
>> it may be the case that the CPU minimum can be even lower.
>>
>> Memory: we can test this. I don't think this will be a huge issue since
>> today everything is loaded with extra RAM, but we can see the average for
>> the simplest simulation and multiply it by some constant.
>>
>> OS: I guess that's already listed on the ReadMe.
>>
>> Really, the best way to test this is to use the minimum hardware and try
>> running on that:
>> http://gamedev.stackexchange.com/questions/437/how-do-i-dete
>> rmine-my-games-minimum-hardware-software-requirements
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
>
> _______________________________________________
> 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. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161003/3382fec4/attachment-0001.html>

From milefn at rpi.edu  Wed Oct  5 16:41:03 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 5 Oct 2016 20:41:03 +0000
Subject: [Imstk-developers] What's the difference between device servers and
	device clients?
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D2D3B@ex14mb4.win.rpi.edu>

Right now, there's no server class for HDAPI. What's the difference between device servers and device clients?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161005/0acc619a/attachment.html>

From alexis.girault at kitware.com  Wed Oct  5 16:56:07 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 5 Oct 2016 16:56:07 -0400
Subject: [Imstk-developers] What's the difference between device servers
 and device clients?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D2D3B@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D2D3B@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mDedV=NonhY7yBcGKEF-+8t7bO9cgzhmyt++by_o72GWA@mail.gmail.com>

The server/client API in iMSTK is based on the VRPN API, you can read more
about it here:
- https://github.com/vrpn/vrpn/wiki/Writing-Servers
- https://github.com/vrpn/vrpn/wiki/Client-side-VRPN-Devices



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

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

On Wed, Oct 5, 2016 at 4:41 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Right now, there's no server class for HDAPI. What's the difference
> between device servers and device clients?
>
> _______________________________________________
> 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/20161005/9f76cdca/attachment.html>

From alexis.girault at kitware.com  Wed Oct  5 17:02:14 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 5 Oct 2016 17:02:14 -0400
Subject: [Imstk-developers] What's the difference between device servers
 and device clients?
In-Reply-To: <CAG1Y6mDedV=NonhY7yBcGKEF-+8t7bO9cgzhmyt++by_o72GWA@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D2D3B@ex14mb4.win.rpi.edu>
 <CAG1Y6mDedV=NonhY7yBcGKEF-+8t7bO9cgzhmyt++by_o72GWA@mail.gmail.com>
Message-ID: <CAG1Y6mC-qaWqX0cbLW1JEvSmskfErQc6NsEf9zaOTTkWjydhSQ@mail.gmail.com>

*Sorry my email left before I was done.*

The server/client API in iMSTK is based on the VRPN API, you can read more
> about it here:
> - https://github.com/vrpn/vrpn/wiki/Writing-Servers
> - https://github.com/vrpn/vrpn/wiki/Client-side-VRPN-Devices


The interest of the separated client & server is that is is easy to set up
a server on a different machine than your application (client) is.

HDAPIDeviceClient is just a wrapper for the HD library which does not have
the same infrastructure and does not require you to manually run a server
independent from the client, as far as I understand.

On Wed, Oct 5, 2016 at 4:56 PM, Alexis Girault <alexis.girault at kitware.com>
wrote:

> The server/client API in iMSTK is based on the VRPN API, you can read more
> about it here:
> - https://github.com/vrpn/vrpn/wiki/Writing-Servers
> - https://github.com/vrpn/vrpn/wiki/Client-side-VRPN-Devices
>
>
> On Wed, Oct 5, 2016 at 4:41 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Right now, there's no server class for HDAPI. What's the difference
>> between device servers and device clients?
>>
>> _______________________________________________
>> 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/20161005/c6e61850/attachment.html>

From alexis.girault at kitware.com  Wed Oct 19 11:48:58 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 19 Oct 2016 11:48:58 -0400
Subject: [Imstk-developers] Fwd: [New post] Code Style and Automatic
	Formatting in Tomviz
In-Reply-To: <101150012.16178.0@wordpress.com>
References: <101150012.16178.0@wordpress.com>
Message-ID: <CAG1Y6mCge7Jqe2ioR8eb2s1W=p+5zW+Q3V7uUya11otymHVvNg@mail.gmail.com>

Could be interesting for our code style & automatic formatting. Here is
there doc on how to do this:
https://github.com/OpenChemistry/tomviz/blob/master/STYLE.md


---------- Forwarded message ----------
From: The Kitware Blog <donotreply at wordpress.com>
Date: Wed, Oct 19, 2016 at 11:40 AM
Subject: [New post] Code Style and Automatic Formatting in Tomviz
To: alexis.girault at kitware.com


Marcus D. Hanwell posted: "The importance of code style should not be
underestimated, and we have seen a number of changes in our projects over
the last few months. Until recently VTK and ParaView used a style for
braces that I have only ever encountered in projects coming from our"

New post on *The Kitware Blog*
<https://blog.kitware.com/?author=83> Code Style and Automatic Formatting
in Tomviz <https://blog.kitware.com/code-style-automatic-formatting-tomviz/> by
Marcus D. Hanwell <https://blog.kitware.com/?author=83>

The importance of code style should not be underestimated, and we have seen
a number of changes in our projects over the last few months. Until
recently VTK <http://vtk.org/> and ParaView <http://paraview.org/> used a
style for braces that I have only ever encountered in projects coming from
our company, with minimal to no support in most editors. Having a
consistent coding style is important, but it can also be a pain to describe
and takes time to go over in code reviews. I had been tracking clang-format
<http://clang.llvm.org/docs/ClangFormat.html> for quite some time now,
along with several of its predecessors, but this project seemed different
as it built upon the language parser in clang <http://clang.llvm.org/>.

---
# This configuration requires clang-format 3.8 or higher.
BasedOnStyle: Mozilla
AlwaysBreakAfterReturnType: None
AlwaysBreakAfterDefinitionReturnType: None
BreakConstructorInitializersBeforeComma: false
...

For Tomviz <http://tomviz.org/> I based our format file on what CMake
<http://cmake.org/> used in its recent conversion, with some minor
adjustments. I was then able to run it in August on all of our source
files, and Chris Harris added an automated hook on our GitHub repository
<https://github.com/OpenChemistry/tomviz> to validate that proposed changes
comply with the style file. All pull requests are now run through the
checks, with the necessary changes supplied if the test fails. This removes
the need to review pull requests for coding style, and ensures our code
base has a uniform style. Chris has since extended this to our Python code
using flake8 too.

Developers can easily apply the style to their changes, I usually run
'clang-format -i path/to/changed.*', there are other ways to use the tool
too. Now to weigh in on the great brace placement war - we have chosen our
side with CMake and keep them on the same line as the statement, preserving
maximum vertical space. The ParaView project just merged their clang-format
changes this morning, opting to place them on a new line, with VTK using a
custom script that also places them on a new line.

Upcoming posts in the series - tabs vs spaces, emacs vs vim, and finally
Android vs iPhone (I heard the desktop was dead already, but my typing
speed is terrible on a phone and I can't get my development environment up
and running on it). Throwing down the gauntlet, but in all seriousness
automating these things frees up development time while still fostering
style uniformity. The clang-format tool enables us to express our code
style in a very succinct fashion that can be applied very easily before
committing changes - it also understands and can work with diffs/git very
well.

Oh, and spoiler alert...spaces, vim, Android ;-)
*Marcus D. Hanwell <https://blog.kitware.com/?author=83>* | October 19,
2016 at 3:40 pm | Categories: All
<https://blog.kitware.com/?taxonomy=category&term=all> | URL:
http://wp.me/p6QpJO-4cW

Comment
<https://blog.kitware.com/code-style-automatic-formatting-tomviz/#respond>
   See all comments
<https://blog.kitware.com/code-style-automatic-formatting-tomviz/#comments>

Unsubscribe
<https://subscribe.wordpress.com/?key=9ce68109f6979a89466590c0dc80e5f5&email=alexis.girault%40kitware.com&b=LsqmXnKz%2F%26%25afu6SwS%26lLW_j%3FRvaejPbFB_%5BXcRj%3Fafio%3D-%2BR5>
to no longer receive posts from The Kitware Blog.
Change your email settings at Manage Subscriptions
<https://subscribe.wordpress.com/?key=9ce68109f6979a89466590c0dc80e5f5&email=alexis.girault%40kitware.com>.


*Trouble clicking?* Copy and paste this URL into your browser:
https://blog.kitware.com/code-style-automatic-formatting-tomviz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161019/b3b4567c/attachment.html>

From milefn at rpi.edu  Thu Oct 20 15:45:29 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Thu, 20 Oct 2016 19:45:29 +0000
Subject: [Imstk-developers] Copying Vega data
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>

Do Vega operations occur on the same thread as the render loop? If not, then it might be best to buffer and copy over the data instead of directly working on the mesh data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161020/fb8db8e1/attachment.html>

From sreekanth.arikatla at kitware.com  Thu Oct 20 15:53:39 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Thu, 20 Oct 2016 15:53:39 -0400
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>

Hi Nick,
           It happens in a separate thread in the sceneManager module.

On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Do Vega operations occur on the same thread as the render loop? If not,
> then it might be best to buffer and copy over the data instead of directly
> working on the mesh data.
>
> _______________________________________________
> 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. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161020/166db165/attachment.html>

From milefn at rpi.edu  Thu Oct 20 16:04:14 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Thu, 20 Oct 2016 20:04:14 +0000
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>,
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>

In that case, then copying data over shouldn't be a big deal. I thought the copying was occurring on the rendering thread. If we need thread synchronization here, then we can just use a buffered approach.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Thursday, October 20, 2016 3:53 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Copying Vega data

Hi Nick,
           It happens in a separate thread in the sceneManager module.

On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=BpJFDzylJUzmyH0IS2ouZR58VfSo4ijMtYN4jcu2cDKtIV1CJPnTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
Do Vega operations occur on the same thread as the render loop? If not, then it might be best to buffer and copy over the data instead of directly working on the mesh data.

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=bigx7UCbQk9SNSpSCYDnjFakE4iwbAgWDMHb4qE4SpetIV1CJPnTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=jFoBqdkH1xl6pePYXQ0FIrvhA89vs902I3d4sBjmOUatIV1CJPnTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<redir.aspx?REF=3qzFo3FNN4RdtBUk0qOs5JodPEA_-jpKD8tsMGEYn26tIV1CJPnTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>, Carrboro, NC.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161020/0ee77d9f/attachment.html>

From sreekanth.arikatla at kitware.com  Thu Oct 20 18:01:20 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Thu, 20 Oct 2016 18:01:20 -0400
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>

Hi Nick,
            Yes, that can be done (I was under the impression that even
that operation was slow with vtk but haven't looked into that part myself).
The copy could additionally be made conditional since rendering typically
runs faster than the physics.

The mesh needs to be updated though (at least in the case where visual and
physics are the same) since the physics update of future time steps count
on it.

On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> In that case, then copying data over shouldn't be a big deal. I thought
> the copying was occurring on the rendering thread. If we need thread
> synchronization here, then we can just use a buffered approach.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Thursday, October 20, 2016 3:53 PM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Copying Vega data
>
> Hi Nick,
>            It happens in a separate thread in the sceneManager module.
>
> On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu
> <http://redir.aspx?REF=BpJFDzylJUzmyH0IS2ouZR58VfSo4ijMtYN4jcu2cDKtIV1CJPnTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
> > wrote:
>
>> Do Vega operations occur on the same thread as the render loop? If not,
>> then it might be best to buffer and copy over the data instead of directly
>> working on the mesh data.
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> <http://redir.aspx?REF=bigx7UCbQk9SNSpSCYDnjFakE4iwbAgWDMHb4qE4SpetIV1CJPnTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>> <http://redir.aspx?REF=jFoBqdkH1xl6pePYXQ0FIrvhA89vs902I3d4sBjmOUatIV1CJPnTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>
>>
>>
>
>
> --
> Sreekanth Arikatla, Ph.D,
> Senior R&D Engineer,
> Kitware, Inc.
> <http://redir.aspx?REF=3qzFo3FNN4RdtBUk0qOs5JodPEA_-jpKD8tsMGEYn26tIV1CJPnTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>,
> Carrboro, NC.
>
>


-- 
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161020/910ea857/attachment.html>

From alexis.girault at kitware.com  Fri Oct 21 11:03:46 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Fri, 21 Oct 2016 11:03:46 -0400
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
 <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
Message-ID: <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>

Here is how VTK offered to improve mapping volumetric meshes or just data
arrays: http://www.vtk.org/Wiki/VTK/InSituDataStructures

The MappedDataArray (that we tried to use and that Nich got rid of because
of huge overhead cost when calling getVoidPointer in the VBO creation) is
actually deprecated and will be removed in the future. The next iteration
of this functionality which focuses on performance improvements is
presented in this article
https://blog.kitware.com/new-data-array-layouts-in-vtk-7-1/ and detailed on
this wiki page: http://www.vtk.org/Wiki/VTK/Tutorials/DataArrays

If we can improve the renderer and mapper to do what's needed, I believe
we'll be able to use this new data array layouts to reduce data structure
conversion overhead.

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

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

On Thu, Oct 20, 2016 at 6:01 PM, Sreekanth Arikatla <
sreekanth.arikatla at kitware.com> wrote:

> Hi Nick,
>             Yes, that can be done (I was under the impression that even
> that operation was slow with vtk but haven't looked into that part myself).
> The copy could additionally be made conditional since rendering typically
> runs faster than the physics.
>
> The mesh needs to be updated though (at least in the case where visual and
> physics are the same) since the physics update of future time steps count
> on it.
>
> On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> In that case, then copying data over shouldn't be a big deal. I thought
>> the copying was occurring on the rendering thread. If we need thread
>> synchronization here, then we can just use a buffered approach.
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Thursday, October 20, 2016 3:53 PM
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Copying Vega data
>>
>> Hi Nick,
>>            It happens in a separate thread in the sceneManager module.
>>
>> On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=BpJFDzylJUzmyH0IS2ouZR58VfSo4ijMtYN4jcu2cDKtIV1CJPnTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > wrote:
>>
>>> Do Vega operations occur on the same thread as the render loop? If not,
>>> then it might be best to buffer and copy over the data instead of directly
>>> working on the mesh data.
>>>
>>> _______________________________________________
>>> Imstk-developers mailing list
>>> Imstk-developers at imstk.org
>>> <http://redir.aspx?REF=bigx7UCbQk9SNSpSCYDnjFakE4iwbAgWDMHb4qE4SpetIV1CJPnTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>> <http://redir.aspx?REF=jFoBqdkH1xl6pePYXQ0FIrvhA89vs902I3d4sBjmOUatIV1CJPnTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>
>>>
>>>
>>
>>
>> --
>> Sreekanth Arikatla, Ph.D,
>> Senior R&D Engineer,
>> Kitware, Inc.
>> <http://redir.aspx?REF=3qzFo3FNN4RdtBUk0qOs5JodPEA_-jpKD8tsMGEYn26tIV1CJPnTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>,
>> Carrboro, NC.
>>
>>
>
>
> --
> Sreekanth Arikatla, Ph.D,
> Senior R&D Engineer,
> Kitware, Inc. <http://www.kitware.com>, 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: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161021/7772a939/attachment-0001.html>

From alexis.girault at kitware.com  Mon Oct 24 09:25:04 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 24 Oct 2016 09:25:04 -0400
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
 <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
 <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>
Message-ID: <CAG1Y6mADj-C7EK5_9ZNfPcsLVT-=kDoBBZh0us0di+CfdoR8fw@mail.gmail.com>

Nich: a filter that could be used for skinning:
http://www.vtk.org/doc/nightly/html/classvtkWeightedTransformFilter.html#details
Also, another way to apply transforms in vtk is to apply it to the data
structures, and not to the actor:
http://www.vtk.org/doc/nightly/html/classvtkTransformPolyDataFilter.html

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

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

On Fri, Oct 21, 2016 at 11:03 AM, Alexis Girault <alexis.girault at kitware.com
> wrote:

> Here is how VTK offered to improve mapping volumetric meshes or just data
> arrays: http://www.vtk.org/Wiki/VTK/InSituDataStructures
>
> The MappedDataArray (that we tried to use and that Nich got rid of because
> of huge overhead cost when calling getVoidPointer in the VBO creation) is
> actually deprecated and will be removed in the future. The next iteration
> of this functionality which focuses on performance improvements is
> presented in this article https://blog.kitware.
> com/new-data-array-layouts-in-vtk-7-1/ and detailed on this wiki page:
> http://www.vtk.org/Wiki/VTK/Tutorials/DataArrays
>
> If we can improve the renderer and mapper to do what's needed, I believe
> we'll be able to use this new data array layouts to reduce data structure
> conversion overhead.
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x325
>
> On Thu, Oct 20, 2016 at 6:01 PM, Sreekanth Arikatla <
> sreekanth.arikatla at kitware.com> wrote:
>
>> Hi Nick,
>>             Yes, that can be done (I was under the impression that even
>> that operation was slow with vtk but haven't looked into that part myself).
>> The copy could additionally be made conditional since rendering typically
>> runs faster than the physics.
>>
>> The mesh needs to be updated though (at least in the case where visual
>> and physics are the same) since the physics update of future time steps
>> count on it.
>>
>> On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> In that case, then copying data over shouldn't be a big deal. I thought
>>> the copying was occurring on the rendering thread. If we need thread
>>> synchronization here, then we can just use a buffered approach.
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Thursday, October 20, 2016 3:53 PM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Copying Vega data
>>>
>>> Hi Nick,
>>>            It happens in a separate thread in the sceneManager module.
>>>
>>> On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=BpJFDzylJUzmyH0IS2ouZR58VfSo4ijMtYN4jcu2cDKtIV1CJPnTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>>> > wrote:
>>>
>>>> Do Vega operations occur on the same thread as the render loop? If not,
>>>> then it might be best to buffer and copy over the data instead of directly
>>>> working on the mesh data.
>>>>
>>>> _______________________________________________
>>>> Imstk-developers mailing list
>>>> Imstk-developers at imstk.org
>>>> <http://redir.aspx?REF=bigx7UCbQk9SNSpSCYDnjFakE4iwbAgWDMHb4qE4SpetIV1CJPnTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>>> <http://redir.aspx?REF=jFoBqdkH1xl6pePYXQ0FIrvhA89vs902I3d4sBjmOUatIV1CJPnTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sreekanth Arikatla, Ph.D,
>>> Senior R&D Engineer,
>>> Kitware, Inc.
>>> <http://redir.aspx?REF=3qzFo3FNN4RdtBUk0qOs5JodPEA_-jpKD8tsMGEYn26tIV1CJPnTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>,
>>> Carrboro, NC.
>>>
>>>
>>
>>
>> --
>> Sreekanth Arikatla, Ph.D,
>> Senior R&D Engineer,
>> Kitware, Inc. <http://www.kitware.com>, 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: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/e5918b4b/attachment.html>

From milefn at rpi.edu  Mon Oct 24 19:14:30 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 24 Oct 2016 23:14:30 +0000
Subject: [Imstk-developers] Text Rendering
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D4282@ex14mb4.win.rpi.edu>

One thing we may want to look into is optimizing text rendering. I think VTK uses FreeType, but that method has historically been slow for high-performance real-time applications because you essentially have to render out each character at a certain resolution (which is bad for 3D text especially since the render size would need to change with distance).

Valve published an influential paper here that works well in 2D and 3D:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

Also, there's some interesting discussion in this answer here:
http://stackoverflow.com/questions/5262951/what-is-state-of-the-art-for-text-rendering-in-opengl-as-of-version-4-1

What's interesting is that one approach is to model text essentially as a mesh and use geometry shaders to create planes out of the vertices to map the textures on them. IDK how great that approach is though because geometry shaders don't tolerate generating geometry very well, but it's an option. Otherwise, instancing should work well enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/45d39652/attachment.html>

From andinet.enqu at kitware.com  Mon Oct 24 19:18:33 2016
From: andinet.enqu at kitware.com (Andinet Enquobahrie)
Date: Mon, 24 Oct 2016 19:18:33 -0400
Subject: [Imstk-developers] Text Rendering
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D4282@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D4282@ex14mb4.win.rpi.edu>
Message-ID: <CANrU59_rF-Gr+b8bMh52Ew1wkgMQZJ1Dp7Rvp3AkGDi13OM0sQ@mail.gmail.com>

Nick,

But, are we doing any text rendering in iMSTK?

On Mon, Oct 24, 2016 at 7:14 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> One thing we may want to look into is optimizing text rendering. I think
> VTK uses FreeType, but that method has historically been slow for
> high-performance real-time applications because you essentially have to
> render out each character at a certain resolution (which is bad for 3D text
> especially since the render size would need to change with distance).
>
> Valve published an influential paper here that works well in 2D and 3D:
> http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_
> AlphaTestedMagnification.pdf
>
> Also, there's some interesting discussion in this answer here:
> http://stackoverflow.com/questions/5262951/what-is-
> state-of-the-art-for-text-rendering-in-opengl-as-of-version-4-1
>
> What's interesting is that one approach is to model text essentially as a
> mesh and use geometry shaders to create planes out of the vertices to map
> the textures on them. IDK how great that approach is though because
> geometry shaders don't tolerate generating geometry very well, but it's an
> option. Otherwise, instancing should work well enough.
>
> _______________________________________________
> 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 <%28919%29%20969-6990%20x311>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/dae8d144/attachment.html>

From milefn at rpi.edu  Mon Oct 24 19:22:53 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 24 Oct 2016 23:22:53 +0000
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <CAG1Y6mADj-C7EK5_9ZNfPcsLVT-=kDoBBZh0us0di+CfdoR8fw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
 <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
 <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>,
 <CAG1Y6mADj-C7EK5_9ZNfPcsLVT-=kDoBBZh0us0di+CfdoR8fw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D42A2@ex14mb4.win.rpi.edu>

Sorry, kind of late replying to all this stuff.

We will want to avoid skinning on the CPU as much as possible (we can actually totally replace it with current techniques depending on the overhead). I've already done GPU skinning within VTK for non-physical objects, but there are also ways to get that data back from the GPU so that physical objects can interact with it.

>From my understanding, transforming the PolyData vs transforming the Actor is the same thing because when you transform the Actor, you are actually transforming the PolyData. Except for a possible function call or two, this shouldn't help performance that much.
________________________________
From: Alexis Girault [alexis.girault at kitware.com]
Sent: Monday, October 24, 2016 9:25 AM
To: Sreekanth Arikatla
Cc: Milef, Nicholas Boris; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Copying Vega data

Nich: a filter that could be used for skinning: http://www.vtk.org/doc/nightly/html/classvtkWeightedTransformFilter.html#details<redir.aspx?REF=Mj-ffhLpMmrqbB19yuVxiIUZaSQYNnAeowjMqwRFfwPh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvZG9jL25pZ2h0bHkvaHRtbC9jbGFzc3Z0a1dlaWdodGVkVHJhbnNmb3JtRmlsdGVyLmh0bWwjZGV0YWlscw..>
Also, another way to apply transforms in vtk is to apply it to the data structures, and not to the actor: http://www.vtk.org/doc/nightly/html/classvtkTransformPolyDataFilter.html<redir.aspx?REF=jMlnmAMDaiDsGc62Hiq3VI49544X89FiZfCZMctUMprh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvZG9jL25pZ2h0bHkvaHRtbC9jbGFzc3Z0a1RyYW5zZm9ybVBvbHlEYXRhRmlsdGVyLmh0bWw.>

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

http://www.kitware.com<redir.aspx?REF=V0ztJFgTjzT0RMivK0hRASUXAGFbv6DGN1pkRPNgLmvh9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tLw..>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

On Fri, Oct 21, 2016 at 11:03 AM, Alexis Girault <alexis.girault at kitware.com<redir.aspx?REF=yteyC3sJVkEO3f82Co_ESpq3Q1fkEX32iAjTeGolJwfh9xKKY_zTCAFtYWlsdG86YWxleGlzLmdpcmF1bHRAa2l0d2FyZS5jb20.>> wrote:
Here is how VTK offered to improve mapping volumetric meshes or just data arrays: http://www.vtk.org/Wiki/VTK/InSituDataStructures<redir.aspx?REF=W0QgZSv4Lil82rTfMMalcf4HRy-HC7lNK29bE_TZbvrh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvV2lraS9WVEsvSW5TaXR1RGF0YVN0cnVjdHVyZXM.>

The MappedDataArray (that we tried to use and that Nich got rid of because of huge overhead cost when calling getVoidPointer in the VBO creation) is actually deprecated and will be removed in the future. The next iteration of this functionality which focuses on performance improvements is presented in this article https://blog.kitware.com/new-data-array-layouts-in-vtk-7-1/<redir.aspx?REF=lC7VhF1pv4HQM2cWIl25dHZ1vCuA7Pl7ycm0S1QgcJnh9xKKY_zTCAFodHRwczovL2Jsb2cua2l0d2FyZS5jb20vbmV3LWRhdGEtYXJyYXktbGF5b3V0cy1pbi12dGstNy0xLw..> and detailed on this wiki page: http://www.vtk.org/Wiki/VTK/Tutorials/DataArrays<redir.aspx?REF=od-dJGFb24F8O3ZPX3TIxKHF1Wdl_JfPWJrySkrXfizh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvV2lraS9WVEsvVHV0b3JpYWxzL0RhdGFBcnJheXM.>

If we can improve the renderer and mapper to do what's needed, I believe we'll be able to use this new data array layouts to reduce data structure conversion overhead.

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

http://www.kitware.com<redir.aspx?REF=V0ztJFgTjzT0RMivK0hRASUXAGFbv6DGN1pkRPNgLmvh9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tLw..>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

On Thu, Oct 20, 2016 at 6:01 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<redir.aspx?REF=_Owr_YQTfZKAWfqGaOOYZuWot-8vG6XQWZ7Br5h9jPDh9xKKY_zTCAFtYWlsdG86c3JlZWthbnRoLmFyaWthdGxhQGtpdHdhcmUuY29t>> wrote:
Hi Nick,
            Yes, that can be done (I was under the impression that even that operation was slow with vtk but haven't looked into that part myself). The copy could additionally be made conditional since rendering typically runs faster than the physics.

The mesh needs to be updated though (at least in the case where visual and physics are the same) since the physics update of future time steps count on it.

On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=p5ifK7JY0Eepw5XG7soqYLo0f_dPp4RsAVinmxk9nZLh9xKKY_zTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
In that case, then copying data over shouldn't be a big deal. I thought the copying was occurring on the rendering thread. If we need thread synchronization here, then we can just use a buffered approach.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<redir.aspx?REF=_Owr_YQTfZKAWfqGaOOYZuWot-8vG6XQWZ7Br5h9jPDh9xKKY_zTCAFtYWlsdG86c3JlZWthbnRoLmFyaWthdGxhQGtpdHdhcmUuY29t>]
Sent: Thursday, October 20, 2016 3:53 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<redir.aspx?REF=bx23EM43AtmQgYvCbEjpnfXIcS_tQE5rNGeIqYymj6zh9xKKY_zTCAFtYWlsdG86aW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
Subject: Re: [Imstk-developers] Copying Vega data

Hi Nick,
           It happens in a separate thread in the sceneManager module.

On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=ocxGB5FkJv35wN8y-lTM3IZ4R1_pXNzwE78SMgHQgZ_h9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9QnBKRkR6eWxKVXpteUgwSVMyb3VaUjU4VmZTbzRpak10WU40amN1MmNES3RJVjFDSlBuVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>> wrote:
Do Vega operations occur on the same thread as the render loop? If not, then it might be best to buffer and copy over the data instead of directly working on the mesh data.

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=pu_u9CUZNHFCaXnghztPOxRIHbMr0l_TEQmVbssAXGjh9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9YmlneDdVQ2JRazlTTlNwU0NZRG5qRmFrRTRpd2JBZ1dETUhiNHFFNFNwZXRJVjFDSlBuVENBRnRZV2xzZEc4NlNXMXpkR3N0WkdWMlpXeHZjR1Z5YzBCcGJYTjBheTV2Y21jLg..>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=fFMsZ7UGz2CLybSHL1J4CGNaD0s53E51-sCOb8Vj1Y7h9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9akZvQnFka0gxeGw2cGVQWVhRMEZJcnZoQTg5dnM5MDJJM2Q0c0JqbU9VYXRJVjFDSlBuVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmFXMXpkR3N0WkdWMlpXeHZjR1Z5Y3cuLg..>




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<redir.aspx?REF=u7i0bBhvPK_GCVYVlUovQfLaYQQs2PbAfCOuaaB20wHh9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9M3F6Rm8zRk5ONFJkdEJVazBxT3M1Sm9kUEVBXy1qcEtEOHRzTUdFWW4yNnRJVjFDSlBuVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>, Carrboro, NC.




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<redir.aspx?REF=iPFOxu_xpn0F3aj5CbwyYmwxre4q-9mD__ejLG4gJq7h9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>, Carrboro, NC.


_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=Xn3p_umUXJuCWxKHh5TDSeCfT9CpdG-En5N9SOzOJafh9xKKY_zTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=s9Ve0F8F1WRAVWb_4wUjTq69kMytXHnHZuTRcmA-rh7h9xKKY_zTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/1e9db157/attachment-0001.html>

From milefn at rpi.edu  Mon Oct 24 19:33:29 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 24 Oct 2016 23:33:29 +0000
Subject: [Imstk-developers] Text Rendering
In-Reply-To: <CANrU59_rF-Gr+b8bMh52Ew1wkgMQZJ1Dp7Rvp3AkGDi13OM0sQ@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D4282@ex14mb4.win.rpi.edu>,
 <CANrU59_rF-Gr+b8bMh52Ew1wkgMQZJ1Dp7Rvp3AkGDi13OM0sQ@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D42B5@ex14mb4.win.rpi.edu>

Anytime we need to display text on screen, we have to do text rendering. This would probably be a smaller bottleneck anyway, but text in 3D environments will be necessary for VR simulations that need text. Do you know whether this would be a commonly used feature for the type of applications that use iMSTK?
________________________________
From: Andinet Enquobahrie [andinet.enqu at kitware.com]
Sent: Monday, October 24, 2016 7:18 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Text Rendering

Nick,

But, are we doing any text rendering in iMSTK?

On Mon, Oct 24, 2016 at 7:14 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=GcaQIKykAf_p3U92afkjAfkcR6JBs14ytzeQbMTcl_vemiGvZPzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
One thing we may want to look into is optimizing text rendering. I think VTK uses FreeType, but that method has historically been slow for high-performance real-time applications because you essentially have to render out each character at a certain resolution (which is bad for 3D text especially since the render size would need to change with distance).

Valve published an influential paper here that works well in 2D and 3D:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf<redir.aspx?REF=1fm5UykOzXr3tI-V-rnL8JEZxa8GofNa8dtQklaZ9AHemiGvZPzTCAFodHRwOi8vd3d3LnZhbHZlc29mdHdhcmUuY29tL3B1YmxpY2F0aW9ucy8yMDA3L1NJR0dSQVBIMjAwN19BbHBoYVRlc3RlZE1hZ25pZmljYXRpb24ucGRm>

Also, there's some interesting discussion in this answer here:
http://stackoverflow.com/questions/5262951/what-is-state-of-the-art-for-text-rendering-in-opengl-as-of-version-4-1<redir.aspx?REF=L9ceArDG43rIPBojqyK2Tdcb-8qhHD1R5mMe9zNttRfemiGvZPzTCAFodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzUyNjI5NTEvd2hhdC1pcy1zdGF0ZS1vZi10aGUtYXJ0LWZvci10ZXh0LXJlbmRlcmluZy1pbi1vcGVuZ2wtYXMtb2YtdmVyc2lvbi00LTE.>

What's interesting is that one approach is to model text essentially as a mesh and use geometry shaders to create planes out of the vertices to map the textures on them. IDK how great that approach is though because geometry shaders don't tolerate generating geometry very well, but it's an option. Otherwise, instancing should work well enough.

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=GFN3h9T9h-_mhyIUlZi8aYZaKD7tDPVFblgKpLFip_XemiGvZPzTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=bzMtMSx-px0PYxry6kqu5cZ1Xw94t38LYay7g4P1K27emiGvZPzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>




--
Andinet Enquobahrie, Ph.D., MBA
Assistant Director of Medical Computing
Kitware, Inc.

http://www.kitware.com<redir.aspx?REF=UcbyTjHf0Zc5067o0PP1gs2m54iM8yQJDlREvU_iFQbemiGvZPzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
(919) 969-6990 x311<tel:%28919%29%20969-6990%20x311>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/a5693f50/attachment.html>

From andinet.enqu at kitware.com  Mon Oct 24 19:36:09 2016
From: andinet.enqu at kitware.com (Andinet Enquobahrie)
Date: Mon, 24 Oct 2016 19:36:09 -0400
Subject: [Imstk-developers] Text Rendering
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D42B5@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D4282@ex14mb4.win.rpi.edu>
 <CANrU59_rF-Gr+b8bMh52Ew1wkgMQZJ1Dp7Rvp3AkGDi13OM0sQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D42B5@ex14mb4.win.rpi.edu>
Message-ID: <CANrU59_dsX9xSeaDcyOGynxuRqaO=uEMgLO7fPW63Q8+Nsq13A@mail.gmail.com>

Text rendering  probably will not be a major issue for use. I would suggest
we focus on the main rending issues that are causing performance slow-down

On Mon, Oct 24, 2016 at 7:33 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Anytime we need to display text on screen, we have to do text rendering. This
> would probably be a smaller bottleneck anyway, but text in 3D environments
> will be necessary for VR simulations that need text. Do you know whether
> this would be a commonly used feature for the type of applications that use
> iMSTK?
> ------------------------------
> *From:* Andinet Enquobahrie [andinet.enqu at kitware.com]
> *Sent:* Monday, October 24, 2016 7:18 PM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Text Rendering
>
> Nick,
>
> But, are we doing any text rendering in iMSTK?
>
> On Mon, Oct 24, 2016 at 7:14 PM, Milef, Nicholas Boris <milefn at rpi.edu
> <http://redir.aspx?REF=GcaQIKykAf_p3U92afkjAfkcR6JBs14ytzeQbMTcl_vemiGvZPzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
> > wrote:
>
>> One thing we may want to look into is optimizing text rendering. I think
>> VTK uses FreeType, but that method has historically been slow for
>> high-performance real-time applications because you essentially have to
>> render out each character at a certain resolution (which is bad for 3D text
>> especially since the render size would need to change with distance).
>>
>> Valve published an influential paper here that works well in 2D and 3D:
>> http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_
>> AlphaTestedMagnification.pdf
>> <http://redir.aspx?REF=1fm5UykOzXr3tI-V-rnL8JEZxa8GofNa8dtQklaZ9AHemiGvZPzTCAFodHRwOi8vd3d3LnZhbHZlc29mdHdhcmUuY29tL3B1YmxpY2F0aW9ucy8yMDA3L1NJR0dSQVBIMjAwN19BbHBoYVRlc3RlZE1hZ25pZmljYXRpb24ucGRm>
>>
>> Also, there's some interesting discussion in this answer here:
>> http://stackoverflow.com/questions/5262951/what-is-state-of-
>> the-art-for-text-rendering-in-opengl-as-of-version-4-1
>> <http://redir.aspx?REF=L9ceArDG43rIPBojqyK2Tdcb-8qhHD1R5mMe9zNttRfemiGvZPzTCAFodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzUyNjI5NTEvd2hhdC1pcy1zdGF0ZS1vZi10aGUtYXJ0LWZvci10ZXh0LXJlbmRlcmluZy1pbi1vcGVuZ2wtYXMtb2YtdmVyc2lvbi00LTE.>
>>
>> What's interesting is that one approach is to model text essentially as a
>> mesh and use geometry shaders to create planes out of the vertices to map
>> the textures on them. IDK how great that approach is though because
>> geometry shaders don't tolerate generating geometry very well, but it's an
>> option. Otherwise, instancing should work well enough.
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> <http://redir.aspx?REF=GFN3h9T9h-_mhyIUlZi8aYZaKD7tDPVFblgKpLFip_XemiGvZPzTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>> <http://redir.aspx?REF=bzMtMSx-px0PYxry6kqu5cZ1Xw94t38LYay7g4P1K27emiGvZPzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>
>>
>>
>
>
> --
> Andinet Enquobahrie, Ph.D., MBA
> Assistant Director of Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> <http://redir.aspx?REF=UcbyTjHf0Zc5067o0PP1gs2m54iM8yQJDlREvU_iFQbemiGvZPzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>
>
>
>


-- 
Andinet Enquobahrie, Ph.D., MBA
Assistant Director of Medical Computing
Kitware, Inc.

http://www.kitware.com
(919) 969-6990 x311 <%28919%29%20969-6990%20x311>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161024/ea95ab99/attachment.html>

From alexis.girault at kitware.com  Tue Oct 25 10:15:20 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Tue, 25 Oct 2016 10:15:20 -0400
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D42A2@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
 <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
 <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>
 <CAG1Y6mADj-C7EK5_9ZNfPcsLVT-=kDoBBZh0us0di+CfdoR8fw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D42A2@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mCfmoLsy58GBcyhjvfXF0qTqjR9_LVafWGqF9Qdr6kA1A@mail.gmail.com>

>
> We will want to avoid skinning on the CPU as much as possible (we can
> actually totally replace it with current techniques depending on the
> overhead). I've already done GPU skinning within VTK for non-physical
> objects, but there are also ways to get that data back from the GPU so that
> physical objects can interact with it.
>

Looking forward to learn more about this. As the rest, please make sure to
keep track of this to show why current solutions in VTK would limit us.


> From my understanding, transforming the PolyData vs transforming the Actor
> is the same thing because when you transform the Actor, you are actually
> transforming the PolyData. Except for a possible function call or two, this
> shouldn't help performance that much.
>

Well not really: the actor will apply the transforms on the polydata
vertices at each frame. If we have an initial transform that we do not want
to concatenate every frame, using the filter will allow us to update the
input polydata.

Also, have you had a look at the no-copy arrays from my previous emails?
Those will be a main feature of the VTK 7.1 release.


> ------------------------------
> *From:* Alexis Girault [alexis.girault at kitware.com]
> *Sent:* Monday, October 24, 2016 9:25 AM
> *To:* Sreekanth Arikatla
> *Cc:* Milef, Nicholas Boris; imstk-developers at imstk.org
>
> *Subject:* Re: [Imstk-developers] Copying Vega data
>
> Nich: a filter that could be used for skinning: http://www.vtk.org/
> doc/nightly/html/classvtkWeightedTransformFilter.html#details
> <http://redir.aspx?REF=Mj-ffhLpMmrqbB19yuVxiIUZaSQYNnAeowjMqwRFfwPh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvZG9jL25pZ2h0bHkvaHRtbC9jbGFzc3Z0a1dlaWdodGVkVHJhbnNmb3JtRmlsdGVyLmh0bWwjZGV0YWlscw..>
> Also, another way to apply transforms in vtk is to apply it to the data
> structures, and not to the actor: http://www.vtk.org/doc/nightly/html/
> classvtkTransformPolyDataFilter.html
> <http://redir.aspx?REF=jMlnmAMDaiDsGc62Hiq3VI49544X89FiZfCZMctUMprh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvZG9jL25pZ2h0bHkvaHRtbC9jbGFzc3Z0a1RyYW5zZm9ybVBvbHlEYXRhRmlsdGVyLmh0bWw.>
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> <http://redir.aspx?REF=V0ztJFgTjzT0RMivK0hRASUXAGFbv6DGN1pkRPNgLmvh9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tLw..>
> (919) 969-6990 x325
>
> On Fri, Oct 21, 2016 at 11:03 AM, Alexis Girault <
> alexis.girault at kitware.com
> <http://redir.aspx?REF=yteyC3sJVkEO3f82Co_ESpq3Q1fkEX32iAjTeGolJwfh9xKKY_zTCAFtYWlsdG86YWxleGlzLmdpcmF1bHRAa2l0d2FyZS5jb20.>
> > wrote:
>
>> Here is how VTK offered to improve mapping volumetric meshes or just data
>> arrays: http://www.vtk.org/Wiki/VTK/InSituDataStructures
>> <http://redir.aspx?REF=W0QgZSv4Lil82rTfMMalcf4HRy-HC7lNK29bE_TZbvrh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvV2lraS9WVEsvSW5TaXR1RGF0YVN0cnVjdHVyZXM.>
>>
>> The MappedDataArray (that we tried to use and that Nich got rid of
>> because of huge overhead cost when calling getVoidPointer in the VBO
>> creation) is actually deprecated and will be removed in the future. The
>> next iteration of this functionality which focuses on performance
>> improvements is presented in this article https://blog.kitware.c
>> om/new-data-array-layouts-in-vtk-7-1/
>> <http://redir.aspx?REF=lC7VhF1pv4HQM2cWIl25dHZ1vCuA7Pl7ycm0S1QgcJnh9xKKY_zTCAFodHRwczovL2Jsb2cua2l0d2FyZS5jb20vbmV3LWRhdGEtYXJyYXktbGF5b3V0cy1pbi12dGstNy0xLw..>
>> and detailed on this wiki page: http://www.vtk.org/Wiki/
>> VTK/Tutorials/DataArrays
>> <http://redir.aspx?REF=od-dJGFb24F8O3ZPX3TIxKHF1Wdl_JfPWJrySkrXfizh9xKKY_zTCAFodHRwOi8vd3d3LnZ0ay5vcmcvV2lraS9WVEsvVHV0b3JpYWxzL0RhdGFBcnJheXM.>
>>
>> If we can improve the renderer and mapper to do what's needed, I believe
>> we'll be able to use this new data array layouts to reduce data structure
>> conversion overhead.
>>
>> Alexis Girault
>> R&D Engineer in Medical Computing
>> Kitware, Inc.
>>
>> http://www.kitware.com
>> <http://redir.aspx?REF=V0ztJFgTjzT0RMivK0hRASUXAGFbv6DGN1pkRPNgLmvh9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tLw..>
>> (919) 969-6990 x325
>>
>> On Thu, Oct 20, 2016 at 6:01 PM, Sreekanth Arikatla <
>> sreekanth.arikatla at kitware.com
>> <http://redir.aspx?REF=_Owr_YQTfZKAWfqGaOOYZuWot-8vG6XQWZ7Br5h9jPDh9xKKY_zTCAFtYWlsdG86c3JlZWthbnRoLmFyaWthdGxhQGtpdHdhcmUuY29t>
>> > wrote:
>>
>>> Hi Nick,
>>>             Yes, that can be done (I was under the impression that even
>>> that operation was slow with vtk but haven't looked into that part myself).
>>> The copy could additionally be made conditional since rendering typically
>>> runs faster than the physics.
>>>
>>> The mesh needs to be updated though (at least in the case where visual
>>> and physics are the same) since the physics update of future time steps
>>> count on it.
>>>
>>> On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=p5ifK7JY0Eepw5XG7soqYLo0f_dPp4RsAVinmxk9nZLh9xKKY_zTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>>> > wrote:
>>>
>>>> In that case, then copying data over shouldn't be a big deal. I thought
>>>> the copying was occurring on the rendering thread. If we need thread
>>>> synchronization here, then we can just use a buffered approach.
>>>> ------------------------------
>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com
>>>> <http://redir.aspx?REF=_Owr_YQTfZKAWfqGaOOYZuWot-8vG6XQWZ7Br5h9jPDh9xKKY_zTCAFtYWlsdG86c3JlZWthbnRoLmFyaWthdGxhQGtpdHdhcmUuY29t>
>>>> ]
>>>> *Sent:* Thursday, October 20, 2016 3:53 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* imstk-developers at imstk.org
>>>> <http://redir.aspx?REF=bx23EM43AtmQgYvCbEjpnfXIcS_tQE5rNGeIqYymj6zh9xKKY_zTCAFtYWlsdG86aW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>>>> *Subject:* Re: [Imstk-developers] Copying Vega data
>>>>
>>>> Hi Nick,
>>>>            It happens in a separate thread in the sceneManager module.
>>>>
>>>> On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> <http://redir.aspx?REF=ocxGB5FkJv35wN8y-lTM3IZ4R1_pXNzwE78SMgHQgZ_h9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9QnBKRkR6eWxKVXpteUgwSVMyb3VaUjU4VmZTbzRpak10WU40amN1MmNES3RJVjFDSlBuVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>>> > wrote:
>>>>
>>>>> Do Vega operations occur on the same thread as the render loop? If
>>>>> not, then it might be best to buffer and copy over the data instead of
>>>>> directly working on the mesh data.
>>>>>
>>>>> _______________________________________________
>>>>> Imstk-developers mailing list
>>>>> Imstk-developers at imstk.org
>>>>> <http://redir.aspx?REF=pu_u9CUZNHFCaXnghztPOxRIHbMr0l_TEQmVbssAXGjh9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9YmlneDdVQ2JRazlTTlNwU0NZRG5qRmFrRTRpd2JBZ1dETUhiNHFFNFNwZXRJVjFDSlBuVENBRnRZV2xzZEc4NlNXMXpkR3N0WkdWMlpXeHZjR1Z5YzBCcGJYTjBheTV2Y21jLg..>
>>>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>>>> <http://redir.aspx?REF=fFMsZ7UGz2CLybSHL1J4CGNaD0s53E51-sCOb8Vj1Y7h9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9akZvQnFka0gxeGw2cGVQWVhRMEZJcnZoQTg5dnM5MDJJM2Q0c0JqbU9VYXRJVjFDSlBuVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmFXMXpkR3N0WkdWMlpXeHZjR1Z5Y3cuLg..>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sreekanth Arikatla, Ph.D,
>>>> Senior R&D Engineer,
>>>> Kitware, Inc.
>>>> <http://redir.aspx?REF=u7i0bBhvPK_GCVYVlUovQfLaYQQs2PbAfCOuaaB20wHh9xKKY_zTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9M3F6Rm8zRk5ONFJkdEJVazBxT3M1Sm9kUEVBXy1qcEtEOHRzTUdFWW4yNnRJVjFDSlBuVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>,
>>>> Carrboro, NC.
>>>>
>>>>
>>>
>>>
>>> --
>>> Sreekanth Arikatla, Ph.D,
>>> Senior R&D Engineer,
>>> Kitware, Inc.
>>> <http://redir.aspx?REF=iPFOxu_xpn0F3aj5CbwyYmwxre4q-9mD__ejLG4gJq7h9xKKY_zTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>,
>>> Carrboro, NC.
>>>
>>>
>>> _______________________________________________
>>> Imstk-developers mailing list
>>> Imstk-developers at imstk.org
>>> <http://redir.aspx?REF=Xn3p_umUXJuCWxKHh5TDSeCfT9CpdG-En5N9SOzOJafh9xKKY_zTCAFtYWlsdG86SW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>
>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>> <http://redir.aspx?REF=s9Ve0F8F1WRAVWb_4wUjTq69kMytXHnHZuTRcmA-rh7h9xKKY_zTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vaW1zdGstZGV2ZWxvcGVycw..>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161025/06f9c0be/attachment-0001.html>

From milefn at rpi.edu  Tue Oct 25 19:04:08 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Tue, 25 Oct 2016 23:04:08 +0000
Subject: [Imstk-developers] Copying Vega data
In-Reply-To: <CAG1Y6mCfmoLsy58GBcyhjvfXF0qTqjR9_LVafWGqF9Qdr6kA1A@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D3F6C@ex14mb4.win.rpi.edu>
 <CAJFrbFLFy7Vc2+-2bmyy1ed1ywszAzuVux4FC36f0aPt8CvTgA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D3F8F@ex14mb4.win.rpi.edu>
 <CAJFrbFKp-ZRuXT+HXFgW+2PDHuNP_kAZ_i+e9Ra=V8312iA0oQ@mail.gmail.com>
 <CAG1Y6mBpJNiUV2RteUVvHZqGiJmWrdbe276qq8MyUheVvmA2xg@mail.gmail.com>
 <CAG1Y6mADj-C7EK5_9ZNfPcsLVT-=kDoBBZh0us0di+CfdoR8fw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D42A2@ex14mb4.win.rpi.edu>,
 <CAG1Y6mCfmoLsy58GBcyhjvfXF0qTqjR9_LVafWGqF9Qdr6kA1A@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D4354@ex14mb4.win.rpi.edu>

"Well not really: the actor will apply the transforms on the polydata vertices at each frame. If we have an initial transform that we do not want to concatenate every frame, using the filter will allow us to update the input polydata."

What's considered an initial transform? Doesn't the transform for each polydata component always get updated each frame with either solution? I don't remember seeing any chain of transformations, but I could be wrong.
________________________________
From: Alexis Girault [alexis.girault at kitware.com]
Sent: Tuesday, October 25, 2016 10:15 AM
To: Milef, Nicholas Boris
Cc: Sreekanth Arikatla; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Copying Vega data

We will want to avoid skinning on the CPU as much as possible (we can actually totally replace it with current techniques depending on the overhead). I've already done GPU skinning within VTK for non-physical objects, but there are also ways to get that data back from the GPU so that physical objects can interact with it.

Looking forward to learn more about this. As the rest, please make sure to keep track of this to show why current solutions in VTK would limit us.

>From my understanding, transforming the PolyData vs transforming the Actor is the same thing because when you transform the Actor, you are actually transforming the PolyData. Except for a possible function call or two, this shouldn't help performance that much.

Well not really: the actor will apply the transforms on the polydata vertices at each frame. If we have an initial transform that we do not want to concatenate every frame, using the filter will allow us to update the input polydata.

Also, have you had a look at the no-copy arrays from my previous emails? Those will be a main feature of the VTK 7.1 release.

________________________________
From: Alexis Girault [alexis.girault at kitware.com<redir.aspx?REF=vWg7t4BmO8BE6kxIqgegpCsNYU_BOjiNJ9ZOQvoavvXeDF9n7fzTCAFtYWlsdG86YWxleGlzLmdpcmF1bHRAa2l0d2FyZS5jb20.>]
Sent: Monday, October 24, 2016 9:25 AM
To: Sreekanth Arikatla
Cc: Milef, Nicholas Boris; imstk-developers at imstk.org<redir.aspx?REF=4cNPXXIvL0jH5ZpcsgY6jkDVW7OQb0ZwIy-3sBoqNcHeDF9n7fzTCAFtYWlsdG86aW1zdGstZGV2ZWxvcGVyc0BpbXN0ay5vcmc.>

Subject: Re: [Imstk-developers] Copying Vega data

Nich: a filter that could be used for skinning: http://www.vtk.org/doc/nightly/html/classvtkWeightedTransformFilter.html#details<redir.aspx?REF=NiGZf8vZZzv3Kmg2jdIh5LVqc-E5wT-x3bP-7TXfOY7eDF9n7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TWotZmZoTHBNbXJxYkIxOXl1VnhpSVVaYVNRWU5uQWVvd2pNcXdSRmZ3UGg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMblowYXk1dmNtY3ZaRzlqTDI1cFoyaDBiSGt2YUhSdGJDOWpiR0Z6YzNaMGExZGxhV2RvZEdWa1ZISmhibk5tYjNKdFJtbHNkR1Z5TG1oMGJXd2paR1YwWVdsc2N3Li4.>
Also, another way to apply transforms in vtk is to apply it to the data structures, and not to the actor: http://www.vtk.org/doc/nightly/html/classvtkTransformPolyDataFilter.html<redir.aspx?REF=Ldjx-MZbHf7XFJr4LOb-MyY8Rxm-_pgJR4bL_cyzN2feDF9n7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ak1sbm1BTURhaURzR2M2MkhpcTNWSTQ5NTQ0WDg5RmlaZkNaTWN0VU1wcmg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMblowYXk1dmNtY3ZaRzlqTDI1cFoyaDBiSGt2YUhSdGJDOWpiR0Z6YzNaMGExUnlZVzV6Wm05eWJWQnZiSGxFWVhSaFJtbHNkR1Z5TG1oMGJXdy4.>

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

http://www.kitware.com<redir.aspx?REF=Yma4donf675i5VZidc7xAGw0FuK0SBKfIiuIQ4xZ9zTeDF9n7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9VjB6dEpGZ1RqelQwUk1pdkswaFJBU1VYQUdGYnY2REdOMXBrUlBOZ0xtdmg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0THcuLg..>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

On Fri, Oct 21, 2016 at 11:03 AM, Alexis Girault <alexis.girault at kitware.com<redir.aspx?REF=sRIfsIwVB-x7ne_o5tRKVi6rQFVve3n9WJ5tg_4FfVTeDF9n7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9eXRleUMzc0pWa0VPM2Y4MkNvX0VTcHEzUTFma0VYMzJpQWpUZUdvbEp3Zmg5eEtLWV96VENBRnRZV2xzZEc4NllXeGxlR2x6TG1kcGNtRjFiSFJBYTJsMGQyRnlaUzVqYjIwLg..>> wrote:
Here is how VTK offered to improve mapping volumetric meshes or just data arrays: http://www.vtk.org/Wiki/VTK/InSituDataStructures<redir.aspx?REF=9PIX1JWFfIsqz9JQ0njKyVDxjNPAfNuR5uVMcsk1U-c_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9VzBRZ1pTdjRMaWw4MnJUZk1NYWxjZjRIUnktSEM3bE5LMjliRV9UWmJ2cmg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMblowYXk1dmNtY3ZWMmxyYVM5V1ZFc3ZTVzVUYVhSMVJHRjBZVk4wY25WamRIVnlaWE0u>

The MappedDataArray (that we tried to use and that Nich got rid of because of huge overhead cost when calling getVoidPointer in the VBO creation) is actually deprecated and will be removed in the future. The next iteration of this functionality which focuses on performance improvements is presented in this article https://blog.kitware.com/new-data-array-layouts-in-vtk-7-1/<redir.aspx?REF=0K3-VLSVkLUDE6FNjdNR107GRTMRTwBfHzA4LGNa-BE_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9bEM3VmhGMXB2NEhRTTJjV0lsMjVkSFoxdkN1QTdQbDd5Y20wUzFRZ2NKbmg5eEtLWV96VENBRm9kSFJ3Y3pvdkwySnNiMmN1YTJsMGQyRnlaUzVqYjIwdmJtVjNMV1JoZEdFdFlYSnlZWGt0YkdGNWIzVjBjeTFwYmkxMmRHc3ROeTB4THcuLg..> and detailed on this wiki page: http://www.vtk.org/Wiki/VTK/Tutorials/DataArrays<redir.aspx?REF=Cg9LnixKjhI0e-6m7Q9qu9_F2prOkvkYktO4is9RcyI_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9b2QtZEpHRmIyNEY4TzNaUFgzVEl4S0hGMVdkbF9KZlBXSnJ5U2tyWGZpemg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMblowYXk1dmNtY3ZWMmxyYVM5V1ZFc3ZWSFYwYjNKcFlXeHpMMFJoZEdGQmNuSmhlWE0u>

If we can improve the renderer and mapper to do what's needed, I believe we'll be able to use this new data array layouts to reduce data structure conversion overhead.

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

http://www.kitware.com<redir.aspx?REF=A825WjpK0JsiLnAq4uil9omNwrzK3Dc640AhF_I0-lk_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9VjB6dEpGZ1RqelQwUk1pdkswaFJBU1VYQUdGYnY2REdOMXBrUlBOZ0xtdmg5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0THcuLg..>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

On Thu, Oct 20, 2016 at 6:01 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<redir.aspx?REF=7uQ5chR7U6FJ9Ukhsw7zbednT4uUqrEmZP4hLrlTnxY_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9X093cl9ZUVRmWktBV2ZxR2FPT1ladVdvdC04dkc2WFFXWjdCcjVoOWpQRGg5eEtLWV96VENBRnRZV2xzZEc4NmMzSmxaV3RoYm5Sb0xtRnlhV3RoZEd4aFFHdHBkSGRoY21VdVkyOXQ.>> wrote:
Hi Nick,
            Yes, that can be done (I was under the impression that even that operation was slow with vtk but haven't looked into that part myself). The copy could additionally be made conditional since rendering typically runs faster than the physics.

The mesh needs to be updated though (at least in the case where visual and physics are the same) since the physics update of future time steps count on it.

On Thu, Oct 20, 2016 at 4:04 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=LeoQR4aSgFdV-H8Cx7kHYV4WAFFV3cQf6YNes50rfW8_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9cDVpZks3SlkwRWVwdzVYRzdzb3FZTG8wZl9kUHA0UnNBVmlubXhrOW5aTGg5eEtLWV96VENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>> wrote:
In that case, then copying data over shouldn't be a big deal. I thought the copying was occurring on the rendering thread. If we need thread synchronization here, then we can just use a buffered approach.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<redir.aspx?REF=7uQ5chR7U6FJ9Ukhsw7zbednT4uUqrEmZP4hLrlTnxY_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9X093cl9ZUVRmWktBV2ZxR2FPT1ladVdvdC04dkc2WFFXWjdCcjVoOWpQRGg5eEtLWV96VENBRnRZV2xzZEc4NmMzSmxaV3RoYm5Sb0xtRnlhV3RoZEd4aFFHdHBkSGRoY21VdVkyOXQ.>]
Sent: Thursday, October 20, 2016 3:53 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<redir.aspx?REF=eC08QHF3SEUze_Wu50FhxGnjbsH4uiOcNZX5SA3rGeg_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9YngyM0VNNDNBdG1RZ1l2Q2JFanBuZlhJY1NfdFFFNXJOR2VJcVl5bWo2emg5eEtLWV96VENBRnRZV2xzZEc4NmFXMXpkR3N0WkdWMlpXeHZjR1Z5YzBCcGJYTjBheTV2Y21jLg..>
Subject: Re: [Imstk-developers] Copying Vega data

Hi Nick,
           It happens in a separate thread in the sceneManager module.

On Thu, Oct 20, 2016 at 3:45 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=WAPIvW97zcw_nuWaEuIE6KS_saghvxD8Rodjka_-hWQ_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9b2N4R0I1RmtKdjM1d044eS1sVE0zSVo0UjFfcFhOendFNzhTTWdIUWdaX2g5eEtLWV96VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5UW5CS1JrUjZlV3hLVlhwdGVVZ3dTVk15YjNWYVVqVTRWbVpUYnpScGFrMTBXVTQwYW1OMU1tTkVTM1JKVmpGRFNsQnVWRU5CUm5SWlYyeHpaRWM0Tm1KWGJITmFWMXAxVVVoS2QyRlROV3hhU0ZVdQ..>> wrote:
Do Vega operations occur on the same thread as the render loop? If not, then it might be best to buffer and copy over the data instead of directly working on the mesh data.

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=Hhr6NrAgDwjPSyGecvi5WL31p1lgvgYA9PWtEZt-P9s_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9cHVfdTlDVVpOSEZDYVhuZ2h6dFBPeFJJSGJNcjBsX1RFUW1WYnNzQVhHamg5eEtLWV96VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5WW1sbmVEZFZRMkpSYXpsVFRsTndVME5aUkc1cVJtRnJSVFJwZDJKQloxZEVUVWhpTkhGRk5GTndaWFJKVmpGRFNsQnVWRU5CUm5SWlYyeHpaRWM0TmxOWE1YcGtSM04wV2tkV01scFhlSFpqUjFaNVl6QkNjR0pZVGpCaGVUVjJZMjFqTGcuLg..>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=Bz0846WnqnvhxaRuFQOV_T1285lilyTjr66G6qKR07E_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ZkZNc1o3VUd6MkNMeWJTSEwxSjRDR05hRDBzNTNFNTEtc0NPYjhWajFZN2g5eEtLWV96VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5YWtadlFuRmthMGd4ZUd3MmNHVlFXVmhSTUVaSmNuWm9RVGc1ZG5NNU1ESkpNMlEwYzBKcWJVOVZZWFJKVmpGRFNsQnVWRU5CUm05a1NGSjNUMms0ZG1OSVZtbGlSMnhxVEcxMGNHUklaR2hqYlZWMVdUSTVkRXd5TVdoaFYzaDBXVmMwZG1KSGJIcGtSMngxV20wNGRtRlhNWHBrUjNOMFdrZFdNbHBYZUhaalIxWjVZM2N1TGcuLg..>




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<redir.aspx?REF=1mLU4CKAm-atWiJ_y43ImgAjJGqoPIOis-vvBQYypEk_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9dTdpMGJCaHZQS19HQ1ZZVmxVb3ZRZkxhWVFRczJQYkFmQ091YWFCMjB3SGg5eEtLWV96VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5TTNGNlJtOHpSazVPTkZKa2RFSlZhekJ4VDNNMVNtOWtVRVZCWHkxcWNFdEVPSFJ6VFVkRldXNHlOblJKVmpGRFNsQnVWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMA..>, Carrboro, NC.




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<redir.aspx?REF=zKIWQu5TE5MeXXqTz0jv6jSUhN6HWVnTiwWZiKh-bE0_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9aVBGT3h1X3hwbjBGM2FqNUNid3lZbXd4cmU0cS05bURfX2VqTEc0Z0pxN2g5eEtLWV96VENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>, Carrboro, NC.


_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<redir.aspx?REF=3nQC4xfr3GijQzL3P5Z1kKe9zRH410te_3V-EpWH88U_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9WG4zcF91bVVYSnVDV3hLSGg1VERTZUNmVDlDcGRHLUVuNU45U096T0phZmg5eEtLWV96VENBRnRZV2xzZEc4NlNXMXpkR3N0WkdWMlpXeHZjR1Z5YzBCcGJYTjBheTV2Y21jLg..>
http://public.kitware.com/mailman/listinfo/imstk-developers<redir.aspx?REF=YBG_6Y28pTe3kQtsyk1KrWF7QUySet_LUMc4mf1Rexk_bmFn7fzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9czlWZTBGOEYxV1JBVldiXzR3VWpUcTY5a015dFhIbkhadVRSY21BLXJoN2g5eEtLWV96VENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmFXMXpkR3N0WkdWMlpXeHZjR1Z5Y3cuLg..>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161025/547e8d3c/attachment-0001.html>