search

mitsuba-renderer / mitsuba2

Mitsuba 2: A Retargetable Forward and Inverse Renderer
Other
2.05k stars 267 forks source link

releasing python wheels on pypi #50

Closed martinResearch closed 4 years ago

martinResearch commented 4 years ago

it would be great to have mitsuba2 released on pypi.org. Is that planned to be done soon?

Speierers commented 4 years ago

Hi @martinResearch, This isn't on our roadmap at the moment. Although it would be great to have this in the future!

martinResearch commented 4 years ago

Hi @Speierers I experimented with compiling wheels for windows and linux using Appveyor and saving them in the artifacts Here is the wheel for windows python 3.7: https://ci.appveyor.com/project/martinResearch/mitsuba2/builds/31969410/job/ufj1omwev0a4htdb/artifacts Here is the wheel for Unbuntu python 3.7 https://ci.appveyor.com/project/martinResearch/mitsuba2/builds/31969410/job/12r454fqn09xk7ye/artifacts The time limit on appveyor is 1h which is unfortunately too short to compile all the different flavors of Mitsuba. Also I did not manage to compile for GPU as installing Nvidia's OptiX requires to log on Nvidia's website. This is obtained from this branch https://github.com/martinResearch/mitsuba2/tree/appveyor_python_wheels_artifacts It would not be much more work to upload these wheels to Pypi once you created an account there. Should I prepare a PR with the new setup.py ?

I think that releasing the wheels on Pipy should really be a priority in order to ease adoption.

wjakob commented 4 years ago

There is no way that we can release wheels for the huge amount of potential variants and complex dependencies like CUDA, Optix, and vector instruction sets like AVX/AVX512/... This is an advanced tool for researchers, so compiling it should not be an impediment to adoption.

martinResearch commented 4 years ago

Indeed it seems that release wheels for the very large amount of variants is not practical. However I believe a very large percentage of non computer graphic researchers would be satisfied with only a small subset of the variants. Probably rgb+scalar and rgb+packet with AVX would be enough for most non researcher people. Like done when installing Tensorflow from the wheel on pypi, a message inviting the user to recompile the library could be printed in case AVX2,SSE or AVX512 is detected at run time.  I believe that a wheel with a restricted set of variants is better than no wheel at all.

I understand from your comment that the main target for this library is computer graphics researcher. However I believe this renderer could be very useful to many people outside that community, in the computer vision community for example and in the python ecosystem in general, and I seems to me that it would be a missed opportunity not to make this amazing library easily usable for them too. Unfortunately it seems that there is no "pip installable" ray tracer libraries and I was very enthusiastic at the prospect that Mitsuba could fill that void. The fine grained python binding in Mitsuba make is an even more attractive option. Having available python wheels for the most commonly use scenarios would allow people to use Mitsuba in their python project as simply an additional dependency in their list of requirements and would make it much easier for them  to redistribute their own project that depends on Mitsuba as a python module, as well as running tests for their projects on continuous integration platforms for example without having to use a private Mitsuba wheel and a mechanism to access it. 

martinResearch commented 2 years ago

Amazing to see compiled wheels for mitsuba 3 on pypi . Thank you for the great work!