[Paraview] volume rendering/ isosurfaces from a adaptive subset of a regular grid.

[Wylie, Brian]

> -----Original Message-----
> From: paraview-bounces at paraview.org 
> [mailto:paraview-bounces at paraview.org] On Behalf Of Daniel Goldstein
> Sent: Tuesday, May 03, 2005 10:24 AM
> To: paraview at paraview.org
> Subject: Re: [Paraview] volume rendering/ isosurfaces from a 
> adaptive subset of a regular grid.
> 
> Lisa Avila wrote:
> 
> > Hi Daniel,
> >
> >
> >
> >> 1)  Are hexahedral grid elements the only type supported for 
> >> unstructured volume rendering and isosurfaces?
> >
> >
> > Actually, I believe all the unstructured grid volume 
> rendering methods 
> > currently work on tetra - so ParaView automatically tetrahedralizes 
> > your data for you before rendering.
> 
>  Ok. I can generate hexahedral elements fairly easily from my 
> data. What is the overhead for ParaView to "automaticly 
> tetrahedralizes" the data?
> If it is low then it is best for me to make hexahedra and let 
> ParaView make tetrahedra from them. Does this sound like a 
> reasonable plan?
> 

Yes, that is totally fine. Having the volume rendering tetrahedralize
the data is pretty quick.


> >
> >> 2) Do the faces of the hexahedral elements need to be contiguous? 
> >> (i.e.. can four small faces meet up with one large face?)
> >
> >
> > The tetrahedral model can be an arbitrary set of tetrahedra.
> 
>  Ok this relates to the response above.  If I generate hexahedra such 
> that a face never mates with more then one face but
> mutiple small faces can match to a larger face, will Paraview 
> be able to 
> make a clean tetrahedral grid from it that will
> make good isosurfaces without cracks and holes?  I want to understand 
> the consequences of how I generate the grids before hand.
> 

	
This should also be fine. Unstructured data makes no assumptions about
how faces of elements match up.

> >
> >
> >> 3) Is there any limit on the number of  unstructured grid elements 
> >> that can be volume rendered with ParaView?
> >
> >
> > Yes - the current version cannot handle large grids (large 
> being more 
> > than maybe a few hundred thousand elements) because of the memory 
> > overhead of the method. Sandia has a nice hardware projection 
> > technique which is being incorporated in ParaView now - this will 
> > handle much larger grids  and will be much faster than the current 
> > method.
> 
>  
>    Can you point me to a reference to this project. I am 
> interested in 
> what hardware they are using (so I can see if I can get access to the 
> same hardware..)
>

No special hardware. The 'hardware' method Lisa is referring to, is the
translation of tetrahedral cell elements into properly 'shaded'
triangles that get processed by the OpenGL library (w or w/o graphics
card... "hardware"). The basis of the algorithm is actually quite old
(Projected Tetrahedra.. Shirley and Tuchman.. 1986 I believe... :)

 
> 
>    Thanks a million for the help!  I'm impressed with ParaView so far!
> 
> Dan
> 
> >
> >
> >> 4) I noticed that KitWare has a phase 1 SBIR for working on AMR 
> >> visualization. Will this code end up in ParaView?
> >
> >
> > If we get a Phase II it is likely to show up in ParaView. 
> This is not 
> > likely to happen very soon - if we get Phase II the funding 
> would not 
> > start until January I believe. However, the base classes will be in 
> > VTK within the next month or so.
> >
> >
> > Lisa
> >
> >
> >
>

Just a general note, this is 'unstructured' volume rendering. Going to
be much slower than structure volume rendering, so be prepared for slug
like performance. :) 

Brian Wylie - Org 9227
Sandia National Laboratories
MS 0822 - Building 880/A1-J
(505)844-2238 FAX(505)845-0833                       
     ____                  _    __
    / __ \____  _________ | |  / (_)__ _      __ 
   / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
  / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
 /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/

                                    Unleash the Beast