In my application the size of the rendered objects is sometimes extremely huge and also located at extreme distance, this cause many issues as the default size for the floating point is 32 bits.
All the calculations are done using the double version of the panda types (LPoint3D, …), but that leads to strange code like :
np.set_pos(*obj.position)
as a LPoint3d() can not be implicitly converted to LPoint3f()
I also use a lot of tricks to scale down the scene before rendering, using bins to control the rendering of far objects, using adaptive lens scaling, shifting objects origin near the camera and so on…
Yet I still have problems due to the limited precision of the 32 bits floats and it gets harder and harder to work around them. (the last problem I encountered can only be solved, I think, by using several cameras and display regions which is rather overkill).
On the other hand, when I’m using a double precision fp version of Panda, I have almost no problem at all (except some basic adaptation to make the scene scale manageable)
I could build my own version of Panda to ship it with my app, but that’s a lot of work, I need to find how to integrate a custom version of Panda with deploy-ng, and if someone wants to use my app using the source they have to trust my build or rebuild panda themself.
So, if official double precision fp Panda3D packages could be provided it would be quite helpful to me, I could get rid of single precision compatibility and remove the obscure workarounds in my code.
This is not about bitness but rather about precision. You can build Panda3D to use double precision instead of single precision, providing the build option --override STDFLOAT_DOUBLE=1 to makepanda
That way, any Vector and Float type without using the suffixes f/d/F/D you’ll always get double precision floats/vectors/points
To be clear, I assume you are talking about double-precision floating-point numbers. The title threw me off since “64-bit build” is typically used to describe something else.
You can compile Panda3D in double-precision mode by adding --override STDFLOAT_DOUBLE=1 to the makepanda.py command. You can add the --wheel flag to produce a .whl, which can be used with deploy-ng.
If there is enough interest, we could make an official double-precision build available, but there would need to be enough interest as it otherwise doubles the release engineering workload.
Sorry, when I talked about 64bits version of panda, I meant panda built with STDFLOAT_DOUBLE=1
The problem is not using LPoint3d instead of LPoint3(f), but rather that all the internal calculation in Panda are done using 32bits float and so have limited precision.
I didn’t mean to tell you to use LPoint3D/f but rather that it’d be useful in this context to not use types with specific precision. Leaving the choice to Panda3D to use the precision with which Panda3D was built… (e.g. 1. build Panda3D with double precision, 2. only use generic types, not precision specific ones)
I need double precision to perform calculation without too much precision loss (and in some case I even need 128bits precision). As the calculations are using 3d vectors, I’m using Panda double precision type, I didn’t want to reinvent the wheel. And as the result of the calculation are used to position the objects in the scene, I need this conversion from LSomething3d to LSomething.
When using a single precision version of Panda, there is no implicit conversion from double precision type to single precision, hence the weird construct set_pos(*position) to do the conversion.
your request seems reasonable, though as @rdb noted:
It might also be helpful to open an Issue on github about the fact that there is no implicit type casting atm in Panda3D with operations such as set_pos(). It would be interesting to understand the design choices that prohibit it now and if this could be extended to allow for it in the future. (I know that this isn’t the fix for your exact situation, but it could still be useful to others, since I used the same weird construct in the past and tbh, it just felt hacky, doing so…)
How do you specify a local wheel in setup.py, apart from pypi_extra_indexes I don’t see any other parameters ? Should I copy the wheel into __whl_cache__ ?
