Truform & Sci-Vis

L

lifeguard1999

New member
The work I perform is Scientific Visualization. Basically this means taking terabytes of data and turning it into pretty pictures and animation so that the researcher can understand it. We also take it and visualize it in 3-D (since the data is in 3-D + varies with time) using SGI supercomputers. We do this using Crystal Eyes active shutter glasses and a hugs panormaic screen.

However, SGI's performance increase in the CPU and graphics realm has slowed considerably. I wrote some code from the ground up using OpenGL and C++. It compiles and runs not only on SGI's computers, but also on the Wintel platforms.

At work with a dual 1.7 GHz Xeon & Geforce 2 Quadro I get 124 frames per second. With the 400 MHz SGI CPUs and InfiniteReality2 graphics, I get 50 fps. At home with a 933 Pentium3 and 8500, I get 35 fps. At home I am CPU bound, not ill-rate bound.

The data I am using is a fuel injector for a gas turbine engine. Basically it looks like a cigar with smoke rings (torus in shape) puffing out. There are 312 time steps, with an average of 17,000 +/- 500 vertices for each time step.

So I decided to take the code and add in Truform (PN Triangles). My results are:

TruForm OFF: 37 fps
Truform ON:
Triangle Level 0: 35.5 fps
Triangle Level 1: 22.5 fps
Triangle Level 2: 13.5 fps
Triangle Level 3: 9.75 fps
Triangle Level 4: 6.75 fps
Triangle Level 5: 5.20 fps

The image quality is second best without Truform. Here I am using normals for every vertex (as oppossed to using normals for the "face"). However, its performance is the best. So I rate it best overall.

The best image quality is higher levels of Truform with linear interpolation of the normals. As you can see, higher levels give worse performance.

Worst is quadratic interpolation of the normals with the level = 1. The "cigar" took on the "texture" of a circuit board. Level > 2 showed better results.

I could tell very little difference between linear/cubic for the points. Zooming in real close revels that cubic looks better. But at 30fps, the difference was too small to notice.

Conclusion:

Truform is easy to code in OpenGL. It took less than half-an-hour. For this particular data set on this particular computer, it is not worth it. However, I will leave it in for possible use on future data sets.

Future Work:

-> I may take out my 8500 and drop it in the dual 1.7 GHz at work and see how it performs there.

-> In about a month, the OpenGL/C++ code will be freely available for download from my work site.

-> What the heck do these other ATI extensions do? There is only one way to find out ...

:)
 
Last edited:
That's pretty cool!

I'm just taking a wild guess, but are you using a meta surface of some kind for the visulation?
 
It is an iso-surface. This is a surface that is created when a variable (such as air pressure or density or temperature) is held constant. In this case, the variable is azimuthal vorticity.
 
Images

Images

Grrr. I cannot figure out how to post images. I tried the "img /img" tags and it does not look like it works.

Anyway, here are 3 shots of the vortex from the fuel injector. It is zoomed in so you can only see 90 deg. of it so that Truform becomes more apparant.

No Truform:
vwp


Truform Level 5, Quadratic normals, Cubic points
vwp


Truform Level 5, Linear normals, Cubic points
vwp
 
Last edited:
Hmm...I can't seem to see those photos...I log into Yahoo! but it tells me I've reached a restricted area.

It's very exciting to see TRUFORM used in the SciVis space. We're seeing growing application of TRUFORM to areas outside of games, including some researchers at Kyushu University in Japan who are applying PN Triangles to cloth simulations.

Have you thought of reducing the amount of vertices in the input data in such a way that the PN Triangles interpolated the dataset? I can't see the images, so I don't know the nature of your data, but this may be one way to effectively compress the data and improve performance. Are you also using ATI_vertex_array_object? If not, it's probably worth experimenting with by creating one VAO per time step. For more on VAO, see our white paper.

-Jason
 
My mistake. I forgot to open it up for public consumption. I have corrected that.

Yes, I plan to decimate the surface and see how Truform handles it.
 
