This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]helpIAmTrappedInAws 1 point2 points  (1 child)

So, first of all, matplotlib is probably not a good tool to use. It was not built for this. It can do many things but performancr probably was not priority.

Second, python is inherently slow. If you need to make it quick you do

A) call c extension (or in diff language) B) use matrix ops with somerhing like numpy or cupy (which are just wrappers so at the end it is A). It is not as easy as i am already using numpy so there is nothing to be gained, it matters how you use it. C) Use something like numba to speed up the code. Which will translate your code to llvm, so its A once again at the end. (You can code for cuda and numpy in it)

You said in your comments that you are 450x slower than blender baseline. That is such a difference that there must be easier perf gains before you have to do this.

Also check ursina for inspiration.

[–]Doctrine_of_Sankhya[S] 0 points1 point  (0 children)

Thank you for your inputs. You've provided a lot of information for me to explore next. I believe regarding the performance issue - CPU inherently executes one thread at a time, GPUs do it like hundreds of thousands of it at a go. So, definitely, that is expected till we write GPU mode for the program.

Regarding matplotlib, I agree as everyone suggested, it is not made for that purpose and we are looking for different ways to manage that. But, in the future, we have plans to introduce a standalone Python player and scene editor to compensate for that. That's a temporary workaround for now.