yet another nooby raytracer

[H3ro]

Hallo,

I started writing, but the forum did something stupid when I pressed one of the links I was trying to add here.

In short:
Cool to see your project, looks good so far. I am working on a raytracer as well, but looks like you have had more progress than me. If interested, you can see my raytracer a few threads down.
For help with loading object files, see this links:
Link1 (http://local.wasp.uwa.edu.au/%7Epbourke/dataformats/obj/)
Link2 (http://www.ultimategameprogramming.com/demoDownload.php?category=OpenGL&page=6)

Also, the way you are doing ray intersection looks a bit weird I think, so you might want to reconsider that part. (assuming thats what your doing in the main.cc you posted)

Good luck with development

[rende]

hey, ye i saw your project.. thats why i posted mine here aswell :) thanks for the reply

Also, the way you are doing ray intersection looks a bit weird I think, so you might want to reconsider that part. (assuming thats what your doing in the main.cc you posted)

yeah its because im converting between different variabl e structures... very messy. Well I'll try and recode the obj loading part and see if i can get that silly bug sorted out. Thanks for the links btw.
Next is 3d transforms (rotation/scale etc.. of loaded objects and the camera) image output so i can start rendering animations. :scream:

Duno where to start with lighting though... i've read up a little on matrix transformations and vector math, but I guess i've been away from maths for too long after school.

[H3ro]

Here is my code where I call the intersection routine. Hope it helps.


// Loop through all the primitives in the scene and return the
// the closest one
for (int currentPrimitive = 0; currentPrimitive <=totalPrimitves;
currentPrimitive++)
{
// Find the primitive we are currently testing against
Primitive* testObject = thisScene.getPrimitive(currentPrimitive);

// Check if the ray hits the current object
intersectionRes = testObject->intersectionTest(currentRay);

// If the ray hits something, check if its the closest object
if (intersectionRes.hit != 0)
{
// Find closest primitive by comparing distance
if (intersectionRes.distance < closestDistance )
{

closestDistance = intersectionRes.distance;
closestPrimitive = currentPrimitive;
}
}
}


Lighting is not that hard, all you have to do is to create a new ray and see it it hits any of the lights in the scene.

[rende]

Wanted to quickly ask this.. from http://www.flipcode.com/articles/article_raytrace01.shtml i saw he normalizes the ray direction vector
vector3 o( 0, 0, -5 );
vector3 dir = vector3( m_SX, m_SY, 0 ) - o;
NORMALIZE( dir );
Ray r( o, dir );

I had a look at the source code..


#define DOT(A,B) (A.x*B.x+A.y*B.y+A.z*B.z)
#define NORMALIZE(A) {float l=1/sqrtf(A.x*A.x+A.y*A.y+A.z*A.z);A.x*=l;A.y*=l;A.z*=l;}


so what exactly is dot and normalize for?

[rende]

Small update.. trying to recode some parts so i can implement recursive raytracing/lighting.

http://fluentart.com/gallery/albums/scraps/fr012render.jpg

[H3ro]

Wow, nice update. Would not call that a small one, looks like you have done a lot of work sins your last post.

I am working on the object loading part of my raytracer. No matter what I do my object loader does not work

[rende]

Try copying mine.. just load obj.h and obj.cpp and check in my main.cc how to use it. you have to add a v 0 0 0 at the top of you .obj file though, still havent fixed that.

[yarniso]

That's probably because the indices start at 1 and not 0 for an .obj file (if my memory serves me well). So just subtracting 1 from all the indices you read should solve the "adding a vertex" issue.

[rende]

Ye, i tried that. Its almost as if the parser skips the first entry. Subtracting one from the index causes the program to crash.

Havent had much time to work on this project since my last update.. :(

[Robert Bateman]

so what exactly is dot and normalize for?

performs the dot product on 2 vectors, normally used to find the angle between them. Normalise is used to turn a vector into unit length vector. btw, I wouldn't recommend using macros, but if you do, make sure that you always check for a division by zero in the normalize routines. It frequently happens if you have degenerate triangles, then the floating point error stack costs you tonnes of CPU cycles.


#define DOT(A,B) (A.x*B.x+A.y*B.y+A.z*B.z)
#define NORMALIZE(A) {float l=DOT(A,A); l = l>0 ? 1.0f/sqrt(l) : 0;A.x*=l;A.y*=l;A.z*=l;}

[Carina]

performs the dot product on 2 vectors, normally used to find the angle between them.

Or, as in this case, performing the dot product of a vector and itself gives you the length of that vector, squared. Hence, the square root of the dot product of a vector with itself gives you the length of the vector.

Dividing each component of the vector by its length gives you the normalised vector (i.e. a vector in the same direction as the original, but with length 1).

You see dot used a lot in graphics for this purpose as we are often interested in the squared length of a line connecting two points. While most libraries provide functions to find the length of a vector, they normally first find it's squared length, and returns its square root. Thusly, using "getLength()" to get the length, then multiplying it by itself, would computationally mean "compute the squared length, take it's square root and multiply it by itself".. Pretty pointless and unnecessarily expensive:)

Errr.. Haven't a clue if that last bit makes any sense to anyone else, but I know what I mean :D

[UrbanFuturistic]

That was the complicated way of putting it, yes :p

The length of lines at an angle in 3D space are calculated using basic trigenometry, same as a triangle. just think of the line as the hypotenuse and dx, dy and dz as adjacent, opposite and.. other opposite. This means that as sqrt(a^2+o^2) = h, sqrt(x^2+y^2+z^2) = h.

I'd also advise dropping macros altogether if at all possible. Even if you're not going to be programming in proper C++, there are advantages to using a C++ compiler.

1) Any libraries you compile will interface without problems with C++ code.
2) String and iostream are just really useful for files and, um, strings.
3) Replace macros with inline functions, you do it like this:

