Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
Thanks...but for anyone contemplating writing a ray tracer, here's my 2 cents.
I've found that trying to decipher somebody else's code, especially a fully formed app like POV-Ray, can drive you up a wall and take forever to figure out. And in the end you still may not understand exactly what's going on.
My approach is to read some good explanations of the basic concepts, then write "pseudo-code" to help you design an overall plan, and then convert that to actual code. And that way you get down to the details and it helps to really understand what's going on.
And as we all know (all of us who have done software development) software guys hate to write decent documentation of their code, so you'll spend forever sifting thru code and cross-referencing where stuff is called from and on and on just to figure out what's going on.
90% of the time when I use somebody else's code or scripts I end up spending hours writing explanatory comments inside the code, renaming variables so they make sense, and figuring out what the heck they're doing.
Oh yeah, no doubt. Just thought maybe you're interested to dig around a bit, see how others have done it.
Havent heard that name in a while. For a while it was way ahead of the curve.
I played around with Povray a bit once a long time ago. It is good for the classic spheres over checkerboards renders with other geometric shapes but you needed sharware software to make more complex shapes. A few of us ran it on a Unix server at work for a while and the system administrator never spotted it.
I was intersted in ebergely's description of the process. The first part sounds like what used to be called ray casting, a lot of the old 3D games like Castle Wolfenstein and Doom used it. Those games only went as far as working out what the ray hit and what colour it was. Once you start looking at reflections, surface properties, illumination and shadows it gets a lot more complicated and you need more than one ray per pixel. I was thinking about creating a ray casting engine but never got around to it, maybe I will if I can find the time,
Cool. With all the experts here hopefully we can get some good input on how all of this works. My next step is figuring out the correct way to convert a simple Lambertian albedo RGB value to make it an emitter. I cranked the RGB values up way past 1.0 (into the 20's and 30's range) and it seemed to work, but I'm not sure if that's the correct approach. Anyone?
I always have a big amount of respect for peope who dare to take these tasks on! My hat off to you!
Albedo is the ratio of diffuse reflected radiation to the total incident radiation. Not sure a value over 1 makes sense, and I would think you’re working with 32 bit floats that represent values between 0 and 1 anyway.
This ratio gets multiplied by the incident radiation, so in your test that seemed to work, what happens when the incident radition is zero? It should still emit, no?
- Greg
ETA I would think you would need a second additive term to go along with the multiplied ratio.
I dunno, it seems to work. I think one issue is I just hijacked the Lambertian material without changing the fact that an emissive should only emit, not reflect the surroundings.
In case there's anyone interested in doing your own ray tracer (and doesn't mind cheating a bit...
) you can download the free Optix ray tracing engine, which includes a bunch of API's that do much of the grunt work (detecting ray hits on scene objects, etc.) and write your own higher level ray tracer. Optix isn't a full ray tracer, but rather a lower level set of code you can put together to make a ray tracer.
The problem is (IMO) that it's written in C and C++, and I hate C. But if you like C, it's pretty cool, with tons of samples you can load into Visual Studio. Not sure about the Optix Prime part, which is kind of a subset of Optix that does specific stuff like hit detection really really fast, but is very limited (no shader calcs, etc.).
Isn't Optix included with Iray? Is it a helper for Iray?
Pretty cool stuff, I dont have to capacity for this kind of work, but its admirable what you can do with the 3rd dimension!
Optix is a set of NVIDIA software tools that help do some of the lower level stuff related to building a complete rendering software like Iray. I assume that Studio's Iray uses it a lot. I believe it also works with CUDA to do basic ray tracing tasks and sending those to the GPU's.
The Optix Prime feature in DAZ's Iray (the checkbox in the render settings) allows you to use a subset of the Optix tools that are designed to so some of those simple ray tracing tasks much faster. I could be off, but it's something like that. All of this stuff works together and it's tough to keep track of who does what.
Whats your goal of writing a raytracer, is it like an exercise for you? As I assume writing something production ready would take quite some time.
somevariable_untitled_0002
^ This stuff haha
or
function ThatNobodyKnowsWhatItDoes() {}