On 19-9-2018 1:02, Kenneth wrote:
> Back in 2006, Norbert posted a really interesting macro 'tool' -- an object
> 'position finder' (or 'new object placer' as I call it)--that I've only recently
> become aware of. (Thanks, Thomas de Groot.) The code had a few flaws that I
> thought I would try and fix, as it's quite magical in what it does.  Norbert
> even mentioned at the time that in was not very mature. My own code is below, in
> a preliminary form. Currently, it's a stand-alone scene, for testing; I want to
> turn it into an include file eventually..
> 

Well done, sir! I have little time at this particular moment, but be 
sure that I am going to test your code. Just wanted you to know that I 
was aware.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Well done, sir! I have little time at this particular moment, but be
> sure that I am going to test your code. Just wanted you to know that I
> was aware.
>

Many thanks!

NOW, I'm finally going to take a leisurely look at your own code. I was on a
"mission from God" (as the Blues Brothers would say), to see how far I could get
on my own. Wow, did that hurt my brain!! Fun yet frustrating, at the same time.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> *The code seems to be more precise if, for cam_ang, you use more of a 'zoom'
> angle than a wide-angle (i.e., 30 is better than 67, for example.) This would
> just be temporary, until the new object is correctly placed and you no longer
> need the macro.
>

Hmm. The 2nd part of that little paragraph needs clarifying (only because the
code is presently a self-contained test scene): The accurate placement of an
object *depends* on the camera angle (cam_ang) staying the same. It needs to be
pre-set with whatever value you choose, and NOT changed (at least *while* using
the macro). For example, with a given set of...

cam_loc
lookat
cam_ang

....for the camera, the preview render will look the way you want, and you then
choose a 'point of interest' in the scene. If you then *change* cam_angle, that
chosen point will not be where you thought it would be-- since the essence of
the code is to work solely with the visual on-screen preview (which 'sets' the
point of interest BASED ON the three parameters.) A different cam_angle would
naturally create a different-looking on-screen preview.

Again, this caveat applies only to the current test scene set-up.

BTW, you CAN currently use the macro itself in one of your own scenes, to try it
out. Just make sure the three camera parameters match those of the 'real' camera
in your scene. (And the macro call needs to go somewhere AFTER your own scene
camera; the macro's built-in camera temporarily replaces it.) Once you've placed
your new object, you no longer need the macro, and you can then change your own
camera parameters to whatever you like.

Post a reply to this message

On 19-9-2018 11:38, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>
>> Well done, sir! I have little time at this particular moment, but be
>> sure that I am going to test your code. Just wanted you to know that I
>> was aware.
>>
> 
> Many thanks!
> 
> NOW, I'm finally going to take a leisurely look at your own code. I was on a
> "mission from God" (as the Blues Brothers would say), to see how far I could get
> on my own. Wow, did that hurt my brain!! Fun yet frustrating, at the same time.
> 
> 
> 

I like it! I really do, and I shall replace my own version with yours.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I like it! I really do, and I shall replace my own version with yours.
>

Thanks, glad to hear that it's useful!

I may re-instate my 'kludge' fixes for some of the remaining traced 'normal'
behavior; I found a way to include that stuff in a brute-force kind of way (it's
not very elegant code, but produces results.) I'm currently running more tests,
to see if there are *other* kludges that I need to add ;-)  If it all works out
in a satisfactory way, I'll post the updated macro here.

Post a reply to this message

On 23-9-2018 21:26, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>> I like it! I really do, and I shall replace my own version with yours.
>>
> 
> Thanks, glad to hear that it's useful!
> 
> I may re-instate my 'kludge' fixes for some of the remaining traced 'normal'
> behavior; I found a way to include that stuff in a brute-force kind of way (it's
> not very elegant code, but produces results.) I'm currently running more tests,
> to see if there are *other* kludges that I need to add ;-)  If it all works out
> in a satisfactory way, I'll post the updated macro here.
> 
> 

That would be excellent.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> > I like it! I really do, and I shall replace my own version with yours.

> >
> > I may re-instate my 'kludge' fixes for some of the remaining traced 'normal'
> > behavior...

I've just come across another subtle flaw in the code-- NOT normal-related--
that's probably been there since my *early* experiments. I  may have introduced
it with my own fixes, I don't know. Basically, *sometimes* the arrow or 'new'
object suddenly flips from one side of the preview render to the other. But it
happens only with certain juxtapositions of camera and lookat point, and their
positions relative to the x/y plane at the origin. It's strange that I didn't
see this flaw previously,  even after 100-plus tests of the code! (All my
previsous tests just happened to avoid this situation, amazingly.)

Luckily, I've been able to deduce the 'rules' that govern this behavior, so I'll
add a fix for it-- as soon as I figure out how ;-)

Post a reply to this message

On 25-9-2018 22:12, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>> I like it! I really do, and I shall replace my own version with yours.
> 
>>>
>>> I may re-instate my 'kludge' fixes for some of the remaining traced 'normal'
>>> behavior...
> 
> I've just come across another subtle flaw in the code-- NOT normal-related--
> that's probably been there since my *early* experiments. I  may have introduced
> it with my own fixes, I don't know. Basically, *sometimes* the arrow or 'new'
> object suddenly flips from one side of the preview render to the other. But it
> happens only with certain juxtapositions of camera and lookat point, and their
> positions relative to the x/y plane at the origin. It's strange that I didn't
> see this flaw previously,  even after 100-plus tests of the code! (All my
> previsous tests just happened to avoid this situation, amazingly.)
> 
> Luckily, I've been able to deduce the 'rules' that govern this behavior, so I'll
> add a fix for it-- as soon as I figure out how ;-)
> 

That is strange and I have no clue - nor experience - about this.

Something else though, troubles me from even before your work. There are 
scenes where the results from the trace are significantly away from the 
initial screen position given to the macro. I shall try to get a demo 
scene together where this is demonstrated.

-- 
Thomas

Post a reply to this message

On 26-9-2018 8:32, Thomas de Groot wrote:
> Something else though, troubles me from even before your work. There are 
> scenes where the results from the trace are significantly away from the 
> initial screen position given to the macro. I shall try to get a demo 
> scene together where this is demonstrated.
> 

I have got a test scene where the problem is demonstrated. I attach it 
here, together with a slightly changed version of your position finder 
and Gilles Tran's Visibility Test macro (which might be necessary). This 
last one I often use to get the right zoom value for the camera in order 
to calculate traces exactly within the visible screen scene. If I make 
myself understood... I don't think however, from my testing, that that 
influences the issue at hand in any way.

I am curious to learn what you think.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'islaytest.7z.zip' (6 KB)

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I have got a test scene where the problem is demonstrated. I attach it
> here, together with a slightly changed version of your position finder
> and Gilles Tran's Visibility Test macro...

Thanks! I will investigate this. Gille's macro is also new to me-- so
double-thanks for bringing it to my attention :-)

My many code trials have been real brain-twisters; sometimes one 'fix'
introduces yet another problem. At times, I've had to step away from the code to
regain my sanity ;-) But it's *slowly* improving as I continue work on it.

Post a reply to this message