--- In realtime_raytracing@yahoogroups.com, "MightyMartin"
<m26401122@j...> wrote:
>
>
> Hello all, let me introduce myself. My name is Martin,
> and i'm a student in a university in Indonesia. Right now,
> i'm studying Ray Tracing as my Final Project, but i can't
> find a good resource on the net. Actually, it's not the
> Ray Tracing itself that bother me (because i have already
> taken that lecture subject). It's the Cone Tracing, because
> my final project will heavily based on this optimizing-
> techniques of Ray Tracing. And it's very little resources
> on the net of the Cone Tracing. All that I know is that
> the Cone Tracing is an optimization of Ray Tracing that
> forms a cone to shoot rays instead of shoot ray to all
> direction (which waste optimization). Please for you who
> can give me a little hints about the cone tracing and the
> formula, or maybe give one or two url of good references
> of Cone Tracing on the Net. Thank you very much. I'll wait
> for your reply, guys.
>
> God bless you all,
> Martin

http://www.siggraph.org\education\materials\HyperGraph\toc.htm

> Hello all, let me introduce myself. My name is Martin,
> and i'm a student in a university in Indonesia. Right now,
> i'm studying Ray Tracing as my Final Project, but i can't
> find a good resource on the net. Actually, it's not the
> Ray Tracing itself that bother me (because i have already
> taken that lecture subject). It's the Cone Tracing, because
> my final project will heavily based on this optimizing-
> techniques of Ray Tracing. And it's very little resources
> on the net of the Cone Tracing. All that I know is that
> the Cone Tracing is an optimization of Ray Tracing that
> forms a cone to shoot rays instead of shoot ray to all
> direction (which waste optimization). Please for you who
> can give me a little hints about the cone tracing and the
> formula, or maybe give one or two url of good references
> of Cone Tracing on the Net. Thank you very much. I'll wait
> for your reply, guys.

I always get confused when speaking about "cone tracing", because some
people mean "tracing thick rays" (a method to implement anti-aliasing) where
others use it as a synonym of "beam tracing" (a method to exploit ray
coherence).

Looks like you are looking for "beam tracing". If so you should have a look
to "Beam Tracing Polygonal Objects" by Hackbert & Hanrahan, and some other
publications on this topic.

--
Marco

Hello all, let me introduce myself. My name is Martin,
and i'm a student in a university in Indonesia. Right now,
i'm studying Ray Tracing as my Final Project, but i can't
find a good resource on the net. Actually, it's not the
Ray Tracing itself that bother me (because i have already
taken that lecture subject). It's the Cone Tracing, because
my final project will heavily based on this optimizing-
techniques of Ray Tracing. And it's very little resources
on the net of the Cone Tracing. All that I know is that
the Cone Tracing is an optimization of Ray Tracing that
forms a cone to shoot rays instead of shoot ray to all
direction (which waste optimization). Please for you who
can give me a little hints about the cone tracing and the
formula, or maybe give one or two url of good references
of Cone Tracing on the Net. Thank you very much. I'll wait
for your reply, guys.

God bless you all,
Martin

Hmmm, two projects that might be of some interest, both aiming at
interactive shading:

Gelato is Exluna's evolution, running partly on GPU... it'd be nice to
see some benchmarks.
http://film.nvidia.com/page/gelato.html

Old news is now the development of FPrime from Worley Labs:
http://www.worley.com/fprime.html

Comments? Anyone tried out one already?

\ Piero

>Hello,
>
>we would like to inform you that our new Realtime Raytracing Benchmark
>
>- RealStorm Bench2004
>
>is finally released.
>
>Check http://www.realstorm.com to get it.
>It would be nice if you find the time to send your results back.
>(Data\database.rdb)
>
>regards,
>
>Michael Piepgras
>Engine Programming
>contact@...
>www.realstorm.com

Hi

>>Btw if you mention Purcells Paper it is
>>only fair to mention Carr et als, too they have a paper at the
>>same  conference with the same topic (GI strategies) on GPUs.

>A minor correction:

>Nathan A. Carr, Jesse D. Hall and John C. Hart. The Ray Engine. Proc.
>Graphics Hardware 2002, Sep. 2002 (can be found at
>http://graphics.cs.uiuc.edu/~jch/papers/)

>was at Proc. Graphics Hardware, not SIGGRAPH 2002 (where Purcell's paper
>was presented). The thing I like about Purcell et al. was that they put
>just about everything they could on the GPU-side; Carr's approach is more
>limited.

That's not the one I ment, I ment the one you mention below (which is
at the same conference, Purcell's Photon mapping is GH and Carr is GH this
year also). Altough I wonder what both papers actually have to do with new
graphics hardware. ;)

