fidos wrote:
> I was quite
> disappointed because I leaved it running for 24h on 4 cores and still some
> noise remain...

24 hours on 4 cores...

well, despite the long render times of path tracing and still noise and 
fireflies, at least one of the main complains of JVP himself, if I 
remeber correctly, has been solved:  the metallic blurred reflections on 
the fridge handles show no aliasing problems. :)

keep it up...

Post a reply to this message

Severi Salminen wrote:
>  I simply love the idea of brute force rendering:
> no need to tweak 30 parameters to get perfect results.

brute force methods like path tracing or finite step methods like photon 
mapping are just different methods of solving the infamous "rendering 
equation".  The finite step methods give very reasonable results in far 
shorter times in exchange for a little tweaking.

In povray, neither radiosity nor photon mapping really require all that 
amount of parameters to be tweaked, because there's not that much and 
the defaults are sensible enough.  More likely you'll just need 
experience and knowledge to get right the 5 or 6 parameters that really 
need tweaking...

Post a reply to this message

nemesis wrote:

> In povray, neither radiosity nor photon mapping really require all that
> amount of parameters to be tweaked, because there's not that much and
> the defaults are sensible enough.  More likely you'll just need
> experience and knowledge to get right the 5 or 6 parameters that really
> need tweaking...

Basically I agree: this is a tradeoff between rendering time and
tweaking time. And usually the tweaking takes less time. But, for
example, in this thread there is still no good rendering of the original
scene from Povray - without the use of lightsources. And if you use
light sources you have to add more parameters to tweak. With bruteforce
you get everything correct with no tweaking at all. And that is why I
like it.

But I admit: the speed difference is still big. So big that the benefits
of brute force still don't make it practical for productive work.

Post a reply to this message

nemesis <nam### [at] nospamgmailcom> wrote:
> In povray, neither radiosity nor photon mapping really require all that
> amount of parameters to be tweaked, because there's not that much and
> the defaults are sensible enough.  More likely you'll just need
> experience and knowledge to get right the 5 or 6 parameters that really
> need tweaking...

That might be true a lot of the time, but I have several scenes that I can't
render completely correctly with radiosity. No matter what I do with the
parameters (and they are mostly speed-juggling parameters, remember), there
simply aren't enough samples gathered to completely eliminate artifacts,
especially at high resolutions.

I have a question concerning this new approach however. Could the number of rays
be limited for particular objects? Many parts of the scene may reach acceptable
quality long before others, so continuing sample gathering only for particular
scene elements would surely speed up the process. This might be done
automatically, or explicitly set in the SDL.

Possible? Difficult? Impossible? Laughable?

answers on a postcard, please!

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> I have a question concerning this new approach however. Could the number of rays
> be limited for particular objects? Many parts of the scene may reach acceptable
> quality long before others, so continuing sample gathering only for particular
> scene elements would surely speed up the process. This might be done
> automatically, or explicitly set in the SDL.
In the posted renderings, the ray are shooted in priority were noise remain. Not
exactly the same than your proposal but very efficient.

Regards,
Fidos

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> That might be true a lot of the time, but I have several scenes that I can't
> render completely correctly with radiosity. No matter what I do with the
> parameters (and they are mostly speed-juggling parameters, remember), there
> simply aren't enough samples gathered to completely eliminate artifacts,
> especially at high resolutions.

I wish povray dropped the old radiosity engine in favor of the photon mapping
industry standard for GI, not just caustics.  Photon mapping seems to solve
many problems that radiosity can't, including more sharp shadow projections,
subsurface scattering etc.

> I have a question concerning this new approach however. Could the number of rays
> be limited for particular objects?

like in "tweaking a scene by hand to get faster renderings"?

Post a reply to this message

Severi Salminen wrote:

> At present I can only draw the balls with one color by finding
> ray-sphere intersections. So no lighting at all. But at least it works.

And now I can do a lot more. May I proudly present the first real render
of my simple ray tracer! Sorry, no checkered floor :( I took maybe 30+
minutes or so on one core. The depth was 3 (ie. you can see balls
illuminated by indirect lighting from surfaces that were lit directly).
There are no optimizations and it can only handle balls of various
colors. But I still love the simplicity! No settings to tweak, just let
it go.

The hardest part was to figure out that I had a lousy algorithm for
producing randomly distributed rays over hemisphere area. They were sooo
not random and produced some odd artifacts. Now I use something like this:

y = sqrt(rand(0..1))
theta = acos(y)
phi = 2*pi*rand(0..1)

x = sin(theta)*cos(phi)
z = sin(theta)*sin(phi)

And then I rotate it according to the intersection point normal. Things
to do in near future:

1. Optimizations to make it faster :) Have to look at that portal thing.
Fidos, any good source of info on portals??
2. Have to check that I'm actually doing everything now properly. It
looks OK to me but you never know.
3. More objects.

Post a reply to this message

Attachments:
Download 'render1.jpg' (19 KB)

Preview of image 'render1.jpg'

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Severi Salminen wrote:
It looks very well starting.

> 1. Optimizations to make it faster :) Have to look at that portal thing.
> Fidos, any good source of info on portals??
I don't have source info. The idea is to help paths to find the light with fake
objects. This objects are shooted in priority.

Post a reply to this message

A new rendering with the scene of the patio of Jaime Vives Piqueres
(http://www.ignorancia.org/en/index.php?page=Patio).

The redering took 16h on the 4 cores of a Q6600 !

Any comments wellcome.

Regards,
Fidos

Post a reply to this message

Attachments:
Download 'patio.jpg' (434 KB)

Preview of image 'patio.jpg'

fidos wrote:
> The redering took 16h on the 4 cores of a Q6600 !

whoohoo!!  poor us mortal povvers... ;)

hmm, some weird shadows from the plants near the fountain that I don't 
recall in the original scene... perhaps other angle for the light source 
(or whatever other bright object simulating the sun)?

Post a reply to this message