On 27-9-2018 20:29, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> 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