Well I have some major issues with Purcell's Siggraph Paper 2002 he does
not really mention how things actually should work or can be
implemented on the GPU. Best example how does he distinguish secondary rays and
primary
rays. Does he trace first primary rays till the end and make another setup
for secondary rays? Then what about the early stencil
test, to rely on this is not a good option. Or what about his datastructures
on GPU? How many memory does he need to get a decent scene onto the GPU?

Carr's approach is maybe limited but it should actually work, but suffers
extremly from many gpu->cpu transfers (which are costly).
Frankly I wouldn't try to implement either Purcell's nor Carr's
GPU raytracing approach.

Best regards,
   J.D.

--
Explore SRT with the help of Java3D
(http://wwwvis.informatik.uni-stuttgart.de/relativity/minkowski)
(http://www.antiflash.net/java3d/relativity (mirror)

> > let's hope that next generation of GPUs will prove even more versatile
> > allowing cleaner implementations (is random access to memory still so
> > far to come?).
>Yes definitly. Having normaly not random access is what makes gpu's fast.
>Look at data rates drop when using texture indirections. It seems things
>are not even going to improve with new memory technology, as penalties
>for band hopping are still tremendous.

Actually I had originally written "(is ra2m still a dream?)" :-)
But who knows what will those guys come up with? Its all evolving so
quickly...  i.e. three years ago people laughed when one mentioned
raytracing on consumer hardware. (btw there are atleast 2 guys doing it
on PS2... thats what i call consumer! :-)  if specs are those anticipated,
will we all use PS3s for GI? :)
Anyway already integer capabilities would be a nice thing, and that
shouldnt need any redesign...

>Btw if you mention Purcells Paper it is
>only fair to mention Carr et als, too they have a paper at the
>same  conference with the same topic (GI strategies) on GPUs.

Uh thanks, had missed it, pretty nice!
Wanna see the thing live :-)

>Those times for radical different approaches are definitly over since
>years.

Since 1997? ;-)
We have seen that, but whats the reason? Dont say there's no place left to
explore anymore...   it has been mostly scratching the surface so far.

>What I want to see more are spectral phenomens. (Yes they are
>HARD) How can someone call himself a Global Illumination solver without
>taking these effects into account.

Which ones do you consider hard?
I dont see much left to do on a theorical point of view...
...and most of such phenomena shouldnt bring substantial slowdown when
implemented carefully.
But as long as there are memory and bandwidth issues we'll all have to stick
with our silly color triplet. (btw i bet most commercial renderers still
implement
dispersion just by supersampling with rgbcolored rays/photons; anyone tested
Brazil and FRender to check it out?).
Instead I'd like to see more polarization around, but that's just an
implementation
issue, not that theres not enough material around...

\ Piero






