mostly unfinished @mostlyunfinished - Tumblr Blog

Posts

As of this past week, JTracer is complete as it pertains to the course requirements. I compiled my test renders into a single video here to show the evolution as the project grew from 400 lines of C++ code in the first incarnation to just over 3000 8 weeks later. I enjoyed going back through the images as I can recall nearly every issue the image highlights and the eventual fix employed.

Writing a ray tracer is something I’ve wanted to do for a very long time. However I never had right starting place or motivation for this kind of project. Ultimately I’m very happy for the experience of doing this as a class and I learned a lot about the structure of code and the process of digesting research papers and the associated mathematics into code.

Next term I’ve got class of computer vision, but I hope to begin a new jtracer as well... good times!

#raytracing #raytrace #rendering #render #c++#cs #programming #jtracer

JTracer - Textures, Noise & Stuff

This past week I added in support for file textures in the color channel of materials. I also built out a few procedural generators including an implementation of Perlin noise (original perlin, I just read through the 2002 update paper, so I’ll fix that soon), a simple checkerboard, stripes, and a wavy weird noise-ish thing.

Additionally I also fixed a couple things that were standing out, such as transparent objects casting full shadows and a few small improvements for speed during the adaptive subdivision refinement. I also altered my sphere class constructor so I can shove spheres into my scene list more effectively so I can do more populated layouts. It was a very simple change, and one I’ve been meaning to make for several weeks.

The above image shows the following materials: Chrome, Glass, Checkered Lambert, Striped Lambert, Red Glossy Plastic, Glossy Gold (kinda), Red Clay and file based materials for Earth, Mars, Jupiter and the Moon.

As always, getting here involved a lot of iteration:

Gotta get high rez bunny in here, sphere in the back has the odd wavy texture, it’s based on a stack of sines.

Bunny with noise - and my file texture reading rendering inverted:

Adaptive sampler keeps doing it’s job:

This is where I started my day:

Checker is straight forward, it’s a solid checker so checking the sign of the sin in 3-space:

Picking the wrong objects to ignore trace shadows:

Fixed it, added texture maps using the stb_image header - it’s great:

Perlin noise implemented, but not interpolated:

Now with tri-linear interpolation:

Moved to a bigger space to help see, and added smoothing:

Higher frequency:

Add multiple frequencies to create turbulence:

And then marble-ish:

Making a loop with a loop:

Random material selection:

teapot.

#raytracing #raytrace #render #rendering #programming #c++#cs #jtracer

JTracer - Refractions, Fresnel, Falloff & Gloss

I believe my refractions are now properly fixed. I’m checking for backface intersections with a dot product and then inverting the intersection normal and flipping the incoming/outgoing indices of refraction. Things are looking far better. I also implemented a far more accurate fresnel calculation for reflection. I’ll post an image below which illustrates that better. In the realm of “finally!” is doing an inverse square falloff for the lighting. I still only have point lights in use, though I have a plan for some very basic area lights now.

As if my rendering couldn’t get more painful, I got annoyed with perfect reflections and added a glossy reflection hack. While I believe it’s a fairly valid method, it’s not accurate to anything in particular. In the image above, I believe I set the glossy ray count to 16 and the ray depth to 5, so with a little back of the napkin figuring my intersection tests go way up. But it looks better... so.. yeah.

More images!

Oh, yeah, I also added a NaN test to rid myself of total internal reflection wackiness:

poof! gone.

Fresnel tests - based on IOR (index of refraction) so it can be implemented on both transmissive and opaque objects, here the object on the left is a chrome, front-center is glass:

You can see the reflection fall off here:

Or, better here. Center row, chrome. High IOR on the left to low IOR on the right:

Then I thought, “hey, what about glossy reflections, I think I could come up with a way.”

so a variable scatter added to the reflection ray later ( just one scattered ray ):

ooo! how about 16 scattered rays:

Stack up some chrome spheres and a glossy brass in the center:

looks good on floors:

There’s an oddity in the top spheres here, but emissive materials look nice with glossy reflections (hmmm...):

Gold bunny:

Chrome Bunny (70k polygons):

I also made a modification to the BVH code so that I’m getting yet another little speed boost out of it... little by little....

#rendering #render #raytracing #raytrace #c++#cs #programming #jtracer

JTracer - Refraction, first run..

It’s not right yet, but I’m not one to hide errors:

