Hi, this is my blogpost regarding the HW2 of CENG469. The objective this time was to improve upon the previous homework, adding a controllable plane enviornment mapping and animated water.<\/p>\n\n\n
Migration<\/h2>\n\n\n\n
I started by copying over hw1 and examining the provided starter code. I merged the utility files that I had edited with the new ones and added the imgui library.<\/p>\n\n\n\n
Plane<\/h2>\n\n\n\n
My first task was to add the plane. I changed the camera struct into two structs, one keeping the plane’s position rotation and speed and another that keeps the camera’s offset and rotation. I added the keyboard shortcuts for zooming, plane and camera rotations. I implemented the and repurposed the code from last homework’s U-mode camera to implement the camera’s rotation while using the ordinary rotation for the plane. Then I changed the movement code such that the current speed moves the plane along the +z axis and w<\/code>\/s<\/code> buttons change the speed. Finally I added the code that offsets the camera in its +z direction from the plane.<\/p>\n\n\n\n
When implementing this with the information fresh in my mind from studying for the midterm, I realized that I had written quat rotation code wrong in the previous homework. Instead of v'=qvq*<\/sup><\/code>, I was using v'=vq<\/code>. However, upon fixing this everything broke. I eventually learned that glm overrides quat multiplication such that it rotates a vector, not multiply it directly.<\/p>\n\n\n\n
I added the variables to import the parts of the plane model and the draw calls (with the appropriate offsets) for each one. I added a time variable to the GLState<\/code> that I used to determine the rotation of the propeller. Later I made the propeller rotation also dependent on the plane’s speed.<\/p>\n\n\n\n
Textures<\/h2>\n\n\n\n
With that done I moved on to the textures. I realized that with 4 models and 6 textures the code for drawing the plane was quite cumbersome to have in the main loop, so I created a struct to hold all its texture, model and shader variables and moved the draw code to a single method of the struct. Also seeing how the starter code had different shaders for different things instead of changing the mode uniform of one shader, I created seperate shaders for the plane and terrain. The plane shader simply maps the given texture as color.<\/p>\n\n\n\n
To draw the terrain I created another struct that holds all the terrain textures and handles the pipeline. This made the main loop nicer and easier to dollow. For its fragment shader I used the fragment x-z<\/code> coordinates as the u-v<\/code> coordinates. Instead of the sharp color transitions in the hw1 I wanted the textures to smoothly change, so I removed the if-else gates and used 2 mix calls mix the textures. I ended up not using the shore texture in the shader.<\/p>\n\n\n\nTexture mapping<\/figcaption><\/figure>\n\n\n\n
Tonemapping<\/h2>\n\n\n\n
With that done the next goal was tonemapping. I looked up how to do this in OpenGL and found an official aritcle with some sample code. I created another struct that’d keep the texture buffers and shaders. I implemented the process using the apis already used in the project following the example of the sample code. I also read the tonemapping using mipmapping paper to see how to implement that part of the code. Finally I named the method endRender<\/code> and placedits call at the end of the main loop. The tonemapped image looked significantly brighter but upon comparing it with the texture files I decided it was correct.<\/p>\n\n\n\nTexturing<\/figcaption><\/figure>\n\n\n\n
Enviorment Mapping<\/h2>\n\n\n\n
I decided to create another method under the same struct called startRender<\/code> that’d have the enviornment mapping code. I implemented the new enviornment.frag by loosely following the cubemap generation code in the slides. However as the camera could face any direction unlike a cubemap I had to improvise. I devised that if I pass the gaze direction and the field of vision to the fragment shader I could use atan<\/code> and asin<\/code> to find the i-j<\/code> coordinates (u-v<\/code> of the spherical image).<\/p>\n\n\n\n
In my first implementation I figured that if I just calculated the i-j<\/code> coordinates of the gaze vector I could multiply the fragment’s u-v<\/code> coordinates with the FOV to find the correct i-j coordinates. Initially everything was sideways, but eventually I figured out that I was assigning i to j and vice versa. After fixing that it seemingly worked, but upon rotating the camera it was obvious something was off.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.metu.edu.tr\/e263308\/files\/2026\/05\/Screenshot_20260503_215020-1024x612.png\")
![\"\"](\"https:\/\/blog.metu.edu.tr\/e263308\/files\/2026\/05\/Screenshot_20260503_220241-1024x611.png\")