_It sucks._ It’s no better than the AMD 1090T, which incidentally was taken _off_ the market by AMD. Now I know why. The 1090T performs very similarly (with no overclocking at all, either chip) to the “new” AMD 8 core.

I was already using an AMD 1090T to do parallel raytraces. I thought I’d get a second machine as a workhorse. Built one for $500. Shoulda gone with Intel. I’m running the same raytrace in parallel, one on this machine (which I’m also using to write this post) and I’m leaving the FX 8150 alone. The FX 8150 spawned 8 threads to raytrace on (7 for raytracing and 1 for the UI) because 8 cores were detected, here on the 1090T only 5 raytracing threads are running, +1 for the UI thread.

So far they are neck and neck, even though I am using this machine to write this post. The FX 8150 machine has completed 119/300 jobs (each “job” is 2 800 pixel long rows), this machine 117/300 jobs. Totally terrible. I expected _some sort_ of improvement, with a 400 MHz faster clock speed and 2 extra cores, but you get absolutely nothing.

It’s the SAME core as the 1090T, far as I’m concerned.

DOES TRANSLATION VS ROTATION ORDER MATTER?

__YES IT DOES__.

From here on in, we will assume a COLUMN major matrix. This means that vectors are POST MULTIPLIED by matrices.

MATRIX1 * MATRIX2 * SOME_VECTOR

means SOME_VECTOR gets “hit” by MATRIX2 first, then MATRIX1. Matrix multiplication is associative, so it doesn’t matter if we multiply through (MATRIX1*MATRIX2) first, then multiply THAT resultant 4×4 matrix by SOME_VECTOR. The result will be the same if we do (MATRIX1*MATRIX2)*SOME_VECTOR or if we do MATRIX1*(MATRIX2*SOME_VECTOR). That’s associativity for matrices.

BUT IT DOES matter if we do

MATRIX2 * MATRIX1 * SOME_VECTOR

You will get a completely different result vs when you do MATRIX1*MATRIX2*SOME_VECTOR.

If you do translation*rotation, the effect is __spinning in place__, because ROTATE about axis (we are still @ origin), then translate.

translation * rotation, produces SPINNING effect, column major

translation * rotation, produces SPINNING effect, column major

If you do rotation*translation, the effect is __ORBITING__ around an axis, because trans FIRST, then rotate about the axis (which is now far away)

rotation * translation, produces ORBITING effect, column major

rotation * translation, produces ORBITING effect, column major

Final note, if you are using ROW MAJOR matrices, then these results are reversed (ie backward).

# Problem: patchy renders

# Diagnosis: Eye is TOO CLOSE to the surfaces when rendering hemicubes.

– turn OFF backface rendering (CULL THE BACKFACES!!)
– move the eye 1e-9 units in the direction of the eyeToLook vector (to move it JUST ABOVE the surface of the patch you are getting the hemicube for)

This error means visual studio 2010 is unhappy about a DEBUG/RELEASE/BUILD folder already existing. You need to go to your project folder and delete ALL build folders (/Debug, /Release) and then rebuild the project.

Also noted that constitutes a +90 degree phase shift in sin( x )

The reason r is sqrt( 1 + u^2 + v^2 ) is:

Here’s the msdn unshit scriptlet, which just replaces the /windows/desktop/ part of the url with nothing:

javascript:window.location = String(window.location).replace(/(.*)\/windows\/desktop(.*)/, ‘$1$2′ ) ;

EVERY VECTOR HERE IS A UNIT VECTOR EVEN IF IT DOESN’T APPEAR SO IN THE DIAGRAMS

If you have an incident vector hitting a surface (that has a normal defined for it!), then you can calc the angle of the reflected vector like so:

EVERY VECTOR HERE IS A UNIT VECTOR EVEN IF IT DOESN’T APPEAR SO IN THE DIAGRAMS

ANSWER:

reflected = incident – 2 × (normal ⋅ incident) normal

WHY?

