17 replies to this topic

[Hertta]

Lately I've been interested about OpenGL and DirectX for 3D. However, I believe that the better approach would be to understand the 3D in-depth before going in to 3D via API. Thus I'd love to gain some experience, and I think that software rendering is the best way to achieve it.

I've checked the DevMaster article but I would like to read it in more newbie friendly way. Maybe my google-fu is weak since I haven't had much results regarding this. Maybe I am 15 years late? :D

Any books, articles, whatever regarding software rendering is welcome. To dephten the thread, I'd like to hear others experience and history with software rendering, discussing it's pros and cons and way of implementing it, different algorithms etc.

Your turn. ;)

[imerso]

I think that http://chrishecker.c...hnical_Articles is still a very valid lecture, and totally agree that software rendering gives you a better understanding of computer graphics in general.

But in practice, there is the problem that it is traditionally slower than hardware rendering, which implies in simpler graphics and lower resolution to achieve acceptable interactive speeds, so the average user will not understand the fact that you're doing ALL the work yourself.

Unless the new many multicore tech brings SW back, I don't see it as a viable real world option, but as a great learning experience only.

[Nyx]

vrnunes said:

Unless the new many multicore tech brings SW back, I don't see it as a viable real world option, but as a great learning experience only.

If we do see CPUs with tons of cores someday, people will most likely want to use all that power for software raytracing/path tracing rather than software rasterization.

[Hertta]

Nyx said:

If we do see CPUs with tons of cores someday, people will most likely want to use all that power for software raytracing/path tracing rather than software rasterization.

By that time I think that GPU's would do the trick even better. :huh:

[rouncer]

A software rasterer (ive written a few) is comprised of

* a perspective correct textured triangle renderer
* a clipper (do this in 2d after youve projected, except for the near plane)

the triangle renderers need is obvious, but without the clipper you wont be
able to go "inside" the objects, so you wont be able to model an environment
without a clipper.

also, you need these

* a good easy to use vector and matrix library
* a good interface to get the models onto the screen with with little code.

then after that its almost exactly identical as using direct x anyway.


but one last thing ill tell you, is that software rastering gives you total freedom in how you do things, so anything is possible like texture coordinates in the triangle indices instead of vertices, you can go quasi voxel also.

its limitless and i think its perhaps MORE fun (maybe a little more challenging at the start)

I had some success with multicore, but youll never get anisotropic filtering like on the video card...

[Hertta]

Found some material. However, it seems that almost all of them require quite a bit knowledge about how 3D works, i.e. experience with OpenGL/DirectX. This obviously goes against my current experience and the reasons I want to do it in software.

Maybe the best question: Where did you learn software rasterization from?

[Goz]

Hertta said:

Maybe the best question: Where did you learn software rasterization from?

Id been playing with 3d transformations using BGI (Borland Graphics Interface) to do my rasterisation. Eventually i wanted texture mapping and Z-Buffering so I started work on my own rasteriser. I started out simply scan converting a triangle and then using something called a "pencil and paper" (;)) I worked out the rest as I went along :) It was hard learning this stuff pre-internet ... I do however have a bloody good understanding of how such things work now.

[rouncer]

You can work the clipper out yourself for sure...
one handy tip - perspective texture mapping means you interpolate 1/z not z, and it comes out curved across the triangle
instead of flat straight which isnt correct at all.

[v71]

Look like you want to follow the path i have started about 20 years go, all i can say is do it only if you want to havea deep 3d knowledge and unfortunately , today isn't going to help you much, if you want to get a job, you need to know shaders ( which i hate write ) and dx or opengl, taking account that opengl is dying i would go for dx10 and have a good math background .
One day you might regret having spent time on a pure sw rasterizer as i did

[rouncer]

Theres nothing to regret about sw rasterization, quake 1 look still comes out!

hehe that sounds bad, nah, editors like zbrush are soft rastered and look great.

[.oisyn]

Some articles that have helped me in the past: 3DICA, Zed3D

[Kenneth Gorking]

.oisyn said:

Some articles that have helped me in the past: 3DICA, Zed3D

Heh, I used those exact two when I started out :)

Another thing I did, was download engines and code-samples that did software rasterization, and study it to see how they did it. I remember there was a lot of Quake I+II level loaders around at the time, and alot of them used software rendering to display the levels.

[Nick]

Hertta said:

Lately I've been interested about OpenGL and DirectX for 3D. However, I believe that the better approach would be to understand the 3D in-depth before going in to 3D via API. Thus I'd love to gain some experience, and I think that software rendering is the best way to achieve it.

If ultimately you want to use OpenGL and Direct3D then I don't think writing a software renderer wins you anything. You'll spend a lot of time implementing things that are easy to understand as an abstraction but hard to get exactly right. Furthermore, modern graphics cards are so programmable by using shaders that you'll really learn the same skills anyway.

Quote