>--
>Explore SRT with the help of Java3D
>(http://wwwvis.informatik.uni-stuttgart.de/relativity/minkowski)
>(http://www.antiflash.net/java3d/relativity (mirror)
>
>
>
>
>Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>   List owner:   realtime_raytracing-owner@onelist.com
>
>Shortcut URL to this page:
>   http://www.onelist.com/community/realtime_raytracing
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

>Btw if you mention Purcells Paper it is
>only fair to mention Carr et als, too they have a paper at the
>same  conference with the same topic (GI strategies) on GPUs.

A minor correction:

Nathan A. Carr, Jesse D. Hall and John C. Hart. The Ray Engine. Proc.
Graphics Hardware 2002, Sep. 2002 (can be found at
http://graphics.cs.uiuc.edu/~jch/papers/)

was at Proc. Graphics Hardware, not SIGGRAPH 2002 (where Purcell's paper
was presented). The thing I like about Purcell et al. was that they put
just about everything they could on the GPU-side; Carr's approach is more
limited.

They also have another paper of interest this year (I haven't looked at it
yet):

Nathan A. Carr, Jesse D. Hall and John C. Hart. GPU Algorithms for
Radiosity and Subsurface Scattering. Proc. Graphics Hardware, July 2003

Purcell's been thinking along somewhat similar lines, see
http://graphics.stanford.edu/papers/photongfx/.

Eric

> Hi,

> I replied to your email but I believe my email address changed so it bounced
(it is being sent as ppsloan@... instead of just
ppsloan@...) - feel free to forward this to
> the list...

> -Peter-Pike Sloan

> -----Original Message-----
> From: Peter-Pike Sloan
> Sent: Tuesday, June 10, 2003 4:41 PM
> To: 'realtime_raytracing@yahoogroups.com'
> Subject: RE: [realtime_raytracing] global illumination news and oldies


> This (GDC paper) is basically a description of the diffuse part of our
siggraph paper from last year.  We have two papers at siggraph this year that
extend the technique:

> "Clustered Principal Components for Precomputed Radiance Transfer", Peter-Pike
Sloan, Jesse Hall, John Hart, and John Snyder

> This paper compresses our previous results, extends the simulator to include
subsurface scattering and discusses least squares projection to spherical
harmonics restricted to the hemisphere (should
> have been done for the glossy work before and westins BRDF stuff is more
accurate if this is done as well.)  Compression enables higher frequency
lighting in the diffuse case and makes glossy
> objects much faster than they were last year (from 2fps to 30-50fps depending
on the model, if we make the non-local viewer assumption it's closer to 300fps,
but that isn't in the paper because we
> didn't think about it until last week...)  We use transfer matrices that map
from incident radiance to exit radiance (this makes compression more
straightforward...) instead of incident radiance to
> "transferred incident" radiance like we did last year.

> "Bi-Scale Radiance Transfer",
> Peter-Pike Sloan, Xinguo Liu, Heung-Yeung Shum, and John Snyder

> This (short) paper merges ideas from PRT with BTF's.

> The above papers will be on my web page soon:

> http://research.microsoft.com/~ppsloan

> There is a nice paper by Lehtinen and Kautz that was at I3D this year ("Matrix
Radiance Transfer") that encodes transfer matrices from incident to exit
radiance, but use a directional basis to
> represent exit radiance and runs PCA on the transfer matrices (this gives them
better glossy performance than we had last year, but our technique from this
year is more efficient...)

> There are two other related papers at siggraph:

> "All-Frequency Shadows Using Non-linear Wavelet Lighting Approximation", Ren
Ng, Ravi Ramamoorthi, Pat Hanrahan

> This (very nice) paper represents the lighting environment using haar wavelets
on a cube map and uses ideas from non-linear wavelets (ie: use the N most
"important" wavelet coefficients and throw
> out the rest) to do sparse matrix (well, really a bunch of sparse vectors -
they only did image relighting or diffuse objects) times sparse vectors (the
thresholded lighting coefficients) on the
> CPU.

> "Precomputing Interactive Dynamic Deformable Scenes"
> Doug L. James, Kayvon Fatahalian

> This paper precomputes both highly non-linear dynamics and GI of deformable
objects for a restricted "impulse palette", and uses linear dimensionality
reduction to efficiently store and playback
> the scene using the GPU.  It's a really nice paper IMO.

> These aren't real time raytracing papers however, they do real time global
illumination by precomputing a bunch of non-real time stuff.  I am working on an
article describing how to do the
> precomputation efficiently on the GPU (well, at least for the direct lighting
case with diffuse objects...) that will be in the book ShaderX2...

> -Peter-Pike Sloan

> -----Original Message-----
> From: A.W. van den Heuvel [mailto:A.W.v.d.Heuvel@...]
> Sent: Monday, June 09, 2003 11:22 PM
> To: Piero Foscari
> Subject: Re: [realtime_raytracing] global illumination news and oldies


> Hi,

> I recently came accross the following paper:
http://www.research.scea.com/gdc2003/spherical-harmonic-lighting.pdf

> Still haven't checked it but it seems to be a promising way to calculate
radiosity.

> - Ton

>> Hi all....

>> So, some news, a paper from Tim Purcell implementing photon mapping on
>> the
>> GPU; pretty
>> interesting but its not yet practical (i.e. photon splatting is comparable
>> in results albeit simpler),
>> let's hope that next generation of GPUs will prove even more versatile
>> allowing cleaner
>> implementations (is random access to memory still so far to come?).

>> Also some new stuff from the Saarbrücken guys on interactive GI
>> through
>> clusters of PCs
>> ("A scalable approach to global illumination" where they further optimize
>> the previous InstantGI
>> system, and "Interactive GI in complex and highly occluded
>> environments"adressing
>> large unimportant lightsource counts).

>> Some time ago the demo Still Sucking Nature was also released, see
>> www.realstorm.de.
>>   Lastly, for those who missed it, there was last year's EG STAR:
>> Damez,
>> Dmitriev & Myszkowski:
>> "Global illumination for interactive applications and high-quality
animations".

>> There's plenty of good implementations around, but no radically new
>> approaches to GI, how comes? Even some old well known methods didnt
>> receive imho enough analytical attention yet...
>> Any thoughts?

>>   \ Piero





>> Community email addresses:
>>   Post message: realtime_raytracing@onelist.com
>>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>>   List owner:   realtime_raytracing-owner@onelist.com

>> Shortcut URL to this page:
>>   http://www.onelist.com/community/realtime_raytracing

>> Your use of Yahoo! Groups is subject to
>> http://docs.yahoo.com/info/terms/



> ------------------------ Yahoo! Groups Sponsor ---------------------~--> Get A
Free Psychic Reading! Your Online Answer To Life's Important Questions.
> http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/_iFolB/TM
> ---------------------------------------------------------------------~->

> Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>   List owner:   realtime_raytracing-owner@onelist.com

> Shortcut URL to this page:
>   http://www.onelist.com/community/realtime_raytracing

> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Non-text portions of this message have been removed]

Hi

Wow thought this list is dead :)

>So, some news, a paper from Tim Purcell implementing photon mapping on
>the  GPU; pretty
>interesting but its not yet practical (i.e. photon splatting is
>comparable in results albeit simpler),
> let's hope that next generation of GPUs will prove even more versatile
> allowing cleaner implementations (is random access to memory still so
> far to come?).

Yes definitly. Having normaly not random access is what makes gpu's fast.
Look at data rates drop when using texture indirections. It seems things
are not even going to improve with new memory technology, as penalties
for band hopping are still tremendous.
Btw if you mention Purcells Paper it is
only fair to mention Carr et als, too they have a paper at the
same  conference with the same topic (GI strategies) on GPUs.

>There's plenty of good implementations around, but no radically new
>approaches to GI, how comes?

Those times for radical different approaches are definitly over since
years. What I want to see more are spectral phenomens. (Yes they are
HARD) How can someone call himself a Global Illumination solver without
taking these effects into account.

--
Explore SRT with the help of Java3D
(http://wwwvis.informatik.uni-stuttgart.de/relativity/minkowski)
(http://www.antiflash.net/java3d/relativity (mirror)

Hi,

I recently came accross the following paper:
http://www.research.scea.com/gdc2003/spherical-harmonic-lighting.pdf

Still haven't checked it but it seems to be a promising way to
calculate radiosity.

- Ton

> Hi all....

> So, some news, a paper from Tim Purcell implementing photon mapping on the
> GPU; pretty
> interesting but its not yet practical (i.e. photon splatting is comparable
> in results albeit simpler),
> let's hope that next generation of GPUs will prove even more versatile
> allowing cleaner
> implementations (is random access to memory still so far to come?).

> Also some new stuff from the Saarbrücken guys on interactive GI through
> clusters of PCs
> ("A scalable approach to global illumination" where they further optimize
> the previous InstantGI
> system, and "Interactive GI in complex and highly occluded
> environments"adressing
> large unimportant lightsource counts).

> Some time ago the demo Still Sucking Nature was also released, see
> www.realstorm.de.
>   Lastly, for those who missed it, there was last year's EG STAR:  Damez,
> Dmitriev & Myszkowski:
> "Global illumination for interactive applications and high-quality
animations".

> There's plenty of good implementations around, but no radically new
> approaches to GI, how
> comes? Even some old well known methods didnt receive imho enough
> analytical attention yet...
> Any thoughts?

>   \ Piero





> Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>   List owner:   realtime_raytracing-owner@onelist.com

> Shortcut URL to this page:
>   http://www.onelist.com/community/realtime_raytracing

> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Hi all....

So, some news, a paper from Tim Purcell implementing photon mapping on the
GPU; pretty
interesting but its not yet practical (i.e. photon splatting is comparable
in results albeit simpler),
let's hope that next generation of GPUs will prove even more versatile
allowing cleaner
implementations (is random access to memory still so far to come?).

Also some new stuff from the Saarbrücken guys on interactive GI through
clusters of PCs
("A scalable approach to global illumination" where they further optimize
the previous InstantGI
system, and "Interactive GI in complex and highly occluded
environments"adressing
large unimportant lightsource counts).

Some time ago the demo Still Sucking Nature was also released, see
www.realstorm.de.
   Lastly, for those who missed it, there was last year's EG STAR:  Damez,
Dmitriev & Myszkowski:
"Global illumination for interactive applications and high-quality animations".

There's plenty of good implementations around, but no radically new
approaches to GI, how
comes? Even some old well known methods didnt receive imho enough
analytical attention yet...
Any thoughts?

   \ Piero

I thought I'd share some things I came across and see if anyone has other
links.  I'm a game programmer professionally, and I'm very interested in
real-time raytracing on the side.  I'm especially looking forward to the
next generation of game consoles, since I think they will be up to the
task of allowing the first comercially produced real-time raytraced game.

As far as I know, there are two real-time raytraced games in existance:

RTChess:
http://www.newimage.com/~rhk/rtchess/

AntiPlanet:
http://www.virtualray.ru/eng/news.html

And one in the works:
http://www.realstorm.com/Screenshots.html

Has anyone seen any others?

Also, one gap that I can see is research on animating characters with
non-rigid vertex weighting (meaning a vertex can be influenced by 2 or
more bones in the skeleton).  Does anyone know of research into
appropriate bounding structures for such a character?  What I imagine
would be necessary would be to also animate on demand -- only characters
that are rendered would be animated at all, and only the bones that
correspond to the rendered polys would be animated.  Unfortunately, I
haven't seen any research addressing these issues yet, and it seemms like
a difficult (though solvable) problem.

Greg

hi,

the benchmark is nice, but the page is a little uninformative for the
interrested programmer :)
could you tell us a little about the dirty details of the tracer used?
things like:
- does it use sse/sse2/3dnow?
- if so, how do you exploit it? coherent seems unlikely as you seem to be
using full solids instead of tris.
- what kind of spatial subdivision scheme does it use? (seems to have
portals in there, but what for the tracing core?)
- how far did you go into raw assembly or is it all plain c?
- what other surprising insights did you get from making the tracer fast?
any neat & non-obvious tricks you want to share? :)


/shiva^kolor

----- Original Message -----
From: "wurstbrot20002000" <contact@...>
To: <realtime_raytracing@yahoogroups.com>
Sent: Wednesday, August 07, 2002 2:09 AM
Subject: [realtime_raytracing] Realtime Raytrace Benchmark


> Hello,
>
> we launched our new website, about realtime raytracing. at
> www.realtimeraytrace.de you fill our new rtrt-benchmark at the
> downloads section.
>
> If you find the time to run the benchmark, i would be pleased if you
> send the file data\database.rdb back to my email:
> contact@...
>
> thanks for you time,
>
> Michael Piepgras
> (TTS/F.A.N./Oxyron)
>
>
>
>
> Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>   List owner:   realtime_raytracing-owner@onelist.com
>
> Shortcut URL to this page:
>   http://www.onelist.com/community/realtime_raytracing
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

I released an open source volumetric raytracer (after some discussions I
found out that volumetric raytracer is the most correct name for it), the
project is called Trixel and it's on sourceforge here:
http://sourceforge.net/projects/trixel

It would be cool if someone added a feature, or just gave me some comments
on the coding style.

(btw it's the same thing as the cube posts I made here as hybrid6666, but
this time open
source)

Hello,

we launched our new website, about realtime raytracing. at
www.realtimeraytrace.de you fill our new rtrt-benchmark at the
downloads section.

If you find the time to run the benchmark, i would be pleased if you
send the file data\database.rdb back to my email:
contact@...

thanks for you time,

Michael Piepgras
(TTS/F.A.N./Oxyron)

Hey, that's pretty cool.  It runs fast.  I actually
wrote something similar- mine is based on octrees, and
you can give the tips of the octree a 32-bit rgb value
instead of a pointer.  But, mine was designed so that
you're not supposed to get so close you can see the
individual cubes- a given scene might contain millions
upon millions of them, agglomerated into bigger
objects.  If you do get that close, they don't look
like cubes, because I fudged it to run faster.  I've
been working on mutating this system to be able to
draw arbitrary quadratics as well, by converting them
into cubes recursively as the rendering proceeds.
That doesn't work yet though.

Sean

--- hybrid6666 <hybrid6666@...> wrote:
> I've seen lots of raytracers with spheres in it,
> planes, nurbs,
> blobs, and so on, but never one with cubes.
>
> That's why I made one with cubes.
>
> You can download it here:
>
>
http://www.perilith.com/~lode/trixel/Files/Trixel002.zip
>
> Use arrows + mouse to move, b to place a block in
> front of you, and
> F1 --> F6 to open different levels. Additional
> commands are in the
> included readme file.
>
> Please give comments.
>
> Thanks.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Which security solution is right for your Web site?
> Before you
> decide, request your FREE guide, "Securing Your Web
> Site For Business," to learn the facts. In the
> guide, find solutions for: * Encrypting online
> transactions * Securing corporate intranets *
> Authenticating your Web site Get your FREE guide
> today at:
>
http://us.click.yahoo.com/RzQ9wC/OyKEAA/Zr0HAA/_iFolB/TM
>
---------------------------------------------------------------------~->
>
> Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:
> realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:
> realtime_raytracing-unsubscribe@onelist.com
>   List owner:
> realtime_raytracing-owner@onelist.com
>
> Shortcut URL to this page:
>
> http://www.onelist.com/community/realtime_raytracing
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Seems quite good, fairly fast on my work machine too (2 gig p4) - now add lights
and shadows, and I shall spend happy hours playing with it :-)
   ----- Original Message -----
   From: hybrid6666
   To: realtime_raytracing@yahoogroups.com
   Sent: Friday, June 07, 2002 11:56 PM
   Subject: [realtime_raytracing] Cube based raytracer


   I've seen lots of raytracers with spheres in it, planes, nurbs,
   blobs, and so on, but never one with cubes.

   That's why I made one with cubes.

   You can download it here:

   http://www.perilith.com/~lode/trixel/Files/Trixel002.zip

   Use arrows + mouse to move, b to place a block in front of you, and
   F1 --> F6 to open different levels. Additional commands are in the
   included readme file.

   Please give comments.

   Thanks.



   Community email addresses:
     Post message: realtime_raytracing@onelist.com
     Subscribe:    realtime_raytracing-subscribe@onelist.com
     Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
     List owner:   realtime_raytracing-owner@onelist.com

   Shortcut URL to this page:
     http://www.onelist.com/community/realtime_raytracing

   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]

Hi
> > Check out this one: http://graphics.stanford.edu/papers/rtongfx/
> > Still gotta look wether what they use is in Opengl2 already...
> > Anyone can tell? Tim?
>
> OpenGL 2.0 does in fact look like it includes many of the features we
> advocated in the paper.  Of course, it is unknown how efficiently any
> new cards supporting OpenGL 2.0 will support those features we use.
And it is rather unknown when OpenGL 2.0 really arrives. I heard from some
sources there are serious problems in the background of the consortium. So
I would rather recommend to have a look at DX9. Which is already available
in a Beta-Stadium. And I think it has many features OpenGL2.0 wants to
bring allong, too. The advantage with DX9 you can test out things at once
as functions are normally simulated in software and do not have to wait
for a card to arrive.

> We'll just  have to wait until some hardware comes out so we can try
> things out ...

Well the P10 from 3dlabs looks very interesting with a total number of 200
SIMDs units. I could  think the people from Saarbruecken might be very
keen on this. (As they seem to take heavy use of SIMDs on PIII/IV)

EOF,
  J.D.

I've seen lots of raytracers with spheres in it, planes, nurbs,
blobs, and so on, but never one with cubes.

That's why I made one with cubes.

You can download it here:

http://www.perilith.com/~lode/trixel/Files/Trixel002.zip

Use arrows + mouse to move, b to place a block in front of you, and
F1 --> F6 to open different levels. Additional commands are in the
included readme file.

Please give comments.

Thanks.

On Thursday 06 June 2002 22:09, you wrote:
> Message: 1
>    Date: Thu, 30 May 2002 23:07:46 -0000
>    From: "elendar_k5" <eLendar@...>
> Subject: Hardware accelerated raytracing
>
> Hi all.
>
> I'm quite new to rtrt, though I've been in the list for some months
> now. Anyway, I think I should introduce myself a bit, since it's my
> first post.
> My name is Oscar Peñas. I'm a computer science student, and I have
> some demoscene background, so I prefer the scener point of view of
> rtrt, though I don't discard other approaches.
>
> I was messing around with some ideas lately about the possibility of
> implementing a raytracer using the acceleration of modern cards,
> like
> for example letting opengl do the zbuffer stuff to get a preview of
> which objects are more likely to be intersected by primary rays.
> I am willing to know your thoughts to this respect. Do you think
> it's
> possible? What are the possibilities?


You could use an item buffer to get "exactly" which objects the
primary rays intersect.  This has been done and gives a good
performance gain.  But... for very simple scenes (Demo Scene
purposes), the overhead of reading from the frame-buffer will
prob. nullify the advantage.  For complex scenes, the number and
complexity of solving the nth generation rays (n>1) would make the
result non-interactive.
>
> Btw, say I want to use opengl's depth buffer. Is there any way of
> accessing the depth buffer memory space to manipulate its values
> directly?


You can certainly read it and clear it, I don't know why you would
want to write to it. Besides, look up Item Buffers. They're great.

> See ya.
> ________________________________________________________________________
>
> Message: 2
>    Date: Wed, 05 Jun 2002 16:44:52 -0000
>    From: "quartzy75" <wally@...>
> Subject: Re: Hardware accelerated raytracing
>
> >I was messing around with some ideas lately about the possibility
> >of
>
> >implementing a raytracer using the acceleration of modern cards,
> >like
>
> > for example letting opengl do the zbuffer stuff to get a preview
> > of
> > which objects are more likely to be intersected by primary rays.
> > I am willing to know your thoughts to this respect. Do you think
>
> it's
>
> > possible? What are the possibilities?
>
> Check out this one: http://graphics.stanford.edu/papers/rtongfx/
> Still gotta look wether what they use is in Opengl2 already...


They're using neither.  The ray-tracer is implemented on a simulator
for hardware which does not (but probably soon will) exist.
Great paper.

> Anyone can tell? Tim?
>
> Sincerely
>            Piero


Cheers..

> Check out this one: http://graphics.stanford.edu/papers/rtongfx/
> Still gotta look wether what they use is in Opengl2 already...
> Anyone can tell? Tim?

OpenGL 2.0 does in fact look like it includes many of the features we
advocated in the paper.  Of course, it is unknown how efficiently any
new cards supporting OpenGL 2.0 will support those features we use.
We'll just have to wait until some hardware comes out so we can try
things out ...

-Tim

Hi,

since I am new to this list as well, I'd better introdue myself first,
too...:-)
I am Phil Robert, an engineer with SGI's core rendering group and I also
do some research partially focused on raytracing for my PhD.

