On 12 January 2012 01:15, F i L <[email protected]> wrote:
> Manu wrote:
>
>> Yes the lib would supply standard operations, probably even a matrix type
>> or 2.
>>
>
> Okay cool. That's basically what I wanted to know. However, I'm still
> wondering exactly how flexible these libraries will be.
Define 'flexible'?
Probably not very flexible, they will be fast!
> Have some code of more complex operations?
>>
>
> My main concern is with my "transition" objects. Example:
>
> struct Transition(T) {
> T value, start, target;
> alias value this;
>
> void update(U)(U iteration) {
> value = start + ((target - start) * iteration);
>
> }
> }
>
>
> struct Vector4(T) {
> T x, y, z, w;
>
> auto abs() { ... }
> auto dot() { ... }
> auto norm() { ... }
> // ect...
>
> static if (isTransition(T)) {
> void update(U)(U iteration) {
> x.update(iteration);
> y.update(iteration);
> z.update(iteration);
> w.update(iteration);
> }
> }
> }
>
>
> void main() {
> // Simple transition vector
> auto tranVec = Transition!(Vector4!float)();
> tranVec.target = {50f, 36f}
> tranVec.update(0.5f);
>
> // Or transition per channel
> auto vecTran = Vector4!(Transition!float)();
> vecTran.x.target = 50f;
> vecTran.y.target = 36f;
> vecTran.update();
> }
>
> 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.
>
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
:)
I think the term 'iteration' is a bit ugly/misleading though, it should be
't' or 'time'.
My matrix code also looks something like:
>
> struct Matrix4(T)
> if (isVector(T) || isTransitionOfVector(T)) {
>
> T x, y, z, w;
> }
>
> 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.
>
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.
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:
>
> struct Vector4(T) {
> version (SIMD_128) {
> static if (T.sizeof == 32) {
> __v128 xyzw;
> }
> else if (T.sizeof == 64) {
> __v128 xy;
> __v128 zw;
> }
> }
> version (SIMD_256) {
> // ...
> }
> }
>
> Of course, that would obviously complicate the method code quite a bit.
> IDK, your thoughts?
>
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).
You can probably even try it out now with what Walter has already done...
