🚀 go-pugleaf

In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com (Chris Green) writes:
>
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. Given appropriate temporal filtering, and a general enough
>4-d ray-tracer, shouldn't this provide a potential for improved
>quality? Is anyone familiar with any research or applications
>of this? I'm familiar with Don Mitchell's paper on interlace
>and chroma filtering for video.
>
>
>--
>Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
>Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

Try muxing the outputs from 1000 framebuffers into a single analog stream.
I would rather pass on this approach.  The PixelFlow box captures the output 
from a composition network rated at 4 Gbytes/s into a single frambeubffer.

I don't believe this approach is truly scalable either, since its still
an example of the N to 1 mux problem.  So it is, in my opinion, contention
limited (the laws of physics won't cooperate and provide infinite digital
bus or network bandwidth).

I advocate a tessellated display approach myself, where each tessellation
element owns a processor, framebuffer, and display.  The trick is to coordinate
the system temporally.  The scalable concurrent visualization system trades
contention for asynchronous execution.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com (Chris Green) writes:
>
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. Given appropriate temporal filtering, and a general enough
>4-d ray-tracer, shouldn't this provide a potential for improved
>quality? Is anyone familiar with any research or applications
>of this? I'm familiar with Don Mitchell's paper on interlace
>and chroma filtering for video.
>
>
>--
>Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
>Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

Try muxing the outputs from 1000 framebuffers into a single analog stream.
I would rather pass on this approach.  The PixelFlow box captures the output 
from a composition network rated at 4 Gbytes/s into a single frambeubffer.

I don't believe this approach is truly scalable either, since its still
an example of the N to 1 mux problem.  So it is, in my opinion, contention
limited (the laws of physics won't cooperate and provide infinite digital
bus or network bandwidth).

I advocate a tessellated display approach myself, where each tessellation
element owns a processor, framebuffer, and display.  The trick is to coordinate
the system temporally.  The scalable concurrent visualization system trades
contention for asynchronous execution.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> Chris Green,
chrisg@cbmvax.cbm.commodore.com writes:
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. 

I can't think of anything directly related, but here are a couple 
indirectly related items:

- Many video games and other tightly coded interactive programs
use a technique called "beam chasing" to schedule screen updates
and interaction.  The idea is to be aware of the position of the
CRT beam in order to avoid writing a graphic to the screen while
the beam passes through it, producing a "tearing" effect.

