search

psteudolus / RayTracer

RayTracer in one weekend
MIT License
0 stars 0 forks source link

Encapsulate Ray Tracer From Main #4

Open psteudolus opened 5 years ago

psteudolus commented 5 years ago

Main should really just be a top level control function, we don't want to be doing any actual work in there. I want to encapsulate all of the ray tracing stuff into it's own class.

psteudolus commented 5 years ago

We want the ray tracer class to control the general flow of the ray tracing itself. It will take in the initialization parameters and get the camera, world, and any hitable objects within the world constructed. The methods for color, randomScene, parallelTrace, and serialTrace will all live in the class.

psteudolus commented 5 years ago

Attempted this last night but ended up getting frustrated and accidentally blowing up the local repository after attempting to switch branches in visual studio. Not 100% sure what happened there, but I'm going to be more careful moving forward when I do this.

The issue I ran into was an out of bounds exception on:

double closestSoFar = tMax;
(int i = 0; i < listSize; ++i) {
    if (list[i]->hit(r, tMin, closestSoFar, tempRec)) {
        hitAnything = true;
        closestSoFar = tempRec.t;
        rec = tempRec;
    }
}

This happened in the past due to issues in world construction, leaving listSize and list[i] out of sync. However, this isn't what happened here, list size was correct but there was no data in the list.

My gut feeling is that one of my refactors let to Hitable items pointed at in the list being destroyed before they could be accessed. This was the point I tried to jump back to the other branch to compare code and Visual Studio blew it up.

psteudolus commented 5 years ago

Moving from objects being created in global space to objects being created inside a class fucks with the pointer use. I'm pretty certain this is the issue.

psteudolus commented 5 years ago

From my reading's over the past few days about pointer ownership and objects being created in stack or heap memory I think I have a good idea as to what was happening. Sadly I don't have the old code anymore, but when I refactor I can properly manage the object lifecycle using RAII and smart pointers.

The resource life cycle needs to be intrinsically tied to the containing object lifecycle, that's part of the issue that I was having when moving from global space into code space. Global stack objects would exist through the entire lifecycle of the program, and class heap objects would live beyond when they were destroyed. In effect their life cycle was flipped.

I'm going to create an issue to move away from using naked new/delete to make_smartpointer.