
Learning how to write a 3D engine from scratch in C#, TypeScript or JavaScript (2013) - adamnemecek
https://blogs.msdn.microsoft.com/davrous/2013/06/13/tutorial-series-learning-how-to-write-a-3d-soft-engine-from-scratch-in-c-typescript-or-javascript/
======
marktangotango
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](http://www.cbloom.com/3d/techdocs/pipeline.txt)

~~~
Negative1
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).

~~~
sehugg
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.

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

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

Just a guess.

------
evincarofautumn
I noticed an interesting optical illusion with the rotating cube vertices
example: if you interpret it as rotating one way, it’s an ordinary cube—the
back face appears smaller because it’s farther away; but if you interpret it
as rotating the _other_ way, you see a shape that’s constantly stretching and
deforming.

This leads me to wonder what a game would look like if all perspective were so
inverted, so that the _farther_ away an object is, the _larger_ it appears.

~~~
corysama
Reverse perspective rendering:
[https://vimeo.com/12518619](https://vimeo.com/12518619)

~~~
iamcreasy
Can't even imagine how it would look like with VR.

------
okasaki
That's a renderer, not engine. An engine is a lot more than just putting some
triangles on screen.

------
munchbunny
This is like learning how to write a ray tracer, or learning to write a
compiler, etc. etc.

In other words, it's elucidating to do, but unless you're an industry veteran
or subject matter expert, you should almost never do it with the intent of
actually using the result.

------
reedlaw
Can anyone recommend some advanced tutorials for making a 3D engine with
OpenGL? I'm looking for something beyond rendering simple polygons with
gouraud shading. How do you handle loading large worlds while maintaining a
high frame rate? How do you make scenes more realistic with shadows and
ambient occlusion?

~~~
munchbunny
This is a very, very deep rabbit hole. The kind which people make PhD's and
careers out of digging into this hole. Actually, it's several holes.

Loading large worlds while maintaining a high frame rate? It's one deep
problem for Skyrim-style worlds. Another for shooters. Yet another for
Minecraft. Shadows are yet another deep problem, and so is ambient occlusion,
and any number of lighting/rendering techniques.

In other words, you're not really in tutorial territory anymore. You're in
article/paper territory.

~~~
moonchrome
As someone whose dug these holes before - there are tutorials even for
advanced stuff, usually when a hacker figures out some paper he shares it with
others in a less academicky way and then it's much easier to pick up. I still
remember casey muratori gjk video in highschool, i found some paper using math
notation for sums and throwing abstract terms arround and then I saw this guys
video and it clicked and I had a collision detection demo running in two days.

Academic approach is nececary for research work but when you're just
implementing stuff it's already been groked by other people and you can find
their blog/notes/code online.

------
rocky1138
This is something I've wondered about for years. It truly feels like a black
art. I look forward to reading this.

------
piyush_soni
This is very nice! For once, we should try to write _everything_ that's
happening in our pipeline ourselves!

------
misnome
Does anyone know of any accompanying articles, but for raytracing, or other
methods of rendering? It'd be nice to have a suite of examples of different
methods.

~~~
fogleman
I found these very helpful when writing my own path tracer:

[http://www.thepolygoners.com/tutorials/GIIntro/GIIntro.htm](http://www.thepolygoners.com/tutorials/GIIntro/GIIntro.htm)

[http://www.iquilezles.org/www/articles/simplepathtracing/sim...](http://www.iquilezles.org/www/articles/simplepathtracing/simplepathtracing.htm)

------
bozo1979
Nice post. I'm trying to read up on opengl es to prep for a vr world. Having a
hard time at it. I'm a back end dev so maybe not my strong suit.

~~~
ktRolster
I've been thinking of doing something similar. What frameworks and such have
you considered using? That is, what tools do you think would be helpful?

~~~
bozo1979
Unity is high level and really easy to code. But it is not opengl .. I have
been watching courses onot computer graphics to try and figure it out but
tough going as I said.