<EDIT #1>
O.K. I admit it. I goofed when I ran these numbers. I ran them on a Pentium 3 700E that was not overclocked to 933 as it was when I started this thread. I will rectify this when I get home.
</EDIT #1>

O.K. I reduced the number of vertices and triangles by 50%. The results were stunning.

TruForm OFF: 88.5 fps (139% increase)
Truform ON:
Triangle Level 0: 47.0 fps (32% increase)
Triangle Level 1: 37.5 fps (67% increase)
Triangle Level 2: 22.5 fps (67% increase)
Triangle Level 3: 16.2 fps (66% increase)
Triangle Level 4: 11.5 fps (70% increase)
Triangle Level 5: 8.42 fps (62% increase)

It appears that the 8500 was geometry bound. Just look at that 139% increase! Everywhere else was a 60% increase over the prior scores. (I cannot explain why Level 0 showed only a 32% increase. That mystifies me.)

Now the question is:

Does the quality of Truform at Level 1 for a model 50% its original size equal, surpass, or fall short of the quality of the original model? After all, they both have about the same framerate.

You can judge the answer for yourself.

Here is the 50% model with no Truform.
vwp


Here is the 50% model with Truform Level = 1. Obviously, the image quality is much better now. Rember that this gets about 37.5 fps.

vwp


Here is the original model with no Turform (37.5 fps). The angle is slightly different than the one above.

vwp


Personally I think that the image quality is about the same, or slightly better.

Still Future Work:

-> How does the 8500 perform at work on the dual 1.7 GHz machine?

-> Using vertex_array_object per JasonM's suggestion.
 
Last edited:
Well, I installed my Radeon 8500 on the Dell 530 (dual 1.7 GHz Xeon) and tried my program. The results were dissappointing.

Full model: 62 fps for the 8500
Full model: 142 fps for the Quadro 2 Pro

Half model: 90 fps for the 8500
Half model: 220 fps for the Quadro 2 Pro

The 8500 was a bit flaky. The animation would stutter at the beginning for either model (20~40 fps), then blaze away at the speeds quoted above. Moving the graphics window or overlaying it with another window would cause it to stutter again, before it picked up speed. This does not happen with the Quadro 2 Pro.

Installation issue? Driver issue? Who knows. When I first tried it, the program ran dog slow (~20 fps). I recompiled the program and all it did was crash. I recompiled the GUI library and got the results above. If I had had time to recompile the GLUT library, then maybe it would have worked better.

But this exercise made me realize one mistake I made in my previous post. Check the EDIT section for details.
 
Until you're using VAO, I'd hesitate to draw a lot of conclusions about geometry performance, especially given the amount of unique data you're chewing through frame to frame.

-Jason
 
One thing I noticed in your numbers comparison is that you are comparing the 8500 against a Quadro. For a lot of things, this will give you a reasonable comparison. Unfortunately, in this case, I think you are relying pretty heavily on what are sometimes considered workstation features. This is where the Quadro really ought to be compared against an 8800 instead.

The main thing I noticed is that you seem to be using GLUI for your UI, and it relies on features like bitmaps that are often considered workstation features. Disabling those features, for a build might give you a better idea of how the other aspects of performance stack up.

Outside that, you may want to look at how you feed geometry to the card. Jason mentioned something about this with regard to a specific extension, but applies in a more general sense.

-Evan
 
just to change the subject

just to change the subject

you guys deal with OpenGL coding right?? ok i need your help by identifiying a bug i get with my Radeon 8500 in GTKRadiant i made a thread about it to try and collect more data on it so i could help the GTKRadiant dev guys find some help working around it

heres the thread

http://www.rage3d.com/board/showthread.php?threadid=33601993

i have an image link there which shows the problem i encounter i reckon its to do with the lacking OpenGL implementation in the 8500's OpenGL driver but i might be wrong, and if any of u guys could perhapse help the GTKRadiant guys fix this they'd be very happy to give you any info u need

www.qeradiant.com

but lots of people using the 8500 cards are suffering this problem and it seems to be the same on all computers that have used a Radeon 8500 and GTKRadiant
 
Last edited:
You must log in or register to reply here.
Back
Top