Comment by marktangotango | Hacker News Reader

Comment by marktangotango | Hacker News Reader

Doing 3D rendering in software is incredibly satisfying, it's one of those things that can make you feel like a REAL computer programmer (compiler implementation has a similar effect, I believe).

I briefly scanned through these articles and did not see any mention of polygon clipping. A note to the inexperienced; it took me some years (I am dense at times) to realize that one of the primary uses for polygon clipping is to clip polygons against the view frustum in view space (ie after polygons have been projected to the screen). This is useful to only draw the part of a possibly very large polygon that is visible. As a consequence of clipping, a triangle can result in 5 sided polygon, so drawing/rasterizing arbitrary polygons, not just triangles is desirable. You'll often read about rasterizing arbitrary side polygons when studying software 3D, this is why.

Also, I always like to link this tour de force by Charles Bloom when software 3D comes up, it's a great read:

http://www.cbloom.com/3d/techdocs/pipeline.txt

In modern graphics programming there are really two layers to writing a 3D engine; low-level and high-level. Funny enough, low-level rendering code does not mean the same thing today as it did 20 years ago.

I totally agree that knowing how triangle/fragment clipping works at the lowest level is a valuable skill but for the vast majority of people its a level of complexity way above their need. From a practical perspective (i.e. you want to make a Game, Simulation, realtime 3D rendering of any kind), you should not be writing a software rasterizer. As an exercise in learning, go for it, but if you want to have both practical and marketable skills, you need to learn a graphics API like OpenGL, Direct3D or even Metal. These APIs mask a lot of the implementation details but in return you get a fast, reliable and consistent API.

From a high-level, you find ways to use these APIs in smart ways to optimize for modern graphics cards. That in itself is a MASSIVE challenge and not to be underestimated. This is where a smart use of API calls becomes an excellent Engine.

For myself, I started backwards, learned OpenGL then Direct3D then finally built a software rasterizer and raytracer. To me that was a great way to learn because I first understood the high-level concepts (what are textures, what is a mesh) before learning low-level concepts (what are barycentric coordinates, how does bresenhams work, how do you do perspective correction).

There's even a third layer -- engines like UE4 or Unity or libraries like SceneKit. There are so many steps to setting up shaders and lights that it's handy to have something that can intelligently handle all the moving parts -- like juggling the limited per-pixel lights with vertex lights, for example.

How can a third party commercial 3D engine be a layer to writing your own 3D engine?

I imagine maybe by not providing all the pieces one might need in certain types of rendering algorithms.

Just a guess.

Excellent post, thank you.

Surprisingly, there are still areas where SW renderers are the only way, like in underpowered navigation devices without OpenGL support or running on exotic embedded operating systems.

I second this. When I wrote my first frustum cull method it opened up so many other possibilities. After clipping, I would say look into writing a quadtree (2d) followed up by an octree (3d). Even though quadtree's are confined to a single plane they are quite useful even in 3d games.

I can recommend the game programming gems series. I don't know what number they are up to now, I had the first three and they were a huge asset in learning all these techniques and more.

Another really awesome talk to watch about some aspects of this is David Braben's talk on making the original Elite in 32K of ram.

I think this is the link but it doesn't work on mobile: http://www.gdcvault.com/play/1014628/Classic-Game-Postmortem

It's also nice to check out CUDA if you have a Nvidia card. You can run parts of your code very easy on the GPU gaining a lot of speed.

If I'm a "normal" web programmer, how much of a step up is Cuda programming going to be? I've got some geospatial functions (like point-in-polygon) that might benefit from being run on the GPU.

http://sysweb.cs.toronto.edu/publication_files/0000/0247/icc... is a good example of the kinds of things I'm looking at but I only barely grasp the concepts in the paper itself.

As far as I know Cuda is only available as a C bin.

CUDA can be programmed in C, C++, Fortran, Haskell, .NET, Java and any other language with backends than can spit out PTX, hence why researchers always favoured it over OpenCL.

OpenCL now has SPIR

I know, it was a response to those developeers wanting to stay away from OpenCL C code or using translators that would generate OpenCL C from their languages of choice.

Lets see if they are still on time to change the wave.

I think there's a decent MOOC on udacity; or at least there was at some point. Linear algebra helps a bit, but you can probably pick up most of what you need to get started.

Reply on news.ycombinator.com