Simple 3D engine tech demo

[alexh]

I think he's talking about this one?

https://eab.abime.net/showthread.php?t=34481

[Rst7]

Originally Posted by alexh

I think he's talking about this one?

https://eab.abime.net/showthread.php?t=34481

No, this is another issues, I take into account this kind of behavior.

[Rst7]

Another gfx mode now possible - 32 colors with palette. Still reasonable performance, but for fastram configuration it can be optimized more.

[Karlos]

That's awesome. You know, 32 colours is fine. Consider an art direction, e.g. greyscale or sepia, something that naturally lends itself to a basic gradient that is representable that way.

[boemann]

Huge respect, and very interested in the coding side of things as well.

[Rst7]

Originally Posted by boemann

Huge respect, and very interested in the coding side of things as well.

You can ask any questions And look at source code on github

[boemann]

Originally Posted by Rst7

You can ask any questions And look at source code on github

So can the camera rotate in all directions ?

[Rst7]

Originally Posted by boemann

So can the camera rotate in all directions ?

Yes. Only yaw/pitch control (by mouse) now implemented in target code, but roll control processed too (by simple PID controller for zero roll angle).

[Karlos]

Originally Posted by Rst7

You can ask any questions And look at source code on github

I know it's absolutely not the intent here but have you considered how this might work on an accelerated machine with RTG? All the 3D transformation, affine texturing and tesselation, on a faster CPU with no actual C2P to care about. You could have the beginnings of a killer FPS engine.

[boemann]

So how do you handle the rendering - I imagine you don't do z buffer, but is it a (reverse) painters algorithm with sorted polygons. basically tell me a bit about these things. Thanks in advance.

[Rst7]

Originally Posted by Karlos

I know it's absolutely not the intent here but have you considered how this might work on an accelerated machine with RTG? All the 3D transformation, affine texturing and tesselation, on a faster CPU with no actual C2P to care about. You could have the beginnings of a killer FPS engine.

C2P stage now is not performance limiter. All other computations eat most time (C2P take about 10-15% on complex scenes) . Some improvements for accelerated machines can be done, but if you want 50FPS with 1280*1024 screen resolution without about-GHz CPU - it's impossible.

[boemann]

I have looked at the code but find it hard to orient myself in the code.

The reason I ask is that I would like to make a flight simulator with a curvy landscape

[Karlos]

Originally Posted by Rst7

C2P stage now is not performance limiter. All other computations eat most time (C2P take about 10-15% on complex scenes) . Some improvements for accelerated machines can be done, but if you want 50FPS with 1280*1024 screen resolution without about-GHz CPU - it's impossible.

C2P is a limit, in the sense that you are using 32 colours. I do have realistic expectations though, I was thinking 320*240, 256 colours on a faster CPU, but making use of the same 3D techniques.

[Rst7]

Originally Posted by boemann

So how do you handle the rendering - I imagine you don't do z buffer, but is it a (reverse) painters algorithm with sorted polygons. basically tell me a bit about these things. Thanks in advance.

Yes, there is no z-buffer.

All mesh splitted by kd-tree by boxes with faces. All boxes contains list of their faces. For all boxes there is potentially visible set of other boxes. PVS packed as compressed bitmap (something like a Quake's PVS).

At first engine find kd-tree node (box) with camera and take packed PVS for this box.

While PVS is depacking, engine test all potentially visible boxes by viewing frustum. This is done by tricky way with only 9 addition + 3 compare. This test is not ideal, but very fast. (You can check algorithms in functions DecrunchPVS and DecrunchPVSleaf in Map/render.cpp (PC-prototype, but written closelly with target code or vise versa)).

Face's lists of all visible boxes merging in one work list for 3D rotation.

After that all vertexes of all faces in work list rotated and projected (if applicable) in view space. All invisible faces (backface or out from view space) droping as early as possible (function RotateAllFaces in Map/render.cpp)

Next stage is radix sort by distance for face (function SortFacesAndDraw in Map/render.cpp)

After sort we can render all far faces as filled rectange (function RenderF in Map/render.cpp). This is simple (if you don't want have a fast render )

All mid-distance faces are rendered with simple affine texture mapping.

All near-distance faces split by horisontal lines with 20px step (in reality this is 4 divide planes) for tesselation. There is no face splits by vertical lines coz simple adding vertexes in split place to existing face is enough.

After this splits all faces are rendered with simple texture mapping again.

And the last stage is C2P.

[boemann]

Thanks a lot for that description that was really useful !

Now another question about the c2p: Why a HAM screen. Does it make the c2p more efficient somehow

[Rst7]

Originally Posted by Karlos

C2P is a limit, in the sense that you are using 32 colours. I do have realistic expectations though, I was thinking 320*240, 256 colours on a faster CPU, but making use of the same 3D techniques.

320*240*8bpl C2P is copy-speed on 030 50MHz. About 40000 color clocks, less than one frame.

More problems may be with math precision. I made a lot of simplifications due to resolution only 160*100. I'm not sure that this will be good in 320*240.

[Rst7]

Originally Posted by boemann

Now another question about the c2p: Why a HAM screen. Does it make the c2p more efficient somehow

Yes. But only for strange color mode 160px with 2 bits per R/G/B. But not very efficient as tested later, only a little.

[Karlos]

Originally Posted by Rst7

320*240*8bpl C2P is copy-speed on 030 50MHz. About 40000 color clocks, less than one frame.

More problems may be with math precision. I made a lot of simplifications due to resolution only 160*100. I'm not sure that this will be good in 320*240.

You have 4x the area to draw too.

[Rst7]

Originally Posted by Karlos

You have 4x the area to draw too.

Yes, this is a problem too. For example, test start scene now take 574 scanlines for texture mapping (all innerloops time). But it is rendered from chip ram (texture) to chip ram (chunky screen), if engine can use fast ram, speedup will be about 1.3 times. So with fast ram 020 14MHz engine will render scene about 441 scanline (again only tmap innerloops time). With 030 50MHz this will be about 4x speedup, but if we want 4x draw area, all CPU frequency grow will be spent on 4x draw. So start scene will be rendered in 320*240 with fast CPU not too fast as we want

For my opinion, better have 25FPS (or more!) on fast CPU with current resolution.

[Karlos]

Don you make use of any mip mapping with the textures? I recall that, at least when textures are in cacheable memory (which only matters if you have a CPU with datacache) that smaller versions of textures result in better cache access. Certainly this is noticeable in games like quake, where disabling the mip mapping really cripples the performance of the software renderer (as well as looking worse due to aliasing).