- march along the ray not from left to right (fill columns first, helps with caching) - use numba with forced inlining to improve the speed - use a non linear LOD function - use a custom array accessor for numpy arrays (unsafe but faster) What i did for my python voxel engine is: - used numbas prange() which is parallel processing. (This is very simple) - rewrote it in nim with sdl2 and it was still 10x faster than the optimized python version. - currently in the process of using compute shaders to speed it up (grahpics card => parallel processing) if you get some headroom from optimizations, i would suggest adding a bilinear filter for the colormap and heightmap, which impoves the visual quality alot.
Some Ideas on optimizing: -Profile your code! If you don't know what's actually slowing down your program you'll probably spend huge amounts of time just optimizing small things that aren't actually the bottleneck of your program. And in the worst case you'll even slow down parts of your program. -Make sure your using library calls correctly. My personal experience with python graphics is very limited, but it could be that the calls to functions drawing your image and presenting it are taking much longer then expected. In graphics programming generally when rendering the image try to keep calculation of the image and presentation seperate. Hand the rendering API only the finished image as memory operations are much more expensive than math operations. -And lastly: If you're actually trying to get comparable speeds, you will need to use a faster language, like c/c++/rust. It may seem daunting at first, but in the end they are also just programming languages and thus more similar to python than not. Your rendering code for example could look nearly identical. And by using all the high level features provided by the standard libraries of these languages you don't have to be some kind of wizard to use them. Well I'm interested to see what you'll code in the future!
bro was like 'refrain from mentioning parallel processing' but since you can separate and calculate all the verical lines independently of each other you can just use numba in parallel for one of the loops. You have to reorder your z and x loops though, so that you go first through each vertical line and then for it you go through each z distance. For the same resolution that you set and with render distance of 2000 I got like 700-800fps...
Hi, sorry to bother you, but what you suggest seem really interesting but I didn't really get the point on the fact of calculating vertical line, what is it about ?
Dude I had a choice between 2 amazing youtubers and well looking I noticed you, ofc I have to click God bless your sorce code on a textured raycaster helped me so much. funny enough I've used that exact same voxel pixel renderer that your showing on the screen right now to make a doom clone deathmatch shooter that me and my bother love Amen man wish you well
Also, this is coming from someone writing a Vulkan renderer for fun, so take this with a grain of salt, but OpenGL is not very hard to learn. Some of it doesn’t transfer great to Python, so if you really want it to go fast I’d honestly say moving to Kotlin (likely using LWJGL’s OpenGL bindings) would probably go reasonably well considering you know Python already.
Just in case still too slow no matter what you do... have Javascript with JSON creating temp (buffer overwriting) PNG1 + PNG2 to do all the heavy lifting so it reads like MP4 streaming instead.
rendering with the experimental _sdl2 module in pygame-ce should speed things up a lot as it will draw using the GPU i've seen some performance increase using pypy with pygame too
First of, what I don't see a lot of ppl mentionning here, is to try identify what truly makes your code slow down... Forget about implementing x or y blindly. Without knowing what kind of issue you are addressing (memory banwidth ? Too much computation ?) you are not going to make significant improvement. So get a python profiler, learn a bit how pygame works (bc imho you may be calling its graphic api in an very unsufficiant maneer), and see which functions calls slow you down. Then, and only then try to think about optimization : Is computing the square root too much ? Maybe try an approx. Is blitting one pixel after another too expensive ? Maybe try to coerce chunk of colors together. etc etc.. Finally, when this repeated over and over, and you can't get much more, only then should you consider multiprocessing (which is a whole another beast on its own) That's how I would do it. Have fun !!!
Use a DDA alg. just use a DDA alg. that's literally all it takes. instead of using a fixed step size, use a DDA to march through the voxel grid and check each voxel for collision with the ground. its superior. Also compute shaders bro.
Do rendering on the GPU please. Use a graphics API with python bindings. Rendering on the CPU is a goddamn crime. Yet alone rendering on a CPU with python!
I like it when people in Python actually know that Python is dogshit slow. I know there is "fast Python" like Cython, PyPy, multiprocessing, etc... But at that point it is easier to just use something else, like C. This is clearly for fun. Like writing DOOM in bash. Who cares about performance when you can have fun, am I right?
Shaders pls, just use shaders of any kind, compute shaders or fragment… you can save up so many resources by using them for other cool stuff and allow it to run on any potato
For performance you should rewrite it in Rust and then hand $5,000 in cash to me immediately. This will surely improve your FPS
hey, i want some too
@@lukasjetu9776 Always happy to lend some performance. I’ll cut you a sweet deal too: $3,000
after making it in rust do it again in C++ as it is just a bit better (le joke)
- march along the ray not from left to right (fill columns first, helps with caching)
- use numba with forced inlining to improve the speed
- use a non linear LOD function
- use a custom array accessor for numpy arrays (unsafe but faster)
What i did for my python voxel engine is:
- used numbas prange() which is parallel processing. (This is very simple)
- rewrote it in nim with sdl2 and it was still 10x faster than the optimized python version.
- currently in the process of using compute shaders to speed it up (grahpics card => parallel processing)
if you get some headroom from optimizations, i would suggest adding a bilinear filter for the colormap and heightmap, which impoves the visual quality alot.
Some Ideas on optimizing:
-Profile your code! If you don't know what's actually slowing down your program you'll probably spend huge amounts of time just optimizing small things that aren't actually the bottleneck of your program. And in the worst case you'll even slow down parts of your program.
-Make sure your using library calls correctly. My personal experience with python graphics is very limited, but it could be that the calls to functions drawing your image and presenting it are taking much longer then expected. In graphics programming generally when rendering the image try to keep calculation of the image and presentation seperate. Hand the rendering API only the finished image as memory operations are much more expensive than math operations.
-And lastly: If you're actually trying to get comparable speeds, you will need to use a faster language, like c/c++/rust. It may seem daunting at first, but in the end they are also just programming languages and thus more similar to python than not. Your rendering code for example could look nearly identical. And by using all the high level features provided by the standard libraries of these languages you don't have to be some kind of wizard to use them.
Well I'm interested to see what you'll code in the future!
Cache Combine Distant Voxels: when more than one voxel looks like a single pixel.
great video as always
bro was like 'refrain from mentioning parallel processing' but since you can separate and calculate all the verical lines independently of each other you can just use numba in parallel for one of the loops. You have to reorder your z and x loops though, so that you go first through each vertical line and then for it you go through each z distance. For the same resolution that you set and with render distance of 2000 I got like 700-800fps...
Is there source for this code he and you did?
Hi, sorry to bother you, but what you suggest seem really interesting but I didn't really get the point on the fact of calculating vertical line, what is it about ?
Pretty coool, I would suggest using numba to speed things up
This guy knows
1000 subscribers! Gratz!
i think you could optimize it by using a different coding language and using parallel processing
Dude I had a choice between 2 amazing youtubers and well looking I noticed you, ofc I have to click God bless your sorce code on a textured raycaster helped me so much. funny enough I've used that exact same voxel pixel renderer that your showing on the screen right now to make a doom clone deathmatch shooter that me and my bother love Amen man wish you well
this reminds me of a spoonkid video, this is wonderful
_group voxels into chunks and raycast the chunks
-frustum culling
-sparse voxel octree for more efficient raycasting
Wow make this more popular get this guy to 1m subs
you need to blow up i love your videos
Also, this is coming from someone writing a Vulkan renderer for fun, so take this with a grain of salt, but OpenGL is not very hard to learn. Some of it doesn’t transfer great to Python, so if you really want it to go fast I’d honestly say moving to Kotlin (likely using LWJGL’s OpenGL bindings) would probably go reasonably well considering you know Python already.
Just in case still too slow no matter what you do... have Javascript with JSON creating temp (buffer overwriting) PNG1 + PNG2 to do all the heavy lifting so it reads like MP4 streaming instead.
Using a jit compiler should improve performance drastically
rendering with the experimental _sdl2 module in pygame-ce should speed things up a lot as it will draw using the GPU
i've seen some performance increase using pypy with pygame too
how much faster do you think this could get if you did all the calculations using numpy?
What engine or library are you using for this? Looks cool
Just Pygame for the display
First of, what I don't see a lot of ppl mentionning here, is to try identify what truly makes your code slow down... Forget about implementing x or y blindly. Without knowing what kind of issue you are addressing (memory banwidth ? Too much computation ?) you are not going to make significant improvement.
So get a python profiler, learn a bit how pygame works (bc imho you may be calling its graphic api in an very unsufficiant maneer), and see which functions calls slow you down. Then, and only then try to think about optimization :
Is computing the square root too much ? Maybe try an approx.
Is blitting one pixel after another too expensive ? Maybe try to coerce chunk of colors together. etc etc..
Finally, when this repeated over and over, and you can't get much more, only then should you consider multiprocessing (which is a whole another beast on its own)
That's how I would do it. Have fun !!!
you could try running it with pypy
its an alternative python implementation thats quite fast and very compatible with cpython code
wow, just wow
Use a DDA alg. just use a DDA alg. that's literally all it takes. instead of using a fixed step size, use a DDA to march through the voxel grid and check each voxel for collision with the ground. its superior. Also compute shaders bro.
why's young garfield teaching me python
Great work!
Avoid the use of floating point numbers altogether when rendering in gameplay by using dict() cache or memoization.
Maybe use resize * 16 + PIL blur to create the height map
Binary Meshing (Cache): 0 = space. 1 = voxel... create a pre-calc rotation dict()
please try nonperpendicular processin
Try running it in pypy.
Pypy is just a python interpreter but is much faster than cpython.
one optimization technique is to use c++
I bet Shoriminimoe has some great optimization tips
How Sets Can Truly OPTIMIZE Your Python Code - ua-cam.com/video/k_Hp4C-OQmM/v-deo.html
Now do it in C
Speeding Up Python Code With Caching - ua-cam.com/video/0_ievUF0L_E/v-deo.html
Do rendering on the GPU please.
Use a graphics API with python bindings.
Rendering on the CPU is a goddamn crime.
Yet alone rendering on a CPU with python!
why does this only have have 76 views 😭😭
Make it in c and vulkan with hardware raytracing (very fun trust me)
use parrallel processing.
PLEASE USE THE NUMBA MODULE!!!
i'm thinking of two words and they both begin with the letter p
I like it when people in Python actually know that Python is dogshit slow. I know there is "fast Python" like Cython, PyPy, multiprocessing, etc... But at that point it is easier to just use something else, like C.
This is clearly for fun. Like writing DOOM in bash. Who cares about performance when you can have fun, am I right?
time to switch to lua boy 300x the performance frfr
He should add multithreading 😆
2:29 y'uore're*
I’m sure people have already said this but please just profile before listening to anyone’s suggestions, fix what’s slow not what looks slow.
2:29 *your
Shaders pls, just use shaders of any kind, compute shaders or fragment… you can save up so many resources by using them for other cool stuff and allow it to run on any potato
2:45 and java
xD
I bet you can't create it on templeOS
what the hell man dont find me
cool! please never code graphics in python again! thanks!
Use C++ 😂
why python tho......
Python isn't that slow
wait until you find out about the GIL
@@theglowpt3 ... flashbacks. GIL is such a headache.