Hi Evan,
On Mar 5, 2013, at 12:31 AM, Evan Kao wrote:
> Hi Luca,
>
> Thanks for the additional suggestion.
>
> You are right, there's lots of room for improvement regarding visualization
> in patching (and in general). Thanks for the suggestion!
>
> Just to clarify further, I wasn't trying to suggest it needed any
> improvement, just that one little feature didn't seem to be working properly
> for me, which I suspect has more to do with Windows or myself than vmtk.
I don't think it's you or (for once) Windows. This is a vmtk feature that
hasn't received much attention - I basically implemented what I needed at the
time, and I didn't need to visualize the image data results from within vmtk.
This can be improved a lot with a relatively low effort, I pinned it to my todo
list.
Luca
> Thanks,
> Evan Kao
>
> On Mon, Mar 4, 2013 at 4:31 AM, Luca Antiga <luca.ant...@gmail.com> wrote:
> Hi Evan,
>
> On Mar 1, 2013, at 7:51 PM, Evan Kao wrote:
>
>> Hello Luca,
>>
>> Thanks for the quick response and help. Using subdivisions seemed to have
>> fixed the problem of missing patches (I did end up having to use the
>> AbscissaMetric array as the longitudinal axis in vmtkbranchpatching as
>> opposed to StretchedMapping due to issues with Python crashing when trying
>> to compute the bifurcation reference systems from the subdivided surface,
>> but this is probably more of an issue with the system I'm using than one
>> with vmtk).
>
> It's possible, but try to use subdivision after the mapping and prior to
> patching. You'll still see the little hole at the bifurcation center, which
> shouldn't be that big of a deal (although I don't know your exact
> application), but you'll be able to use StretchedMapping for the patching,
> which results in a more regular coverage of the surface.
>
>> Why nonsense? The data is all there.
>>
>> To clarify, I don't think the data is nonsense, but when I provide the flag
>> -patcheddatafile xxx.vti/png for vmtkbranchpatching, it doesn't seems to
>> visualize the data correctly, as seen in the image files I attached in the
>> previous e-mail (I just see a gray rectangle). But it's probably not a big
>> deal, since I can just export the raw data and visualize it however I want,
>> as you suggested.
>
> You are right, there's lots of room for improvement regarding visualization
> in patching (and in general). Thanks for the suggestion!
>
> Luca
>
>> Thanks,
>> Evan Kao
>>
>> On Fri, Mar 1, 2013 at 4:01 AM, Luca Antiga <luca.ant...@gmail.com> wrote:
>> Hi Evan,
>>
>> On Mar 1, 2013, at 1:59 AM, Evan Kao wrote:
>>
>>> Hello group,
>>>
>>> I am still having some trouble with mapping and patching data. When I
>>> created the patched surface and viewed it, I noticed that some patches of
>>> the surface were missing (see: missingpatches.png,
>>> any011_wss_clipped_patching.vtp). Inspecting the surfaces generated from
>>> the previous steps, it seems small pieces of the surface is cut out at the
>>> bifurcation (surface after splitting.png, any011_wss_clipped.vtp), although
>>> I don't know if that is related to the problem in the surface patching
>>> step, or simply a result of the way the centerlines were formed
>>> (centerlines,png, any011_wss_cl.vtp).
>>
>> Both issues are related to the fact that the surface is probably too coarse
>> in some regions relative to the size of the patch. Also, due to the way
>> clipping is performed, you can have a small missing triangle at the
>> bifurcation, whose size decreases with the increase in the surface density.
>> This is due to the linear interpolation of the cuts on top of the
>> triangulation.
>> A workaround in these cases is to pass the surface through
>> vmtksurfacesubdivision -method butterfly -subdivisions 1
>> prior to patching.
>>
>>> The image files generated with the patched data (both .vti and .png) were
>>> nonsense (vmtkimageviewer of patcheddata.png,
>>> any011_wss_clipped_patching.png, any011_wss_clipped_patching.vti).
>>
>> Why nonsense? The data is all there. It's one image in which all three
>> branches are stored contiguously, this way:
>>
>> SECTORS x (SLAB_A + SLAB_B + SLAB_C)
>>
>> I attach a couple of screenshots that demonstrate it, obtained using
>> Paraview.
>>
>> It's probably not the most practical way to plot the data, though. I suggest
>> you export the vtp patched data this way:
>>
>> vmtksurfacewriter -ifile any011_wss_clipped_patching.vtp -ofile foo.dat
>> -celldata
>>
>> which will generate a csv-like file in which lines are individual patches,
>> each with its wss value, groupid, slab and sector.
>> This will allow you to generate plots of the unwrapped surface for your
>> needs using any general purpose plotting software by plotting sector on x,
>> slab on y and wss as the color.
>>
>> Hope this helps
>>
>> Luca
>>
>>> To simplify the issue, I also tried mapping and patching only one branch
>>> segment (the aneurysm) by cutting out the other branches with
>>> vmtksurfaceclipper before any sort of branch extraction and splitting.
>>> There didn't seem to be any issues with missing patches this time around,
>>> but the .png file also failed to provide the expected results (the patched
>>> 3D surface, and the "unwrapped" 2D surface).
>>>
>>> Any idea on what's going wrong?
>>>
>>> Thanks,
>>> Evan Kao
>>>
>>
>>
>>
>>
>>
>>> On Fri, Feb 22, 2013 at 3:54 PM, Evan Kao <tos...@gmail.com> wrote:
>>> Thanks, Arjan. That was an extremely helpful explanation.
>>>
>>>
>>> On Wed, Feb 20, 2013 at 4:40 PM, Arjan Geers <ajge...@gmail.com> wrote:
>>> Hi Evan,
>>>
>>> VTK polydata files store the location of points and information on how
>>> these points are connected to form cells. Additionally, they can store
>>> scalars and vectors at each point or cell. So, indeed, you want the WSS
>>> field already included in the surface file before performing any
>>> vmtkbranch* operations.
>>>
>>> Hopefully, you can export from your CFD solver an ASCII file similar to
>>> surface.tec (attached). It contains x,y,z-coordinates of each point, the
>>> wss magnitude at each point, and connectivity information. When opening
>>> this surface with vmtksurfacereader, VMTK converts it into a VTK polydata,
>>> which can then be written with vmtksurfacewriter (see surface.vtp
>>> attached). To check what VMTK actually does when converting the ASCII file,
>>> go to the function 'ReadTecplotSurfaceFile' in vmtksurfacereader.py. This
>>> should provide you with some hints on how to convert your own format to
>>> VTP.
>>>
>>> Hope this helps,
>>>
>>> Arjan
>>>
>>> PS: Since the commercial CFD solver Ansys-CFX is quite widely used, the
>>> attached script cfx2vtp.py (variation on above-mentioned
>>> 'ReadTecplotSurfaceFile') might be useful to some reading this email.
>>> Converting surface.csv (attached) should give surface.vtp again.
>>>
>>>
>>> On Wed, Feb 20, 2013 at 9:40 PM, Evan Kao <tos...@gmail.com> wrote:
>>> Hello,
>>>
>>> I am confused about some of the details regarding the matching and patching
>>> of data in the tutorial. Specifically, at what stage in the process are we
>>> supposed to import the simulation data into vmtk, and how? For instance,
>>> in the tutorial, are the WSS and OSI distributions already part of the
>>> surface file ("aorta.vtp") before any processing occurs? It doesn't seem
>>> like there are any ways to import data in any of the vmtkbranchmetrics,
>>> vmtkbranchmapping, or vmtkbranchpatching functions. And what form does the
>>> data have to be in? It should be pretty easy to export nodal or cell CFD
>>> data as an array, but how would we incorporate that into vmtk?
>>>
>>> Thanks for your time,
>>> Evan Kao
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> vmtk-users mailing list
>>> vmtk-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
>>>
>>>
>>>
>>>
>>> <any011_wss_clipped_patching.png><centerlines.png><missing
>>> patches.png><surface after splitting.png><vmtkimageviewer of patched
>>> data.png><any011_wss_clipped_patching.vtp><any011_wss_clipped_patching.vti><any011_wss_cl.vtp><any011_wss_clipped.vtp>------------------------------------------------------------------------------
>>>
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________
>>> vmtk-users mailing list
>>> vmtk-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________
> vmtk-users mailing list
> vmtk-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/vmtk-users
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
vmtk-users mailing list
vmtk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vmtk-users