Regarding your questions, there are some approaches to do RTRT using GL
accelerators, the latest one is available from
http://graphics.stanford.edu/papers/rtongfx/. Further there are some
nice demos from the demo scene which do that, although kind of more
limited.

You can ie. set the z-buffer values by rendering having DEPTH test
enabled but w/o drawing. But you cannot write into this buffer directly
unless you are on a UMA machine.

HTH - but I am sure others know better and more about all this,
though...:-)

cheers,

-Phil

On Friday, May 31, 2002, at 01:07 AM, elendar_k5 wrote:

> Hi all.
>
> I'm quite new to rtrt, though I've been in the list for some months
> now. Anyway, I think I should introduce myself a bit, since it's my
> first post.
> My name is Oscar Peñas. I'm a computer science student, and I have
> some demoscene background, so I prefer the scener point of view of
> rtrt, though I don't discard other approaches.
>
> I was messing around with some ideas lately about the possibility of
> implementing a raytracer using the acceleration of modern cards, like
> for example letting opengl do the zbuffer stuff to get a preview of
> which objects are more likely to be intersected by primary rays.
> I am willing to know your thoughts to this respect. Do you think it's
> possible? What are the possibilities?
>
> Btw, say I want to use opengl's depth buffer. Is there any way of
> accessing the depth buffer memory space to manipulate its values
> directly?
>
> See ya.
>
>
>
>
>
> Community email addresses:
>   Post message: realtime_raytracing@onelist.com
>   Subscribe:    realtime_raytracing-subscribe@onelist.com
>   Unsubscribe:  realtime_raytracing-unsubscribe@onelist.com
>   List owner:   realtime_raytracing-owner@onelist.com
>
> Shortcut URL to this page:
>   http://www.onelist.com/community/realtime_raytracing
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

