Software renderer guide

Then you switch to using Direct3D or OpenGL. :D

Just kidding, actually, if you already have sorted textured triangles, then you're pretty well along already. I think next could be lighting, actually. Do you already have gourand (spelling?) shading on your triangles, can you interpolate between vertex colors (since that's needed for vertex lighting). After that, maybe transparency (and fog). :D Can we see some screenshots?

How are you approaching this? As a raytracer or rasterizer?

Is this really desired? Also as learning experience, I did that on java over many many months to learn, and got job on the java side.

But when I switched to OGL and shaders, though the graphics concept is solid, I was behind others in API knowledge.

@xycsoscyx - yup, gouraud shading is done :) hmm...maybe transparency (translucency, i meant) next...that'd be difficult...if I have let's say 1000 triangles on top of each other...each one translucent to the one below it...

@smitty1276 - as a rasterizer...

@parasolstars - yeah, i know basic opengl already...i just want to learn some of the things that make it work...


any more ideas guys? the only idea i've got was translucency and fog...(fog i don't have _any_ idea how to go about it)...

I suggest you implement phong shading, if you haven't already. It should be simple. Then, do spherical environment mapping. Should be dead easy too. Further, implement a z buffer. This would also allow you to do depth fog. After this, you might want to branch out into model loading and culling algorithms, since you'll want to stress test your renderer.

As an aside, I keep writing software renderers every so often for the sheer fun of it. Doing so has not impeded my knowledge of any api.

hmm...phong shading...alright will look into that...thanks!

how does one implement a z-buffer? does one store each pixel's "z-value"? wouldn't that take a huge amount of memory?

thanks.

If you have an Affine textured triangle rasterzer, z-buffering is a no go. If you have a perspective correct one, then use a zbuffer.

What you do is this:

if you have a 640 by 480 screen, you allocate a memory that could contain that screen. ie. 640 * 480 * sizeof(float)

For each pass, set your buffer to zeros
Now for each texel on the triangle, you check if a pixel ocupies that depth and compare if it's farther. if the texel is farther, tehn dont plot, otherwise plot.

In my experience with software rendering, sorting seems fast enough or instead of a z-buffer, you could use a polygon buffer using the zcenters of each poly instead of each texel.

Here's a waving torus using tinyptc.

http://rel.betterwebber.com/junk.php?id=59

Source in Freebasic with inline ASM for the scanline renderer.

@relsoft - i know what a z-buffer is...what i'm worried about is the amount of memory it'd take up (this is being developed on/for cellphones)...z-center for polygon isn't correct/exact and there are easy cases where it'd fail...


@anonymous poster 1 - why "optimized" assembly? on the PC side, i think (i read somewhere) the msvc++ compiler (the later ones) would use SSE/SSE2 where available and generates great assembly...

@anonymous poster 2 - i agree. doesn't matter though, you can't really do much assembly in cellphones...(like doing assembly in symbian c++, which is really a hack)....

The Ultimate 3D Coding Tutorial (C) Ica /Hubris 1996,1997,1998

Tony, thanks for that link.

thank you for the link Tony :)

Do you have a clipper and a transform pipeline with model, world and projection matrix yet? Using homogeneous coordinates is a must for best flexibility and performance.

Quote:

Original post by Anonymous Poster Also, I'm always worried by comments like "written in optimised assembly language": are you sure you can do a better job than the compiler nowadays? Do you really know the entire available instruction set on a modern PC cpu inside out? Have you profiled to see where the bottlenecks are? Are you considering that cpus today are almost infinitely fast and most bottlenecks are caused by cache misses (or even memory bandwidth, with cache friendly code).

These are the typical arguments to avoid learning assembly. They are FALSE!

