Real time ray tracing
Jennifer Stewart
Many 3D modeling/animation programs have Render Preview options, letting
you see an approximation of the final render to give you quick feedback as
you make changes in the scene. Are any of these renders ray traced? Are
there any real time (or close to real time) ray tracers in commercial
animation software?
Also, if you were doing a study of the major 3D modeling/animation
packages out there, which would you include? So far I'm considering:
3D Studio
Alias/Maya
SoftImage
Bryce
What am I missing? (I'm only interested in major, well-known packages) My
specific interest is the tools these provide for editing the lighting in a
scene.
Thanks,
Jen
*********
Master's Student in Computer Science, Brown University
www.cs.brown.edu/people/jks
James Parks
Jennifer Stewart wrote:
>
> Many 3D modeling/animation programs have Render Preview options, letting
> you see an approximation of the final render to give you quick feedback as
> you make changes in the scene. Are any of these renders ray traced? Are
> there any real time (or close to real time) ray tracers in commercial
> animation software?
>
> Also, if you were doing a study of the major 3D modeling/animation
> packages out there, which would you include? So far I'm considering:
>
> 3D Studio
> Alias/Maya
> SoftImage
> Bryce
>
> What am I missing? (I'm only interested in major, well-known packages) My
> specific interest is the tools these provide for editing the lighting in a
> scene.
Render previews are mainly to check how the animation looks at speed,
not how the final product will look. Final look can be determined by
rendering specific single frames. A raytraced preview kind of defeats
the purpose of a preview.
Well, as you probably know, ray tracing is severly computer intensive. I
know that 3DS MAX will give you shaded previews.
Animation packages?
Don't forget ElectricImage - used widely in TV production, Mac based
Houdini - many people swear by it, UNIX based
Sumatra - I don't think it's out yet. Next gen SoftImage|3D
James Parks
http://www.geocities.com/SoHo/Studios/1486
Mike K
Jennifer Stewart wrote:
> Are there any real time (or close to real time) ray tracers in commercial
> animation software?
Depends :-) "Ray tracing" is a very generic term that covers a large
variety of techniques. The capabilities of the hardware you are on, and
which particular features you desire, will determine how fast the scene
renders. The latest crop of 3D games could be considered the simplest
"ray-tracing" renderers, with minimal features, and they're pretty close
to real time on PC's. Perhaps you should make a list of what particular
features you are interested in and post it for comment.
> What am I missing?
You missed Lightwave, from Newtek (http://www.newtek.com/)
Mike :-)
Roger A. Moncrief
Jennifer Stewart wrote:
>
> Many 3D modeling/animation programs have Render Preview options, letting
> you see an approximation of the final render to give you quick feedback as
> there any real time (or close to real time) ray tracers in commercial
> animation software?
>
> packages out there, which would you include? So far I'm considering:
>
> 3D Studio
> Alias/Maya
> SoftImage
> Bryce
>
> What am I missing? (I'm only interested in major, well-known packages) My
> specific interest is the tools these provide for editing the lighting in a
> scene.
>
> Jen
>
> *********
>
> Master's Student in Computer Science, Brown University
> www.cs.brown.edu/people/jks
Jen,
You might want to check out Imagine for Windows and trueSpace. Check my
reviews if you are unfamiliar with those applications. Hope this helps.
Good luck.
--
Roger A. Moncrief
http://www.indrev.com
Indepth Reviews
Indepth reviews of WinImages, trueSpace 3.1, Imagine for Windows, Ray
Dream Studio 4.1, Bryce 2, World Construction Set 2, Detailer, Goo,
Click & Create, CourseWorks 3.2 CBT, Desktop Support Factory, 3D Deck,
Kitchen & Bath, etc. on line now. Animated Communications' 3D
Choreographer in work. All pages enhanced with music by the Keyboard
Wizard.
Twyst
>Depends :-) "Ray tracing" is a very generic term that covers a large
>variety of techniques. The capabilities of the hardware you are on, and
Uhm... This is NOT true. Ray-tracing is a very SPECIFIC technique, with
different algorithms.
Raytracing is where you trace the path of a "ray" from the viewer's eye to
the object.
>which particular features you desire, will determine how fast the scene
>renders. The latest crop of 3D games could be considered the simplest
>"ray-tracing" renderers, with minimal features, and they're pretty close
Again, this is not Ray-tracing. It's called "texture-mapped polygons" No
raytracing is involved. Most commercial modellers will give you a preview in
the polygon method, and use a method of rendering called "Scanline" -- It
"scans" the scene line-by-line, and checks for intersections according to a
Z-Buffer( how it tells where each object is in relation to the front of the
scene ). OpenGL is a method of doing this. Note, please, that for all the
fancy reflections and other stuff, those are "faked", with the computer
calculating how a "reflection map" gets distorted. This is faster, IMHO,
than actually doing the calculations to check the "real" reflection. Most
Commercial modellers, such as 3dsMax, are strictly "mesh" based, whereas
most raytracers, such as Pov-Ray, are mathematical surfaces. A sphere
rendered in 3dsMax NEVER looks as good as a sphere rendered in Pov-Ray, due
to this fact. The "mesh" sphere is jagged.
The major reason that raytracing isn't commercially used, is the speed
factor. Scanline rendering is FAR faster than raytracing. It's a simple
matter of economics. "If I can render THIS many frames of an animation in
THIS length of time using scanline, and it takes twice as long to do it
raytraced, then I can produce faster using scanline."
At the current stage of technology, it's practically impossible to get
"real-time" raytracing. I suspect you might have to be stuck with polygon
meshes, and scanline rendering, although they aren't real-time either.
>to real time on PC's. Perhaps you should make a list of what particular
>features you are interested in and post it for comment.
Twyst================================
EFnet and NewNet #povray Channel Operator
Website: http://www.geocities.com/~twystedmynd
E-Mail: tw...@v-wave.com
=====================================
Mark Whitney
:
:
>Also, if you were doing a study of the major 3D modeling/animation
>packages out there, which would you include? So far I'm considering:
>3D Studio
>Alias/Maya
>SoftImage
>Bryce
>What am I missing? (I'm only interested in major, well-known
>packages) My specific interest is the tools these provide for editing
>the lighting in a scene.
>Thanks,
>Jen
Well, you missed mentioning Lightwave altogether for one thing, but
there are several more packages out there. Finding out what those are
should be part of your research obviously.
You could probably leave out Bryce though, or at least don't put it in
the same category as the items listed.
M.
(Around PM on 04/29/98)
(Please remove the obvious spam bait items in my address
if they appear should you like to reply to me privately.)
---
~ CMPQwk 1.42.6- California raisin murdered: Cereal Killer suspected!
John Reidar Mathiassen
Not to mention LightWave from NewTek. One of the most popular 3D packages
for commercial CG.
John Reidar
Jennifer Stewart wrote in message ...
>Many 3D modeling/animation programs have Render Preview options, letting
>you see an approximation of the final render to give you quick feedback as
>you make changes in the scene. Are any of these renders ray traced? Are
>there any real time (or close to real time) ray tracers in commercial
>animation software?
>
>Also, if you were doing a study of the major 3D modeling/animation
>packages out there, which would you include? So far I'm considering:
>
>3D Studio
>Alias/Maya
>SoftImage
>Bryce
>
>What am I missing? (I'm only interested in major, well-known packages) My
>specific interest is the tools these provide for editing the lighting in a
>scene.
>
>Thanks,
>Jen
>
Rarius
>Many 3D modeling/animation programs have Render Preview options, letting
>you see an approximation of the final render to give you quick feedback as
>you make changes in the scene. Are any of these renders ray traced? Are
>there any real time (or close to real time) ray tracers in commercial
>animation software?
>
>Also, if you were doing a study of the major 3D modeling/animation
>packages out there, which would you include? So far I'm considering:
>
>3D Studio
>Alias/Maya
>SoftImage
>Bryce
>
>What am I missing? (I'm only interested in major, well-known packages) My
>specific interest is the tools these provide for editing the lighting in a
>scene.
You forgot to mention POVRay. Although it is freeware, it is one of the best
true raytracers around... Many of the other packages 3DS, Lightwave etc are
not true raytracers, but hybrid renderers. POVRay is free (as I said) and
has a large userbase, probably larger than any other package.
For an example of POV lighting have a look at these piccies...
http://home.totem.co.uk/PhilipC/Gallery.htm
In POV you can position light sources, specify spotlights (width and
falloff), atmospheric interaction, distance falloff, reflection, two types
of highlight, surface roughness... the list goes on and on... Give it a
go...
Rarius
i...@direct-web.net
On Wed, 29 Apr 1998 18:45:41 -0700, "Twyst" <sirt...@hotmail.com>
wrote:
>Uhm... This is NOT true. Ray-tracing is a very SPECIFIC technique, with
>different algorithms.
>Raytracing is where you trace the path of a "ray" from the viewer's eye to
>the object.
>Again, this is not Ray-tracing. It's called "texture-mapped polygons" No
>raytracing is involved. Most commercial modellers will give you a preview in
>the polygon method,
Try in Gourard or flat shading.. polygon method means nothing.
>ad use a method of rendering called "Scanline" -- It
>"scans" the scene line-by-line, and checks for intersections according to a
>Z-Buffer( how it tells where each object is in relation to the front of the
>scene ). OpenGL is a method of doing this.
>Note, please, that for all the fancy reflections and other stuff, those are "faked",
>with the computer calculating how a "reflection map" gets distorted.
No. Thy're not. On a scanline renderer you fake it, and even on a ray
traced render you fake it, just different ways of faking it. Do you
use radiousity after yout do a raytraced render? If no, then you're
still faking.
> This is faster, IMHO,
>than actually doing the calculations to check the "real" reflection.
There is no 'real' reflection. Except to rebuild the universe yourself
(taking an infinite amount of time, energy, patience and power),
you're just faking it.
> Most Commercial modellers, such as 3dsMax, are strictly "mesh" based, whereas
>most raytracers, such as Pov-Ray, are mathematical surfaces.
Excuse me? POV-Ray has to convert mathmatical surfaces to poly's even
if the polys are as low as pixel leve, you still get quantization. As
to meshes, they're trade offs. Exchange a complex mathematical formula
(I want to see the full set of differentail functions used to create a
frog). When you use a mesh, you expect to to totally distort and
disrupt a mathematical surface.
>A sphere rendered in 3dsMax NEVER looks as good as a sphere rendered in Pov-Ray, due
>to this fact. The "mesh" sphere is jagged.
Sorry. I have seen sphere's as good or better, it's a matter of how
much memory and time you have.
>The major reason that raytracing isn't commercially used, is the speed
>factor.
BWAHHHHHH! Sorry hans, you don't get the chevette, would you like to
go for the $200? It isn't commerially used? Where have you been?
Lesse... Softimage, Lightwave, Max 1/2, Animation Master,
Truespace..do I need go on (Blue Sky uses it extensively for things
like 'Joe's Apartment' etc.)
>Scanline rendering is FAR faster than raytracing. It's a simple
>matter of economics. "If I can render THIS many frames of an animation in
>THIS length of time using scanline, and it takes twice as long to do it
>raytraced, then I can produce faster using scanline."
Yes, that's how it was, but now that the hardware has increased enough
in speed, many implementations of RT are in use and will be even
moreso.
>At the current stage of technology, it's practically impossible to get
>"real-time" raytracing. I suspect you might have to be stuck with polygon
>meshes, and scanline rendering, although they aren't real-time either.
It depends on your scene, the amount of reflection, refraction and
movement.
>>to real time on PC's. Perhaps you should make a list of what particular
>>features you are interested in and post it for comment.
Or study some of the webpages first, then come back with questions.
remove the spam from my email box to speak with me.
http://www.fortunecity.com/skyscraper/tyrell/71 The WebChicken Page
http://www.geocities.com/researchtriangle/8064
http://gfxfan.home.mindspring.com
Henri Sivonen
In article <Pine.SOL.3.96.980429145000.6956A-100000@kato>, Jennifer
Stewart <j...@cs.brown.edu> wrote:
>Are
>there any real time (or close to real time) ray tracers in commercial
>animation software?
You may want to check out a real time or almost real time raytraced
non-commercial interactive *demo* called RayTime at :
http://subway.student.utwente.nl/~ramig/RayTime.html
(If you don't have the required OS, you can at least have a look at the
screenshots.)
--
Henri Sivonen
hen...@clinet.fi
WWW: http://www.clinet.fi/~henris/
Larry Gritz
In article <6i8hpe$nr...@crash.videotron.ab.ca>,
Twyst <sirt...@hotmail.com> wrote:
>Again, this is not Ray-tracing. It's called "texture-mapped polygons"
Texture mapped polygons are a geometric description, not a rendering
method. You can raytrace polygons, run them through a scanline
renderer, whatever. They have nothing to do with each other.
> use a method of rendering called "Scanline" -- It
>"scans" the scene line-by-line, and checks for intersections according to a
>Z-Buffer( how it tells where each object is in relation to the front of the
>scene ). OpenGL is a method of doing this.
"Scanline" refers to an entire family of algorithms. Though z-buffer
is sometimes colloquially referred to as scanline, many people would
say that it more properly belongs to the "object-order" family of
hidden surface algorithms. (N.B. this classification is a little
fuzzy, since most z-buffer scan converters do exploit scanline
coherence within a triangle, but not over the entire scene.)
OpenGL is not a rendering method at all, but rather a rendering API.
It's popular for talking to z-buffer polygon scan converters (and IMHO
is poorly designed inasmuch as it exposes too much of underlying
implementations), but it's primarily a way of *talking* to renderers,
not a rendering method.
If you're going to be pedantic, get it right.
-- lg
--
Larry Gritz Pixar Animation Studios
l...@pixar.com Richmond, CA
Andrew M
Mike Weber wrote:
>
> I think sPatch does it using OpenGL
>
> Mike
> >
> >
> >Care to give some examples? Saying "certain apps" isn't specific enough for
> >me to go and look them up.
> >=)
That really couldn't be raytracing, for one, it would be way too
cpu-intesive to convert the biezer(spelling?) curves to triangles or
whatever, plus raytrace, in real time. Besides, it would be rather
overkill, considering you can't change textures or finishes. AFAIK,
opengl doesn't even allow raytracing.
Andrew McDavid
Twyst
John Nagle wrote in message ...
>"AndyM" <an...@genetics.co.uk> writes:
>>Twyst wrote in message <6i8hpe$nr...@crash.videotron.ab.ca>...
>
>>>At the current stage of technology, it's practically impossible to get
>>>"real-time" raytracing. I suspect you might have to be stuck with polygon
>>>meshes, and scanline rendering, although they aren't real-time either.
>
>>Wake up and smell the coffee my friend...
>>We're there.... It'll start to arrive in certain apps this year..
>
> Softimage has demonstrated real-time Mental Ray ray-tracing.
>It was announced at SIGGRAPH last year. You slave a whole render
>farm to one workstation, and the perspective window in Softimage
>is rendered in real time, assuming your render
>farm is big enough. You may need 50-100 computers, but for some
>production shops, it's a worthwhile expenditure.
>
> John Nagle
Uhm.. Please note.. I said PRACTICALLY impossible. for (rough estimate, I
could be wrong) about %80 of the users, that is just not practical.
As a ( badly skewed, but nonetheless valid) example:
How many people in this newsgroup have:
a) access to 50-100 computers
b) can afford to run them as a renderfarm?
There may be universities with this many computers, but they can't afford to
run them as renderfarms.
By practical, I meant "for the average user". I guess I should have stated
that.
Bear in mind, as well, that that isn't really a breakthru.. Throw enough
CPUs at anything, and it'll get unbelievably fast.
Twyst
(Diagnosed with podiamastication) =)
Mike K
Twyst wrote:
> ... snipped good stuff here ....
> Again, this is not Ray-tracing. It's called "texture-mapped polygons"
> ... snipped good stuff here ....
That's my point exactly, any discussion of "real-time raytracing" needs
to _exactly_ define what particular effects, algorithms, etc. are
desired, or we're all going to get bogged down in a big flame war over
terminology.
Mike :-)
Paul Miller
l...@pixar.com (Larry Gritz) writes:
>OpenGL is not a rendering method at all, but rather a rendering API.
>It's popular for talking to z-buffer polygon scan converters (and IMHO
>is poorly designed inasmuch as it exposes too much of underlying
>implementations), but it's primarily a way of *talking* to renderers,
>not a rendering method.
Sort of an oxymoron, since it was *designed* to be an interface to graphics
hardware. If anything its the hardware implementations that are a result
of the OpenGL API itself.
>If you're going to be pedantic, get it right.
Agreed.
--
Paul T. Miller | pa...@elastic.avid.com
Principal Engineer | Opinions expressed here are my own.
Avid Technology, Inc. Madison - Graphics and Effects Software Group
AndyM
Twyst wrote in message <6i8hpe$nr...@crash.videotron.ab.ca>...
>At the current stage of technology, it's practically impossible to get
>"real-time" raytracing. I suspect you might have to be stuck with polygon
>meshes, and scanline rendering, although they aren't real-time either.
Wake up and smell the coffee my friend...
We're there.... It'll start to arrive in certain apps this year..
AndyM
Peter Yu
A long time ago, on a computer far, far away... "Twyst"
<sirt...@hotmail.com> wrote:
>Again, this is not Ray-tracing. It's called "texture-mapped polygons" No
>raytracing is involved. Most commercial modellers will give you a preview in
>the polygon method, and use a method of rendering called "Scanline" -- It
>"scans" the scene line-by-line, and checks for intersections according to a
>Z-Buffer( how it tells where each object is in relation to the front of the
>scene ). OpenGL is a method of doing this. Note, please, that for all the
>fancy reflections and other stuff, those are "faked", with the computer
>calculating how a "reflection map" gets distorted. This is faster, IMHO,
>than actually doing the calculations to check the "real" reflection. Most
>Commercial modellers, such as 3dsMax, are strictly "mesh" based, whereas
>most raytracers, such as Pov-Ray, are mathematical surfaces. A sphere
>rendered in 3dsMax NEVER looks as good as a sphere rendered in Pov-Ray, due
>to this fact. The "mesh" sphere is jagged.
This is true. But, there are advantages to meshes. They can be
easily modified, but were started in the general shape of a sphere.
>The major reason that raytracing isn't commercially used, is the speed
>factor. Scanline rendering is FAR faster than raytracing. It's a simple
>matter of economics. "If I can render THIS many frames of an animation in
>THIS length of time using scanline, and it takes twice as long to do it
>raytraced, then I can produce faster using scanline."
Actually, I think Lightwave does raytrace (anyone know for sure?). I
know for sure Truespace (a less known animation package) does do
raytracing.
>At the current stage of technology, it's practically impossible to get
>"real-time" raytracing. I suspect you might have to be stuck with polygon
>meshes, and scanline rendering, although they aren't real-time either.
Realtime raytracing will probably involve things like 500 TFLOPS
processors, and super fast I/O buses, etc.
--
Peter Yu
Email: None.
"I may be surrounded by insanity, but I'm not insane."
John Nagle
"AndyM" <an...@genetics.co.uk> writes:
>Twyst wrote in message <6i8hpe$nr...@crash.videotron.ab.ca>...
>>At the current stage of technology, it's practically impossible to get
>>"real-time" raytracing. I suspect you might have to be stuck with polygon
>>meshes, and scanline rendering, although they aren't real-time either.
>Wake up and smell the coffee my friend...
>We're there.... It'll start to arrive in certain apps this year..
Softimage has demonstrated real-time Mental Ray ray-tracing.
John Nagle
>>It was announced at SIGGRAPH last year. You slave a whole render
>>farm to one workstation, and the perspective window in Softimage
>>is rendered in real time, assuming your render
>>farm is big enough. You may need 50-100 computers, but for some
>>production shops, it's a worthwhile expenditure.
>> John Nagle
>Uhm.. Please note.. I said PRACTICALLY impossible. for (rough estimate, I
>could be wrong) about %80 of the users, that is just not practical.
>As a ( badly skewed, but nonetheless valid) example:
> How many people in this newsgroup have:
>a) access to 50-100 computers
>b) can afford to run them as a renderfarm?
>By practical, I meant "for the average user". I guess I should have stated
>that.
>Bear in mind, as well, that that isn't really a breakthru.. Throw enough
>CPUs at anything, and it'll get unbelievably fast.
Actually, being able to apply a large number of non-shared-memory
computers to a single render with decent latency is a neat trick.
In three years, many animators will have 4-processor
Merced machines doing this, I expect. It's great if you're trying to
get the final appearance of something right.
John Nagle
Animats
Absolutely Barking Stars
On Thu, 30 Apr 1998 23:10:21 -0700, "Twyst" <sirt...@hotmail.com>
wrote:
>> Softimage has demonstrated real-time Mental Ray ray-tracing.
>>It was announced at SIGGRAPH last year. You slave a whole render
>>farm to one workstation, and the perspective window in Softimage
>>is rendered in real time, assuming your render
>>farm is big enough. You may need 50-100 computers, but for some
>>production shops, it's a worthwhile expenditure.
>> John Nagle
>Uhm.. Please note.. I said PRACTICALLY impossible. for (rough estimate, I
>could be wrong) about %80 of the users, that is just not practical.
>As a ( badly skewed, but nonetheless valid) example:
> How many people in this newsgroup have:
>
>a) access to 50-100 computers
>b) can afford to run them as a renderfarm?
>By practical, I meant "for the average user". I guess I should have stated
>that.
>Bear in mind, as well, that that isn't really a breakthru.. Throw enough
>CPUs at anything, and it'll get unbelievably fast.
Well, that point is true, but i would say that the computer I am
typing this on has roughly 100 times more memory *and* runs at 100
times the clock speed of the one I owned 10 years ago. It is too
fanciful to suggest that in 10 years time an equal advance may have
been made? In which case, we will probably see real-time raytracing
capable computers (at least VERY expensive ones) within, say, 5 years?
TTFN
Jon
Carsten Whimster
>Also, if you were doing a study of the major 3D modeling/animation
>packages out there, which would you include? So far I'm considering:
>
>3D Studio
>Alias/Maya
>SoftImage
>Bryce
I would replace Bryce with RayDream Studio 5, unless you are interested in
landscape creation... It is a neat package, but not really in the same
league as Maya :)
--
C a r s t e n W h i m s t e r
bcrwhims AT uwaterloo DOT ca
Michael S. Flynn
<<In which case, we will probably see real-time raytracing capable computers
(at least VERY expensive ones) within, say, 5 years?>>
This would be cool, but I don't think it's likely given the current CPU
technology. In order to be faster, pathways have to be smaller/closer
together since it takes time, no matter how small a fraction of a second,
for electrons to travel any given distance, no matter how short.
While multiple CPU systems might approach the needed number-crunching, I
think that in order to have a true real-time ray tracer you would to have
multiple single-function CPUs. There are chips being produced that can do 1
trillion calculations/second, but they only do 1 or a few calculations. Make
a separate CPU for each function of a ray tracer, and maybe you could get
close to real time.
(Real time to me means instantaneous screen redraws at any color depth and
any screen resolution)
sav...@sagelink.net
Michael S. Flynn wrote:
> While multiple CPU systems might approach the needed number-crunching, I think that in order to have a true real-time ray tracer you would to have multiple single-function CPUs. There are chips being produced that can do 1 trillion calculations/second, but they only do 1 or a few calculations. Make a separate CPU for each function of a ray tracer, and maybe you could get close to real time.
(Real time to me means instantaneous screen redraws at any color depth
and any screen resolution)
>
Just an item I found surfing about... ah, progress ;)
AP
27-MAR-98
HAIFA, Israel (AP) One day, Israeli physicist Uri Sivan hopes to meet a
colleague's 40-year-old challenge to store all the texts of the Library
of Congress 17 million books along 500 miles of shelves on a space the
size of a speck of dust.
Sivan says while that day is still far off, he and two fellow
researchers have made progress by mixing biology and electronics for the
first time letting DNA molecules build electronic circuits.
"We are using the same machinery used in biology. We are taking
advantage of 4.5 billion years of evolution and letting the DNA do most
of the work," Sivan said as he fiddled with the espresso machine in his
office at the Technion, one of Israel's premier research institutes
located in the hills above Haifa Bay.
In a first step, the research team Sivan, chemist Yoav Eichen and
biophysicist Erez Braun has produced a conductive wire that is
one-thousandth the width of a hair, or less than half the size of wires
in use today.
The Technion team hopes to build a wire that is 250 times smaller than
the existing ones.
The implications are as far reaching as the proportions are
microscopic. A microchip assembled with DNA could create faster,
cheaper and more complex computers and electronic products. A computer
built with DNA-made microchips could store 100,000 times as much
information as a current model.
The process of building a microchip with DNA begins the same way an
ordinary chip is built. However, single strands of DNA molecules are
attached to the gold electrodes that are traditionally used as
connectors.
In the lab, Braun played a video of the experiment taken through a
microscope. The footage showed the molecules of the DNA strand quickly
recognizing each other and attaching to the two electrodes to create a
bridge.
To make the bridge conduct electricity, a thin layer of silver was
added onto the structure, resulting in a tiny metal wire.
The Technion team's work was published in the Feb. 19 issue of the
science journal Nature and their conceptual breakthrough in the field of
nanoelectronics has won praise from U.S. colleagues.
"This will likely be viewed as the paper that set us off down the
road," said Daniel Colbert of Rice University's Center for Nanoscale
Science and Technology in Texas.
The idea to harness the self-assembling abilities of tiny DNA molecules
to create electronic circuits was the result of ongoing conversations
between the three Technion colleagues.
"We came up with the idea over lots of coffee, liters (gallons) of
coffee," said Sivan.
"Mega liters of coffee," joked Braun. The team said the research is
still in its infancy, and they have far to go before meeting a 1958
challenge by a colleague, Nobel Laureate Richard Feynman, to store the
Library of Congress on a speck of dust.
"We have shown that DNA molecules can be effectively used as organizers
for the simplest electronic component, a conducting wire," said Eichen.
"The next step is a self-assembled transistor 100 times smaller than
those used in present microchips," he added.
Theran Cochran
[snip nifty article about self assembling circuits]
What's the URL for this article? Really cool.
--
Theran Cochran - the...@geocities.com
http://www.geocities.com/SiliconValley/Way/8201
Matthew Mc Clement
Peter Yu wrote:
*snip*
>
> Actually, I think Lightwave does raytrace (anyone know for sure?). I
> know for sure Truespace (a less known animation package) does do
> raytracing.
>
Yup, Lightwave does, and so does 3dsMax2 although lots of people arn't to happy with it.
It sorta like:
Raytrace? Yes
Anti-Aliasing? Yes
Goes and does the raytracing.
Not much to configure eh?
Cheers, Matthew
Alex Segal
> While multiple CPU systems might approach the needed number-crunching,
I
> think that in order to have a true real-time ray tracer you would to have
> multiple single-function CPUs. There are chips being produced that can do
1
> trillion calculations/second, but they only do 1 or a few calculations.
Make
> a separate CPU for each function of a ray tracer, and maybe you could get
> close to real time.
Look at http://www.art.co.uk they are doing a "raytracing chip". Some time
ago they said it is almost realtime.
Johannes Hubert
Mike Weber wrote in message <6ib2ro$k5o$1...@hops.adnc.com>...
>I think sPatch does it using OpenGL
Nope. sPatch does use OpenGL all right, but OpenGL does not use raytracing.
Johannes.
Phil Captain 3D McNally
>>Wake up and smell the coffee my friend...
>>
>>We're there.... It'll start to arrive in certain apps this year..
>>
>>AndyM
>
>
>Care to give some examples? Saying "certain apps" isn't specific enough for
>me to go and look them up.
Just what I was thinking.
I use Cinema 4D XL which is recognised as one of the fastest raytracers
around (it also has a scanline renderer). I remember hearing they (Maxon)
ran it on some 20 processor beast (I forget what) and managed 4fps
raytraced 320 x 240 (I think).
So I think that we are not quite there yet. Still if you want to test this
super fast render have a look at the demo.
Phil 3D
Fabien Mosen
>The major reason that raytracing isn't commercially used, is the speed
>factor.
have a look at www.bluesky.com for commercial raytracing...
Cheers,
Fabien.
Fish
Alex Segal wrote:
realtime raytracing what ? A sphere and a cube wouldn't be so hard to
get raytraced realtime. But
add a few hairy monkeys, and maybe a dozen elephants and hippo's, doing
the macarena together in the rain, splashing their feet in
muddy waterpools in a street filled with reflecting windows...well I
don't think I'll be alive to see that being raytraced realtime ....:-)
best ,
--
RONALD VAN VEMDEN
CYBERFISH LABORATORIES
3D animation & computergraphics
http://www.cyberfish.nl
Taps
Fish wrote:
>
> Alex Segal wrote:
>
> > > While multiple CPU systems might approach the needed
> > number-crunching,
> > I
> > > think that in order to have a true real-time ray tracer you would to
> > have
>
> realtime raytracing what ? A sphere and a cube wouldn't be so hard to
> get raytraced realtime. But
> add a few hairy monkeys, and maybe a dozen elephants and hippo's, doing
> the macarena together in the rain, splashing their feet in
> muddy waterpools in a street filled with reflecting windows...well I
> don't think I'll be alive to see that being raytraced realtime ....:-)
> RONALD VAN VEMDEN
Within your lifetime? Perhaps. Check out the articles on quantum
computing in the latest Scientific American and Byte. We may yet
see raytracing done using quantum-level computers, which will provide
enormous speed increases.
Taps
Nick Portelli
No kidding. What are quantum computers, 6 bits or something, instead of 2.
But I doubt quantum computers are being developed for raytracing.
Nick Portelli
They actually made a prototype that worked recently. I can't remember out of
what(element, substance). Maybe the next generation of computers will be a
quantum processor and a DNA harddrive.
Taps wrote:
> As far as I understand it, quantum computers employ qubits, which
> are quantum bits whose value is both 0 and 1 in the unobserved
> coherent state which stablizes to either 0 or 1 in the observed
> decoherent state.
>
> The state of the art is currently very low-end: according to the
> SciAm article, Gershenfeld, Chuang, and Kubinec built a two-bit
> quantum computer that could search a four-item database.
>
> They state that the speed of a quantum computer depends on
> the speed of the nuclear spins of atoms, which range from
> several to 100 Hz. Although this is slow compared to a
> silicon chip, the parallelism of a quantum machine lets it
> do tasks a billion times faster. Since raytracing is ideally
> suited for parallel computing, quantum computing could play
> a large role in it.
>
> A pixel grid made of qubits would, in its coherent state, contain
> every possible picture (there was an old Omni magazine article about
> such
> a machine). The desired image would emerge when the state became
> decoherent.
>
> Taps
Taps
As far as I understand it, quantum computers employ qubits, which
are quantum bits whose value is both 0 and 1 in the unobserved
coherent state which stablizes to either 0 or 1 in the observed
decoherent state.
The state of the art is currently very low-end: according to the
SciAm article, Gershenfeld, Chuang, and Kubinec built a two-bit
quantum computer that could search a four-item database.
They state that the speed of a quantum computer depends on
the speed of the nuclear spins of atoms, which range from
several to 100 Hz. Although this is slow compared to a
silicon chip, the parallelism of a quantum machine lets it
do tasks a billion times faster. Since raytracing is ideally
suited for parallel computing, quantum computing could play
a large role in it.
A pixel grid made of qubits would, in its coherent state, contain
every possible picture (there was an old Omni magazine article about
such
a machine). The desired image would emerge when the state became
decoherent.
Taps
Sergey Zabaryansky
Hello!
On Fri, 29 May 1998, Taps wrote:
> As far as I understand it, quantum computers employ qubits, which
> are quantum bits whose value is both 0 and 1 in the unobserved
> coherent state which stablizes to either 0 or 1 in the observed
> decoherent state.
> The state of the art is currently very low-end: according to the
> SciAm article, Gershenfeld, Chuang, and Kubinec built a two-bit
> quantum computer that could search a four-item database.
Pls, give me URL of the article about such computers.
It's very interesting.
Sergey Zabaryansky
http://www.users.lucky.net.ua/~zssoft/
[Computer Graphics] [Win32] [System Programming]