- In a talk given by Pacific Data Images several years ago, one of
the developers there discussed how they produced interlaced animation
for video.  Since they knew that when the work was reproduced the odd
scanlines would appear 1/60th of a second after the even ones (or 
vice-versa, I'm not a video expert) they updated the positions of
moving objects between interlace scans.  I've also heard people say
that being aware of the interlacing is important for getting motion
blur to look correct on video.  The PDI talk was written up in a
SIGGRAPH course notes ages ago ('82 or '84; something like that).

Cheers,
jp

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11566@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
|> Try muxing the outputs from 1000 framebuffers into a single analog stream.
|> I would rather pass on this approach.  The PixelFlow box captures the output
|> from a composition network rated at 4 Gbytes/s into a single frambeubffer.
|>
|> I don't believe this approach is truly scalable either, since its still
|> an example of the N to 1 mux problem.  So it is, in my opinion, contention
|> limited (the laws of physics won't cooperate and provide infinite digital
|> bus or network bandwidth).

    PixelFlow should be extremely scalable. The composition network
has fixed bandwidth no matter how many renderers are used, and latency
due to the length of the composition network increases very slowly as
additional rendering boards are added.

    If you're referring to some other aspect, please explain in more
detail.

|> I advocate a tessellated display approach myself, where each tessellation
|> element owns a processor, framebuffer, and display.	The trick is to coordinate
|> the system temporally.  The scalable concurrent visualization system trades
|> contention for asynchronous execution.

    If you mean that each processor is responsible for a fixed screen
area, this approach wastes most of the processors when looking at
something far away. It also trades off moving pixels for moving
primitives, and moving primitives is definitely not scalable.
Pixel-Planes 5 uses a considerably more complex variant of this
decomposition and partly addresses these concerns.
--
    Jon Leech (leech@cs.unc.edu)    __@/
    "Totally bounded: A set that can be patrolled by a finite number
     of arbitrarily near-sighted policemen."    A. Wilonsky, 1978

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com
(Chris Green) writes:

>	Has anyone ever attempted to take advantage of the
>"infinite-frame-rate" of raster scan devices, particularly video?  What
>I mean by this to render your animation with the knowledge that each
>pixel is (for instance) 35ns later than the preceeding pixel, and that
>each scan-line is ~63uS later than the preceeding one. Given
>appropriate temporal filtering, and a general enough 4-d ray-tracer,
>shouldn't this provide a potential for improved quality? Is anyone
>familiar with any research or applications of this? I'm familiar with
>Don Mitchell's paper on interlace and chroma filtering for video.

Take a look at "Device Dependent Image Construction for Computer
Graphics", RV Klassen, Research Report CS-91-19, Department of Computer
Science, University of Waterloo, Waterloo, ON, Canada.  

Victor looks at how to minimize the discrepancies between a desired
image and the image generated by a display device, given a model of the
spatial and temporal intensity profiles of the device (my rough
paraphrase of one aspect of the thesis.  If I'm really not doing it
justice, I hope he'll correct me.)
--
Blair MacIntyre --- bm@cs.columbia.edu --- CS Department, Columbia University

"Men can get into shaving, because it reminds them of what stud hombres
they are, having to tame their manliness on a regular basis." - Dave Barry

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11566@sun13.scri.fsu.edu> rms@well.sf.ca.us (richard
marlon stein) writes:
...
>Try muxing the outputs from 1000 framebuffers into a single analog stream.
>I would rather pass on this approach.  The PixelFlow box captures the output 
>from a composition network rated at 4 Gbytes/s into a single frambeubffer.
>
>I don't believe this approach is truly scalable either, since its still
>an example of the N to 1 mux problem.  So it is, in my opinion, contention
>limited (the laws of physics won't cooperate and provide infinite digital
>bus or network bandwidth).

Since I work on PixelFlow, I feel compelled to comment on this.  The
PixelFlow composition network is scalable precisely because it doesn't
suffer from contention problems.  Each node composites its output with
the composited output of the nodes before it and sends it on to the
nodes after it.  It's a straight chain of boards so there is no
contention; each board dealing only with two sources for a single
pixel that it has to choose between for its single pixel output.  The
network is pixel-pipelined so adding an extra board just adds another
pixel-time's worth of latency to the composition.  The scalability
limits are not with numbers of nodes, but with display size since the
composition network speed is determined by the number of pixels you
want to push through per second.

-marc (olano@cs.unc.edu)
Grad student, University of North Carolina at Chapel Hill

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

In article <11579@sun13.scri.fsu.edu> leech@cs.unc.edu (Jon Leech) writes:
<
<In article <11566@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
<|> Try muxing the outputs from 1000 framebuffers into a single analog stream.
<|> I would rather pass on this approach.  The PixelFlow box captures the output
<|> from a composition network rated at 4 Gbytes/s into a single frambeubffer.
<|>
<|> I don't believe this approach is truly scalable either, since its still
<|> an example of the N to 1 mux problem.  So it is, in my opinion, contention
<|> limited (the laws of physics won't cooperate and provide infinite digital
<|> bus or network bandwidth).
<
<    PixelFlow should be extremely scalable. The composition network
<has fixed bandwidth no matter how many renderers are used, and latency
<due to the length of the composition network increases very slowly as
<additional rendering boards are added.
<
<    If you're referring to some other aspect, please explain in more
<detail.
<
<|> I advocate a tessellated display approach myself, where each tessellation
<|> element owns a processor, framebuffer, and display.	The trick is to coordinate
<|> the system temporally.  The scalable concurrent visualization system trades
<|> contention for asynchronous execution.
<
<    If you mean that each processor is responsible for a fixed screen
<area, this approach wastes most of the processors when looking at
<something far away. It also trades off moving pixels for moving
<primitives, and moving primitives is definitely not scalable.
<Pixel-Planes 5 uses a considerably more complex variant of this
<decomposition and partly addresses these concerns.
<--
<    Jon Leech (leech@cs.unc.edu)    __@/

I would like to PixelPlanes hammer on a 1 Terabyte dataset.  One things for sure
though, I know when I've been beat.  Since the SCVS does not "subdivide" the
screen by assigning processors to a specific region of a single display surface,
I don't think you are in a position to judge the architecture.  Ask Molnar if
he'll sign the non-disclosure agreement, and then you can judge.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

chrisg@cbmvax.cbm.commodore.com (Chris Green) writes: 

> ... render your animation with the knowledge that
> each pixel is (for instance) 35ns later than the preceeding pixel, 
> and that each scan-line is ~63uS later than the preceeding one.

forgive my being brusque: the effects of ignoring the 35 ns temporal
offset between adjacent pixels are absolutely negligible.

even the 63 us temporal offset between adjacent lines is negligible for
all practical purposes: an ever-so-slight temporal slant is introduced,
but no viewer can tell. in fact tube cameras (e.g. vidicons) have the
slant, but modern (frame-transfer) CCD cameras integrate every pixel
during the same exposure interval, and so have no V/T slant.

the effect that is NOT negligible is the exposure time with respect to the
frame time. this has to do with motion blur, but there's more to it than
that. I'm preparing a note about this, but i'll give you the teaser:

  an infinitely short exposure time is optimum to capture motion IF the
  viewer's eye, at the ultimate display device, is tracking the motion.

but if the viewer's eye is NOT tracking motion, say she's locked on the
stationary background, then you should expose for a frame time and
introduce blur, else the temporal content of the moving thing is liable to
generate spatial aliasing. 

for example, if the shot is across a street, and the viewer's eye is
dwelling on a restaurant sign, and a truck with ten-pixel-pitch black and
white stripes speeds by in front at a velocity of ten pixels per frame,
the black and white stripes will alias to become stationary if you've used
an instantaneous shutter. the viewer will judge the apparently-stationary
stripes that appeared for an instant in front of the restaurant to be an
artifact. if you integrate for a frame time, you will get the blur that
the visual system expects.

however if the viewer was eye-tracking the truck, then she will judge it
to be an artifact that the truck's stripes turned gray when it started to
move.

there is no correct solution to this problem. my belief is that the best
pragmatic solution is to integrate for a third of the frame time.

but i can't prove it.

c.

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu