constructors for point, vec and mat double to single conversion

Registered by Hypnos

add constructor to linmath classes that take the double-precision equivalent as argument (and vice versa).

examples (which currently do not work):
Point3( Point3D(1,2,3) )
Vec3D( Vec3(4,3,2) )

Blueprint information

Status:
Complete
Approver:
David Rose
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
David Rose
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
rdb
Completed by
rdb

Related branches

Sprints

Whiteboard

Constructors are difficult because of the template-like nature of the linmath classes, but the LCAST macro is designed for this purpose. It means "linmath cast".

LVector3d foo = LCAST(double, LVector3f(1, 2, 3));

Of course, this only works in C++, because it's a macro. A Python equivalent would be useful.

David

----------------------------

What if we do it like this: (for example. I didnt test it)
We add this in fltnames.h:
#define OTHERFLOATNAME(arg) arg##d
And in dblnames.h:
#define OTHERFLOATNAME(arg) arg##f
(Yes, I swapped them.)
We add this in lvector3_src.h:
INLINE_LINMATH FLOATNAME(LVector3)(const OTHERFLOATNAME(LVecBase3) &copy);
Then we add the function in the .I file that simply calls the LCAST.
Would that be a solution or is that too hacky?

pro-rsoft
--------------------
That seems like it would work, and I'd be fine with that solution. But I just had a better idea. This problem will go away if we defined a __len__ method for vectors, etc. That would make it work like a sequence, and we could then just use the * operator:
>>> vf = Vec3(1, 2, 3)
>>> vd = Vec3D(*vf)
It would also make things like tuple(vf) work properly, so it's a better solution all-around.

I've been meaning to do this in general for all the classes that have an operator[] method and a get_num_items() or equivalent method.

David
--------------------
I tried to take a poke at implementing my idea but horribly failed. Adding one include line somewhere gave me a flood of compiler issues that probably have to do with the order in which files are included.

Your way sounds excellent. Does interrogate currently support __len__ functions? If not, where would we implement that?

pro-rsoft
-----------------
Interrogate does not currently support __len__ functions. We'd have to add support for this. Since interrogate is something of a mess inside, this is probably much easier for me to do than anyone else right now.

I've been wanting to retool interrogate's support for operator [] anyway. Right now it only maps it to __getitem__, but it would be nice if it could support __setitem__ as well.

David

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.