Hi Stefan,
Here is another idea, suggested by Bruno. We no longer see the need for k-d
tree partitionning. Since the data is on every computer, and since the
ply file
probably has a list of triangles (specified by indices), and a list of
vertices,
why can you simply say that pipe 1 processes the first x percent, pipe 2
processes
the next y percent, etc. Our only explanation is that you want the user
to see
nice colored regions for display purposes. But for visualization purposes,
spatial coherence on each individual channel is not important.
Any comments?
Gordon
Stefan Eilemann wrote:
On 14. Jan 2008, at 17:28, Gordon Erlebacher wrote:
Hi,
I got a 3 node (2 pipes on one, 1 pipe on another), working
from my local site. Works between several HP xw6400, but not
when I include kirk (a xw9300). It has a different CPU. I'll worry
about this later.
Afaik these are all Opterons - so that shouldn't matter.
We tried the lucy.ply file. It has 14,000,000 vertices, takes 1.3 Gbytes
of memory. Could not get eqPly.64 to work.
Does it crash, or simply not respond?
We suspect that it takes
a very long time to create the k-d tree.
Could be. If you set the log level to INFO, you should see some prints
during the kd-tree creation. Once it's created, you can copy
it to all clients.
So several thoughts arise:
1) why should the entire file be on every computer? One can imagine
that people (I know some) do computations on a remote machine with
multiple CPUs and a part of their data is already on each machine.
Because it allows a simpler implementation. The data structure
allows out-of-core visualization, but nobody had the time to
implement that in eqPly yet.
We are thinking of evolving a version of eqPly into an application
(vs. example code).
2) There could be a ply preprocessor that divides the file off-line.
then reading it would be much more efficient.
Correct. Another way is to load the model on the application node
and distribute it via eqNet::Objects. Render clients would only
partially map the objects needed. This has the advantage that the
application can modify data, which is then sync'ed to the clients.
3) Have you, Stefan, or anybody, every tried very large polygonal
models?
A colleague at the University did test the David 1mm data set for a
to-be-published paper. I don't know the size for it, but maybe he'll
jump in. He'll also be able to give you a ballpark figure for the
kd-tree creation time.
Cheers,
Stefan.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
begin:vcard
fn:Gordon Erlebacher
n:Erlebacher;Gordon
email;internet:[EMAIL PROTECTED]
tel;work:(850) 644-0186
tel;fax:(850) 644-0098
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
eq-dev mailing list
[email protected]
https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
