News:

Function Finder  Find all the functions within source code files

Main Menu

Build a basic 3D Render Engine

Started by stevmjon, May 03, 2022, 10:25:50 PM

Previous topic - Next topic

kevin

Quotefor fun i copy/pasted my code into python (and edit to suit language difference) to compare the speed between both languages with the same code set up (same scene with same camera angle).

PB = 11 seconds
python = 26 seconds

even though PB is using legacy direct x, the brute force calculations are still good.

  Wow dude,  That's pretty cool.  Given the shoe string budget this house of cards is built under..  :( 

  Although the display surface (DX) isn't the bottleneck here,  since the cost of computing the pixel is greater than that of drawing it.  If the math libraries (intersection functions for example) were converted to native then there's probably a 10 fold speed up there.   

  What I found during Visible Worlds,  which is basically a light mapper that renders the world from every possible location in the world, was restructuring the data won back a lot more performance as scene complexity went up than micro optimizing stuff ever did.  But that's still on a single core.

  Was thinking the other day, the easiest way to thread such applications would be splitting the program up into back and front end apps.  The front end is the UI controller and a render app is passed the scene for rendering.   So the more render apps the more parallel the work load is done.

  So to the reduce the work load by 4 potentially 4, run 4 copies of the render app and then wait form them to complete.  Each could bump each row or section as bitmap for the master to load and display.  The data couple of passed by as files or even a local network. Which basically a local render farm.  There's still a saturation point though, but very doable!   



   

stevmjon

Quote from: kevin on June 19, 2024, 11:48:01 PMAlthough the display surface (DX) isn't the bottleneck here,  since the cost of computing the pixel is greater than that of drawing it.  If the math libraries (intersection functions for example) were converted to native then there's probably a 10 fold speed up there.

is this for playbasic, or python?

if playbasic, does this mean if i convert the intersection functions to DLL's and include them?
if python, is there 3D functions i can use instead? i know  there are modules you can import, but i am not sure which one's.

Quote from: kevin on June 19, 2024, 11:48:01 PMWas thinking the other day, the easiest way to thread such applications would be splitting the program up into back and front end apps.  The front end is the UI controller and a render app is passed the scene for rendering.   So the more render apps the more parallel the work load is done.

sounds interesting. i am not sure how to go about this. the parrallel bit sounds good. i would like to try it.
It's easy to start a program, but harder to finish it...

I think that means i am getting old and get side tracked too easy.

kevin

Quoteis this for playbasic, or python?

   yep both, or really anything being executed via a runtime.


Quoteif playbasic, does this mean if i convert the intersection functions to DLL's and include them

   yep..  Hence PB2DLL


Quotesounds interesting. i am not sure how to go about this. the parrallel bit sounds good. i would like to try it.

  Well the simplest way is via Execute File.   You could create batch file and launch a swarm of them. Then wait for status signals from them in the UI app.  Which might as simple as generating a file, memory mapping though to passing data through a local network.   

  Won't be pretty though in legacy PlayBASIC.