 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> Is this what POV-Ray actually uses for the intersection of a ray and a
> sphere? I just spent half an hour working out both the geometrical
> interpretation of this and its equivalence to the result of the quadratic
> equation with the coefficients that Andrew posted, and I'm really impressed
> at how simple it is. And annoyed at the fact that I never could have come up
> with it myself =)
Yeah, Pov uses the exact same method. It is very simple and fast method.
Pov also has one additional check, which I'm not sure is worth it. POV
also returns both hits always. I only return the hit in front of the
ray. I have no use for the other.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> Yeah, Pov uses the exact same method. It is very simple and fast method.
> Pov also has one additional check, which I'm not sure is worth it. POV
> also returns both hits always. I only return the hit in front of the
> ray. I have no use for the other.
It's used for CSG. (E.g., if you "difference" the sphere against
something else, the "back" intersection might actually be where the
solid surface begins.)
[Mutters something about Haskell and lazy evaluation...]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> Warp wrote:
> > That's the reason why you can't, for example, scale something by 0.
> > Inverting that matrix would result in a division by 0.
> Presumably it would also result in an invisible object too though. ;-)
Not if you scale by 0 on only one axis.
> Does POV-Ray actually apply all the matricies and invert only the final
> one? Or does it construct them in inverted form in the first place?
IIRC it calculates the inverted matrices when parsing and uses them
when rendering.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Presumably it would also result in an invisible object too though. ;-)
>
> Not if you scale by 0 on only one axis.
Ah, good point...
>> Does POV-Ray actually apply all the matricies and invert only the final
>> one? Or does it construct them in inverted form in the first place?
>
> IIRC it calculates the inverted matrices when parsing and uses them
> when rendering.
I thought that would be the case.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 14 Mar 2008 11:41:35 +0200, Severi Salminen wrote:
> 2. What does "ucomisd %xmm0, %xmm0" effectively do? It compares the same
> register.
Checks whether the low double precision floating point value
in the register is (non-)zero.
In the SSE architecture, an instruction such as "por" does not affect
the flags, so the familiar x86 way of "or eax, eax" to set flags would
not work on SSE.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> It's used for CSG. (E.g., if you "difference" the sphere against
> something else, the "back" intersection might actually be where the
> solid surface begins.)
Hmm. I still don't get it. Why should I ever need to trace the ray in
the "wrong direction"?
The ray starts at camera and goes forward. If anything interesting is
found, it is in front of the ray, right? And the only exception is if
the camera is inside an object. But even then: shouldn't it be enough to
trace forward. Please enlighten me :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> Invisible wrote:
>
>> It's used for CSG. (E.g., if you "difference" the sphere against
>> something else, the "back" intersection might actually be where the
>> solid surface begins.)
>
>
> Hmm. I still don't get it. Why should I ever need to trace the ray in
> the "wrong direction"?
>
> The ray starts at camera and goes forward. If anything interesting is
> found, it is in front of the ray, right? And the only exception is if
> the camera is inside an object. But even then: shouldn't it be enough to
> trace forward. Please enlighten me :)
You will never need an intersection from *behind* the camera.
However, a ray typically intersects a sphere in two places. POV-Ray
generates both points of intersection because you might need them both.
(E.g., if the object is transparent, you'll want to trace a ray out of
it. If the object is involved in CSG with other objects, the "back"
surface might actually be the first visible surface. etc.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> However, a ray typically intersects a sphere in two places. POV-Ray
> generates both points of intersection because you might need them both.
> (E.g., if the object is transparent, you'll want to trace a ray out of
> it. If the object is involved in CSG with other objects, the "back"
> surface might actually be the first visible surface. etc.)
Ok, but I guess that you can still handle all cases with an intersection
routine that only returns the point in front of the ray?
1. If the object is transparent, you first enter the object and then exit.
2. In CSG the same applies: you still have to first enter all the
participating objects to calculate the outcome.
So this is not something that is mandatory but a convenience?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> So this is not something that is mandatory but a convenience?
Pretty much, yes.
(Although if you're bothering to compute the coefficients of a quadratic
equation, it seems a shame to compute them all over again to find the
second point of intersection...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> (Although if you're bothering to compute the coefficients of a quadratic
> equation, it seems a shame to compute them all over again to find the
> second point of intersection...)
Well, I use the simplified form I posted to this thread. It is
computationally quite simple. So it all boils down to how often you
actually need the "unneeded" intersection and what is the net effect. I
haven't measured it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
