Nsryjdtyk

Before this is tagged as a duplicate, I am having the exact same problem as the individual who asked this question.

Unfortunately, it doesn't have an answer that helped at all, so hopefully this will spark a better discussion. Using C++, the task at hand is to program a classic ray tracer. I am using a Phong shading model, and I am able to illuminate my scenes accurately up until I need to cast shadow rays.

Just for reference, here is a picture of what I have so far without attempting shadows:

Following a traditional ray tracing algorithm where I look for the closest object to my pinhole camera, I call the following function that computes the resulting pixel colour:

glm::vec3 Scene::illuminate(Ray* primary, Surface* object, glm::vec3 hitPt)

{

    float red, green, blue;

    Material m = object->getMaterial();

    float p = m.phongCoef;

    glm::vec3 kD = m.diffuse;

    glm::vec3 kS = m.specular;

    glm::vec3 kA = m.ambient;

    float iA = m.ambienceIntensity;

    float i = lightSrc.lightIntensity;

    glm::vec3 n = object->getSurfaceNormalAt(hitPt); //normalized before return.

    glm::vec3 viewRay = primary->getDirection();   //normalized class member.



    glm::vec3 lightRay = glm::normalize((lightSrc.getOrigin()) - hitPt); //origin not normalized before here

    glm::vec3 h = glm::normalize(viewRay + lightRay);

    float nDotlightRay = glm::dot(n,lightRay);

    float nDoth = glm::dot(n, h);



    bool inShadow = false;

    Ray shadowRay;

    //hitPt = glm::normalize(hitPt);

    shadowRay.setOrigin(hitPt);

    shadowRay.setDirectionVector(lightRay);

    for (int k = 0; k < objects.size(); ++k) {

        if (objects.at(k)->intersect(shadowRay)) {

            //std::cout<<shadowRay.getDirection().x<<","<< shadowRay.getDirection().y <<","<<shadowRay.getDirection().z<<"n";

            inShadow = true;

            break;}}



    //plug in to shading model

    if (inShadow)

    {

        red = kA.x*iA;

        green = kA.y*iA ;

        blue = kA.z*iA ;

    }

    else{

        red = kA.x*iA  +  kD.x*i*(fmax(0,nDotlightRay))  +  kS.x*i*(powf((fmax(0, nDoth)),p));

        green = kA.y*iA  +  kD.y*i*(fmax(0,nDotlightRay))  +  kS.y*i*(powf((fmax(0, nDoth)),p));

        blue = kA.z*iA  +  kD.z*i*(fmax(0,nDotlightRay))  +  kS.z*i*(powf((fmax(0, nDoth)),p));

    }



    glm::vec3 pixelColor = glm::vec3(red, green, blue);

    return pixelColor;

}

I have tried to use descriptive variable/function names so as to minimize the explanation that accompanies my code. glm::vec3 is just a data structure from the GLM math library that holds a 3D vector on which matrix/vector manipulations can be done.

As in the question I linked above, here is what my scene looks like after trying shadows.

The light position for this scene is (0, 2.5, -7.75) expressed in the camera reference frame (which has an origin of (0,0,0) and is facing the negative z-direction). For another scene, the light source is at (4, 6, -1) and for that the output isn't even consistent with the problems of the other scene I tried to render as you can see here; it only has a thin grey line across the top of the scene, no shadows anywhere else? I am completely lost and have spent about 10 hours on this problem alone; any advice would be great.

Please let me know if there is any other information else I can provide, such as how I calculate distance and hitPoint?? I dont know if I should look into those since the shading part works perfectly, or do you guys think it Could still cause this problem? Depth and such shouldn't be a problem since the objects look correct up until shadows?

Answering my own question: The specific shadow artifacts mentioned above were a result of omitting the ray origin in my intersection calculations. Originally I didn't bother since my camera reference frame was at (0,0,0). But for shadow rays, the origin is not a zero vector and thus reusing the same intersection-test functions gave results that were totally off. Making sure to use normalized direction vectors is also key or the outputs will make no sense, making it difficult to narrow down what the bug could be.