PDA

View Full Version : Raytracer?


dbates
12-09-2005, 10:41 PM
Hey all,

I'll be taking a C++ course next semester and I would like to know if I could tackle a raytracer by the end of the class. I know there's some math involved, and some heavy programming techniques, but I would really like to make at least a simple raytracer. I've looked at the tutorial on http://www.flipcode.com/articles/article_raytrace01.shtml and the code is beyond me. . . ;)

So. . . do you think I'll be able to make a raytracing program? Or should I forget the idea for now?

--dbates

ace4016
12-09-2005, 11:30 PM
An intro to C++ course? If so, then not really. I think you should wait and learn programming in-depth before trying to attempt a raytracer. Make sure you program a lot more then the course assignments too, otherwise you most likely won't be able to do much after the course ends.

-Vormav-
12-10-2005, 02:02 AM
There is this one little well-kept secret about most 3d-related programs like this: they're not as complex as they look or sound.
That being said, if you've never done any coding before, then I'd doubt it. But if you understand some of the basics already, it could be possible. You don't have to be a very experienced programmer to write a basic raytracer. Building a fast, well-optimized one, though? Well, that's an entirely different matter...

sallymander
12-10-2005, 08:51 AM
Raytracing can be one of the easier tasks in computer graphics, but it is not something you'd tackle after an intro programming class. In order to build the SIMPLEST ray tracer, here's what needs to be done. First of all it's pointless to have a ray tracer if you have nothing to ray trace. So at minimum you need to internally build a scene. So let's say a camera with a fixed position, a sphere, and one light, as well as an internal coordinate system. Then to actually render out an image, you need to figure out how to use imagebuffers. I highly doubt that's something they'll teach you in class. google it. Then comes the actual ray tracing. And that "some math involved"...raytracing is all about math--specifically linear algebra. You will need to generate and multiply a lot of matrices, shoot rays, do dot products, calculate normals, and normalize vectors. So if you're not comfortable with that, don't do it. Otherwise, all you have to do is figure out how to do the mathematical operations in C++ and use a simple algorithm and you're set. But seriously, if you're not comfortable with any of the above, you're better off not shooting yourself in the foot.

cJaynes
12-10-2005, 07:19 PM
Well I jut took a intro class to C and we touched on C++. To learn about the language the project for the whole semester was to keep adding functionality and methods to a ray tracer.
We started out by reading files.. then moved on to creating objects.. and so forth. I acctually just finished up specular lighting.
The code it self isn't hard, what is hard is being able to debug our code!!! First you have to have some idea on what is going on so you know what you should be getting. Then you have to start tracing through all your methods to see what is screwing up. It's been a fun classes programming wise, I think the math is way worse then the coding.
So it can be done, just takes alot of patience and time... so good luck!

ace4016
12-10-2005, 08:14 PM
hehe, is there really a point in making a raytracer that isn't efficient or does something in a different way? Could just be me:shrug: . That's one reason I advise a stong knowledge of the language you use, as well as the math that goes with it. At a basic level, you will basically be making clone raytracers. Not exactly the best beginner project either imo.

rendermaniac
12-10-2005, 09:22 PM
If you are going to learn a language you may as well make it interesting. As long as you don't expect it to produce amazing images - spheres, maybe polygons then I'd say go for it.

I'd recommend having a look at OpenEXR http://www.openexr.com/ to output as EXR. It also comes with some good Maths libraries. Or you could use libTiff http://www.libtiff.org/ to output as Tiff.

Also see if you can get a copy of Introduction to Raytracing by Andrew Glassner http://www.glassner.com/andrew/writing/books/irt.htm which is a really, really good introduction to raytracing. Better to find it in a library as it's a little pricey.

Simon

Nyx2095
12-10-2005, 10:49 PM
I would say it depends on your confidence level when it comes to programming. If you've never programmed before, then forget it. If you have some prior experience, then you possibly could. I personally made my first raytracer in about 2 weeks, with diffuse surfaces and reflections. I then implemented refractive surfaces later on.

