|
|
Post by jzarra on Jun 3, 2020 5:10:28 GMT
|
|
fremag
Junior Member
Posts: 73
|
Post by fremag on Jun 3, 2020 8:12:37 GMT
I also realized that in my implementation, alternating the order of matrices when multiplying them affects the output transform considerably.
Translating then scaling is not the same thing as scaling then translating.
The problem is not in your implementation, this is a math effect: in general matrix multiplication is not commutative.
Good luck for next chapters but I would really recommend to do the basic tests first before going to "Putting it together". The "Reflection and refraction" is not easy and there a lot of places where nasty bugs could happen.
|
|
|
|
Post by jzarra on Jun 3, 2020 11:25:17 GMT
Thanks Mr. Fremag,
I am excited about moving forward now to Chapter 7, I will be more rigourous with the tests.
The plasma effect on the sphere still concerns me though, I have not been able to figure out why the points where the specular reflection are colored with the diffuse values.
If you have any suggestions about this please let me know.
Anyway, thanks again for all your advice!
|
|
fremag
Junior Member
Posts: 73
|
Post by fremag on Jun 3, 2020 13:53:24 GMT
In this picture, the diffuse part looks good and the specular too. But the sum looks wrong because it's green where is should be white.
In your code, I see this:
// Here I extrapolate the colors from the 0-1 range to 0-255 range.
c.m_r = static_cast<int>(255.999 * c.m_r);
c.m_g = static_cast<int>(255.999 * c.m_g);
c.m_b = static_cast<int>(255.999 * c.m_b);
I don't think it's good to multiply red/green/blue by 255.999 because colors could be higher than 1 as we sum them in the lighting function.
Near the specular spot, the diffuse color is violet so r/g/b ~ 150/30/150 but we use values between 0 and 1 so it's 0.6/0.1/0.6
The center of the specular spot is almost white, let's say: 0.8/0.8/0.8
So the sum will be 1.4/0.9/1.4
When you multiply by 255.999 and cast to int you get: 358 / 230 / 358 I don't know what will happen with the red and blue component as they are higher than 255. The green part is lower than 255 so it could explain why the spot looks green ?
Look at the book page 21 and the test: "Constructing the PPM pixel data", there is a case where color(1.5, 0,0) is transformed in to "255 0 0"
The tests may look like a waste of time slowing you down when you start but in the long term you'll realize it saves a lot of time !
|
|
|
|
Post by jzarra on Jun 3, 2020 15:10:09 GMT
Dear Mr. Fremag, You are right, looking inside the .ppm file I can see some pixels with red and blue values higher than 255:  I was supposing that the values were gonna be clamped as mentioned in the chapter, using the following text at the beginning of the .ppm file as in the example: P3
256 256
255That makes me wonder how the author achieved clamping between 0 and 255 range if the header of the .ppm file does not recognize the maximum color value. Multiplying by 255 was my idea of extrapolating the values because not doing it will fill the .ppm file with small decimal numbers:  I will look into how to extrapolate the numbers within the 0-255 range in C++ and get back with some results to discuss. Thanks again! |
|
fremag
Junior Member
Posts: 73
|
Post by fremag on Jun 3, 2020 18:16:25 GMT
I don't think you have to normalize all the pixel values.
I just added something like this before writing in the ppm file: if value > 255 then value = 255
and it works well.
When you take a picture with a camera, if there is too much light, your pixel is over exposed but is still white.
If you try both methods I'll be glad to see some pictures to compare results.
|
|
