[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