Yes, writing more optimized code than the compiler is very possible. In fact by learning assembly you'll also learn the compiler's limitations and become a better high-level programmer as well. The instruction set might seem endless at first but it's actually quite manageable. There's a system behind it and the mnemonics are really easy to remember once you've used them. And CPUs are certainly not infinitely fast. If you divide the clock frequency by the screen resolution, desired framerate and estimated overdraw, you're left with a very small number of clock cycles per pixel to do texture filtering, lighting, z-buffering, etc. Cache misses and bandwidth are hardly an issue because of high correlation high processing ratio.

Quote:

Original post by _nomad_ i know what a z-buffer is...what i'm worried about is the amount of memory it'd take up (this is being developed on/for cellphones)...

You need at least 16-bit per pixel. So for a 640x480 screen (bigger than your cellphone I assume), it takes 150 kB.

Quote:

why "optimized" assembly? on the PC side, i think (i read somewhere) the msvc++ compiler (the later ones) would use SSE/SSE2 where available and generates great assembly...

It can only use trivial scalar SSE instructions, which isn't faster than regular FPU code. Vector SSE is up to four times faster, but can only be written manually. Besides, you need to adjust your algorithms to make optimal use of (vector) SSE, which the compiler is totally not capable of.

If your renderer is perspective-correct, you'll be interpolating 1/z across your tris. You might consider storing 1/z in your depth buffer instead of z and using it for comparison test. That way you don't have to resolve your z-value first.

ex.

Instead of:_________________________

actualDepth = 1 / interpolatedDepth

if (actualDepth < zBuffer(x,y))
zBuffer(x,y) = actualDepth
fBuffer(x,y) = actualDepth

you can just do this:________________

if (interpolatedDepth > zBuffer(x,y))
zBuffer(x,y) = interpolatedDepth
fBuffer(x,y) = actualDepth

Saves a divide, but changes the distribution of z values in your depth buffer.

BennyW

Hey, Benny? You from DBF too?

_nomad_: You know how much memory your "target" phone should hold. So it's just simple subtraction by the amount of memory your buffer holds.

Quote:

Original post by C0D1F1ED Quote: Original post by _nomad_ i know what a z-buffer is...what i'm worried about is the amount of memory it'd take up (this is being developed on/for cellphones)... You need at least 16-bit per pixel. So for a 640x480 screen (bigger than your cellphone I assume), it takes 150 kB. Quote: why "optimized" assembly? on the PC side, i think (i read somewhere) the msvc++ compiler (the later ones) would use SSE/SSE2 where available and generates great assembly... It can only use trivial scalar SSE instructions, which isn't faster than regular FPU code. Vector SSE is up to four times faster, but can only be written manually. Besides, you need to adjust your algorithms to make optimal use of (vector) SSE, which the compiler is totally not capable of.

yeah i calculated it (memory usage) for the phone...kinda a bit no-no...i'll have to think of another way...

i see, nice info regarding SSE...:)

@BennyW - thanks for the insight. :)

@relsoft - i know...that's too obvious...and unfortunately, on, say, some series60 phones, getting memory doesn't equal "available" memory...fragmentation is a huge factor...

Quote:

Original post by C0D1F1ED It can only use trivial scalar SSE instructions, which isn't faster than regular FPU code. Vector SSE is up to four times faster, but can only be written manually. Besides, you need to adjust your algorithms to make optimal use of (vector) SSE, which the compiler is totally not capable of.

No, no and no.

Of course the burden lies onto the compiler and msvc is sub-par (mscv2k5 included).

A decent compiler (gcc, icc) equiped with proper SSE math lib implementation produces faster code - as measured on recent cpu - when generating scalar SSE instead of straight x87.
Those two compilers, under some conditions, can auto-vectorize therefore producing vectorized SSE code automatically.

Now efficient vector code require proper data structures to begin with - AoS vs SoA etc - and even on ideal conditions you'll never acheive a x4 speedup but on absolutely trivial tasks. In the real world, if you're careful and after much tinkering with intrinsics you'll be rewarded with a x2.5 boost.