A basic raytracer is not very difficult to do. If you program it in C++, no matter how inefficient you make it, it will still render pretty fast on simple scenes (this would not be the case with a scripting language like python or PHP, however). You don't even need *any* libraries outside of what your compiler provides. You can read and parse your own scene description files (but you don't even need a scene description file in a basic raytracer, because you can just hardcode a simple scene). And you can write your own 24 bit uncompressed TGA image files fairly simply (the spec is rather intuitive, you just have to know that it stores colors in BGR, and not RGB, like the spec seems to suggest). As for the math involved, if you have done linear algebra, you should understand it. You don't even need matrices in your basic raytracer. Just ray-object intersections. The simplest objects usually being planes and spheres... You can build a box out of 4 infinite planes, place a sphere and a point light in it... And do your first simple render...

But yes, if you don't feel confident with C++ and how to use it, then I wouldn't advise you to do this as a school project. Just do it in your spare time. Start by writing a class to manipulate 2D images and save them in your favorite format (I advise using TGA). Then you can code some classes for primitives (usually, people have them inherit from a base "raytracable" primitive class), and make a class to represent rays. Then you can implement some logic to trace sampling rays from the location of your camera into the scene, and follow the theory from there... Do what should happen when a ray hits an object.

mummey
12-11-2005, 12:31 AM
Try this book: Realistic Ray Tracing (http://www.akpeters.com/product.asp?ProdCode=1985)

dbates
12-12-2005, 04:45 PM
Wow. . . thanks for all the responses!

I have some programming experience (the C part of C++); I haven't had linear algebra yet (just Calculus I) but I think I can pick it up fairly quickly. The reason I'm thinking about a ray tracer is because one of my high school friends built one in about a week--just a basic one, with reflections and specularity. I'll do some googling over Christmas break and look up those resources you guys recommended (thanks!).

--dbates

EDIT: Incidentally, have you guys ever heard of a format called "ppm"? I used that to make some basic images (fog, checkerboard, gradients) with C++. . . it's really easy to program for, but I'm not sure how useful it is compared with, say, TGA or JPG.

GStoll
12-12-2005, 05:16 PM
I'll second this. If you're just starting out, get the Glassner book. It's a little dated in terms of techniques, but that's fine. Really excellent introduction to RT and it includes both real math and real code (the really critical bit for any book on graphics, IMHO).

The up-to-date book to get is Physically Based Rendering by Pharr & Humphreys, which is also a ray tracing book with plenty of both real math and real code in it. That probably wouldn't be digestible for you at this point, but would be perfect once you've gotten a little farther along.

Come to think of it, those might be the only two graphics books I actually like...

-G


Also see if you can get a copy of Introduction to Raytracing by Andrew Glassner http://www.glassner.com/andrew/writing/books/irt.htm which is a really, really good introduction to raytracing. Better to find it in a library as it's a little pricey.

Simon

stew
12-12-2005, 06:48 PM
For the beginning, PPM will do it just fine.
BTW, if you're serious about it and intend to not just write any raytracer but a good raytracer at some point in the future, Physically based rendering (http://www.pbrt.org/) is the most comprehensive book I've seen on that topic. You probably won't understand much at first (without solid C++ and math), but it's a good long-term investment.

dbates
12-12-2005, 09:15 PM
Also see if you can get a copy of Introduction to Raytracing by Andrew Glassner http://www.glassner.com/andrew/writing/books/irt.htm which is a really, really good introduction to raytracing. Better to find it in a library as it's a little pricey.

It's in the UT-Austin library, but both copies are checked out until mid-January. . . Amazon has a used copy for about $60, which is forty dollars less than new (but still pricey). I'm going to try to get the library copy.

mummey
12-13-2005, 02:08 AM
EDIT: Incidentally, have you guys ever heard of a format called "ppm"? I used that to make some basic images (fog, checkerboard, gradients) with C++. . . it's really easy to program for, but I'm not sure how useful it is compared with, say, TGA or JPG.

PPM's are basic raw data. Quite often its still in ASCII. Its a good starter but I would move on to TGA or some other format when reasonable.

cJaynes
12-13-2005, 08:20 PM
Yea ppm's are a great start.
Our class started with just reading/writing ppm files. Then we converted to grey scale/ and started on what we would later use as texture mapping by resizing the images. Its fairly easy to manipulate the ppm's. To get a g value from a *pixp
(pixp +row*numcols+cols)->g
based on the way we created stucts. Probably a little inefficient but it got the job done.

The vector math really wasn't that bad, just build a good veclib library!

Carina
12-14-2005, 02:07 PM
I reckon writing a basic raytracer shouldn't be TOO hard.. the problem would be trying to make it 1. efficient, and 2. easy to add on to.

The book mummey suggested is great in that it shows you actual code. I never found the concepts behind raytracing hard to understand but what messed with my head to start with was translating it into code, and the Realistic Ray Tracing book is great for that. I found many raytracer programming tutorials online that were considerably lacking in that they skipped logical steps necessary for understanding, mixed up terminology, provided horrific code, and they were generally not particularly conductive to learning how to program, even though you may eventually end up with a raytracer that "does the job". I'm sure there are perfectly good tutorials out there, just giving a simple warning not to rely too heavily on some of the stuff available online.

I reckon the best way to go would be to keep it simple. Don't get too caught up in trying to make it supremely efficient. Basic functionality is probably the way to go, and then if you get to a point where you can see obvious places where you can improve efficiency go for it. There are many bits and pieces that go into a raytracer and trying to make sure they're all slotting together as efficiently as possible is time consuming.

I would point out that writing a raytracer is part of a third year course being taught at our university, and some third year computer science students find it a bit of a struggle (and they have been programming for at least three years). So while it's certainly possible, if the programming course you're taking is an introductory course, and you haven't done much programming before, you might find it a struggle.

cJaynes
12-14-2005, 03:36 PM
I would point out that writing a raytracer is part of a third year course being taught at our university,

They are changing out program so now Freshman will be doing a raytrace in their second programming class! When I was a freshmen we started in java, now they want to start in C. All I can say is those poor freshmen...

But just showing off, I justed finished my raytracer this past weekend and I still have alot I am going to add, but i meet the requierments for the assignment for my class..
It supporst ambient,diffuse, and specular light. Procedural shading. Plane, finiteplabes, triangles,spheres, cubes, and hopefully this weekend spotlights/texture mapping ( Iam so close!!)

here is my main function (fairly simple)

#include "ray.h"

int main(
int argc,
char **argv)
{
model_t *model = (model_t *)malloc(sizeof(model_t));
int rc;

model->proj = projection_init(argc, argv, stdin);
projection_dump(stderr, model->proj);

model->lights = list_init();
model->scene = list_init();

rc = model_init(stdin, model);

model_dump(stderr, model);

if(rc == 0)
make_image(model);

return(0);


}

fairly simple. Even though it is all in c we have alot of pseduo polymorhism and what not and here is and image set at AA samples to 10 and specular lighting, took less then a minute to render...

http://www.clemson.edu/%7Ejaynes/Images/test1.jpg

Nyx2095
12-14-2005, 06:39 PM
I would point out that writing a raytracer is part of a third year course being taught at our university, and some third year computer science students find it a bit of a struggle (and they have been programming for at least three years). So while it's certainly possible, if the programming course you're taking is an introductory course, and you haven't done much programming before, you might find it a struggle.

Not to rant or anything, but I wrote my first raytracer in high school. The reason some students find it hard is because they simply haven't got any real hands-on programming experience. I am currently in CS, and it seems most students are afraid of code. The university, wanting to make it easier for the average student, simply reduces the amount of coding practice to focus more on generalized mathematical theory. Furthermore, the use of programming languages like java, in my opinion, makes it harder for students to understand the functioning of programs in the long term, because the language itself allows them to stay relatively far from the technical details (which are sometimes quite important to understand what's going on).