There’s a lot of oddities happening, but I’m getting there. Overall the implementation of this went pretty quickly. I still need to figure out what to do with my shadow rays on the transmissive objects and I’m suspicious about what is happening to internal rays intersecting with the backside of the primitives. I haven’t developed a good strategy to track down those errors quite yet. I’ve got a couple more features to go on my wishlist, but I believe I’m getting close to the end of what I want to do with this engine. It’s been a massive learning quest and overall I’m pretty pleased with what I’ve put together in 8 weeks given my general schedule and lack of time to give to various tasks.

It’s a pretty straightforward raytracer for sure, but the world has moved on a bit. I’d like to take what I’ve learned and write a brute force path tracing engine in the future with a much better overall structure from the outset. One of the big issues I continue to have is speed, and while I understand that I can’t compare to the big engines today, I do feel I should be able to hit and acceptable medium of time rendering and quality of image. I know that will lead me down the road of probabilities and statistics, but hey, a little adventure never hurt anyone.

first just detect that I’ll have a transmissive object:

returning the new view direction vector as color:

and, then just pass that back to the trace function.. boop!

mild success? Bring on the bunny! No reflections here, and while I add them later it’s not ideal. I need to start building a trace tree.

seems about right.. but is it?

Not all roses - screwed stuff up as I tried to refine my approach. I need to check but I’m guess the gray is NaN returns (not a number).

return of the teddy bear...

more errors.. The 70k polygon bunny destroys my render time. I should implement additional statistics for what’s happening inside my BVH structure, and actually I’d really like to do that once I’m wrapped up a bit. I’ll use this engine to develop strategies of trouble shooting my next engine at this by trying to generate a standard set of utility image exports from a rendered frame which can help me visualize the choices being made.

#rendering #render #raytracing #raytrace #programming #c++#cs #jtracer

JTracer - Reflections, for real this time.

While walking to the train yesterday it suddenly dawned on me that I was not, in fact, calculating correct reflections. In my brief excitement of getting everything actually working, I had slugged in a reflection ray off of the normal, not the reflected view vector. duh. So I went back in and repaired that, converted my specular calculation from the Phong model to the Hall model, introduced a very basic fresnel falloff to the reflections, and implemented a really rough environment light based on the background gradient I’m calculating.

I think there’s still some issue in how I’m going about my BVH intersection calculations because my render times with reflections and a dense mesh are pretty staggeringly stupid. That said, they’re not crippling.

If nothing else, this process has been super enjoyable and once I finish this term, I’m looking forward to starting anew. I have some thoughts about my refreshed approach, but I need to poke around some more to center up on a structure that will be more flexible.

Next up: refractions and hopefully some area lights.

Some good images this time as always..

I was not handling light color properly, so I fixed that first:

went from improper reflections to just terrible reflections:

finally to correct reflections:

lots of reflections and their kinda awesome looking adaptive sample rates:

Looking in the wrong direction for a skylight:

flip!

fresnel test:

implemented (yeah, I know, pretty terrible)

The skylight introduces a lot of noise, I haven’t looked into combatting that yet...

till next time....

#rendering #render #raytracing #raytrace #programming #cs #c++#jtracer

JTracer - Reflections Abound

One more for good measure, this was not speedy:

And the adaptive samples image. Black = 4 samples, Gray = 9 samples, White = 25 samples interpolated for a single pixel.

#rendering #render #raytracing #raytrace #programming #cs #c++#jtracer

JTracer - Refactor, Reflect, and the Shadow.

Queue the gratuitous, reflection image (these renders are probably doing damage to my claim that I’m an actual 3d artist...):

Implementing shadows and reflections SHOULD have been fairly straightforward this week. However, what I discovered was that my BVH code had some flaws that exposed themselves once I had rays originating deeper inside the scene structure. Essentially not only were my prim splits in error, but I wasn’t properly detecting ray intersects from inside bounding boxes. Additionally my triangle intersects had some issues as well. Oddly these things didn’t manifest themselves until a few other things came into play. Once I started pinning down where these errors were coming from, I decided that I should probably take the time and further refactor my code into a more organized design.

Part of me thinks that I should have had the code organized in a way where I could have isolated issues more quickly. Perhaps it would have been better to have reflection and shadows working much earlier on spheres, then on triangles before implementing a mesh input and then BVH. All in all, looking back there’s definitely a different order of steps I would have gone in.

