Learning Math For 3D Programming

Using this book: http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Third/dp/1435458869

I'm trying to learn so that I can write a simple ray tracer. Once I've done that, I want to write a path tracer and then implement metropolis light transport as a semester project for a class.

The only problem is I've never done any kind of graphics programming before, so I have no idea if my craptop is going to be a huge problem. It has integrated graphics and an intel core 2 with 2 cores running at 1.66ghz. I figure that this will be fine because ray tracing is more dependent on the CPU than the GPU, isn't it?

Just don't want to put in the work and then have to buy a new computer, I'm fucking broke.

Also, how feasible is it to do this in C#? My class is titled "Computer Graphics", but it is taught by a CIS professor, and there are 9 CS students and over 20 CIS students in the class, so it covers precisely nothing that one would expect to find in a CG class, and is really just an introduction to C# and XNA, with a semester long C# project to go with it. The entire first month is going to be spent on fucking C# syntax and collections in a 4000-level class.

I need something cool to do graphics-wise in C# here. I don't want to write a shitty space shooter. I can't even install XNA on my computer, anyway, as it doesn't support shaders, so I have to borrow a computer for the XNA assignments. If a cool ray tracer isn't feasible, what is?

1) Analytic geometry
2) Linear algebra
3) ?????
4) Profit

So don't bother looking for a new laptop? Anything with a video card is ridiculously expensive.

Ray tracing is easily feasible, language doesn't matter unless you are wanting to implement intensive features (global illumination, super sampling etc). Path tracing is a bit harder and not as well understood.

Almost nothing will be done on the GPU unless you write for the GPU yourself (don't, anything you could write within a year or two will render in under 30 seconds anyway).

Step 1: Write Vector3f class. Scalar multiplication, dot product, cross product, normalization, addition, subtraction, negation, modulation, saturation, length, and distance functions go in here.

Step 2: Write simple Ray3f class. A ray is just two Vector3f's, (point and direction).

Step 3: Create simple object. Each object needs a getNormal function which takes a point and returns the object normal at that point, along with an intersection function which takes a ray and returns the point of intersection, if it exists. A sphere is probably easiest to get up and running.

Step 4: Write camera. This gets created with some view parameters (fov, width, height, eye point, look at vector, up vector (usually 0,1,0)). Has a getPixelColor function which creates a ray from the eye point through that pixel on the image, and then intersects it with all objects (spheres) in the scene with a depth buffer to get the color. You can now create images.

Step 5: Optionally, implement lighting (could be simple models like Phong, or advanced BRDF, radiosity, photon mapping etc), AA, more objects, texturing, CSG, reflection, refraction, shadows, caustics, dof, and so on.

No it's better to do the raytracing with the GPU...

because if you trace the rays with the CPU it will take much longer... =D
because the CPU has to trace the rays and in the same time run the program that trace the rays... =)

If youre using OpenGL, you'll need a very recent graphics card to anything with OpenGL 4.0

Doing raytracers is fine on DirectX which was XNA uses, but youre stuck using C#

>>6
I seriously hope you aren't recommending a beginner implements a ray tracer in OpenGL.

>>4
Sorry, but what do you mean by vector modulation and saturation? Google doesn't turn up anything that seems relevant to ray tracing.

Thanks a lot, by the way!

ray tracing.. funny. i remember gawking at parametric equations for sound visualizations in winamp.