Carina
12-15-2005, 09:01 AM
Not to rant or anything, but I wrote my first raytracer in high school. The reason some students find it hard is because they simply haven't got any real hands-on programming experience. I am currently in CS, and it seems most students are afraid of code. The university, wanting to make it easier for the average student, simply reduces the amount of coding practice to focus more on generalized mathematical theory. Furthermore, the use of programming languages like java, in my opinion, makes it harder for students to understand the functioning of programs in the long term, because the language itself allows them to stay relatively far from the technical details (which are sometimes quite important to understand what's going on).

I couldn't agree more. I'm not saying it's your age, or that CS students are generally great programmers, what I was getting at was that if he is doing an introductory programming course, and is not a confident programmer, he might find it difficult.

I completely agree with you about teaching Java as a first programming language, when I did my degree I was taught C++, now I am tutoring a first year introductory course at my current university teaching not only Java as the first language, but also using a teaching tool called BlueJ which allows them to get halfway through the first year without even having to touch a main method.. :rolleyes:

cJaynes
12-15-2005, 03:03 PM
BlueJ is the Devil, I thought we were the only university dumb enough to use that software. I hated it soooo much. We only had to use it for Our first class, but still it was terrible. Im really glad they are getting away from Java here, and going back to good old C and C++.

arvid
12-15-2005, 07:26 PM
cJaynes, nice work, how long have you been at it? :)

