|
 |
On 2-9-2018 8:41, Thomas de Groot wrote:
> Anyway, find here my version attached.
>
I see (too late, sorry) that for my version you may need the following
macro too, but only for the testing of the position finder, otherwise
not. And you can replace that by your own stuff of course.
--
Thomas
Post a reply to this message
Attachments:
Download 'utf-8' (12 KB)
|
|
|
|
Mike Horvath <mik### [at] gmail com> wrote:
>
> Could you provide a sample where the script fails? I tried a +z to -z
> camera direction, as well as a wide angle, and the numbers seemed okay.
>
If you can pull up Norbert's original pristine file, add these test objects to
the scene (they're independent of his code-- they're just origin markers to see
what's going on)...
union{
cylinder{0,.4*x .012} // X
cylinder{0,.4*y .012} // Y
cylinder{0,.4*z .012} // Z
text{ttf "cyrvetic.ttf" "+ X" 0.1, 0 rotate 90*x scale .15
translate <.4,.03,0>} // " + X"
text{ttf "cyrvetic.ttf" "+ Y" 0.1, 0 scale .15
translate <-.1,.4,0>} // " + Y"
text{ttf "cyrvetic.ttf" "+ Z" 0.1, 0 rotate 90*x scale .15
translate <-.1,.03,.45>} // "+ Z"
translate .32*y
pigment{rgb <.2,.2,1>}
}
Now set his x_pos and y_pos variables to...
#declare x_pos = 20;
#declare y_pos = 90;
Now, run his code, with no no other changes. (Note that his camera is facing -z
by default, not the usual +z.) In the render, the 'positive' x-axis direction is
still facing to the right, when it should be to the left. (It's like the render
has been 'mirrored.') He does include a 'mirror' variable within the macro-- a
switch from +1 to -1 -- which will fix that-- but it also flips his on-screen
text (next to the arrow,) so don't use it.
Now, change his camera to a forward-looking one. Try this...
#declare cam_loc = <-.5,1.8,-3>;
#declare lookat = <.1,0.2,2>;
In this render, the axis markers look correct, the arrow's text looks correct--
but the arrow is actually on the wrong side of the screen now (left to right).
The x_pos of 20 should put it on the left, but it's now on the right.
Most of this behavior requires only minor fixes (some of which I've managed to
figure out, in a quick-and-dirty way) but I'm still testing things.
And I haven't yet taken a look at Thomas's newer code, to see what goodies he
has come up with...
Post a reply to this message
|
|
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 2-9-2018 3:54, Kenneth wrote:
> > Thomas, I've been playing around with [Norbert's] code, and I see where some
> > improvements can be made...
>
> You are right. Over time, I have "improved" on the code, one of the
> improvements being the possibility to use true 2D screen coordinates
> instead of percentages. Also that "facing" problem is more or less
> tackled I think, although I regularly have cases where it does not work.
> However, It mostly works and I light a candle to Saint Norbert each
> time. :-)
>
> Anyway, find here my version attached.
>
hey, I think I've figured out most of the needed changes-- after a marathon
coding session ;-) I still haven't taken a look at your own code (yet!) ; I
first wanted to see what I could come up with. I'll probably post my version
(along with some needed instructions on how to use it), but I'll do it
elsewhere, so as not to hi-jack this thread any further.
It will be fun to compare the two independent approaches we've come up with.
Post a reply to this message
|
|
|
|
On 9/2/2018 3:43 AM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>>
>> Could you provide a sample where the script fails? I tried a +z to -z
>> camera direction, as well as a wide angle, and the numbers seemed okay.
>>
>
> If you can pull up Norbert's original pristine file, add these test objects to
> the scene (they're independent of his code-- they're just origin markers to see
> what's going on)...
>
Oh, I wasn't sure if you were talking about Norbert's script or
"screen.inc".
Mike
Post a reply to this message
|
|