> I was messing around with some ideas lately about the possibility
of
> implementing a raytracer using the acceleration of modern cards,
like
> for example letting opengl do the zbuffer stuff to get a preview of
> which objects are more likely to be intersected by primary rays.
> I am willing to know your thoughts to this respect. Do you think
it's
> possible? What are the possibilities?

Check out this one: http://graphics.stanford.edu/papers/rtongfx/
Still gotta look wether what they use is in Opengl2 already...
Anyone can tell? Tim?

Sincerely
            Piero

Hi all.

I'm quite new to rtrt, though I've been in the list for some months
now. Anyway, I think I should introduce myself a bit, since it's my
first post.
My name is Oscar Peñas. I'm a computer science student, and I have
some demoscene background, so I prefer the scener point of view of
rtrt, though I don't discard other approaches.

I was messing around with some ideas lately about the possibility of
implementing a raytracer using the acceleration of modern cards, like
for example letting opengl do the zbuffer stuff to get a preview of
which objects are more likely to be intersected by primary rays.
I am willing to know your thoughts to this respect. Do you think it's
possible? What are the possibilities?

Btw, say I want to use opengl's depth buffer. Is there any way of
accessing the depth buffer memory space to manipulate its values
directly?

See ya.

>
>
>
>Yes, let me also use this opportunity to express my gratetude to the
>helpful people around here. Ingo: I am looking very much forward to read
>your latest paper, it seems like the kind of research I'd like to
>conduct during my masters year (as a thesis). =)
>
though they are also all on my web site, the best place to find them
(and any
successive papers, which might be written by other people) is on
http://www.openrt.de/Publications
the videos are rather big, though, and one of the pages still doesn't
contain any text...

     Ciao

         Ingo

