Julia code returns lists with Blender's numpy #2
Comments
|
Checking differences in Command-line Python: Blender: So the fact that Blender links statically to libpython is definitly a difference that might be of influence here. |
paulmelis
added a commit
that referenced
this issue
Sep 3, 2020
…when running the same code under plain Python (where it returns numpy arrays). No clear cause found, see #2 for details
|
With a locally compiled version of Python 3.7.7 statically linked to libpython and NumPy 1.19.1 it works correctly: So could be a NumPy version-related issue? |
|
Python 3.8.5 (system version) with older NumPy 1.17.5 WORKS: Dang, so it's not just the older NumPy |
|
Static Python 3.7.7 with older Numpy 1.17.5 WORKS: |
|
Using the |
|
Comparing I.e. same set of dynamic libs used |
|
Manually built Python 3.7.7 using Blender's site-packages (i.e. numpy and pyjulia) FAILS: So there really appears to be something different in the |
|
Blender's numpy is patched, but nothing of importance here. Numpy build script in Blender also doesn't reveal anything noteworthy. |
|
Running Blender's So that's pretty definitive, it is the numpy in Blender that's causing this. |
|
Doing the same trick with Blender itself (i.e. override Getting back numpy arrays instead of lists from Julia also provides (as expected) a massive speedup. Here's the Bunny model: So 623.674ms total instead of 1379.705ms as reported in the readme. Another factor of 2.2x faster, wow. So compared to the subsurf modifier time of 13583.849ms the Julia version would be 21.8x faster... |
paulmelis
changed the title
|
Hmm, this might still be something with the julia package as installed in Blender. Doing the subdiv.py test from Blender uses julia from Removing julia from Blender's site-packages are retesting from within Blender using the site-packages from the manually built Python WORKS: So the julia package isn't of influence. Hmmm, just to make sure running subdiv.py test from within Blender but allowing Blender to pick up the julia package from So still points to Blender's numpy being at fault. |
|
Upgrading Blender's numpy using pip (and reinstall a local copy of pyjulia) fixes this for now: But has the downside of using a non-standard installation of Blender. |
|
Well, what do you know? Manually building NumPy 1.17.5 with the manually built static Python 3.3.7 FAILS: |
|
One more test: building a regular (non-static) version of Python 3.7.7 and manually building NumPy 1.17.5 with that Python. Errr, why is And the answer is NOPE: Trying the same with a Python version dynamically linking to Aha! So now Fingers crossed... nope, still FAILS: |
|
So apparently all manually built NumPy 1.17.5 variants fail. Checking by using the pip version: Guess what, this combo WORKS: |
|
I guess the summary (from what I can deduce so far) is that numpy always fails to return numpy arrays from Julia with a manually built NumPy 1.17.5. With the prebuilt pip version it always succeeds. |
|
As a sanity check here's with my Arch Linux built packages (that do not come from pip), which WORKS: |
|
So what about a manually built NumPy 1.19.1? Oh boy, seems we're on to something as this FAILS: So it's not a NumPy version-specific thing after all... |
|
Reduced the test case (should have done that much sooner 😄): |
|
Now Julia does not allow line tracing, but Python does. So perhaps we can figure out the differences that way. Strangely, there's no great differences, except for the code printing the value (which is of a different type of course). So that suggests that the differences are in the non-Python parts, i.e. code in a shared lib being used. Conversion from a Julia Array to Python is handled in PyCall's Function But since the output Removing the The value of So, apparently PyCall fails to find the header, which raises the exception through Ouch. Checking if that file is being read while it really does not exist: Yup, we're getting somewhere. Right, so we were not actually testing with a fully installed numpy as we're running from the The normal location: Is it in the Blender distribution? Nope. And hence: Okay, so that also explains a lot. Final piece of the puzzle, why does a numpy installed from pip fix the issue? Answer: it includes the headers... |
|
I can find only one reference in the PyCall.jl project page that NumPy headers are required. Specifically in this issue:
|
|
Reported to PyCall.jl at JuliaPy/PyCall.jl#814 |
|
[Sorry I didn't create a new issue] |
Nope, this is just a small test by me to see if any combination of Julia and Blender is feasible. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Comparing the returned values of the
subdivide()incatmull-clark.jlcall under Blender and from regular Python I noticed the following. This is based on the code intest/subdiv.py, which is also stored intest.blendunder(text)in the Blender Text Editor.Python 3.8.5 (command-line)
Blender 2.90 (Run script from UI)
Summary
Python 3.8.5 (command-line):
subdivide()returns a tuple of 4numpy.ndarrayvalues, as expectedBlender 2.90 (UI):
subdivide()returns a tuple of 4 listsSo the differences are probably caused by a different version for Python and/or NumPy.
Rebuilding
PyCallfrom within Blender ((rebuild pycall)text tab) makes no difference.The text was updated successfully, but these errors were encountered: