 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is there some function or quick method of determining whether or not an
object blocks the line-of-sight between two points? The trace()
function, on its own, is subject to false positives. For example:
#declare Obstacle = torus { 3, 1 }
#declare Pt1 = <-1, 0, 0>;
#declare Pt2 = <1, 0, 0>;
#declare Test = <0, 0, 0>;
trace (Obstacle, Pt1, Pt2 - Pt1, Test)
The torus does not block the line of sight between Pt1 and Pt2, but the
trace() function isn't set up to make that distinction.
I have a rough idea for a solution in mind, but it is likely to be
costly in parse time. Is there already a built-in function that I've
missed, or a fast solution to this problem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Is there some function or quick method of determining whether or not an
> object blocks the line-of-sight between two points? The trace()
> function, on its own, is subject to false positives. For example:
>
> #declare Obstacle = torus { 3, 1 }
> #declare Pt1 = <-1, 0, 0>;
> #declare Pt2 = <1, 0, 0>;
> #declare Test = <0, 0, 0>;
> trace (Obstacle, Pt1, Pt2 - Pt1, Test)
>
> The torus does not block the line of sight between Pt1 and Pt2,
I think you'll find it does :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> wrote:
> Is there some function or quick method of determining whether or not an
> object blocks the line-of-sight between two points? The trace()
> function, on its own, is subject to false positives. For example:
>
> #declare Obstacle = torus { 3, 1 }
> #declare Pt1 = <-1, 0, 0>;
> #declare Pt2 = <1, 0, 0>;
> #declare Test = <0, 0, 0>;
> trace (Obstacle, Pt1, Pt2 - Pt1, Test)
>
> The torus does not block the line of sight between Pt1 and Pt2, but the
> trace() function isn't set up to make that distinction.
>
> I have a rough idea for a solution in mind, but it is likely to be
> costly in parse time. Is there already a built-in function that I've
> missed, or a fast solution to this problem?
I never learned of such a built-in function, but I think the following test will
not increase the parse time dramatically. Here your translated torus blocks the
sight.
#declare Obstacle = torus { 3, 1 translate <-2,0,0>}
#declare Pt1 = <-1, 0, 0>;
#declare Pt2 = <1, 0, 0>;
#declare TestDirection=Pt2-Pt1;
#declare Test = <1, 0, 0>;
#declare Hit=trace (Obstacle, Pt1, TestDirection, Test);
#declare ObstacleHit=false;
#if (vlength(Test)>0) // trace successful
#if (vlength(TestDirection)>vlength(Hit-Pt1) )
#declare ObstacleHit=true;
#end
#end
Problems can arise if your starting point Pt1 is very close to the obstacle
since POV has a precision issue comparing floating point numbers.
Best regards,
MIchael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 29/07/2015 08:49, scott a écrit :
>> Is there some function or quick method of determining whether or not an
>> object blocks the line-of-sight between two points? The trace()
>> function, on its own, is subject to false positives. For example:
>>
>> #declare Obstacle = torus { 3, 1 }
>> #declare Pt1 = <-1, 0, 0>;
>> #declare Pt2 = <1, 0, 0>;
>> #declare Test = <0, 0, 0>;
>> trace (Obstacle, Pt1, Pt2 - Pt1, Test)
>>
>> The torus does not block the line of sight between Pt1 and Pt2,
>
> I think you'll find it does :-)
>
1. it's the line of sight from Pt1 toward Pt2
2. trace report an intersection
3. if I'm correct, the intersection is after Pt2
internal clear area of Obstacle is -2 to 2 on X axis ( +/- 3 -/+ 1 )
You are both correct, it's only a matter of checking where is the result
of trace in regards to the pt1/pt2 segment, or not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/29/2015 02:46 AM, MichaelJF wrote:
> I never learned of such a built-in function, but I think the following test will
> not increase the parse time dramatically. [snip]
>
> [snip]
>
> #declare ObstacleHit=false;
> #if (vlength(Test)>0) // trace successful
> #if (vlength(TestDirection)>vlength(Hit-Pt1) )
> #declare ObstacleHit=true;
> #end
> #end
Thank you. I was afraid to try anything involving vlength() because of
the implicit square root calculation, but your idea turns out to be
faster than the other ideas I tried.
It seems that the complexity of the SDL makes more of a difference than
the complexity of the underlying calculation, at least in this case.
This now has me wondering what an LR(k) parser would do for POV-Ray
parse times.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.07.2015 um 17:10 schrieb Cousin Ricky:
> It seems that the complexity of the SDL makes more of a difference than
> the complexity of the underlying calculation, at least in this case.
Absolutely. As a general rule of thumb, the number of tokens processed
is the bottleneck, no matter what you do with SDL. (And remember that
SDL is an entirely interpreted language; no compilation done at all, so
tokens in loops are processed again and again and again.)
Unless you frequently call macros defined in a different source file.
Such macro calls are even significantly more expensive.
For heavy math, functions can be a way out, as those are parsed only
when defined.
> This now has me wondering what an LR(k) parser would do for POV-Ray
> parse times.
No need to dig deep into compiler theory - anything that's not a naive
interpreter, but does /some/ level of compilation instead, would be a
huge step forward ;)
POV-Ray's parser was fine as long as POV-Ray scene files were indeed
just plain scene descriptions. But the approach has become inadequate
ever since macros and loops were introduced.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31.07.2015 17:10, Cousin Ricky wrote:
> Thank you. I was afraid to try anything involving vlength() because of
> the implicit square root calculation, but your idea turns out to be
> faster than the other ideas I tried.
Note if all you do is comparing lengths you don't need the square
root, you can compare the squared sums instead (vdot(v,v)), but of
course the extra tokens may already be more expensive.
Even more directly you can test if P1 and Hit are on the same
side of P2:
#if (vdot(TestDirection,Pt2-Hit) >= 0)
// Hit (Pt1->Pt2 same direction as Hit->Pt2)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
