PTALVecBase

Compiling or Editing the Panda Source
1

David,

Isn’t necessary having also PTALVec2/3/4? Otherwise users have to use PTALVecBase4f and then cast, each time, back to Vec4, and it doesn’t seem really practical.

For example:

x = PTALVecBase4f(Vec4(...),Vec4(...))
... do something
setShaderInput('something',x)
... do something
vec = Vec4(x[0]).dot(Vec4(x[1]))

or am I missing something ?

By the way I finished coding the shader inputs, I got rid of the k_ prefix (keeping it backward compatible) as rdb suggested, and I fixed the struct bug, that now works in this way:

//for input without prefix (all the inputs passed by directly by the user)
setShaderInput('struct_name.input', value)

Someone at ETC is going to test it and commit it in the repository. Not sure when though.

2

But dot() is defined on LVecBase4, so no cast is necessary in your example. What operation do you foresee that requires an explicit case to Vec4?

Sounds awesome. Thanks!

David

3

But even if you can perform the same operations people have to learn that for array of vectors they have to use PTALVecBase4f while for simple vectors Vec4. Is this ok? What about renaming PTALVecBase4f to PTAVec4 (only in python). I think this could help to prevent some confusion.

4

I think we should keep it at LVecBase4f, because most of the time it won’t be a real 4-dimensional vector anyways.

5

Yeah, there’s already confusion about the whole VBase4 vs. Vec4 vs. Point4. Once people have learned the difference between these three, I think the idea that the array class only stores the generic base type is easy enough to grasp.

Before a developer learns the difference between these three, I agree there will be confusion. But I don’t think having a new triple of class names to learn would help.

David

6

Ok, I’ll keep it then, I’ll write some documentation to clarify when PTAVecBase should be used.

Thanks
Federico