ok, this has to be one of the most embarassing things ever... wrong email
address, posted to an entire group... OOPS :) i'm nominated for a partial
darwin award there i think...

anyway, sorry to disturb the peace ;)

thomas

[apologies from the moderator too, wrong button detected too late]

> The one you prefer. But for cross-platform, never use VC+: lots of
standard stuff
> not supported, and lots of non standard stuff integrated.

With little attention you can easily use vc++ and still code portable
stuff... vc's ide is really good, and it have very nice features for
debugging your apps (such es edit&compile, to edit on the fly the source
when you find a bug...). I really like it, even if it's M$ =)

--*PaN!*

heya shaun :)

i'm working on rendering an image using naive path tracing in a very
difficult setting. i'm rendering with 192x192 samples per pixel :)

the picture is 640x480 resolution, i'm doing scanlines 0 to 159, and a
friend of mine with an athlon 1.4ghz is doing scanlines 360 to 480. There
are 160 scanlines between 160 and 359, are you interested? I'm sure one
overnight session using your dual P4 monster should cover it :)

i've included a zip containing the program and the scenefile. just run it,
and set it to low priority (since it's really unresponsive, no
multithreading yet). if you want to use both CPUs, obviously you can start
two copies of the program with half the scanline range. it'll save a whole
bunch of scanlines which you can email me once they're done.

