scene size back

(L) [2006/06/12] [craouette] [scene size] Wayback!

Hello,


I am having problem with the shadows: sometime the triangle next to the current one (in the light dir) is reported as blocking the light, even if it is no the case. As the triangles are almost coplanar, I think this is a numerical problem.

How do you guys avoid this trouble ?


And a related question:

Is there a scale for the scene that minimize numerical problem? for example, if the scene bouding box is (-1, -1, -1) -> (1, 1, 1) all the floating points for ray/intersaction tests will be between -1 and 1 and the floating precision will be used at its maximum.



craouette
(L) [2006/06/14] [lycium] [scene size] Wayback!

iirc, the main point of floating point is to have equal precision in the mantissa across many scales; there are some ieee exactness guarantees for some operations in a certain range, but this doesn't help you most of the time. intuitively, using some of those exponent bits in addition to the mantissa ones (ie using more than just 1 order of [binary] magnitude in your scales) will definitely be better.


can't help with the first problem i'm afraid; never had problems with coplanar triangles and i can't imagine what might cause them.
(L) [2006/06/14] [greenhybrid] [scene size] Wayback!

What algorithm do you use?


I had some problems on ray-tri intersection, but that was on cw/ccw culling. At first I had möller-trumbore, which's orginal version did not intersect backfaces in my tracer. I've replaced it with the version Mr.Bikker mentioned in his tutorial on flipcode. And it worked fine.


I'd say, try out other intersection-algorithms.
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]
(L) [2006/06/14] [craouette] [scene size] Wayback!

I use the one of wald, juste added a test to support double sided face when needed: here is the test:
(L) [2006/06/14] [greenhybrid] [scene size] Wayback!

afaik the bikker version is nearly the wald version.

nevermind, I don't see an error. Maybe you should check the code for triangle-initialization again, lookup if the DOUBLESIDED-flag is set correctly.
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]
(L) [2006/06/14] [Phantom] [scene size] Wayback!

Nope I use the Plucker version. Wald's barycentric test takes less cycles for a hit, but it finds out about hit/not hit pretty late causing it to be less efficient on average. Also, the plucker version is more stable, numerically. And, not unimportant, it's easier to implement and requires less obfuscated preprocessed data.
_________________
--------------------------------------------------------------

Whatever
(L) [2006/06/14] [greenhybrid] [scene size] Wayback!

phantom: wasn't the one on your flipcode-tutorial barycentric? if not, excusez moi  [SMILEY Embarassed]
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]
(L) [2006/06/14] [craouette] [scene size] Wayback!

Yes, but as far as I understand it, the plukker version is quicker only if the test are performed with four rays with the same origin at the same time. Am I wrong ?
(L) [2006/06/14] [Phantom] [scene size] Wayback!

Yes it was. I switched to plucker recently, after reading Carsten's thesis.
_________________
--------------------------------------------------------------

Whatever
(L) [2006/06/14] [greenhybrid] [scene size] Wayback!

I know some people related to raytracing, but who's Carsten?  (I'm sure I've heard that name some weeks ago, but I don't remember)
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]
(L) [2006/06/14] [craouette] [scene size] Wayback!

look here:

[LINK http://ompf.org/forum/viewtopic.php?t=30]

post of the 3 march
(L) [2006/06/14] [greenhybrid] [scene size] Wayback!

ahh okay, thx.
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]
(L) [2006/06/14] [Lynx] [scene size] Wayback!

Stupid question, but doesn't the error shown above come from something completely different, i.e. geometric point (and geometric normal) suggesting shadow, but smoothed normal facing towards light? I think those points geometrically _do_ lie in shadow...
(L) [2006/06/14] [toxie] [scene size] Wayback!

What Lynx said is in fact the problem/solution. Your (interpolated) normal says it's not in shadow, whereas the geometry itself (=triangle) IS in shadow. No way to solve that except increasing triangle count or VERY dirty hacks.
_________________
what do you expect to do if you don't know what to do when you've got nothing to do?
(L) [2006/06/14] [craouette] [scene size] Wayback!

Yeah, you're right. I try to subdivide the sphere and the problem disapear...


thanks for the help!!!


craouette

back