<div class="gmail_quote">On 12 January 2012 01:15, F i L <span dir="ltr"><<a href="mailto:witte2008@gmail.com">witte2008@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes the lib would supply standard operations, probably even a matrix type or 2.<br>
</blockquote>
<br></div>
Okay cool. That's basically what I wanted to know. However, I'm still wondering exactly how flexible these libraries will be.</blockquote><div><br></div><div>Define 'flexible'?</div><div>Probably not very flexible, they will be fast!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have some code of more complex operations?<br>
</blockquote>
<br></div>
My main concern is with my "transition" objects. Example:<br>
<br>
   struct Transition(T) {<br>
       T value, start, target;<br>
       alias value this;<br>
<br>
       void update(U)(U iteration) {<br>
           value = start + ((target - start) * iteration);<div class="im"><br>
       }<br>
   }<br>
<br>
<br>
   struct Vector4(T) {<br>
       T x, y, z, w;<br>
<br></div>
       auto abs() { ... }<br>
       auto dot() { ... }<br>
       auto norm() { ... }<br>
       // ect...<br>
<br>
       static if (isTransition(T)) {<br>
           void update(U)(U iteration) {<br>
               x.update(iteration);<br>
               y.update(iteration);<br>
               z.update(iteration);<br>
               w.update(iteration);<br>
           }<br>
       }<br>
   }<br>
<br>
<br>
   void main() {<br>
       // Simple transition vector<br>
       auto tranVec = Transition!(Vector4!float)();<br>
       tranVec.target = {50f, 36f}<br>
       tranVec.update(0.5f);<br>
<br>
       // Or transition per channel<br>
       auto vecTran = Vector4!(Transition!float)();<br>
       vecTran.x.target = 50f;<br>
       vecTran.y.target = 36f;<br>
       vecTran.update();<br>
   }<br>
<br>
I could make a free function "auto Linear(U)(U start, U target)" but it's but best to keep things in object oriented containers, IMO. I've illustrated a simple linear transition here, but the goal is to make many different transition types: Bezier, EaseIn, Circular, Bounce, etc and continuous/physics one like: SmoothLookAt, Giggly, Shaky, etc.<br>
</blockquote><div><br></div><div>I don't see any problem here. This looks trivial. It depends on basically nothing, it might even work with what Walter has already added, and no libs :)</div><div>I think the term 'iteration' is a bit ugly/misleading though, it should be 't' or 'time'.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My matrix code also looks something like:<br>
<br>
   struct Matrix4(T)<br>
    if (isVector(T) || isTransitionOfVector(T)) {<div class="im"><br>
       T x, y, z, w;<br>
   }<br>
<br></div>
So Transitions potentially work with matrices in some areas. I'm still new to Quarternion math, but I'm guessing these might be able to apply there as well.<br></blockquote><div><br></div><div>I would probably make a transition of matrices, rather than a matrix of vector transitions (so you can get references to the internal matrices)... but aside from that, I don't see any problems here either.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So my main concern is how SIMD will effect this sort of flexibility, or if I'm going to have to rethink my whole model here to accommodate SSE operations. SIMD is usually 128 bit right? So making a Vector4!double doesn't really work... unless it was something like:<br>

<br>
   struct Vector4(T) {<br>
       version (SIMD_128) {<br>
           static if (T.sizeof == 32) {<br>
               __v128 xyzw;<br>
           }<br>
           else if (T.sizeof == 64) {<br>
               __v128 xy;<br>
               __v128 zw;<br>
           }<br>
       }<br>
       version (SIMD_256) {<br>
           // ...<br>
       }<br>
   }<br>
<br>
Of course, that would obviously complicate the method code quite a bit. IDK, your thoughts?<br>
</blockquote></div><br><div>I think that is also possible if that's what you want to do, and I see no reason why any of these constructs wouldn't be efficient (or supported).</div><div>You can probably even try it out now with what Walter has already done...</div>