inline int functionName(parameters) {function code}

The compiler takes care of the rest and it makes it much easier to debug as the compiler deals with the code as you see it and actually knows what's inline and what isn't. It's an absolute munter trying to deal with an error reported at the wrong line because half the code's only there after it's gone through the preprocessor.

4) Use consts or typedefs instead of #defines. eg.

typedef float GLfloat;
const double velocity;
GLfloat distance = 42.5

5) No-one programs in pure C anymore anyway, before the 1999 standard you couldn't even do for (int i = 0; i < j; i++); it had to be int i; for (i = 0; i < j; i++);

[rende]

thanks for the feedback peeps!

I'm trying to code in shadows now, and im not quite sure if im going about it the right way. As I don't have the xyz position of where the camera rays hit whatever it renders, only the length of that ray. Should I get it by using the ray direction from the camera, using Pythagoras? Then cast rays from that position to each light?

Also, id like to implement some sort of area shadows/lights and bounced light. The only way I can think of that could work is to trace a hemisphere of rays at each bounce, and do away with point lights altogether using objects instead.

Any snippets that could help would be awesome :)

[yarniso]

As you will know a ray is defined by r = o + t*d
You have the o (origin) and d (direction) as known values. Now you say you have the "length" of the ray. So I guess you mean you have the 't' value. If you put that into the ray equation above, you get the point where the ray hit geometry.
Then from that point you cast a ray in the direction of the light. If it hits anything before reaching the light then it's in shadow (for point-lights).

Hth.

[playmesumch00ns]

This is probably about the time when you want to start thinking carefully about your interface rather than just coding straight ahead, as choices you make now could restrict you severely further down the line.

At the very least you're going to want:

o Some kind of Hit object that returns information about the hit surface. If you know how far along the ray the intrersection was found, then you know the point of intersection by the point of origin plus the ray direction times the hit distance.

o a Material object that describes the brdf of the surface you've intersected.

o a Light object that defines an interface for sampling and evaluating lights. Subclasses of this will define area lights, point lights and whatever else you want.

Area light sampling itself is fairly simple in the naive case. For example for a rectangular area light, just distribute a bunch of points in a rectangle using e.g. stratified sampling, then transform them to world space based on the transform of the light. Sum the radiance from each of them to trhe shading point multiplied by the visibility function (i.e. trace a shadow ray from the point on the light to the shading point), then divide the result by the number of samples and robert's your mother's brother.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.