Nyx2095
12-15-2005, 08:53 PM
As far as I'm concerned, CS students here are generally not great programmers, because the mentality of my university is that CS is all about math and that actual computers and programming are just some irrelevant technical details. They are overly focused on theory, which, in my opinion, is a mistake. Theory has some importance, but let's face it, computer science is irrelevant without computers. What I do, and have always been doing, is learn on the side. I have become a proficient C++ programmers because I have been using the language since I was 15.

I now consider myself, in my second year of CS, to be capable of creating a full fledged renderer, which is what I will be doing next semester... I will be implementing monte carlo path tracing with irradiance caching, shaders, and possibly photon mapping if I have the time.

A shot from my first GI renderer, based on brute force monte carlo path tracing (doing distributed computations over the internet).
http://xgameproject.com/800x600.png

cJaynes
12-16-2005, 03:25 AM
They are overly focused on theory, which, in my opinion, is a mistake

I am going to second that. The outline of the major topices of my cpsc class next semester:

1)Regular Expressions and Finite Automata
2)Grammars and Pushdown Automata.
3)Turing Machines and Undecidability
4)Overview of Complexity Classes.

I am sure it is going to be benneficial and all but I would much rather have just a pure programming class. Learn by doing it. What really bothers me though is that we have test about programming that involve multiple choice answers. I dunno it really bothers me then they have us write code samples out on paper! They make us buy laptops for the program then they don't let us use them on test. Most of the professor are unsympathetic because they use to program with punch cards... Oh well.

Nyx2095: i like your image, is that the one you did in HS? I'm about to redo mine in pure c++ and see if I can get it as fast as my C version. I heard the C one can get bogged down from creating a new object for the array, so every time it bounces.... so we'll see.

arvid: been programming since HS, but first attempt with C in this class been interesting I really like it. It is alot more powerful the java ... shudders...

Nyx2095
12-16-2005, 03:55 AM
Nyx2095: i like your image, is that the one you did in HS? I'm about to redo mine in pure c++ and see if I can get it as fast as my C version. I heard the C one can get bogged down from creating a new object for the array, so every time it bounces.... so we'll see.

This is a subsequent GI renderer I made the summer after I finished high school.

And about C++... Trust me, if you code well, its just as fast as C. The fact is... The C++ constructs that are useful in a renderer (like polymorphism) are things you would be emulating in C (by using function pointers stored in structs to emulate virtual function calls). It's also very convenient to have access to basic templated data structures when you need them. The visual C++ 2003 also does extremely well at optimizing.

