| IDLgrVolume [message #33679] |
Sat, 18 January 2003 18:56  |
lyubo
Messages: 34
Registered: March 2002
|
Member |
|
|
Is it possible to render/manipulate a volume of size 256x256x256
(or 512x512x512) in real time with IDLgrVolume, and if it is what
hardware can do the job?
Lyubo
|
|
|
|
| Re: IDLgrVolume [message #33748 is a reply to message #33679] |
Tue, 21 January 2003 23:16  |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Paul Woodford" <cpwoodford@spamcop.net> wrote in message
news:cpwoodford-6E78D1.23545921012003@corp.supernews.com...
> In article <b0kjj9$l5a$1@news.rsinc.com>,
> "Karl Schultz" <kNOSPAMschultz@rsinc.com> wrote:
>
>> There's another way to display a volume by building a series of
>> slices with polygons, texture mapped with the appropriate data and
>> alpha information. [...] I'm pretty sure I've posted about this
>> before, but we can revisit if there is interest.
>
> I am interested. I had just started playing around with this idea. A
> recap, or even just some keywords to use on Google, would be great.
Here's the URL:
http://groups.google.com/groups?q=texture+group:comp.lang.id l-pvwave&hl=en&l
r=&ie=UTF-8&oe=UTF-8&as_drrb=b&as_mind=12&am p;as_minm=5&as_miny=1999&as_maxd=21&
as_maxm=1&as_maxy=2003&selm=ap3ual%24a0i%241%40news. rsinc.com&rnum=5
It sort of looks like all I did here was a recap, but I hope it helps a bit.
>> Some companies make plug-in volume rendering accelerator cards and the
>> software that goes with them. I think Mitsubishi is one of them.
>
> The Mitsubishi device is now sold by TeraRecon as VolumePro. Very
> zippy.
>
> <http://www.terarecon.com/>
>
>> But cards like these are expensive
>
> Yes, but not as expensive as a doctor's time.
>
>> and often have upper limits on volume size that are not large enough
>> for some people.
>
> I saw a VolumePro 1000 whipping around a big (400x400x400?) volume in
> real time, and they say it can do that up to 512x512x512.
Thanks for the updates. It has been awhile since I looked at this stuff.
The OP's volume is well within these limits.
Karl
|
|
|
|
| Re: IDLgrVolume [message #33749 is a reply to message #33679] |
Tue, 21 January 2003 20:54 |
Paul Woodford
Messages: 43
Registered: June 2000
|
Member |
|
|
In article <b0kjj9$l5a$1@news.rsinc.com>,
"Karl Schultz" <kNOSPAMschultz@rsinc.com> wrote:
> Since your machine is dual processor, you are also ahead of the game,
> as IDLgrVolume was multi-threaded even before some other IDL
> functions received MT support.
Note that you need to set HINTS=2 to use multiple processors.
In article <b0k1t3$1nug$1@nntp6.u.washington.edu>,
"Rick Towler" <rtowler@u.washington.edu> wrote:
> IDLgrVolume can use multiple CPU's but a look at some older posts
> suggest that the improvement might not be worth the investment.
That is not my experience. I can't recall the last time I actually
timed it, but going from 1 to 2 processors doubled the rendering speed
for me.
Paul
|
|
|
|
| Re: IDLgrVolume [message #33750 is a reply to message #33679] |
Tue, 21 January 2003 20:54 |
Paul Woodford
Messages: 43
Registered: June 2000
|
Member |
|
|
In article <b0kjj9$l5a$1@news.rsinc.com>,
"Karl Schultz" <kNOSPAMschultz@rsinc.com> wrote:
> There's another way to display a volume by building a series of
> slices with polygons, texture mapped with the appropriate data and
> alpha information. [...] I'm pretty sure I've posted about this
> before, but we can revisit if there is interest.
I am interested. I had just started playing around with this idea. A
recap, or even just some keywords to use on Google, would be great.
> Some companies make plug-in volume rendering accelerator cards and the
> software that goes with them. I think Mitsubishi is one of them.
The Mitsubishi device is now sold by TeraRecon as VolumePro. Very
zippy.
<http://www.terarecon.com/>
> But cards like these are expensive
Yes, but not as expensive as a doctor's time.
> and often have upper limits on volume size that are not large enough
> for some people.
I saw a VolumePro 1000 whipping around a big (400x400x400?) volume in
real time, and they say it can do that up to 512x512x512.
Paul
|
|
|
|
| Re: IDLgrVolume [message #33751 is a reply to message #33679] |
Tue, 21 January 2003 15:07 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Lyubomir Zagorchev" <lzagorch@cs.wright.edu> wrote in message
news:b0k0vs$cvf$1@proxy1.wright.edu...
>
> First, thank you for your replies.
>
> The hardware rendering is on and I am running the program under Windows
> 2000,
> on Pentium 4, 2.0 GHz dual processor, 512 Ram, with Nvidia GeForce3
graphics
> card.
>
> I'll make the program and a dummy dataset available for independent
testing
> asap,
> but in the meantime is there any special hardware that can speed up the
> rendering
> of volumes (like particular graphics card, etc.)?
IDLgrVolume::Draw is implemented totally in software, so Rick's advice on
getting the fastest CPU and the most memory you can is good advice. Since
your machine is dual processor, you are also ahead of the game, as
IDLgrVolume was multi-threaded even before some other IDL functions received
MT support. You might want to bring up your Task Manager with the CPU
performance graphs and see if you observe both processors getting hammered
during a long volume rendering.
Selecting IDL hardware vs software rendering won't make a significant
difference because IDL is just drawing a 2D image to the screen, and the
time needed for that is tiny compared to the rendering.
There's another way to display a volume by building a series of slices with
polygons, texture mapped with the appropriate data and alpha information.
It provides a really decent approximation to the volume and displays pretty
quickly. One problem with it is that you have to render the slices back to
front since blending is involved, so you have to change your rendering order
based on the orientation to the view point. I'm pretty sure I've posted
about this before, but we can revisit if there is interest.
Hardware:
There are some OpenGL accelerator cards that support 3D texture mapping. 3D
texture mapping can be used to display volumes, but the speed depends on how
the card vendor implemented the 3D texture mapping support. A long time
ago, RSI experimented with a card from HP that could do this with hardware
acceleration, but I don't remember the outcome. I know part of the issue
was that the OpenGL interface for 3D texture mapping was still under
significant revision and there was much peril in coding anything using these
interfaces. Today, there are not very many cards that support the 3D
texture API. So, currently, IDL doesn't try to use 3D textures for volume
rendering. If the OpenGL driver does this in software, I think that the
technique is similar to the slice idea I mentioned above.
Some companies make plug-in volume rendering accelerator cards and the
software that goes with them. I think Mitsubishi is one of them
(http://www.mitsubishielectric.com/news/1999/052499.htm), but there are
probably others. I suppose that if all the right things were in place, such
a product might offer a C API to the card and you could write an IDL DLM to
send a volume to the card, pull the resulting image back, and draw it to the
screen in IDL. But cards like these are expensive and often have upper
limits on volume size that are not large enough for some people.
Other software:
There are a bunch of free and not-so-free volume rendering software packages
out there if all you want to do is look at volumes and do whatever else they
support. Some may support volume accelerators like the Mitsubishi, but most
are going to be software implementations. They may offer some features
and/or algorithm selection that provide some choices in performance ranges.
Hope this helps,
Karl
|
|
|
|
| Re: IDLgrVolume [message #33753 is a reply to message #33679] |
Tue, 21 January 2003 13:11 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
Oh man, you are going to make me find it again??? :)
The answer comes from the ever effervescent Karl Shultz:
http://groups.google.com/groups?q=IDLgrVolume+%2Bhardware+gr oup:comp.lang.id
l-pvwave+author:Karl&hl=en&lr=&ie=UTF-8&oe=U TF-8&selm=akjl6u%24aok%241%40new
s.rsinc.com&rnum=2
The thread covered a couple of topics but at the bottom Karl addresses
volume rendering:
"The volume renderer built into IDLgrVolume uses a software ray-casting
approach to create the image, which is pretty compute-intensive. OpenGL
acceleration has no impact on rendering IDL volumes, except when blitting
the (2D) result to the screen."
-Rick
"David Fanning" wrote
> Rick Towler writes:
>
>> IDLgrVolume doesn't utilize hardware rendering at all so the type of
>> graphics hardware and hardware/software switch is mostly irrelevant
(only
>> used when blitting the 2d result to the screen).
>
> Really!? Where do you find this information, Rick?
>
> I have a vague recollection this is true, and -- of
> course -- I believe everything you tell me without question,
> but my wife is from Missouri and would like some evidence from
> me. I've been poking around for half-hour now without
> any joy at all. This Alzheimers (or whatever it is) is
> especially bad when I get back from a trip. :-(
>
> Cheers,
>
> David
> --
> David W. Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Phone: 970-221-0438, E-mail: david@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDLgrVolume [message #33754 is a reply to message #33679] |
Tue, 21 January 2003 12:32 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Rick Towler (rtowler@u.washington.edu) writes:
> IDLgrVolume doesn't utilize hardware rendering at all so the type of
> graphics hardware and hardware/software switch is mostly irrelevant (only
> used when blitting the 2d result to the screen).
Really!? Where do you find this information, Rick?
I have a vague recollection this is true, and -- of
course -- I believe everything you tell me without question,
but my wife is from Missouri and would like some evidence from
me. I've been poking around for half-hour now without
any joy at all. This Alzheimers (or whatever it is) is
especially bad when I get back from a trip. :-(
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDLgrVolume [message #33760 is a reply to message #33679] |
Tue, 21 January 2003 09:57 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"David Fanning" wrote
> Sebastian (s@visita2.die.upm.es) writes:
>
>> some figures for a 256^3 volume (MRI) into a 500x500 window:
>>
>> "highest quality" settings:
>> RENDER_STEP=[1,1,1],INTERPOLATE=1,LIGHTING_MODEL=1,TWO_SIDED =1
>>
>> "medium quality" settings:
>> RENDER_STEP=[2,2,5],INTERPOLATE=0,LIGHTING_MODEL=0,TWO_SIDED =0
>>
>> Pentium IV 2.4 GHz, 512MB, W2K, IDL 5.6
>> highest quality: 11-17s
>> medium quality: 0.5-1.0s
>>
>> Pentium III mobile 800 MHz, 256MB, Linux, IDL 5.5
>> highest quality: 35-50s
>> medium quality: 2.0-3.0s
>
> Is this with hardware rendering turned on or off?
> If on, what kind of graphics card are you using?
IDLgrVolume doesn't utilize hardware rendering at all so the type of
graphics hardware and hardware/software switch is mostly irrelevant (only
used when blitting the 2d result to the screen).
As to the original posters question, the hardware that can do the job is the
fastest CPU/RAM combination you can afford. IDLgrVolume can use multiple
CPU's but a look at some older posts suggest that the improvement might not
be worth the investment. Not sure if that is true today.
If you are rooted in x86 land, then the hyperthreading P4's with the
"canterwood" chipset due 2nd quarter '03 would be a good option. AMD's
hammer line of 64 bit procs might be a good choice too but it would be nice
to see some firm numbers on it. If you aren't fixated on the x86
architecture then the please don't kill our Alpha would be a top choice.
-Rick
|
|
|
|
| Re: IDLgrVolume [message #33762 is a reply to message #33679] |
Tue, 21 January 2003 10:44 |
lyubo
Messages: 34
Registered: March 2002
|
Member |
|
|
First, thank you for your replies.
The hardware rendering is on and I am running the program under Windows
2000,
on Pentium 4, 2.0 GHz dual processor, 512 Ram, with Nvidia GeForce3 graphics
card.
I'll make the program and a dummy dataset available for independent testing
asap,
but in the meantime is there any special hardware that can speed up the
rendering
of volumes (like particular graphics card, etc.)?
Thanks,
Lyubo
|
|
|
|
| Re: IDLgrVolume [message #33763 is a reply to message #33679] |
Tue, 21 January 2003 06:47 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Sebastian (s@visita2.die.upm.es) writes:
> some figures for a 256^3 volume (MRI) into a 500x500 window:
>
> "highest quality" settings:
> RENDER_STEP=[1,1,1],INTERPOLATE=1,LIGHTING_MODEL=1,TWO_SIDED =1
>
> "medium quality" settings:
> RENDER_STEP=[2,2,5],INTERPOLATE=0,LIGHTING_MODEL=0,TWO_SIDED =0
>
> Pentium IV 2.4 GHz, 512MB, W2K, IDL 5.6
> highest quality: 11-17s
> medium quality: 0.5-1.0s
>
> Pentium III mobile 800 MHz, 256MB, Linux, IDL 5.5
> highest quality: 35-50s
> medium quality: 2.0-3.0s
Is this with hardware rendering turned on or off?
If on, what kind of graphics card are you using?
Can you make the data and programs available for
independent testing?
> For a comparison: The same data set with similar settings and similar
> results in VTK on the 800 MHz Linux computer takes about 5 +- 1 seconds -
> and VTK provides an "automatic" level of detail mechanism for real-time
> but low-quality rendering while rotating the data set.
Although IDL doesn't provide "automatic" low-quality rendering
while rotating, it is easy enough to provide it yourself. See
the "Drag Quality" settings on FSC_Surface, for example.
http://www.dfanning.com/programs/fsc_surface.zip
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDLgrVolume [message #33764 is a reply to message #33679] |
Tue, 21 January 2003 02:28 |
s[1]
Messages: 21
Registered: December 2002
|
Junior Member |
|
|
Hi,
some figures for a 256^3 volume (MRI) into a 500x500 window:
"highest quality" settings:
RENDER_STEP=[1,1,1],INTERPOLATE=1,LIGHTING_MODEL=1,TWO_SIDED =1
"medium quality" settings:
RENDER_STEP=[2,2,5],INTERPOLATE=0,LIGHTING_MODEL=0,TWO_SIDED =0
Pentium IV 2.4 GHz, 512MB, W2K, IDL 5.6
highest quality: 11-17s
medium quality: 0.5-1.0s
Pentium III mobile 800 MHz, 256MB, Linux, IDL 5.5
highest quality: 35-50s
medium quality: 2.0-3.0s
The time differences for a given quality come from different viewing
angles and different settings for the transfer functions (the more
transparent the slower)
For a comparison: The same data set with similar settings and similar
results in VTK on the 800 MHz Linux computer takes about 5 +- 1 seconds -
and VTK provides an "automatic" level of detail mechanism for real-time
but low-quality rendering while rotating the data set.
Hope that helps,
Sebastian
On Sat, 18 Jan 2003, lyubo wrote:
>
> Is it possible to render/manipulate a volume of size 256x256x256
>
> (or 512x512x512) in real time with IDLgrVolume, and if it is what
>
> hardware can do the job?
>
>
>
> Lyubo
>
>
>
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
