kalle.last@[EMAIL PROTECTED]
wrote:
> Jon Harrop kirjutas:
> > I seriously doubt it. Jacco couldn't ray trace 1M pixels in real time,
let
> > alone triangles...
>
> You have no ideas how wrong you are:
> http://ompf.org/forum/viewtopic.php?p=2702#2702
> ~80k static and 1k dynamic triangle scene with depth fog, reflections,
> texture mipmapping, bumpmapping, bilinear filtering and lots of other
> things run at 8-10FPS @[EMAIL PROTECTED]
on my Core2Duo CPU. That is at least 4M
> primary rays per second with 100% screen coverage. Together with shadow
> and secondary rays around 10M rays per second.
That's for 10x fewer triangles though?
> Btw, Jacco has got an eight core machine at his UNI and is developing a
> game based on ray tracing.
I'm keen to see what he can come up with next. :-)
> > > Anyway, ray tracing a bunny isn't really the best thing to do with
ray
> > > tracing.
> >
> > Exactly. Ray tracing only seems to be good for sphereflakes.
>
> And highly detailed scenes with reflections and refractions, things
> that multipass rendering hates badly. Anyway, we shouldn't debate over
> speed but over efficiency. If you want to debate overs speed then at
> least use comparable HW. In this case, software OpenGL vs software ray
> tracing. Good luck running those pixel shaders on your CPU.
You want to cripple OpenGL to make the comparison fair? You'll be
comparing TBP's C++ with an OCaml newbie's code next... ;-)
> > > Add in some reflections-refractions and shadows and then start
> > > comparing RT vs rasterizing in terms of speed, FLOPS used and code
> > > length.
> >
> > Shadows won't make any difference. Reflections of distant objects can
be
> > done with cube maps, so that won't make any difference either.
> >
>
> How many lines of code will it add to implement point and cone lights
> with nice gradient?
I just implemented completely naive geometric shadows in ~90LOC and
I'm getting 10fps on my laptop at 1600x900. My current algorithm is
using dynamic data structures (mainly lists) that get completely
regenerated every frame. I'll optimise it by changing to static data
structures and incremental updates.
> From my understanding it takes at least one pass to render a cone light
> and six p***** for pointlight to get decent shadow quality with OpenGL
> based rasterizing assuming you use shadowmaps.
There are many different ways to do it. I've used shadow volumes
extruded on CPU and stencilled in hardware. They're exact. Shadow
volumes are probably faster but they're inexact.
> My knowledge about
> rasterization is a bit rusty so I might be wrong but I don't think I'm
> too far off.
I think you're right.
> How much does it cost to create a detailed reflection cubemap and what
> kind would it's quality be? I dare you to render that same scene that
> Jacco does in his demo with the same effects and claim that OpenGL is
> easier to write and more efficient.
I'll try to get his demo up and running (am away from home for the
weekend).
> Also, some scenes with several translucent objects behind each other
> would be nice to see in OpenGL.
Ok.
> > Accurate close-up reflections and refractions you'd need to use
something
> > akin to ray tracing. Use mathematically simple primitives like spheres
and
> > ray tracing has a benefit. So ray tracing is great for reflective
> > sphereflakes and bad for everything else...
>
> Since we don't have wildly availiable HW acceleration for ray tracing
> yet I agree that currently OpenGL is better when you need maximum speed
> and don't need to render massive and detailed scenes. Though RT HW is
> being developed (saarcor.de) and first tests show that RT needs around
> half the memory bandwidth of regular rasterizers. With special purpose
> chips (GPU, RPU, PPU) FP power is a lot cheaper than memory bandwidth.
> In the future as scene complexity rises RT will have even more benefits
> compared to rasterizing.
Gallium Arsenide is the semiconductor of the future. It always has
been and it always will be.
> Also if you haven't noticed then all the real time ray tracers you see
> in ompf.org are tracing only triangle based scenes.
Yes.
> > I already added a completely naive shadow rendering algorithm and
using
> > OpenGL is still many times faster than Jacco's ray tracer. I'll
optimise my
> > OpenGL and post it.
>
> Please post some screenshots with code too when you are done.
Will do.
> I can't
> wait to see how simple it is to create pixel perfect dynamic lights
> with self shadowing in OpenGL.
I just did it in 90LOC but it is too slow to be very useful.
> Even better would be some speed
> comparisons with shadows turned on and off.
Currently 1600fps without shadows and 10fps with. :-)
> Until you are done with
> this I'd like to see that naive shadow thingie you have already
> created.
I'll post the trivial implementation as well as an optimised one then.
I think it is interesting to see the simplest possible way to do
something...
> > > It wouldn't help all that much since primary rays take only part of
the
> > > time in rendering.
> > > When you add in shadows and secondary rays then
> > > tracing primaries won't make a big difference any more, especially
when
> > > you use things such as MLRTA.
> >
> > Even in real time ray tracers?
>
> Yes, why not?
Because they can't afford to trace much more than 1 primary and 1
shadow per pixel.
> > The screenshot on that page is about as compelling as Jacco's grainy
bunny.
>
> You didn't run the latest demo, did you?
Not yet (no Windows here).
> Anyway, here is the post with
> some pictures, post containing the latest demo is right above it:
> http://ompf.org/forum/viewtopic.php?p=2704#2704
I'll try it when I get back to a Windows box.
> > It took me a year to reply, but TBP's C++ ray tracer turned out to be
only
> > 60% faster than the OCaml:
>
> There is a followup in the forum to that very same thread:
> http://ompf.org/forum/viewtopic.php?t=336
> After lots of tweaking, OCaml is still quite a bit slower than C++,
> 5-6x slower if I remember correctly.
The OCaml code was written by a newbie!
> Feel free to post more optimized
> tracer to that thread but make sure you trace triangulated
> sphereflakes..
I already gave the author lots of help with his OCaml and posted
several improved versions to various groups and lists. The OCaml needs
a complete rewrite. It should be 4x smaller and 4x faster. I'll
probably redo the whole thing myself one day but I'm too busy ATM and
OGL is much more fun. :-)
> > > I'd like to make a request for you. You already have a program on
your
> > > home page that renders a sphereflake using occlam. What would be the
> > > speed and code length of comparable OpenGL program?
> >
> > OpenGL would not fare well. However, do you have a ray tracer that can
> > render that in real time? Many people have claimed that is has been
done,
> > but I've never seen anything like it.
>
> You should join the ompf forum and ask someone to make a scene for that
> sphereflake. I know that tbp's tracer is capable of tracing 1M triangle
> happy buddha at 15FPS, I think sphereflake with all its reflections
> should be around 5-10FPS on Core2Duo @[EMAIL PROTECTED]
resolution, possibly more
> if SIMD is used.
Rendering the Buddha at 15fps with shadows and without LOD will be
tricky but I'll give it a go...
Cheers,
Jon.
|