What I am relying on for this program are equations and pseudocode algorithm overviews from my professor’s lectures and notes. I occasionally refer to the book “Raytracing From the Ground Up” by Ken Suffern which is a great text on the subject. Overall, however, I’m doing this mostly on my own. The flaws are mine, but then so are the solutions... Hopefully I’ll have time to do a fairly ground up version after this with the lessons learned and I’ll probably lean much more on prior work, but now I’ll know much more about why these engines are structured the way they are.

Anyway, next step, refractions!

This process of refactoring while adding shadows resulted in a whole bunch of bad images.. enjoy!

ha, bad!

At least the adaptive sampling keeps chugging along...

In this case, I had introduced a giant sphere as a ground surface which then showed up in the top of the frame because of errant ray intersections in the bounding box detection.

Here’s a frame where adaptive sampling had it’s work cut out:

argh!

starting to center up on one of my issues here:

A shadow... and a whole lot of bad.

this was funny...

this was less funny.

clearly a bounding box issue here..

oh good lord, getting worse.

SUCCESS!

Darn, never mind!

Success again!

Reflection success!

nothing fancy here, but a reflection limit of 3 bounces working out just fine.

#rendering #render #raytracing #raytrace #programming #cs #c++#jtracer

JTracer - Adaptive Sampling

With BVH tracing up and running it was time to turn to the next major speed culprit, super sampling. I implemented an adaptive sampling routine which anti-aliases the image with a greatly reduced render time. Oh, also implemented a background gradient sphere. Take this cheesy image:

Here’s the ray count result:

I this case I traced with a 0.05 threshold and 2 levels of adaptive subdivision. If neighboring samples have a difference which above the threshold value, that area gets sub-divided and resampled. This can happen up to 2 times which means that any 1 pixel may be a result of either 4 samples or 16 samples. This scene has nearly 100k primitives, which would have been extra painful a couple weeks ago.

I also re-built quite a bit of the code. I had built most of tracing engine in a fairly straightforward manner, but it became clear to me a couple weeks ago that the ray and camera calculations should be split from the main code and handled as their own classes. This is, I’m sure, fairly common knowledge to anyone who has built one of these, however I’m trying to stay fairly internal and these realizations come with a good bit of clarity this way.

These changes meant that adaptive sampling could be implemented in a few hours as opposed to struggling with it for a much longer time. About 2/3rds of the way through this implementation I realized that I should probably built a tree structure to hold the image data so I don’t re-caclulate certain areas - but i’ll leave that for a little later.

Now that this is all in place, I believe shadows, reflections and refractions should be much more straightforward to implement, and they’re up next.

Next round should be shadows & reflections, plus I hope to implement an environment light as well. Refractions after that, and hopefully area lights in addition...

And of course, image weirdness:

Forgot to move my ray direction in Y...

This proved I was in the right direction:

Getting my meshes in place:

oops:

Initial threshold test:

#rendering #render #raytracing #raytrace #programming #cs #c++#jtracer

JTracer - Need for Speed

This past week I implemented Bounding Volume Hierarchies in my ray tracer and got a 19.5x speedup in my rendering for this particular scene which contains 1002 primitives. The naive method will attempt an intersection on each primitive for each pixel, which is costly. The BVH method will create bounding boxes around all primitives, then continuously subdivide those boxes until they contain a small number of primitives. You end up doing far fewer ray intersection tests along the way (clearly).

I believe I’ve got some tuning to do on top of what I’ve got going so far, but getting here had it’s share of issues. Next step will be to add adaptive subsampling which should be yet another decent increase in speed. At some point I’d like to multithread the process as well as I’m just utilizing a single core at the moment.

The speed increase allows me to up the complexity of my scene:

or even add the high-res bunny in as a default trace object. This scene has about 73k polygons and it traces in about a minute and a half:

Getting the adaptive sampling in there will be critical to moving on to add the rest of the things raytracing is known for and hopefully moving on to more complex shading models as well.

Implementing BVH did not come without issues for me. Because of how I’m passing my data structures around, I ended up with some mis-matched information coming back from the intersection tests. This created some wonderfully messed up images - enjoy!

till next time...

#rendering #render #raytracing #raytrace #programming #cs #c++#jtracer

JTracer - Boxes Abound