Carina
12-16-2005, 09:50 AM
As far as I'm concerned, CS students here are generally not great programmers, because the mentality of my university is that CS is all about math and that actual computers and programming are just some irrelevant technical details. They are overly focused on theory, which, in my opinion, is a mistake. Theory has some importance, but let's face it, computer science is irrelevant without computers. What I do, and have always been doing, is learn on the side. I have become a proficient C++ programmers because I have been using the language since I was 15.


I wouldn't say computers and programming are irrelevant technical details. But if what you want to do is become a good programmer, you don't need to get a CS degree.. Computer SCIENCE is in my opinion SUPPOSED to be more theoretical than practical, and while I found some of it incredibly boring while doing it, I've found it great help since I started my research, as I have needed numerous of the scientific elements involved.

I think the problem is people that like computers and programming subsequently going for a Computer Science degree to wind up in a programmers position, when they would probably have been better off putting in work experience.

stew
12-16-2005, 10:05 AM
Exactly. Computer science is not a programming course - that's also what they told us the very first week when I started studying. That I did end up becoming a programmer afterwards, well - to be honest, I feel like my theoretical skills are still too weak. There are still a lot of times where it takes me by far too long to understand the math in one or the other SIGGRAPH paper.

Carina
12-16-2005, 10:28 AM
Exactly. Computer science is not a programming course - that's also what they told us the very first week when I started studying. That I did end up becoming a programmer afterwards, well - to be honest, I feel like my theoretical skills are still too weak. There are still a lot of times where it takes me by far too long to understand the math in one or the other SIGGRAPH paper.

I reckon many of the papers are written in a fashion where you're MEANT to do a double take and read it x amount of times to understand it. Proof by intimidation.. use enough fancy terms, equations and jargon to scare people out of questioning it;)

stew
12-16-2005, 10:35 AM
True, "scientific publication language" should be taught as an additional course. I was very confused by the subsurface scattering equations in Jensen's book, where when I saw it as RSL code in the RenderMan course notes, I had this "what, that's it?" feeling.

Carina
12-16-2005, 10:55 AM
I had this "what, that's it?" feeling.

Haha.. yeah.. When I first started looking into GI, I was reading papers talking about solid angles. Grabbed a random radiosity book (written by a mathematician I should add) and it devoted a full page of the book explaining what a solid angle was in mathematical terms. Needless to say I still didn't understand what on earth he was talking about. argh.

Since solid angles are infact an exceedingly simple concept, it's no wonder I had problems understanding what on earth was going on in the actual rendering equation.

rendermaniac
12-16-2005, 03:52 PM
That's what I thought about fluids until I saw Jos Stams 2003 Game Developer Conference notes where he steps through the process and finishes off with a complete example in about 200 lines!

Personally I have found that papers aimed at Game developers are a lot more accessible and practical than Siggraph notes. And they are usually based off of a Siggraph course anyway.

Simon

Nyx2095
12-16-2005, 04:07 PM
I wouldn't say computers and programming are irrelevant technical details. But if what you want to do is become a good programmer, you don't need to get a CS degree.. Computer SCIENCE is in my opinion SUPPOSED to be more theoretical than practical, and while I found some of it incredibly boring while doing it, I've found it great help since I started my research, as I have needed numerous of the scientific elements involved.

Well, that's another problem. People think programmers are just some cheap convenience... But in my opinion, programming is an art, and proper programming requires a good theoretical and practical background (more than software engineering provides). I think the state of our software in general would be alot better if all programmers were as competent as they should be... The number of bugs and exploits that are found is simply unreasonable. Yet, I have programmed two 3D engines, and both, even in their beta stage, had less bugs than alot of commercially released games.

I reckon many of the papers are written in a fashion where you're MEANT to do a double take and read it x amount of times to understand it. Proof by intimidation.. use enough fancy terms, equations and jargon to scare people out of questioning it.

I totally agree... I read a number of papers recently because I want to do some research for my new renderer. Unfortunately, the terminology used and the way it is explained felt so incomplete and abstract that some of these papers raised more questions than they answered. My feeling is that its not just that the papers are complex... It's also that mathematical terminology is often not expressive enough. I know mathematicians like to think that maths are everything, but I always perceived maths as being overly static and lacking in dynamism.