EVERY VECTOR HERE IS A UNIT VECTOR EVEN IF IT DOESN’T APPEAR SO IN THE DIAGRAMS

All you’ve gots to do is look at the angle the incident makes with the normal. That’s what the formula I gave says anyway.

But also consider this. If the incident is perpendicular to the normal, then the reflected angle has pretty much no change from the incident angle. IE AT the case where the incident vector has an angle of 90 degrees with the normal of the surface, the “reflected” vector (if you can call it that!) is in the same direction as the “incident” vector. That is because the dot product (normal ⋅ incident) goes to 0 when the angle between incident and normal is 90 degrees, so:

reflected = incident – 2 × (normal ⋅ incident) normal
reflected = incident – 2 × (0) normal
reflected = incident

So that’s interesting. Now consider the other case where the angle between the normal and incident is 180 degrees (ie the ray hits the surface head-on):

EVERY VECTOR HERE IS A UNIT VECTOR EVEN IF IT DOESN’T APPEAR SO IN THE DIAGRAMS

reflected = incident – 2 × (normal ⋅ incident) normal
reflected = incident – 2 × (-1) normal
reflected = incident + 2 × normal

IE reflected turns completely around.

For everything else in between, there’s cosine.

So there is LESS change in the direction of the reflected angle as the incident-normal angle grows. This is encoded by the dot product/cosine in the normal reflection.

Ok, here’s the math for it.

Using this diagram:

EVERY VECTOR HERE IS A UNIT VECTOR EVEN IF IT DOESN’T APPEAR SO IN THE DIAGRAMS

The angle THETA there is going to be the cosine of the NORMAL and the INCIDENT

The SMALLER ANGLE GAMMA is going to be (THETA – 90) because the normal is at an angle of 90 degrees with the surface. That’s why its a normal, duh!

Now then some simple vector math will give you:

The length of the pink side X (perp distance to surface from INCIDENT vector:)

X = sin( GAMMA ) (remember incident is a unit vector)

So, now

REFLECTED = INCIDENT + 2 (sin (GAMMA)) ( NORMAL )

This makes sense because WHEN (sin(GAMMA)) is small, (angle between INCIDENT and NORMAL == nearly 90 degrees) we don’t need to add a large “displacement” in the direction of the normal to get the reflected vector (we add 0 x normal in the extreme case of a 90 degree INCIDENT angle with NORMAL). As the angle between NORMAL and INCIDENT INcreases, so does the displacement we need to use to the reflected vector, until we get to the other extreme case where the REFLECTED = INCIDENT + 2 * NORMAL.

Ok then, simplify.

REFLECTED = INCIDENT + 2 (sin (GAMMA)) ( NORMAL )
REFLECTED = INCIDENT + 2 (sin (THETA – 90)) (NORMAL)
REFLECTED = INCIDENT + 2 (sin (THETA)cos(90) – sin(90)cos(THETA)) (NORMAL)

cos(90)=0, sin(90)=1

REFLECTED = INCIDENT + 2 (-cos(THETA)) (NORMAL)

cos(THETA) = INCIDENT ⋅ NORMAL

REFLECTED = INCIDENT – 2 ( INCIDENT ⋅ NORMAL ) (NORMAL)

And there you have it.

In this model I have, it does the most ODD things.

One thing it does (but this is valid, just I didn’t expect it) is it uses negative texcoord indices sometimes (so f 5/-1 126/-2 140/-3 52/-4). Negative indices just means to use the last vt, 2nd last vt, etc.

The thing it does apparently wrong is it DOES NOT include any newmtl statements, or a mtllib file, and it uses usemtl statements as if they are _IMAGE FILENAMES_ (really its supposed to be map_kd, or map_ka).

The quick fix is to add code:
– if usemtl is attempted but that mtl doesn’t exist, create it and see if there is an image with the same filename as the mtl. If there is, load it and use it for that mtl.
– check the vt index and if it is negative, use the -whatever vt coordinate from your current point in the file

These aren’t _that bad_, but they really should follow the file format correctly

Also, it exports non-convex polygons.