Beginning a round of under-the-hood enhancements looking for some speed improvements. Right now the tracer checks intersections of every single primitive in the scene for every ray of every pixel. The plan is to implement a Bounding Volume Hierarchy scheme to cut that way down.

My first step was to implement a bounding box tracing primitive and define bounds for all objects in the scene:

Colored here for vis purposes only - now the tracer only checks for 3 objects with each ray. Next step was to then only trace the object enclosed in the box if the ray enters:

That little adjustment now means that until a ray hits a box, nothing happens. If it does hit a box it basically asks “what’s in here?” and then proceeds to check all of those sub-objects (in this case, the bunny is 1k polygons). It’s an immediate 6x speed improvement, but as you can see there are artifacts. Even so, the speed increase did finally allow me to trace the 69k bunny model (back to orig materials):

That’s all well and good, but I’m still treating the bunny as a single object instead of a set of primitive triangle objects. So a code overhaul later and mesh objects now generate a set of triangle primitives and are treated as individuals. The rendering of this looks pretty odd because it does the same box culling as above, but on a triangle level:

Looks terrible, but this is actually good news. A good bit of the plumbing is now in place to implement BVH. Here’s what that does.. I’ll get the bounds of all the objects in the scene, split that box somewhere and count how many primitive objects on on each side of the split, if it’s above a threshold, split that sub boxes again, and so on. From the high level view, the ray will intersect with that top level bounds first - so initial testing is on only 1 object when shooting rays into empty space. As it intersects the bounds, that ray will dig down the hierarchy until it either strikes or passes though empty space. Ultimately bringing the number of intersections tests way way down.

I’m certain I’ll screw it up along the way, and hopefully that’ll generate some great, horrible images. But once that’s in place the engine should run WAY faster which sets me up for better features like adaptive sampling, shadows, reflections, etc.. I can spend much more time on the shading functions that I do now and get better results. Huzzah!

#programming #raytracing #raytrace #rendering #render #c++#cs #jtracer

JTracer - Let There Be Lights

Basic Phong shading implemented along with point lights.

Once the normals were right, it wasn’t a great leap to Phong materials and lights. First I implemented a very straight forward diffuse with a single light on the mesh object definition:

And of course I didn’t clamp value for my the image writer I wrote so it’s all sorts of weird.. The ramp banding is a dead giveaway for such things so it was a straightforward fix:

Then I rolled in the specular calculation to the function before pushing it out to all objects.

Goodly satisfying, that is. At this point I’ve got a simple materials structure set up, point lights, spheres, meshes, camera positions, super sampling, etc...

It’s all well and fine, but it’s not quick. So next steps are adding some accelerations and support for much more intelligent adaptive sampling. The next rounds won’t be nearly as visually interesting.

Though what I may do once things are faster is add some more support for render arguments so I can push the camera around a bit and then batch out some animations.. so far so good.

#rendering #render #raytracing #programming #c++#cs #cs699 #jtracer

JTracer - Now Normal

I was indeed registering the incorrect ray hit on the mesh, so all normals are being calculated correctly now, laying the groundwork for proper shading in the very near future...

#programming #cs #cs699 #raytracing #rendering #render #jtracer

JTracer - not Normal

This week saw the addition of calculating normals at a ray hit, basic super sampling for anti-aliasing and a bit of a rebuilt of internal functions.

I’m currently outputting my surface normal values for bug checking. The spheres calculate correctly (red = +X, green = +Y, blue = +Z). However the bunny is all sorts of wrong. I believe this to be an issue with the intersect function not returning the proper ray intersection or possibly and error in the winding order of the polygons. While I fought that for a bit without solving it, it shouldn’t be too difficult to track down.

While I was ignoring that problem I implemented very simple super sampling. I render double size and then scale down with very basic pixel averaging. I do hope to implement a true sampler later.

Here you can see a comparison of output, super sampled image on top, previous result on the bottom, both with blowup inserts:

Internally I did a bit of a re-build of data handling inside the trace functions. As I was working this week, I realized some efficiencies in my method and went ahead and rolled those in. At the moment it doesn’t affect much, but it should make some features easier to roll in during the weeks to come.

I also finally implemented timestamps on my output filenames thus saving every render I make as I go along, which results in some good images to show all my odd results along the way - though some of these are definitely more compelling than my current “good” result - ha!:

