Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Jacco Bikker, posted on April 29, 2005




Image Description, by Jacco Bikker



A while back I sent in an ray tracing IOTD showing the Stanford bunny, rendered at high speed. I've been busy since I made that demo, and these shots show the current state of the art. The top shot represents the maximum image quality: There are textures, adaptive super sampling (for edge anti aliasing), a bloom filter causing a subtle glow and of course the reflections. Sadly all this eye candy comes at a cost. The lower shot shows a very good performing model: The number of rays per second is no less than 3 million on a 1.7 Pentium-M - on a P4 @ 3.2Ghz this would be about 6 million rays per second, which is better than the SaarCOR FPGA ray tracing chip.

Over the past months, many things have improved: The overall speed of the ray tracer has been improved considerably due to some stiff competition from tbp (the odd french dude), there's a complete tool chain now to get from downloaded content to ray traced images (via the .obj file format), and the functionality has been extended considerably (textures, reflections, HDRI, networked rendering etc.).

There will be more good stuff, I'll keep you all informed. Greets - Jacco.


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
malCanDo

May 03, 2005, 04:18 AM

Very cool...

Having this functionality in a plugin form for an opensource app like Blender ( www.blender.org ) would be an excellent way of getting a wide audience to test it!

Mal

 
dummy

May 03, 2005, 04:34 AM

Scali wrote: I'm still not convinced... You're just doing some handwaving here..

You're talking to me?
One of us has implemented such a raytracer (with everything you alludes to, RGSS & whatnot), and it's not you.

I don't agree with any of it, by the way... the polycount has nothing to do with the amount of texturefiltering required...

Right. Ever thought of what's happening when you're nearing one triangle per pixel?

 
dummy

May 03, 2005, 04:54 AM

Scali wrote: I really don't think that the bottleneck in a raytracer is the shift operation. So I doubt it affects performance much.

Of course it's not. But we're talking about optimal performance and that's a kludge for a borked architecture.

a) it wastes decoding bandwith
b) with fat assed vectors and no proper scale factor, addressing is enough of a problem as is
c) it's just one of the kludge that ICC uses to make things fly on a P4

I would not be surprised if icc generated better code than gcc in 64 bits...

Please get a clue and quit speculating about things you have no idea about.
I have both icc8.1 & icc9.0 (beta). In 64bit mode gcc spits better code.
And i have binaries to back up my claims.
(it's another story on ia32 and my guess will be that gcc crappy register allocator is the culprit).

And are you talking about neutral code, or more AMD-slanted?

Obviously i run k8 tuned code on my box. But that's not an issue with gcc as it can also tune it for p4, p-M etc...

Yes, but can you compare your code to this code... and if so... what kind of performance do you get with your code on a P4?

More or less :) (as our respective code evolved concomitantly).
And i don't have any P4 around, so i can't comment.

 
River

May 03, 2005, 05:17 AM

Would be interesting to see how it works on those brand new Dual Core machines. However I doubt anyone has one within reach :)

 
Scali

May 03, 2005, 05:25 AM

dummy wrote: You're talking to me? One of us has implemented such a raytracer (with everything you alludes to, RGSS & whatnot), and it's not you.


You don't know what I've implemented and what I haven't, so stop acting like you know everything, and others know nothing.
I am talking to you yes... You are just handwaving, as in, not giving actual concrete examples, but just saying "This is my opinion, and therefore it is the truth". Well, as I have stated, I do not agree with your opinion.
So if you want to convince me, you'll have to come up with some evidence.

Right. Ever thought of what's happening when you're nearing one triangle per pixel?


Ofcourse, but it's not realistic to assume that you will have one triangle per pixel EVERYWHERE (not without some kind of dynamic subdivision scheme... which would be overkill for something that a texturefilter could handle). Especially not if you want to render at near-realtime framerates, which is what this particular IOTD seems to be about.

 
dummy

