[OLPC-Games] Res: Games Digest, Vol 5, Issue 12

NoiseEHC NoiseEHC at freemail.hu
Mon Jun 25 06:50:00 EDT 2007


Hi!

I am currently working on a 3d renderer, and once I will get a telnet to 
an LX-700 machine I will be able to tell you some numbers what speed 
could you expect from my implementation. The problem with the TinyGL 
implementation is that it is using a quite naive rendering algorithm so 
probably it is not the best match for the XO. (And not only you can do 
more with an optimized one but the same thing will consume less power.)
The problem with a BSP tree is that it took 30 min to calculate a Quake 
level (when it was released, probably less now on a Core2 Duo), and it 
does not support overlapping polygons. So if you want to use a dynamic 
scene you are left with an octree and a Z buffer. (You cannot expect 
activity writers to correctly preprocess everything so you have to do it 
in the renderer.)

So my plan is, if you are interested in:
The minimum target is 400x300x30fps, solid/texture mapped/gouraud shaded 
objects, probably lighting will only work with Y (if it is rendered onto 
an YUV surface).
The client program (game or activity) creates 3d objects in Python then 
call render and that's all. The fact is that we cannot expect activity 
writers to implement a good scene manager for OpenGL, and no good scene 
managers are optimized for software rendering. My goal is that the 
renderer should work without any deeper 3d knowledge from the client 
program's developer.

Implementation plan:
The rendering engine uses hand optimized 3dnow/MMX for drawing 
trapezoids (a triangle is a special trapezoid). I suspended this 
development since I need a real processor to test the cache hierarchy so 
there is no point tuning it further without real data. (It is currently 
a .NET program with a Geode simulator which can draw texture mapped 
triangles.)
The rendering happens in two passes. In the first pass, all triangles 
which are potentially visible in a scanline are pushed into a compressed 
Z-buffer. Compressed means that if a span (8 or 16 pixels) of the 
scanline is inside the appropriate scanline of a triangle then no Z 
values will be calculated and the span will be handled as one big pixel. 
In the second pass the actual rendering occurs (by pixel or by span) and 
it guarantees that every pixel will be set only once (no alpha support 
initially). The Z-buffer for a scanline will fit into the L1 cache so 
hopefully it will be very fast.
The tricky part is the scene manager which integrates culling, 
occlusion, transformation and triangle setup (currently it is just a 
plan, I have no working code for it). The objects are stored in a loose 
octree and in the first pass every visible cube of the octree is put 
into the trapezoid list as maximum 2d bounding boxes (so they are 
projected into view as a rectangle). In the first pass of the scanline 
rendering, if there is an unprocessed bounding box requiring drawing 
then it is further processed (so in an octree the sub cubes are 
transformed into the trapezoid list or in case of object bounding boxes 
the objects are transformed and skinned). That way we get occluders 
without specifying them so if some character is not visible because he 
is occluded by a wall then its geometry will not have to be processed at 
all.

Advantages:
I cannot imagine anything faster and easier to use.

Disadvantages:
Not finished, will take months to implement. Not compatible with legacy 
OpenGL apps.

What do you think about it?

Daniel Monteiro wrote:
> Hi Daniel
> Very tiny indeed.
> We spoke before , about 4 years ago, when I translated (poorly) the 
> SDL_Intro document to portuguese.
>
> BZK is not using Z-Buffer as it may be not suitable for slow devices 
> with big screens (Nokia 770);
> Neither Im using BSP , but a higly modified painter's algorithm. Its 
> not something easy to describe , as Im still working it as my 
> gradutation thesis.
> Well..to best sumarize it: its like a portal rendering using a K-d 
> Tree. Why not Z-Buffer? some plataforms like Symbian OS dont give me 
> acess to a large buffer like the one needed by Z-Buffer , but only to 
> cointainers. (well, that changed recently...but BZK is older than that 
> and the devices that support this are the high end only)
>
> This TinyGL maybe be a good solution for BZK on the XO indeed. 
> although I dont really like much OpenGL and the BZK render is only 
> half compatible...maybe we can work on this...
>
> About the floating point. Im about to make it only optional (activated 
> on compile time), as the new nokia device (N800) has a good FPU too.
>
> []s
>
> Daniel
>
> -----------------------------------------------------------------
> Wow, that's surely a tiny world! A guy with almost the same name as
> mine, that lives in the same country as me, that codes in C++ and do 3D
> programming!
>
> I only sent a message to the devel list, so I'll take the opportunity to
> announce here too: I'm adapting a software renderer implementation of
> OpenGL (TinyGL, by Fabrice Bellard), suitable to be run on the XO.
> Currently it runs the gears demo in fullscreen (actually rendered to a
> 256x256 framebuffer) at 50 fps.
>
> I hope to be able to execute my robotics simulation framework in the XO,
> but there is still a lot of work to be done. You can take a look at what
> I've already accomplished at:
>
> http://www.basso.inf.br/phi/ (check the gallery, it's old but nice :)
> http://www.lec.ufrgs.br/~dmbasso/phi/doku.php 
> <http://www.lec.ufrgs.br/%7Edmbasso/phi/doku.php> (last stable version)
>
> About BZK: does it use BSP for occlusion culling? TinyGL uses a
> z-buffer, but I suspect a BSP-tree would perform better. The Geode's
> floating point is very fast, so BZK's fixed-point is not really an
> advantage on the XO.
>
> []'s
>
> Daniel
>
> ------------------------------------------------------------------------
> Novo Yahoo! Cadê? <http://yahoo.com.br/oqueeuganhocomisso%20> - 
> Experimente uma nova busca.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Games mailing list
> Games at lists.laptop.org
> http://lists.laptop.org/listinfo/games
>   


More information about the Games mailing list