Once those normals are fully repaired, I’ll implement Phong shading and point lights.. till next time…

#programming #cs #cs699 #rendering #raytracing #jtracer

JTracer - Now with color

Baby steps. The ray tracer now properly supports camera position, aiming angle - that was incomplete last time. Additionally I’ve added color to the object definitions and depth sorting on the trace intersections so I’m only shading the closest point and getting proper object overlaps now.

Like I said, nothing major. Next up, phong shading and point lights.

#raytracing #cs #cs699 #programming #rendering #render #jtracer

JTracing Program

I am taking an advanced rendering independent study course for my masters in CS. During the course of the term, I’ll be creating a raytracing program and documenting progress here. I’ve never written a rendering engine before, so I’m excited to see what I can accomplish. A big thank you to Dr. David Breen for taking the time to be my instructor for this term.

Without further ado, my first image:

Link to the full size PNG

Currently the engine supports parametric spheres and mesh objects loaded from an external SMF file(s). Sphere can be placed anywhere in the scene and meshes may be fully transformed (translate, rotate & scale). The engine writes out the final image to the very simple PPM file format (above image is converted to png for web).

Scene stats:

Camera:

Horz FOV 75°

Pos (0, 0, 10)

View Dir ( 0, 0, -1 )

Up (0, 1, 0)

Image:

960 x 540

Objects:

Sphere1:

Trans ( 4, 0, 0 )

Radius ( 2 )

Sphere2:

Trans ( -4, 0, 0 )

Radius ( 2 )

Stanford Bunny 1k

Trans ( 0, 0, 0 )

Rotate ( 180, 0, 0 )

Scale ( 3 )

It’s not fast, but optimizations are coming:

40 seconds for that, yikes! A big issue is that for every ray, every object and every triangle is tested for an intersection, it’s a huge waste of time. But this assignment was about getting the bones of the application in place so that I can flesh it out in coming weeks. I think this stage is always a tough initial up-hill climb to get all the plumbing done. Successive refinement should be more about the fun of getting the images to just look better and better.

Stay tuned!

* Link to original PPM image

#programming #raytracing #rendering #render #cs #drexel #cs699

Finally got around to creating a monitored indoor starter garden - very rough now, figuring out what works. It’s over on my wordpress because for some reason the iframes from thingspeak aren’t super working on tumblr…

#arduino #garden #sensors #thingspeak

bedside table, you know.. for kids.

so I'm officially done with the uke posts (for now). but this is yet another project for the daughter. once she moved to her new room with a bed we had gotten a hand-me-down bedside table. it wasn't in the best of shape, but we liked the look of it. there were two major issues with the table, first being the dinged up finish. second, and perhaps worse, is that the feet were not cut flush and the protective caps were all but gone. I thought this posed a potential "scratch the floor" issue, so I looked for a solution for that. here's a photo of the table from the room:

I forgot to take "beginning" photos so this is all I got. overall you can see the problems pretty clearly - bad finish, ugly, scary feet.

the finish was an easy fix - bright, sunshine yellow spray paint. I did a quick sand to get rid of a lot of dings and then blew a whole can on the table giving it a nice few solid coats.

for the feet, I purchased four giant super balls with the plan to drill them out and shove them on the bottom. this would add weight, protect the floor, and I thought it would look pretty awesome. I decided to use a forstner bit to drill out the balls because of how sharp they typically are. initially I thought it would be smarter to clamp the balls down to drill them, but I was concerned about flexing the ball and drilling an off size hole. so I decided to hand-hold them on a small rig (if you can call it that). I took a lager bit and drilled out a section of wood I had clamped to my mill, this would center the ball up as long as I didn't move the table and give it good support all around for the drilling.

here's the ball in place w/ the proper sized bit ready to go:

it went really smoothly, though generated quite a mess. I had my concerns about hand holding in case the rubber heated and bound to the bit, but I had run the spindle at a fairly low speed to reduce this - it all worked out.

the holes were really clean.

the size was just right too, with a small amount of finagling I could squeeze them on to the bottom of the legs and get a great friction fit as the leg tapered larger. they look great.

and here's the finished table:

it's a huge improvement on looks and stability. I'm going to go ahead and highly recommend the superball table foot.

thanks.

#diy #table #home #kids #kid #super ball #furnishing #furniture

Trending Blogs

Recently Viewed Blogs

mostly unfinished