makepath/rtxpy

Ray tracing using CUDA accessible from Python.

rtxpy's Issues

Add cool images to README

Research available options for GPU-enabled CI

Right now we cannot run tests automatically on github, because the backend has no GPU support

Setup.cfg needs author_email

Using author = makepath in setup.cfg. When building sdist this gives a warning:

warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Extend the python API to be able to query/delete a previously built GAS

Implement GAS compaction

OptiX supports compaction of the acceleration structures that we don't use. We should use it.

Add GPU selection capability

Currently we only use GPU 0 for OptiX, but that need to change. We should pass to init the device on which we want to operate

conda packages

We need conda packages for this repo. @ianthomas23 looking into this.

Are there any examples available?

I have a use case, where I want to calculate hit distance to a mesh from a pinhole camera. Is there any examples of using rtxpy to do something like this?

Add support for IAS

We need to be able to handle more complex scenes, with multiple objects inside, Right now we only support single GAS scenes, but we need to build IAS that supports multiple.

Handle macOS not having support for NVidia

Make the project public and push wheel to PyPI

Prepare to make a formal Python release

Add multi-instance support

Right now there is only one global GAS for OptiX and if the user tries to build a second one we overwrite the first.
We need to add support for multiple GASs

Rename the project and packaging scripts to rtxpy

Notify users about hidden overhead when passing in numpy buffers

OptiX works with both CUPY and NUMPY buffers, while CUPY is handled natively, Numpy can't so we allocate a GPU buffer to copy the numpy pointer into, then run the calculations on the GPU buffer, and then we transfer the results back to the numpy pointer. While this kind of workflow is expected, I've noticed that numba produces a user-facing warning that this usage results in an unnecessary overhead. Maybe we should produce such a warning as well.