programing a raytracer
yah, but i hate working with pixels and images in graphics code, and due to speed and memory issues i had to change the 3 dimensional x y color matrix to a 2d matrix- thus i cant edit pixels verticaly, just horizontaly.
i fixed the problem with phong in my program- it wasn't phong that had the problem apparently, it was my color code which i somehow forgot to set the r g and b as public variables, thus for every light it "forgot" the color applied from the previous light.
the green on the sphere turned out to be the specular color that i had set in that sphere's declaration- the fact that it turned green in the dark had to do with loosing the rgb data.
i fixed the problem with phong in my program- it wasn't phong that had the problem apparently, it was my color code which i somehow forgot to set the r g and b as public variables, thus for every light it "forgot" the color applied from the previous light.
the green on the sphere turned out to be the specular color that i had set in that sphere's declaration- the fact that it turned green in the dark had to do with loosing the rgb data.
a shiny monkey is a happy monkey
Well how many college bound kids do you know who program raytracers or even know what a raytracer, or even a renderer is?Your not thinking like a college bound kid ;p
i finaly figured out how to compile the program into a jar- (they dont teach us that in java class- mostly because our teacher doesnt know how)
download the program from http://www.bluecubegraphics.com under the files section. to run it unzip it and remove the file miniTracer.jar from the archive (dont bother with the source archive its password protected and put there for my personal multicomputer access). the scene is a simple 2 ball one with a phong diffuse and specular. the only things that work on the gui are the text feilds and the render button.
a shiny monkey is a happy monkey
Well how many college bound kids do you know who program raytracers or even know what a raytracer, or even a renderer is?
I think I was 15 when I wrote my first ray-tracer ... 8 hours to render a reflective sphere over a checkered ground plane (compared to less than a second to do the same thing now at higher resolution). Technology's amazing huh?
Re: Working with individual pixels ... making a 1D array was definitely the right decision (especially as Java's arrays are quite memory hungry) but you can easily make a couple of methods to address pixels at the x,y level with some simple maths. Once you start to make more complex scenes, you'll definitely want some way to do adaptive AA.
Ian.
I think I was 15 when I wrote my first ray-tracer ... 8 hours to render a reflective sphere over a checkered ground plane (compared to less than a second to do the same thing now at higher resolution). Technology's amazing huh?

Re: Working with individual pixels ... making a 1D array was definitely the right decision (especially as Java's arrays are quite memory hungry) but you can easily make a couple of methods to address pixels at the x,y level with some simple maths. Once you start to make more complex scenes, you'll definitely want some way to do adaptive AA.
Ian.
15's a little early- maybe they just teach programing late at my school. however i dont think the 3d/programing community is a good representation of the level of students/programers throughout the country- there tends to be a much larger number of "gifted" (i hate that word) people in these communities.I think I was 15 when I wrote my first ray-tracer ... 8 hours to render a reflective sphere over a checkered ground plane (compared to less than a second to do the same thing now at higher resolution). Technology's amazing huh? Wink
as for adaptive AA with 1d array- i've been thinking about it, shouldnt be as hard as i originaly thaught.
a shiny monkey is a happy monkey
yay! i got shadows working and fixed phong-
the trace code is currently a little messy, but still incredibly workable (yay java object oriented stuff) i haven't programed in triangle intersections but thats next. does anybody have any links for methods of normal smoothing?
the reason its purple is because of the ambient which i shall make accessable through the little color panel eventualy.
the trace code is currently a little messy, but still incredibly workable (yay java object oriented stuff) i haven't programed in triangle intersections but thats next. does anybody have any links for methods of normal smoothing?

the reason its purple is because of the ambient which i shall make accessable through the little color panel eventualy.
a shiny monkey is a happy monkey
i know its not java, but genrealy its all good:
http://blogs.msdn.com/coding4fun/archiv ... 74685.aspx
Made in c#
http://blogs.msdn.com/coding4fun/archiv ... 74685.aspx
Made in c#
Yes i know, my spelling sucks
I don't have code, but you can look at theory:
simpler, but worse looking:
Gouraud shading
a bit more complicated, but MUCH better (common way of doing it)
Phong Shading
simpler, but worse looking:
Gouraud shading
a bit more complicated, but MUCH better (common way of doing it)
Phong Shading
so with finding which triangles the vertex is in- is that something usualy put in the scene file or is that usualy somehow programed into the raytracer sceneloader?
for example when i set up how the scene file is set up would it be logical to have the vertexes first numbered and declared then triangles numbered and declared using the previously declared numbered vertexes. the triangle numbers that the vertexes are in would be added in an array to the vertex and then the raytracer would calculate the normal of the vertex based on the triangles that its in?
for example when i set up how the scene file is set up would it be logical to have the vertexes first numbered and declared then triangles numbered and declared using the previously declared numbered vertexes. the triangle numbers that the vertexes are in would be added in an array to the vertex and then the raytracer would calculate the normal of the vertex based on the triangles that its in?
a shiny monkey is a happy monkey
You should probably design your scene file based on the most likely import routes. For example, the .OBJ format defines a triangle (or square, or n-gon) with indices into a global pool of vertices, normals and UVs. Other 3D modelling applications might give you a pool of vertices/normals/UVs on a per-object basis. Implementing both schemes wouldn't do any harm at alloodmb wrote:so with finding which triangles the vertex is in- is that something usualy put in the scene file or is that usualy somehow programed into the raytracer sceneloader?
for example when i set up how the scene file is set up would it be logical to have the vertexes first numbered and declared then triangles numbered and declared using the previously declared numbered vertexes. the triangle numbers that the vertexes are in would be added in an array to the vertex and then the raytracer would calculate the normal of the vertex based on the triangles that its in?

During rendering, it's unlikely you'll ever need to know which triangles a vertex belongs too ... you'll only need it if you want to calculate smoothed normals yourself and that should only ever happen once after the scene is loaded.
Ian.
just programed plane ray intersection. however-- ERRORS!!!!! yummy.
it seems to create a grain on the plane dependent highly on the angle of the plane. the shape of the grain is also dependent on the angle
here is the collision code:
images:



does anybody have any insights?
it seems to create a grain on the plane dependent highly on the angle of the plane. the shape of the grain is also dependent on the angle
here is the collision code:
images:



does anybody have any insights?
Last edited by oodmb on Sun Apr 29, 2007 7:39 am, edited 1 time in total.
a shiny monkey is a happy monkey
Who is online
Users browsing this forum: Ahrefs [Bot] and 20 guests