>>8
Modulation as in colour modulation, component-wise multiplication.  Saturation is clamping between 0 and 1 (you probably won't need this).

>>4
Now that I'm writing a Vector3f class, I'm wondering if it wouldn't be better to just use 4D vectors? e.g., <x,y,z,w>, where w=0 implies that the vector is a direction, and w=1 implies that the vector is a point, for easier transforms.

Is this worth doing at this point? Or should I not worry about it since I won't be making anything move, as my goal is to make pretty pictures and not a real-time renderer?

>>11
It doesn't really matter. In any context you should know if something is a vector or a point.

w=1 is only useful if you want to be able to translate points using matrices, do you want to do that? (Probably not unless you are implementing arbitrary object transformation wrappers).

I see, then I'll just stick with 3d vectors. Thanks!

As implementation goes, could I run into trouble making a separate class for colors instead using vector3fs? From what I've read so far, the only functionality such a class would need are component-wise addition and multiplication.

Never mind, I'll leave modulation in the vector3f class and worry about OOP if it bites me in the ass. :3

I am ashamed to say that it took me like eight hours to do this:

http://imgur.com/Fhxgs

However, the last two of them were spent debugging a collision detection error due to using integer division at some point in my code. I'm not sure if that should make me feel better or worse. ;_;

Progress will be made.

Awesome pics. Great size. Look thick. Solid. Tight. Keep us all posted on your continued progress with any new progress pics or vid clips. Show us what you got man. Wanna see how freakin' huge, solid, thick and tight you can get. Thanks for the motivation.

Add some Phong/Blinn shading and it will be looking sweet bro.

>>4,11
Nice advice/direction, but it's wrong. WRONG. Object-oriented math primitives are WRONG. You won't see any professional game developer doing this anymore.

They just write a thin abstraction layer over top of the target platform's SIMD intrinsics, and keep their vector types as a typedef of the underlying SIMD vector type. Then they build their generic portable C/C++ version to match the same interface, after the fact.

On x86/x86-64, it's something like: typedef __m128 float4;

2D/3D/4D vectors are just float4. Ray's are just float4. Planes are just float4. A bounding sphere representation is just a float4. an axis-aligned bounding box is two float4s. A 4x4 matrix is an array of four float4s.

Behavior is implemented through free functions and they look similar to something like GLSL/HLSL graphics shader math functions. Using OOP for this is just going to end up resulting in a bunch of useless boiler plate for something that is 10x slower than what you could have with a SIMD optimized math library as well as more difficult to use.

Read this OP: http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php

Then read about SoA vs AoS order for vector processing.

>>17
Also, I forgot you're using C#. XNA already has math primitives that thunk into native code for SSE2 support. But there's also SlimMath for C#/.NET which has a more optimized SSE implementation.

http://code.google.com/p/slimmath/

>>17,18
You won't see any professional game developer doing this anymore.
You won't see any professional game developer implementing an in-engine ray tracer so this point is completely fucking moot.

Does babby writing his first raytracer really need to take a big fat dick of SEE up his ass? An octree will give vast performance improvements over using SIMD intrinsics, why don't you suggest that instead?

>>19
>You won't see any professional game developer implementing an in-engine ray tracer so this point is completely fucking moot.
Actually, ray tracing is starting to be used for some things. You can implement a ray-tracer as a gpu shader/compute kernel over a screen fragment for hybrid rendering. Using a deferred shading rendering architecture, it becomes a lot easier to support polygonal rasterization and ray-casting/ray-tracing side-by-side.

Ray-casting/ray-tracing is the preferred method for voxel rendering, voxel mesh splatting like what is done in minecraft is a joke.

This is an implementation written in CUDA, although it could just as easily be implemented with OpenCL or DirectCompute for better portability: http://code.google.com/p/efficient-sparse-voxel-octrees/
http://www.youtube.com/watch?v=Mi-mNGz0YMk

That aside, if you don't learn about SIMD early on, you're also doing it wrong. Too many college graduates and retarded hipsters have no clue about SIMD. Oct-trees are pretty simple to implement, changing your renderer to use them is fairly straight-forward as it doesn't affect your entire code-base. Changing your renderer to use SIMD is more labor intensive as it affects everything. It's better to start with support for SIMD at the beginning of a project.

Update - http://i.imgur.com/M7mWn.png
Before, I had a basic sphere class, vector, and ray classes. The circle I did before was hard-coded in a main method with a double-level for loop casting a ray for each pixel and checking for intersection with a single object, then setting a pixel in the image to a fixed color.

I've since added a Primitive class from which spheres, etc. inherit from, each containing an instance of a Materials class to keep track of a primitive's color, diffuse, and reflective properties. Also created a Scene class to setup multiple objects and detect intersections between a ray and those objects.

Rendering is now also done in its own class with projection plane, camera position, etc. values that are no longer necessarily hard-coded at run-time.

Unfortunately, the only visible difference is that it's easy to render multiple objects now, and that doesn't even work right because my spheres seem to come out overlapping for some reason I haven't thought about yet. v_v;

Anyway, I'll look into SIMD, specifically Slimmath, while my project is still small and easy to change.

I know it might not be easier to use/understand right off the bat, but I'd like to turn this project into something impressive, which is part of the reason why my goal is to implement something complicated like path-tracing and MLT. Also, caustics look fucking awesome and I've heard MLT is particularly good at those. >.>

But yeah, if using SIMD will provide me with a better learning experience and give me something cooler in the long run, I'll take a look at it, now that I'm starting to get some idea of how ray-tracing works.

Actually, I don't really understand how path-tracing differs exactly from ray-tracing just yet, and I'm still not comfortable with ray-tracing, but I figured that implementing the following features would be good preparation for jumping into path-tracing:

Point lighting
Phong shading
(SIMD) //if i decide to go with this, i'll probably do it here
Spot lighting
Directional lighting
Plane objects
Reflection
Refraction
Caustics

Do you guys think this sounds like too much? Also, that's the order I would tackle them in, so if that order seems off, please me know, too.

DUBZTEP <---CHECKIT