To dephten the thread, I'd like to hear others experience and history with software rendering, discussing it's pros and cons and way of implementing it, different algorithms etc.

In my experience software rendering is almost worthless without the use of a 'hardware' API. Spinning a teapot on your screen is fun and all that but it takes you several months to implement (with hardware rendering, one day), and unless you're an artist it won't get more exciting than that. But implementing OpenGL or Direct3D in software is an even greater task, and if your only goal is to learn how these APIs work then you might as well go with hardware rendering directly and learn much faster.

Quote

Maybe the best question: Where did you learn software rasterization from?

Most of those documents are nowadays horribly outdated and would just set you off on the wrong foot. Chris Hecker's articles linked above are probably still the most valuable though.

[Nils Pipenbrinck]

Just to give some additional resources: There is also fatmap.txt and fatmap2.txt. As with all 10 year old stuff the assembler innerloops are obsolete now, but the theory is still valid.

Here's the link to fatmap2: http://www.exaflop.org/docs/fatmap/

[Nyx]

Nick said:

If ultimately you want to use OpenGL and Direct3D then I don't think writing a software renderer wins you anything. You'll spend a lot of time implementing things that are easy to understand as an abstraction but hard to get exactly right. Furthermore, modern graphics cards are so programmable by using shaders that you'll really learn the same skills anyway.

I'd say it's not necessary to implement a rasterizer to understand all that's involved. You can skim over the theory and understand most of it. The most valuable skill is a good understanding of linear algebra (vector, matrices, projection, etc.).

Quote

In my experience software rendering is almost worthless without the use of a 'hardware' API. Spinning a teapot on your screen is fun and all that but it takes you several months to implement (with hardware rendering, one day), and unless you're an artist it won't get more exciting than that. But implementing OpenGL or Direct3D in software is an even greater task, and if your only goal is to learn how these APIs work then you might as well go with hardware rendering directly and learn much faster.

Implementing OpenGL in software would indeed be tedious foolish, especially since it's already been done (http://www.mesa3d.org/). However, there are things to be learned by experimenting. Personally, I will say that I gained deeper insight into this by implementing a raytracer. This didn't take me 20 years, it took me about a week or two... I had spheres raytraced in about a day.

But anyways, let's break it down... How much time should it take you to spin a teapot on your screen in software? Let's assume C++ is being used.

Reading about matrix and vector algebra to understand the theory
- 0 to 30 hours, you might already know this from school
- This knowledge will stay with you for life, it's not wasted effort

Implementing basic matrix and vector algebra classes with operator overloading
- 5 to 20 hours
- ~400+ lines of code
- What you essentially need is matrix multiplication, vector addition, scalar multiplication, dot product, cross product

Reading about the theory behind perspective projection and scanline rasterization
- 4 to 30 hours
- Again, definitely not wasted effort, will help you understand any 3D API

Implementing perspective projection using your linear algebra primitives
- 2 to 5 hours
- ~200+ lines of code
- Here you simply need to understand your camera model and apply the corresponding linear algebra

Implementing naive, flat-shaded polygon rasterization, for the sake of learning
- 2 to 10 hours
- ~400 lines of code
- Here I'm talking about the code to scan through a polygon, scanline per scanline, and write pixels in a frame buffer

Implementing an OBJ model loader and a TGA image writer to read that teapot model and save the rendered image somewhere
- 3 to 8 hours
- ~300+ lines of code
- Those classes can be practical to implement a simple 3D engine or a raytracer, too

Total: 16 to 103 hours, ~1300 lines of code
- Assuming 12 hours of work a week, 1 to 9 weeks
- Assuming 20 hours of work a week, 1 to 5 weeks

My point is that the time varies greatly depending on your skill level, but most of the effort willl be spent reading, gaining valuable insight into how rasterization work at a high level. To get very basic software rasterization working for the sake of learning can be done in less than a week, once you actually understand the principles behind it.

Of course now, if you want texture mapping, lighting, anti-aliasing, and to optimize it all with ASM/SIMD, it will take longer, but at that point, once you have your basic rasterization structure in place, such "upgrades" are actually pretty easy to implement. As you pointed out, many of these things are hard to get "exactly right", but you can still have a toy renderer working pretty quickly, and with a little extra effort, you might even bring it to a sufficient level that you could implement a quake/doom-like game with it. Performance isn't going to be as insanely important as it was back in the doom and quake days.

[imerso]

There are some platforms where software rendering is still alive, an example is the Pocket PC, but even those devices are getting hardware acceleration.

As a final note, you will still need all this knowledge if you are going to create a new GPU. OK, but then you went pretty hardcore. :-)

[lomaany]

What are some 3d max alternatives? I want to learn how to make 3d objects and render them but I’m NOT spending 3500 bucks for 3d max. Are there any MUCH cheaper programs out there that do kind of the same thing?

[imerso]

some good and free alternatives:

www.blender.org
www.wings3d.com
www.povray.org