To rephrase what is being stated:

Everyone agrees learning is a good thing. Rendering alone is a deep enough issue that you could dedicate your life to it. While I am for learning for learnings sake, I think stating that learning enough to make use of something is time well spent too.

For example. If you wanted to integrate speach reco into your engine, would you spend years learning the theory and mastering it, or would you use an API?

I wish I had infinite time and could learn everything I wanted to learn.

quote:

---

Original post by haro
If you were forced to write your pretty demo''s in an architecture that had no specific graphical API''s would you be able to go from plotting a pixel on the screen, to having your amazing bump mapped, volumetric lit, blah blah blah demo? I am very proud that the answer to that question is quickly becoming a ''yes'' for me.

You also call it a step back, but I have no doubt in my mind that if you asked the developers of any AAA game to be able write a port of their program to DOS (with support for a specific video card) they would have zero trouble doing it. These people actually know what they''re doing.

---

No problemo. It think it''s a great thing to understand it all right from the ground up, so you know exactly what you''re doing and why you''re doing it every step of the way. I only have a very basic grasp of how D3D or OpenGL do what they do, and I''d love to have a much better understanding of what''s going on.

My only concerns are, isn''t it going to be staggeringly slow? And how easy is it to port this low-level knowledge to using hardware acceleration to do the same things? Or am I just overestimating the differences between rendering in your own code and getting an API and hardware to do it - is it really just a matter of speed?

zephyr

quote:

---

Original post by zephyr
My only concerns are, isn''t it going to be staggeringly slow? And how easy is it to port this low-level knowledge to using hardware acceleration to do the same things? Or am I just overestimating the differences between rendering in your own code and getting an API and hardware to do it - is it really just a matter of speed?

---

As far as slow. I''d say within a few months you could have a fairly good grasp on the concepts that go into a rendering system. On the other topic, I most definitely think you are overestimating the differences between a software renderer and D3D/OpenGL. You have to remember that on the bottom, Direct3d and OpenGL do exactly what you''re software renderer will do, only using dozens of different video cards video memory as the render area, as opposed to a back buffer which your software renderer uses.

I''ve found porting from software to hardware extremely trivial so far. Everything flows since your software API and DirectX/OpenGL do essentially the same thing. The knowledge I''ve gained in developing a software renderer has expounded my knowledge of DirectX ten fold. Simply knowing what happens when you tell DirectX to do something helps infinitely.

Learning the principles of software rendering is a good thing. You''ll need to know this stuff if you ever switch to a non-PC platform, or if you want to make your 3d engine more backward-compatible.

For example, I recently ran into an interesting problem with certain ATI mobility video cards that don''t have drivers beyond OpenGL 1.1 thanks to laptop vendors'' laziness. Otherwise the performance is just fine (enough for Quake3).

Now, I wanted to use dot3 bump mapping that isn''t in the 1.1 spec. Knowing how dot3 bump mapping works I was able to implement it in software (it''s a very, very fast algo) and just upload unique textures with baked-in diffuse lighting that looks reasonably similar to dot3 but doesn''t require hardware support for it.

quote:

---

Original post by zephyr
My only concerns are, isn''t it going to be staggeringly slow?

---

On these days'' computers, you could write crap and it would still run fast.

knowledge of the theory is essential, because it gives you an idea of what the limits and capabilities are for your particular problem.

however, implementing a software renderer is probably excessive. if you know (can derive at will) the 3d math, the poly filling/clipping, the lighting and texturing theory, then actually implementing it is unnecessary, because a group of people with far more time, backed by far more money, with far more experience have already put it in silicon.

what you can do however is use existing algorithms for different purposes. i for instance am working on a terrain engine based largely on texture mapping and rasterization algorithms. without knowledge of these algorithms i would never have thought of it, but i didnt need to write a software renderer to apply the theory.

just my opinion,
james