May 03, 2005, 05:45 AM

Scali wrote: You don't know what I've implemented and what I haven't, so stop acting like you know everything, and others know nothing.

Sure. Just show the stuff.

Ofcourse, but it's not realistic to assume that you will have one triangle per pixel EVERYWHERE (not without some kind of dynamic subdivision scheme... which would be overkill for something that a texturefilter could handle). Especially not if you want to render at near-realtime framerates, which is what this particular IOTD seems to be about.


Of course?
Let me quote you: "the polycount has nothing to do with the amount of texturefiltering required..."
How to say everything and its contrary in a couple of posts...

 
Scali

May 03, 2005, 06:03 AM

dummy wrote: Sure. Just show the stuff.


What is this, a job interview?
Why don't you just focus on what we're trying to discuss? I believe I am making valid points regarding texture filtering here. Regardless of what I have or haven't coded.

Of course? Let me quote you: "the polycount has nothing to do with the amount of texturefiltering required..." How to say everything and its contrary in a couple of posts...


No, my statement is correct... The polycount doesn't affect it... The size of the polys in screenspace does. You assume that high polycount means small polygon surface in screenspace. This is obviously not a valid assumption in all cases. I hope you realize that aswell.
There's this huge gray area of polys that aren't small enough to be handled by edge-AA, and not big enough to be handled by bilinear filtering.

 
dummy

May 03, 2005, 06:28 AM

Scali wrote: What is this, a job interview?

Bzzt. Wrong answer.

Why don't you just focus on what we're trying to discuss?

Because you've questionned the conclusion i came to after experimentations calling that handwaving.
Quite ironic, isn't it?

 
Scali

May 03, 2005, 06:35 AM

dummy wrote: Bzzt. Wrong answer.


Erm, so because you've not seen my code, you assume I don't know anything about the subject, even though I make valid statements?
Well, since I haven't seen your code either, I guess I can assume you don't know anything either then.

Because you've questionned the conclusion i came to after experimentations calling that handwaving. Quite ironic, isn't it?


Oh I'm sorry, I didn't know it was illegal to question you.
You never said you've done experimentations... and even if you did, you've never shown them to me, so why should I just take your word for it? So as far as I'm concerned it's just you trying to push your opinion as fact, without giving any good arguments to support your opinion, also known as handwaving.

Besides, I still think my statements are valid, and they give plenty of reason to question your conclusions, at least for me... So why don't you focus on discussing that?
So far you've just presented one extreme and unrealistic case where advanced texture filtering may not be that useful... How about more realistic cases? Like for example this lego car, where the texture on the bonnet already has sampling problems under steep angles.

 
davepermen

May 03, 2005, 07:57 AM

hm.. what i'm interested in is, if there is a way to skin the bsp tree directly, so we would not need to recreate it all the time.

or something in between.

and for the filtering: i'd guess with some more samples, and some bether texture encoding to handle them (texture compression stuff), we could use the additional time to access the memory to do bicubic filtering, as the cpu can do a lot of calculations during that time. possibly only double the amount of memory accesses, if done well..

but i haven't done practical lowlevel work since ages.. this is just some brainstorming of theoretical stuff i've read about, and thought about.

the skinning task is much more important anyways. i mean, we _DO_ have solutions for bether filtering. even if they are not really that fast. we have no real solution yet for realtime skinned raytraced characters..

(i'd love to get a prove that i'm wrong with that last statement :D:D:D)

 
davepermen

May 03, 2005, 07:59 AM

this, btw, was post nr. 100 :D now i'm at 101 :D:D

 
dummy

May 03, 2005, 08:21 AM

Scali wrote: So far you've just presented one extreme and unrealistic case where...

Maybe because that's what that kind of raytracer is about?

Damn you davepermen, you've sneaked that 100th post away from me.

 
Jacco Bikker

May 03, 2005, 08:31 AM

