<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with z translate]]></title><description><![CDATA[A list of topics that have been tagged with z translate]]></description><link>https://community.troikatronix.com/tags/z translate</link><generator>RSS for Node</generator><lastBuildDate>Wed, 19 Aug 2026 00:06:48 GMT</lastBuildDate><atom:link href="https://community.troikatronix.com/tags/z translate.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 05 Dec 2020 13:49:37 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Compute z translate for fullscreen image at any ratio]]></title><description><![CDATA[<p><br /></p><p>Thanks for your answers guys. The math is indeed a bit odd. Since I have 33 projections surfaces which all have differents ratios, I can tell that the z translate value is "ratio dependant", but it is still unclear in which ways. And it clearly depend of the 3D projector style.<br /></p>
<p>
In the mean time, I progressed quite a bit. Here is what I came up with, as a reference and in the hope it might help others :</p>
<p>- First, I ended up using 3D rect project because it was more suited for the tilting effect I was trying to achieve. (you can easily change the horizontal and vertical reference, which allows to rotate around the border of the image)</p><p>- As the 3D rect is more of a 3D square (doesn't respect the texture ratio by default), the ratio has to be adapted afterwards. And this is a really strange input range. In case, the javascript function that does the ttrick :<br /></p><p>function main()<br />{<br />    var x = arguments[0] // Size in px of input stream<br />    var y = arguments[1] // Size in px of output stream</p><p>    // The output goes in "aspect mod" of 3D Rect projector</p><p>    if (x &lt; y){<br />        return -100 * ( y/x ) +100<br />    }else if (x &gt; y) {<br />        return 100 * ( x/y ) -100<br />    }else {<br />        return 0<br />    }<br />}   </p><p>- For the Z values, I brute forced it also, with something like that (It's inside a user actor, which I have 33 instances of, so each get his own little z value)<br /></p><p><a href="/assets/uploads/files/1607172366077-z-values.jpg"></a></p><p>For the brute forcing itself, I did this : (this is quite a mess, but basically I generate two background colors with one pixel of difference, I send it to the corresponding virtual stage. Then the virtual stage is grabbed, and displayed on the "preview stage" with a normal projector. This way I can see clearly when the yellow border touches the blue border, and using a midi controller (with a few knob, each doing a different factor 10 increment) I managed to achieve excellent precision quite smoothly.</p><br />
<p></p><p>- So, quite a mess I have to say. A "match stage target size" actor that would have been nice, clearly. But each of the 33 virtual stage is re-projected on the main stage (called Real VP here) using a similar mechanism and a 3D Quad Distort projector to match then angle of the scenery (the scenery is 33 actual frames) so at the end I was able to re-use 80% of my calibration mechanism" for this other purpose, so it was less of a waste of time than I originally belived.</p><p>On the bright side, the result is pretty cool ...<br /><br /></p><br /><br />]]></description><link>https://community.troikatronix.com/topic/7018/compute-z-translate-for-fullscreen-image-at-any-ratio</link><guid isPermaLink="true">https://community.troikatronix.com/topic/7018/compute-z-translate-for-fullscreen-image-at-any-ratio</guid><dc:creator><![CDATA[Yinameah]]></dc:creator><pubDate>Sat, 05 Dec 2020 13:49:37 GMT</pubDate></item></channel></rss>