[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] State of the math branch



I think there are many cases where one might want, say, the halfway
rotated quat between two, or due to varying framerates with things
like network code, (or even just for animation purposes) you might
want to have varying rates, or skip to a different t value. I don't
see how an iterator would be useful in these cases. You would have to
do a 2 step rotation once to get the midway rotation, iterating an
iterator once is pretty unintuitive; and for varying speeds during a
rotation, you would need to recalculate a new iterator every frame.

I haven't looked at it, but intuitively it seems to be trying to wedge
one concept into a very different one. If there were only one
implementation, I would much prefer the t version.

On Sat, Nov 14, 2009 at 11:06 AM, Lorenz Quack <don@xxxxxxxxxxxxxxxxx> wrote:
> Hi René,
>
> René Dudfield wrote:
>>
>> Feel free to merge it into the trunk.  It'll be easier for other
>> people to try it out(binaries, and other things hooked up with trunk),
>> and you can also use the build bot to check for errors on other
>> platforms(like compilation/testing).
>
> Ok. I'll see if I can make it this weekend.
>
>> The (s)lerp idea with the iterator seems a good one.  I've been
>> thinking about doing something like that with line drawing
>> functions... that instead of drawing return the (x,y) coords of where
>> it would draw pixels.  I wonder if it still might be useful to let
>> people supply a t argument, just because people are used to it...
>
> My hope is that the iterator is intuitive enough so nobody will miss the
> t-version. also my version should perform better because it only
> calculates a rotation-matrix once while otherwise you would have to
> recalculate it on every call for the new t-value.
> So for now I would stay with:
> "There should be one-- and preferably only one --obvious way to do it."
> and wait and see if there is strong demand for a t-argument version.
>
>> However, they could just supply one step.
>
> unfortunately I don't think it's that easy to convert from the iterator
> interface to the t-arg interface. you would have to something like this:
>
> def slerp_t(start_vec, end_vec, t):
>    idx, steps = t.as_integer_ratio() # new in python 2.6
>    return list(start_vec.slerp(end_vec, steps))[idx]
>
> which is pretty ugly.
>
>> I guess there is going to be a 4 element quaternion?  What about a
>> Vector4?  Which matrix sizes are you thinking of doing?  I guess 3x3,
>> 3x4 and 4x4?  Or just 4x4?
>
> I was planing on implementing quaternions and only square matrices.
> Is there a use for Vector4? Implementing it would be quite easy but
> do we need it?
> Also, what would be a use case for non-square matrices?
>
>> I noticed one commit log said there was trouble with the buffer
>> interface?  Is this part still a trouble?
>
> Yea. I didn't really understand which parts of the buffer protocol belong
> to the 2.x protocol and which belong to 3.x and what should be supported.
> In general I found this topic a bit confusing and the docs didn't help.
> I have to look into that some other time when I've got the nerve for it.
>
>> Functions like vector_elementwiseproxy_mul,
>> vector_elementwiseproxy_sub etc, could probably share a lot of code,
>> and then for the different part use a switch statement to do the
>> different function.  Something like this:
>>
>> static PyObject *
>> vector_elementwiseproxy_mul(PyObject *o1, PyObject *o2) {
>>    return vector_elementwiseproxy_generic(o1, o2, VECT_OPS_MUL);
>> }
>>
>> Where the vector_elementwiseproxy_generic function would have the
>> switch statement on the various flags passed in.
>
> I'll take a look at it.
>
> thanks for the feedback. looking forward to more of it :)
>
> yours
> //Lorenz
>
>>
>> On Thu, Nov 12, 2009 at 10:31 AM,  <don@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi List,
>>>
>>> I just wanted to give you a short summery of the development in the math
>>> branch.
>>> The goal of the math branch is the inclusion of several math related
>>> types
>>> like vectors, matrices and quaternions.
>>>
>>> Right now I consider the implementation of vectors in 2 and 3 dimensions
>>> as
>>> feature complete.
>>> What this means is that I can't think of more functionality that I want
>>> to
>>> implement and all methods pass their unit tests.
>>> I encourage everyone interested to take a look and make suggestions if
>>> they
>>> find functionality missing.
>>>
>>> The current version is not written for maximum performance.
>>> For example Vector2 and Vector3 share many functions so no dimension
>>> specific
>>> optimizations are implemented. So the current implementation should be
>>> considered a baseline for future optimizations.
>>> To gauge future improvements I intend to write a rudimentary performance
>>> benchmark.
>>>
>>> I don't consider the API to be set in stone. Especially concerning
>>> mutability. Currently vectors are mutable.
>>> If however it turns out that there is no significant performance hit in
>>> making them immutable I tend to do so.
>>> Obviously this will only happen once I have some performance results.
>>>
>>> After that Matrices will be up next.
>>>
>>>
>>> thanks for your time and suggestions.
>>>
>>> //Lorenz
>>>
>>>
>>> PS: I feel that I should briefly comment on the slerp() method.
>>>   I did not follow the default implementation that seems to be prevalent
>>> on
>>>   the Internet. There you repeatedly call the slerp method with a varying
>>>   parameter t. I felt this is unpythonic. In my implementation you pass
>>> the
>>>   number of steps you want into the method which then returns an iterator
>>>   yielding the interpolating vectors. Same applies to the lerp() method.
>>>   Also the algorithm for slerp() is a bit different as to support
>>>   interpolation to a vector of different length.
>>>
>
>