Yes, awesome! Let's take a moment to celebrate this event: Over 100 posts on an IOTD. That hasn't happened since... Well... That hasn't happened in months!

I would like to say 'thanks!' to all the kind people who contributed to this fine result: Dummy (also known as El Pinto Grande, or TBP), his opponent Scali, and everyone who contributed just one or two posts. It's has been an honor. Thank you. Thank you!

;)

 
Scali

May 03, 2005, 08:31 AM

dummy wrote: Maybe because that's what that kind of raytracer is about?


What is what kind of raytracer about?
Can't you make a decent argument for a change?
So far you've only managed to insult my knowledge, made false statements about polycounts, and managed to avoid most things I said...
When are you going to come up with clear sentences, solid arguments, and perhaps demonstrations to prove that you are right, or that I am wrong?
I'm getting rather tired of this.

 
davepermen

May 03, 2005, 08:34 AM

hehe, got ya! :D

 
dummy

May 03, 2005, 09:09 AM

Scali wrote: So far you've only managed to insult my knowledge, made false statements about polycounts, and managed to avoid most things I said...

It's that bad?

When are you going to come up with clear sentences, solid arguments, and perhaps demonstrations to prove that you are right, or that I am wrong?

I think the clear sentence thing is a lost cause.

Now for solid arguments, i think you've set such a high quality standard with "I would not be surprised if icc generated better code than gcc in 64 bits... It never had much trouble doing it in 32 bits" and the likes that, i fear, i cannot comply.

Let's say that i forfeit, while we all eagerly wait for your ass kicking raytracer with incredible texture filtering, crisp AA and fancy postprocessing at interactive rates.

 
Scali

May 03, 2005, 09:26 AM

dummy wrote: Please get a clue and quit speculating about things you have no idea about.


Please fix your attitude problem, and start showing some respect for people you have no idea about.
I think I see why your account was locked.

 
Scali

May 03, 2005, 09:35 AM

dummy wrote: It's that bad?=


Your attitude is that bad yes. You have absolutely no idea who I am, or what my level of knowledge is, so you just assume I don't know what I'm talking about.
It doesn't exactly help you to convince me that you are right, by the way.

I think the clear sentence thing is a lost cause.


Yes, I think you are simply unable to argue your point, so I will just assume I was right.

Now for solid arguments, i think you've set such a high quality standard with "I would not be surprised if icc generated better code than gcc in 64 bits... It never had much trouble doing it in 32 bits" and the likes that, i fear, i cannot comply.


That is completely unrelated to this discussion.
Besides, that wasn't even an argument, it was me expressing my expectations.
Why don't you set the right example with solid arguments, instead of trying to pull all kinds of unrelated nonsense into this discussion?
This won't help convince anyone that you're right either.

Let's say that i forfeit, while we all eagerly wait for your ass kicking raytracer with incredible texture filtering, crisp AA and fancy postprocessing at interactive rates.


Yes, ofcourse you forfeit. You have been unable to argue your point from the beginning.
However, I don't think anyone is eagerly awaiting any raytracer of mine, other than you yourself perhaps... I have no idea why, I never said I was making one, or am planning to make one. So what the heck is your point?

 
davepermen

May 03, 2005, 09:53 AM

I'd love to see one from you. AFAIK you're the same scali as everywhere on the net where you talk about programming issues, and you always talk as you're the best, and know everything.

so yeah, it would be cool to see a raytracer made by "the best" :D

