|
 |
On 27-9-2018 20:29, Kenneth wrote:
> Thomas de Groot <tho### [at] degroot org> wrote:
>> On 27-9-2018 0:09, Kenneth wrote:
>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>
>>> BTW, I noticed a slight mistake in your code:
>>> [Given]
>>> //=======================================
>>> // TEST ROD
>>> // ======================================
>>> //Rod at position given by:
>>> //#declare screen_x_position = 260;
>>> //#declare screen_y_position = 850;
>>> cylinder {<0,0,0>, <0,100,0>,5 pigment {rgb <1,1,0>}
>>> translate <-2426.313, -269.700, -1300.118>
>>> }
>>>
>>> ..... but the actual translation that's returned from those screen
>>> percentages is
>>> translate <-2315.395, -298.978, -1668.753>
>>>
>>> There's still a position error, but not quite as large.
>>
>> That is bizarre because I literally copied the translation values from
>> the screen. So there seems to be a slight difference between computers
>> too...
>>
>
> Well, I discovered why we arrived at different values: It was a really simple
> and dumb mistake I made. I've been running your code tests at 800X600
> resolution; I didn't notice that your own tests used 1280X640. Uh, that does
> make a difference :-) Using your aspect ratio, my values now agree with yours.
> Duh. Sorry for the confusion-- and I'm glad it turned out to be so simple!!
Ouch! glad it is solved! I should have mentioned the change in aspect
ratio. One of the things I tested was if widely different aspect ratio's
influenced the outcome, but no.
Something I thought about this night: would the height_field resolution
influence the trace? compared to a primitive object? Answer: no, it does
not.
Next, after I restored the lineation on the height_field, I found
something for your thoughts. It appears, at least in my test file, that
the shift is /only/ along the z-axis, and furthermore, that the shift
approximates 200 pov units. Is that chance? Is it significant? I have no
idea (yet).
The restored height_field looks like this:
//start code
height_field {
function 500,500 {pattern {bozo scale 0.08}}
smooth
translate <-0.5, 0, -0.5>
texture {
pigment {
average
pigment_map {
[1.0 rgb <0.5, 1, 0.3>]
[0.6 gradient x frequency 100
color_map {
[0.07 rgb -0.3]
[0.07 rgb <0.7, 1, 0.7>]
}
]
[0.6 gradient z frequency 100
color_map {
[0.07 rgb -0.3]
[0.07 rgb <0.7, 1, 0.7>]
}
]
}
}
finish {ambient 0 diffuse 0.5}
}
scale HF_scale
translate -HF_scale.y*y
scale <1, 0.5, 1>
}
//end code
>>>
>>> As an experiment to see the effect of a changing camera angle, try this...
>
> Well, those values are now wrong as well :-O Although, it would still be useful
> for you to run two renders with vastly different camera angle values, to see how
> the found translation value gets more accurate at 'telephoto/zoom' settings.
I did, and the results are certainly better when using the zoom effect.
>
> BTW, Norbert's position-finder code also #debugs the found rotation/translation
> values to the message pane. My own (Windows) set-up for *using* those values is
> to go there, then EDIT/COPY PANE, then paste the contents into Windows' Wordpad
> or Notepad. Then, I re-copy the two values and simply paste them into my scene
> code. (Instead of copying them by eye from the preview render.) It's fast and
> foolproof.
>
> Meanwhile, I continue working...
>
Me too...
--
Thomas
Post a reply to this message
|
|
