I wrote a software rasterizer recently

[attachment=19092:tie3.png]

(this great model is taken from blender models com mady by 'admin')

This is working and I am happy but this is naively written (no asm no cache optymizations etc) and is slow (slower than it could be).

Especially my clipping code is weak.. I mostly just check if 2d triangle result lies in screen if no then clip, I also check some points of 2d triangle with depth buffer if no one is forward then clip the triangle (it is slightly inprecise but it is ok

for me). third - i also test if the whole triange lies back the camera plane then also clip.

I am looking for some techniques to do better clipping here.. preferably some easy ones in first, or medium hard, some hardest the last.. Could someone share some knowledge about such clipping?

Ps. (this model is 300 tys triangles in raw format (I wonder if i would split the data into vertexes and indexes it would fasten the drawing or slowing this... with indexes there is slightly less data probably but there in the code would be the look up for vertx instead of pure stream )

-----

EDIT

well after some thinking i invented something:

precomputing the visiblity, it goes such way:

from the given point of view (there are sphere of them)

some triangles of the model (say 30%) are visible

other (70%) are not - Divide this sphere on say 64

patches and precompute for every triangle if it is seen

from this 'patch' (it would be heavy to precompute,

for example cost of rendering a couple of frames

from couple of places on the patches, the testet

traingle the last to check if it pass the depth buffer -

so this is cost of 64patches x 5 places x noOfTriangles

so for example for this model 320x300 000 = 90 MFrames

this is a lot of precomputing :C but can be done i think)

then set the corresponding bit in some 64 word of flags

1 means form this patchg of visibility this triangle is seen

- that should be very simple to use and top eficient

clipping method :U - though this precomputation time scares me but this can be optymized (for example

it is easy to sign the triangles that goes out for sure,

it is harder to make sure the one that previously passed

will is totaly overvritten so it is also goes out, bout

probably by rendering in changed direction and suming

the onet that goes out will give the sum of the set that

is invisible)

I will try to implement it and check how it is working after some resting i shoul take

As to 'backface culling ' i did it by dot products camera dir and

face normal and throwing of face when its negative but it seem that not all models i use are cooked in such approach friendly way, 9some mixes both orientation of triangles and some treats some faces as a two sided.. so i off it

As to showing routines i could show it - it is badly (unaesthetically) written - but maybe in separate thread and later

camera direction is not fully correct, you need to use the direction between the eye position and one of the vertices of the triangle. otherwise you will cull too many triangles on at some places and too few at others. there are a lot of models cooked in a wrong way, but maybe in your tests it was just this bug and not the models -> fix it and test again ;)

for your culling idea, you just need 64patches x 5 places of frames. just render the object with a different color per triangle and then go over the frame and figure out what colors are in the framebuffer. all invisible triangles will have no color in the buffer. your idea is usually called 'pvs' "precomputed visibility set", you might find quite something about it on the net.

with this backface culling there is also something that

relies on direction of face vertices but i do net get

it (how to implement it) As I said incidentally minority of models i use are compatible with this backface culling

(So indeed I did it but under the key toggle and it is mostly off)

As to PVS it seem to be good idea for me, the way you say still needs as much frames as triangles (well i could not write color but face ids then scan the result - but my mentioned way draw the triangles container forward draw them backward (meybe yet some couple of other direction) and then sum all that sets which off as a invisible set for

that position - THEN repeat this for couple points on patch

and take common subset of invisibles would suffice

- now i am slightly tired to implement it but will try it

later, I only counted per frame the percent of triangles

that passed to 2d rasterisations versus all 3d triangles

sent and it vary between 10% to 50% (usualy only 30%

pass to 2d) so this is ok

as to bounding volume - do you know how this is build?

in preprocesing loops is sorted to wirtual boxes? then if

this is sorted, can it be used only to skip the boxes

that are out of frustrum, yea? It is not helping to cut (cull) of

the rear boxes behind the front boxes?