Jump to content

  • Log In with Google      Sign In   
  • Create Account


Raytracing Artifacts


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Tom Savage   Members   -  Reputation: 110

Like
1Likes
Like

Posted 14 November 2012 - 04:46 PM

I'm currently working on an experimental raytracer which is currently presenting me with a strange artifact that I can't explain.

If you look at the first attached file, you will see an example render (1 sample per pixel). On the right-hand side, there is a noisy band in line with the light source (red sphere). I've added arrows to point out the noisier areas.

When I increase the number of samples - the noise is averaged out and disappears, but has a blurring effect (visible in the second attached image).

Moving the light source will move the artifact as well. It always appears in line with it, moving across the x axis

Has anyone seen this sort of effect before?

Attached Thumbnails

  • success5-1s-annotated.png
  • success5-100s-annotated.png


Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8133

Like
0Likes
Like

Posted 14 November 2012 - 08:19 PM

I've never seen this before. What does the code look like?

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Necrolis   Members   -  Reputation: 1244

Like
4Likes
Like

Posted 14 November 2012 - 10:28 PM

I've seen something very similar to this this, turned out to be precision issues with shadow rays, that is is the ray was intersecting with the surface it was shot from, even though it should be starting from the surface, adding a small offset/bias fixed the problem. it might be a similar issue in your case.

#4 Tom Savage   Members   -  Reputation: 110

Like
0Likes
Like

Posted 15 November 2012 - 06:15 AM

I've never seen this before. What does the code look like?


The render is written in Haskell. I'm not sure if many people here are too familiar with it but here's an intersection routine for spheres: https://gist.github.com/4078346


I've seen something very similar to this this, turned out to be precision issues with shadow rays, that is is the ray was intersecting with the surface it was shot from, even though it should be starting from the surface, adding a small offset/bias fixed the problem. it might be a similar issue in your case.


I suspected floating point precision and already have a minimum distance I will allow for intersections (epsilon in the sample above). I've tried increasing it with no effect. How similar was your example to this one?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS