GP32 3d Routines/engines To Use


To speed it up:
Don't calculate the z-depth of every pixel, just the average over the poly, and use that for all pixels in that poly. Of course this could cause clip[ping issues in complex scenes or intersecting polys at funny angles (especially large polys), but could be ok.

Wouldn't that just be a extremely slow version of the painters algorithm?
It's not expensive to interpolate Z over the polygon, the expensive part is to read/test/write.


---
mithris
 
No, thats why Z-buffering was invented.

The painters algorithm (from what I understand) starts with the furthest away polygon, and drawns every single poly to the screen that is within the clipping area. It overdrws each pixel potentially many, many times - imagine you are looking into a forest, the painters algorithm would draw the far away trees, and progressiely come closer to you, drawing each closer tree over the top of the further ones.

z-buffering, on the otherhand, draws the closest polys first, and then if the further polys are only drawn if there is no poly at that location that is closer. This way each pixel is written to exactly once. Therefore, if a single tree is blocking your whole view, NO trees behind it are drawn.

You may say that drawing pixels to the screen (LCD) doesn't take much time, but each pixel also has texture and lighting calculations associated with it, and if you could test whether the pixel was going to be visible first, you could leave out those texture and lighting calculations, as well as the actual write of the pixel.

of course, correct me if I'm wrong about the painters algorithm (z-buffering I'm pretty sure is right)
 
Hi, I have started a rasterization library, and in the future it will become a complete 3d engine.

I have post a demo at gp32spain, but I cant upload files to the forums so I'll try to link them.

The demo is just a hi-poligon mesh, but mesh lack of one pice (you will notice)

At the moment it has some precision isues, but they will be fixed soon.

The test is doing about 90k flat zbuffered poligons per second.


First 166 version without zoom
http://gp32spain.com/foros/attachment.php?attachmentid=4792

166 version with zoom (only fxe)
http://gp32spain.com/foros/attachment.php?attachmentid=4799

133 version (only fxe)
http://gp32spain.com/foros/attachment.php?attachmentid=4810

You have to download the first version and decompress on gpmm.

I would like to have some feedback of some one doing something similar so I could benchmark against something, the file format is very easy...
Code:
int vertexCount
int poligonCount
(int,int,int)*vertexCount    vertexArray
(int,int,int)*poligonCount   polyArray


So feel free to write a comparision application with your own library please.
 
Hi una-i,

I have tried both the 133 and the 166 versions attached here, and they both reset the GP as soon as they are loaded. My GP32 can get up to 166MHz fine usually.

I have a new BLU+ (taiwanese LCD) on the standard firmware.

For a very brief split second I can see 'pps:0' on bottom corner, then it resets.
 
ah, that works great! The 133 version goes at about 6pps, and the 166 at about 8pps. I see what you mean about the missing polys. Very nice though!
 
Thanks! my latest build is a bit more faster on 166mhz about 11fps, but now I'll focus on fixing the precision issues...

The nice thing about th libray is that you will be able to write pixelshader like code tu customize the renderer, hoppe it gets fast enough to make some nice games :p


Unai Landa.
 
Back
Top