File: README

package info (click to toggle)
illuminator 0.8.9-2
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 2,076 kB
  • ctags: 352
  • sloc: sh: 8,535; ansic: 4,589; makefile: 241
file content (40 lines) | stat: -rw-r--r-- 2,040 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

		 Illuminator Distributed Visualization Library

				  Adam Powell

				 May 11, 2001

This is a quick hack put together to graph 3-D distributed arrays' iso-contour
surfaces using Geomview.  It is not at all "complete", rather a first cut, for
example, it computes triangle locations in parallel, but then rather
inefficiently gathers all of the triangles in the entire system to one node for
rendering and viewing.  A future version (someday) will redistribute the
triangles from the processor where the data live to the processor(s) where it
will be rendered, so the image can be divided into pieces and rendered in
parallel.

Long-term, there are other nice 3-D viewers out there such as Data Explorer
from IBM, MayaVi, etc., some kind of unified front end to them would be nice.
Furthermore, with parallel array storage, much more powerful parallel
visualization concepts are possible.  Like if we can assign to each point a
certain luminoscity and transparency, it's easy to integrate those values along
a line through the locally-stored part of the array to produce a total
transparency and luminoscity for that line in the local array, then just
combine that with other line integrals through the other local sections, and we
have generated a total image in parallel.  So then we have to decide where to
put the lines, and do that with one line per pixel, with the lines converging
for persective, and two sets of such lines for stereo imaging, etc.  Or
multiple sets of lines for flat 3-D displays...

So there's lots of fun stuff we can do with this.  But for now, this humble
beginning.  Share and enjoy.

BUGS:

If an isoquant surface happens to exactly intersect one or more of the
vertices, the triangles on the adjacent tetrahedra may be generated with
coordinates "nan nan nan".  This is a problem, and I'll try to figure out a
solution at some point.  In the meantime, the workaround is to choose a
slightly different isoquant surface value to avoid the intersection (e.g. if
1000 intersects a vertex, then try 999.999).