At some point, when you're discussing an algorithm, if you want to be clear, you need to describe it step by step (ie: pseudocode). Yet many papers focus on vaguely explaining the mathematical theory behind the idea, leaving the implementation out (which is the whole point of the paper, very often... to get a faster implementation) as some "irrelevant technical detail". And even if you do understand all the math, you still don't know many of the steps they went through in making it work, which is rather deceptive.

stew
12-16-2005, 04:16 PM
I think the natural enemy of stable software are not incompetent programmers but project deadlines ;)

Nyx2095
12-16-2005, 04:20 PM
I think the natural enemy of stable software are not incompetent programmers but project deadlines ;)

That too... But you know, I have seen a company pay 5 million dollars to another and then spend 4 years trying to fix a piece of software I feel I could have created and debugged in 8 months with a team of 3 people, and charged at most $500000 for. I also used the software myself... And well, it has this funny bug... Where it would only successfully install 75% of the time... But you didn't know that until later on. I think the main problem could be summed up by two words: visual basic.

Carina
12-16-2005, 04:28 PM
Well, that's another problem. People think programmers are just some cheap convenience... But in my opinion, programming is an art, and proper programming requires a good theoretical and practical background (more than software engineering provides). I think the state of our software in general would be alot better if all programmers were as competent as they should be... The number of bugs and exploits that are found is simply unreasonable. Yet, I have programmed two 3D engines, and both, even in their beta stage, had less bugs than alot of commercially released games.

I agree to some extent.. I wouldn't say programmers don't benefit from theoretical background.. but I think attempting to produce both excellent programmers and fantastic scientists in the one degree would take more than the three or four years available, as well as a complete committment on the part of the student (which I personally can't see happening with the vast majority of undergrads).

Of course some people manage it, but I'm generalising.

stew
12-16-2005, 10:09 PM
Let's try getting the curve back on topic ;) - I hate sounding like broken record, but Pharr/Humphrey's "Physically Based Rendering" is a book that gives even us theory-challenged people access to higher-level GI stuff while still providing hardcore C++ source (for those who haven't seen the book, I'm talking about fast Real2Int IEEE trickery and stealing the last two bits of the kd tree split position for the axis to get a node to 8 Byte size). I may sound like some dumb idiot pimping that book, but for someone who is serious about writing a good raytracer, that book is a better investment that a 512MB stick of RAM or one week of Sushi for lunch.

dbates
12-16-2005, 11:14 PM
Interesting info everyone (I didn't really expect that discussion on CS and programming, but it was good reading anyway). I can't start programming this raytracer until I'm at least part-way into the C++ course, but I'm definitely going to look for a few books at the UT library and see if I can get a theoretical understanding of ray-tracing (the math and all that). I've had basic vectors and matrices, and I've done some dot products too. . . mainly in Pre-Calculus; am I going to need to pick up a Linear Algebra book?

Thanks for all the advice--I really appreciate it!

--dbates

mummey
12-17-2005, 03:48 PM
Let's try getting the curve back on topic ;) - I hate sounding like broken record, but Pharr/Humphrey's "Physically Based Rendering" is a book that gives even us theory-challenged people access to higher-level GI stuff while still providing hardcore C++ source (for those who haven't seen the book, I'm talking about fast Real2Int IEEE trickery and stealing the last two bits of the kd tree split position for the axis to get a node to 8 Byte size). I may sound like some dumb idiot pimping that book, but for someone who is serious about writing a good raytracer, that book is a better investment that a 512MB stick of RAM or one week of Sushi for lunch.

It IS a good book, but any who goes for this one better have at least a couple of years of C++ under their belt. Otherwise, the style this book uses will have the reader constantly looking things up in a C++ manual.

While we're on a related subject:

Best Intro C++ book: anything by Walter Savitch
Best Intermediate/Advanced C++ book: The C++ Programming Language - Bjarne Stroustrop

CGTalk Moderation
12-17-2005, 03:48 PM
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.