I just wanted to write back to the list to give thanks for the thoughts on
this.

I see that a couple of my issues have resulted from the fact that I was
manipulating the normal QC camera in two different ways, and that when doing
so different render patches do not respond exactly the same. I was using a
"Sprite" as a generic term for any renderer, but I am noting differences
between the way that QCMesh, Sprites, and certain 3rd party renderers "line
up". I'm also having some kind of issue with certain patches not responding
to RII in the same way. I'll try to narrow this stuff down and report to
appropriate parties.

I also want to thank Louis for some off-list food for thought on these type
of placement/math issues in general.

Best,
George Toledo

On Sat, Sep 11, 2010 at 1:40 AM, Alastair Leith <[email protected]>wrote:

> I think what George had in mind (guessing here!) is spinning the sprites
> on on X & Y axes to *reveal* the cleverly disguised depth differences when
> viewed with Stereoscopic projection.
>
>
>
> I don't have that kind of gear but you can get a hint with depth testing.
> In this comp the two sprites intersect when Z Pos = [0,-1] for the green
> sprite (LHS). When the Z Pos is <-1 for the green sprite, it always appears
> behind — even when it 'looks' like it could be in front from the yaw/pitch
> positions of the sprites.
>
> I wrote an email (thought better of sending) last night saying that I guess
> (again) George is doing something more complicated in terms of 3D
> transformations/GL Trickery if the *Size is Inversely Proportional to
> Distance from Camera* rule (as demonstrated with Achim's demo) isn't
> working for him. Illustrators and now animators have been using that
> principle since Alberti so it's pretty established. It's easy enough to
> prove for yourself with some similar triangles and Euclidian geometry. I
> guess George must know that because he was already trying it but he seemed
> like he was dismissing the value in stating this as a first principle
> towards the solution (which I think is worth contributing, obviously :?).
>
> Also Dr Mark Wright was not guessing, he was correct about inverse law but
> declared his false assumption (and therefore got the coefficient wrong) when
> he said: "default camera is some distance away already and its not set to 1.
> If the default distance was 2 units then another z unit would need 0.667
> shrink to simulate." Camera is not at (0,0,2). cwright just emailed the
> correct position (which I couldn't remember so thanks!)
>
>
> On 11/09/2010, at 6:13 AM, Achim Breidenbach wrote:
>
> Hello George,
>
> due to some inspiration of other posts in this thread, I think I have the
> correct factor: 0.57735
>
> which is 1 / 1.73205
> 1.73205 is the position of the camera in QC, which someone calculated in
> another post some weeks ago. (= tan(60°)) (sorry, I cant find the post nor
> the author, but I remember the result)
>
> Don't ask me why 0.57735 is equal to tan(30°)...
>
> Find attached my corrected composition.
>
> On the other Hand: Aren't you searching for the exact opposite? Don't you
> want to have a 2D image split into some depth planes and position them in 3D
> space that way, that they match exactly to the 2D image from a certain point
> of view? And when you move the camera slightly you see, that it is actually
> planes spread in 3d space? I am not sure what your effect should look like.
>
> Best,
>
> Achim Breidenbach
> Boinx Software
>
> <z vs width 2.qtz>
>
> On 09.09.2010, at 19:55, George Toledo wrote:
>
> Cool, thanks - Achim, I looked at the qtz you got it more or less (the math
> reduced sprite is still slightly larger).
>
> I basically want to know the *exact *number, from Apple (or really, from
> anyone, but not a visual comparison/kinda close thing, like this).
>
> -George Toledo
>
> On Thu, Sep 9, 2010 at 12:45 PM, Achim Breidenbach <[email protected]>wrote:
>
>> Hello George,
>>
>> find attached a composition that does the z to width conversion. There is
>> a factor of 0.55 in the equation which I filled in by try-and-error. Don't
>> ask my where this value comes from. Anyone?
>>
>> Best,
>>
>> Achim Breidenbach
>> Boinx Software
>>
>>
>>
>>
>> On 09.09.2010, at 17:48, George Toledo wrote:
>>
>> > What kind of equation would be needed to utilize Z coordinates in QC in
>> a way that doesn't change Z translation, but could be used to reduce X/Y
>> scale in a way that makes the object appear to be equivalent size that they
>> would be if translated in Z? In addition, is it possible to emulate the
>> apparent reduction/exaggeration of horizontal or vertical movement of a
>> sprite as it is moved in z by performing math on x/y translations on an
>> object where z isn't at 0?
>> >
>> > Forgetting the x/y translate, it would be nice to know the equation to
>> make a sprite the same size it is at z=-1, z=-2, z=-3 and so on, by
>> manipulating x/y scale for instances when one wants everything to work in
>> only 2 dimensions. The relation isn't linear, and I'm not sure how to back
>> into it.
>> >
>> > If this has been covered, forgive me.
>> >
>> > -George Toledo
>> > _______________________________________________
>> > Do not post admin requests to the list. They will be ignored.
>> > Quartzcomposer-dev mailing list      (
>> [email protected])
>> > Help/Unsubscribe/Update your Subscription:
>> >
>> http://lists.apple.com/mailman/options/quartzcomposer-dev/achim%40boinx.com
>> >
>> > This email sent to [email protected]
>>
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
>
> http://lists.apple.com/mailman/options/quartzcomposer-dev/qc.student.au%40gmail.com
>
> This email sent to [email protected]
>
>
>
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
>
> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com
>
> This email sent to [email protected]
>
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to