(i don't like your attitude as well, but you have some points (and miss some others), and so i respect and accept you just as anyone else)

now instead of continuing in the bashing thread, how about continuing a little bit lower where i replied with some thoughts about the two main points that started this thread: animation and texture filtering quality

 
dummy

May 03, 2005, 09:59 AM

Scali wrote: Please fix your attitude problem, and start showing some respect for people you have no idea about.

I don't care who you are or not.
When you follow up with "I would not be surprised if icc generated better code than gcc in 64 bits..." when i've just said it's the other way around, i call for a reality check.
If you want respect, show some first.

Until then me, my x86-64 linux box and icc/gcc compiled binaries will laugh at you.
Because that's all you deserve.

I think I see why your account was locked.

I'm sure you do, the thing is the account isn't locked.

 
Scali

May 03, 2005, 10:39 AM

davepermen wrote: I'd love to see one from you. AFAIK you're the same scali as everywhere on the net where you talk about programming issues, and you always talk as you're the best, and know everything.


I think you are mistaking me for someone else. I am not "everywhere on the net", only on this forum (at least, programming-related). And I don't post all that often, really. Also, I can't recall making any statements about my skills or knowledge... You must be confused... it's dummy who's been saying he knows all, and I know nothing.

(i don't like your attitude as well, but you have some points (and miss some others), and so i respect and accept you just as anyone else)


This post of yours isn't showing too much respect... But I suppose that is because you are mistaking me for someone else. I don't think I know you.

now instead of continuing in the bashing thread, how about continuing a little bit lower where i replied with some thoughts about the two main points that started this thread: animation and texture filtering quality


I have nothing to add to your speculation. Perhaps dummy can give you some insight, he seems to have all the answers.

 
Scali

May 03, 2005, 10:49 AM

dummy wrote: I don't care who you are or not. When you follow up with "I would not be surprised if icc generated better code than gcc in 64 bits..." when i've just said it's the other way around, i call for a reality check.


Oh really? From here it looks like you just blatantly insult anyone who questions whatever opinions you post (I really can't take "gcc rulez", without any kind of additional information as anything more than just your opinion).
You react as if I've insulted you or something. You posted your experiences, I posted mine. I have no idea why you seem to take it personal...
Just look at what you write: "i've just said it's the other way around"... You assume that whatever you say is the absolute truth, and cannot be questioned whatsoever?
I don't have words for that... well I do, but none that I can post.

If you want respect, show some first.


Erm... I have shown respect throughout these discussions, I have never insulted, even though you have insulted me repeatedly, and ignored large parts of my posts, which is also showing lack of respect.
Besides, why should I be the one who should show you respect? I could just aswell reverse the statement... and you surely haven't shown any respect whatsoever, so if you feel like you haven't been shown respect, it should be obvious why.
Not that I'd want your respect, though.

 
Scali

May 03, 2005, 10:52 AM

Jacco Bikker wrote: I would like to say 'thanks!' to all the kind people who contributed to this fine result: Dummy (also known as El Pinto Grande, or TBP), his opponent Scali, and everyone who contributed just one or two posts. It's has been an honor.


Seriously though... I just wanted to start a discussion on better image quality in raytracers... Well, I started something alright, but not quite what I had in mind...
Do you or anyone else with a better signal-to-noise ratio than dummy have some thoughts on applying more advanced forms of texture filtering in raytracers?
I mean, does everyone think that AA is the way to go, or are my thoughts not as far-fetched as dummy would have us believe?

 
Jacco Bikker

May 03, 2005, 11:51 AM

You're barking up the wrong tree. First, texture filtering is not going to help reduce jaggies, AA does. Second, lots of triangles usually does translate in small triangles, like dummy states, so filtering does really not matter that much when you use extremely detailed models. I'll put it stronger: A sufficiently detailed model could even get away with vertex coloring and skip texturing altogether. Check out my previous IOTD, the Buddha statue: Almost no triangle covers more than 2 pixels. There's no filtering in the world that is going to improve that image. This model does have severe aliasing at the model boundaries, especially at low resolutions. AA will help considerably, at a low cost.

And finally, I have seen "dummy's" work, he knows what he is talking about. He has implemented a very fast ray tracer, AA, filtering, a 64bit version, a HT version and many other things. Of course he can be wrong, but I think he has considerable knowledge. I know he sometimes is not the best tutor, but you're not even trying to listen. That way, you are wasting a potential source of information.

 
dummy

May 03, 2005, 11:57 AM

Scali wrote: Oh really? From here it looks like you just blatantly insult anyone who questions whatever opinions you post (I really can't take "gcc rulez", without any kind of additional information as anything more than just your opinion).


Oh boy.

"on x86-64 the story is different as gcc rulez and you can use more neutral code.
And that's how i get >6Mray/s (IOTD view, not peak) with my own code on my box."
Fact. >6Mray/s with gcc, my code, on my box.

"I would not be surprised if icc generated better code than gcc in 64 bits... It never had much trouble doing it in 32 bits. And else there's the new MS compiler, which is probably even better than icc at most code."
Opinion. Note the use of 'would', 'probably' and 'most code'.

See the nuance?

You can question my methodology, options used for each compiler, code style etc.
But contradicting facts/data points with extrapolations/wild guesses is not only insulting but absolutely silly and totally irrelevant.
And it's not going to take you anywhere.

 
davepermen

May 03, 2005, 12:39 PM

well, the trick is.. in a raytracer, every pixel results in a ray that has only a direction. it doesn't have a width. so theoretically, you'd have to pointsample only for textures..

now of course, in reality, a pixel on the camera chip is not only capturing light rays from one direction, but from a small range. beam tracing would be the correct solution.

the practical approach is to sample rays of that beam, one for an aliased image, more to get more and more antialiasing. even with only point sampling, you'd get perfect filtering.


now actually, the only thing that mathers is "what does the texture represent?". if it is a grid of colours with linear transitions in between, you'd use linear sampling, if it is with stepping in between, you'd use point sampling. cosine sampling, cubic sampling would be other things.

but one thing remains true: there is NO need for anisotropic filtering, or mipmapping, or anything else. because one ray only needs to sample one point on the texture.

for everything else, you'd need additional info per ray, wich you don't always have. gradient information etc, to support correct mipmapping, or even anysotropic filtering. you could realtime estimate it like gpu's do for their ddx and ddy functions, as you work with ray-packets anyways. but it wouldn't been correct.

the only correct way is with antialiasing.


now i would support implmentation of stuff like bicubic or at least bicosine sampling. it wouldn't cost more samples, but a bit more math per sample (the weighting would be different. but actually, a lookuptable could even solve that..). so the bilinearity would go away, wich our eyes got trained over the tens of years to dislike because we see it much too often:D


now you state: anysotropic, mipmapping, etc, would be much cheaper than tracing additional rays. yes, this is true, for ordinary textures. but what if that texture would instead be a bumpmap, wich reflect the rays back into space? if it would just get mipmapped or anyostropic filtered, you would still just fire back one reflected ray. the texture would get filtering, the bumpmapped reflection on it wouldn't. en contraire, it would result in a very aliased reflection image, quite high frequent noise.

only antialiasing with supersampling solves all aliasing problems.

theres a big difference to rastericers. they most of the time rely on big detailed textures, and only need them antialiased as cheap as possible. but by today, we see that shader aliasing artefacts start to stress quite a bit. moving to procedural textures gets quite a no-no due to that.



conclusion:

there are two parts about texture filtering:
1) filtering at the sampling stage: what real function does the discrete function represented by the texture data approximate?
- stepping => pointsample
- linear planes => bilinear
- smooth "hills" => bicubic / bicosine
2) multisampling, subsampling to reduce aliasing (anisotropic filtering, mipmapping).


1) does still have to be supported, and as much functions can be implemented as you want. (another function is "bilinear x-y sampling, z realtime evaluated as sqrt(1-x^2-y^2), means recreation of a normalmap)

2) is essential in a rastericer due to it's nature, and it's very specific domain of applications. it is not really useful for raytracers. but still, they could be used as approximations and shortcuts.





so that was my big long statement about filtering. niam, just dreaming of reimplementing bicubic or bicosine sampling functions :D i'll have something to do tonight :D

 
davepermen

May 03, 2005, 12:42 PM

uhm.. theres a scali on opengl.org, and possibly even one on gamedev.. are you there sometimes, too?

espencially the one on opengl.org sometimes looks very narrowminded and closed towards new ideas and ideologies. wich put me into some stress situations against him quite some times :D

unsure if it's you :D doesn't mather. as i said, you have your points. sometimes i don't think they are right, but you at least have points :D but dummy has some points, too :D (espencially in the thread a bit lower about the >6MRays against your "possibly faster" statement..)


hihi

 
Scali

May 03, 2005, 12:50 PM

Jacco Bikker wrote: You're barking up the wrong tree. First, texture filtering is not going to help reduce jaggies, AA does.


Erm, ofcourse not. I wasn't talking about jaggies... I was talking about sampling problems of textures, as the one on the lego car, for example.

Second, lots of triangles usually does translate in small triangles, like dummy states, so filtering does really not matter that much when you use extremely detailed models.


Again I do not agree. Take for example a planar surface... no matter how many triangles you use, you will get minification problems if you are just relying on a bilinear filter. You'll need at least mipmapping... and then you get the problem of banding, so you'll need trilinear filtering too, if you use mipmaps.
Then generalize this to all surfaces that are 'reasonably planar', and the filtering problems still exist, even though they may be highly tesselated to have detailed curves.
Or in other terms... filtering is only dependent on the screenspace partial derivatives of the parameter.

Sure, you can throw lots of AA at it... but then you're basically mimicking mipmapping... you're effectively just downsampling the texture... only you're doing it after applying it to the model, not before...
And that's where my thoughts come in... I think AA is more expensive than prefiltering the textures and applying trilinear filter or such during rendering, at a lower AA setting.

As far as I know, most offline renderers use some kind of elliptical anisotropic filter.

I'll put it stronger: A sufficiently detailed model could even get away with vertex coloring and skip texturing altogether.


That's a different thing... and in that case, you'd still have to do interpolation of the vertex colours, if you don't want heavy aliasing... And that interpolation is effectively a filter aswell.

Check out my previous IOTD, the Buddha statue: Almost no triangle covers more than 2 pixels. There's no filtering in the world that is going to improve that image.


It's not a textured model, so obviously there is no texture aliasing, hence no texture filtering required.

And finally, I have seen "dummy's" work, he knows what he is talking about. He has implemented a very fast ray tracer, AA, filtering, a 64bit version, a HT version and many other things.


I'm not the one questioning other people's abilities. You're barking up the wrong tree.

Of course he can be wrong, but I think he has considerable knowledge. I know he sometimes is not the best tutor, but you're not even trying to listen. That way, you are wasting a potential source of information.


So far he's not given a lot of information, as far as I can tell... He seems to be too busy insulting me. Then again, perhaps I have missed some information hidden between insults. He should package it better then.

 
Scali

May 03, 2005, 01:01 PM

davepermen wrote: uhm.. theres a scali on opengl.org, and possibly even one on gamedev.. are you there sometimes, too?


Like I said, I only post here.
I think I have registered on gamedev at one point... but I can't recall the last time I posted there, if I posted at all...
And I most certainly haven't been to opengl.org, being as Direct3D is my weapon of choice, when it comes to 3d acceleration.

espencially the one on opengl.org sometimes looks very narrowminded and closed towards new ideas and ideologies.


Funny enough, it seems like I'm the one with 'new ideas and ideologies' (better texturefiltering in exchange for AA), and it's the other people that are being a bit narrowminded about it.

 
davepermen

May 03, 2005, 01:10 PM

hm.. cool, not the same as on opengl.org cool:D strange, too.. easy.

 
This thread contains 160 messages.
First Previous ( To view more messages, select a page: 0 1 2 3 4 5 ... out of 5) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.