you don't have to do this of course, but if you're like me then you're quite
happy to leave your pc running overnight to generate some amazing image
afterwards :) plus, the thought of around 6ghz of effective processing power
is quite nice :)

in other news, how are you? i haven't been able to catch you in the lab
recently, apparently you're kicking back a bit, good to hear :) do you still
plan to go to america at the end of this term?

anyway, keep well, i must sleep now :)

thomas

ps. the image will look crap while rendering, i'll eventually postprocess
the picture to apply exposure control...


[Non-text portions of this message have been removed]

Hi everybody,

> Thank you all for the recommendations.  I've been spending some time

Yes, let me also use this opportunity to express my gratetude to the
helpful people around here. Ingo: I am looking very much forward to read
your latest paper, it seems like the kind of research I'd like to
conduct during my masters year (as a thesis). =)

[OS independency]
> Unfortunately, my computers are currently all running Windows.

Now that is a shame. =) For cross platform computer graphics, I can
recommend SDL (http://www.libsdl.org/). Quoting from the home page:
"Simple DirectMedia Layer supports Linux, Win32, BeOS, MacOS, Solaris,
IRIX, and FreeBSD". Although I never tried it under anything else than
Linux, I still vouch for it. It is extremely simple to use (exception
handling removed):

SDL_Init(SDL_INIT_VIDEO);
SDL_Surface *screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE |
SDL_DOUBLEBUF | SDL_HWACCEL);
Uint32 *buffer = (Uint32 *)screen->pixels;
buffer[y * 640 + x] = 0xRrGgBb;
SDL_Flip(screen);

This piece of code initializes SDL, opens a window (fullscreen also a
possibility), sets a single pixel, and flips the buffers. =)

> 4) Is there a good profiler I can use with this?  (Again, is the
> Windows version better/worse?)

I am using GNU gprof (http://www.gnu.org/manual/gprof-2.9.1/), which
gives me all details I need, and then some. =)

best regards,
Daniel
http://www.cs.auc.dk/~daniel/