Collision detection implementation

The octree collision detection is built for objects when the models are loaded by calling the function ”calcVertNormalsUsingOctree” of the ”ThreeDModel” class. Here the oc-tree is constructed using the ”constructOctee” function, which using the ”Ococ-tree” class, constructs the tree and its children that contain the bounding boxes. The depth of a tree has been set to 5, because it provides the best balance between performance and accuracy of the bounding boxes, the performance impact becomes exponentially higher the more tree levels there are. Once the octree has been made, its vertex normals are calculated by calling ”processVerticesByLeaf”.

Before collision detection checks are made in ”droneCD” function, the ”modelAAB-BCollision” function of ”CollisionDetection” class is called to check if the drone’s AABB intersects the object’s AABB. This is done by getting the coordinates of all corners of a bounding box, iterating through them to find minimum and maximum x, y and z coordinates of both objects and returning a boolean value based on the logic as seen in Fig. 34. Once the function returns true, the 4 point spheres on the drones are checked against the object’s octree via ”isOctreeCollision” in ”ThreeDModel” class.

Figure 33: Shows fog fraction ’f’ being applied to the final fragment colour.

Figure 34: AABB-AABB collision detection logic.

This recursive function iterates through each level of a tree, getting 3 coordinates from each of the 6 faces of a bounding box, calculating the face normals and if the collision is detected (if a point sphere’s distances to all 6 faces is less than 0), the function calls itself to check for collisions on the next tree level. If a collision is detected on the last level, the function returns ”true”, else the collision is not valid and ”false” is returned.

To calculate the distances, a ”calcSidePointPlane” function is used as seen in Fig. 35.

Where ”norm” is a normalized face normal, ”point” is one of the coordinates on the face, ”BVPoint” is a drone’s point-sphere’s position and a ”BVRadius” is the radius around the drone’s point that defines a valid collision area.

Figure 35: Point-Face distance calculation function

Based on which point on the drone triggers a collision, a relevant function ”gener-alCollisionFront”, Rear, Left or Right is called, causing the drone speed to be greatly reduced and reversed to bounce away from an object. Additionally, if a drone collides with a wall mounted lamp, the boolean value ”isLight1Broken” will be set to ”false”, leading to the ambient, diffuse and specular point light values to be set to 0.

The ”droneCD” function also introduces an altitude limit, forcing the drone back down by speeding up its descent as seen in Fig. 36. The invisible boundary walls for the environment are also implemented that follow the same AABB principle as discussed

Figure 36: Drone’s altitude limit and reaction

before, but this time the drone is kept inside the bounding box.

Figure 37: An example of a drone’s front point colliding with the invisible wall.

During the update stage of smoke particles, each particle is checked for collisions using ”pointToAABBCollision” of the ”CollisionDetection” class. This function checks for point-AABB collisions (Fig. 38) is a similar way as been seen in Fig. 34.

Figure 38: Point-AABB collision detection logic for smoke particles.

4 Results

The final project result is a realistically set up environment. The scene has been adjusted to be bright enough for the user to see it well on the screen, while at the same time dark enough to utilize the light sources well during the night time as seen in Fig. 39.

The smoke system resulted in a good representation of chimney smoke, as the smoke blends with the environment, gets thicker the more particles the camera is looking through and as particles collide with the chimney cap as seen in Fig. 40. The smoke is set to 6,000 particles compared to Mendez (2013)’s 2,800 particles, which produces a balance between a realistically thick enough smoke to simulate the chimney smoke and the performance hit that comes with it. The system has been strain tested to observe how

Figure 39: A realistic scene with a day and night cycle.

Figure 40: The final result of a smoke particle system.

the number of particles affects the frame rate in an application with all features active as seen in Table 1. From the strain testing it can be concluded that the simulation loses ap-proximately 1 frame per every 5,000 particles rendered, making 6,000 particles a good number for the smoke of designed scale without making a noticeable compromise on performance. The particle system has also been tested for texture fill rate dependency and the frame rate has not been affected by location and direction of the camera relative to smoke position.

Table 1: Frame rate tests based on a number of smoke particles.

The implemented halfspace fog creates a realistic representation of low ground fog as seen in Fig. 41 and a separate shader effectively fills in the empty space outside of the scene with fog. The fog concentration was tested at lower and higher levels, but the constant density of 0.000018 was found to be the best balance between fog thickness and visibility as seen in Fig. 42. The low density of 0.00001 creates a realistic visualisation of fog with a soft border between the fogged and unfogged halfspace, although the chosen density of 0.000018 creates the same result, but with very dense areas far below the fog plane and shallow areas with light fog, showing greater density variation. The tested density of 0.00003 resulted in an unrealistically strong colour blending that did not suit the fog simulation. Additionally, performance impact has been tested, resulting in no operational gain because all calculations are performed within the shaders and executed on Graphical Processing Unit (GPU), avoiding the Central Processing Unit (CPU) bottlenecking.

Figure 41: Halfspace fog during day and night with constant density value a = 0.000018.

The 3 types of lighting have been implemented as seen in Fig. 43. The result is an ac-curate and simplified representation of light behaviour that has been extended to support shadows across all 3 lighting types as seen in Fig. 44, the Fig. 45 also demonstrates the Blinn-Phong specular highlights. The maps for shadows have been rendered using the 4096x4096 resolution to create accurate shadows since the directional light is required to be far away to cover the whole scene, while keeping the shadow edges noticeably softened by PCF. The Fig. 46 shows shadows at different resolutions.

Figure 43: This figure shows the effects of directional, point and spotlight lighting types.

Figure 42: Halfspace fog tests: a) low density of 0.00001, b) optimal density of 0.000018 and c) high density of 0.00003.

Figure 44: Directional, point and spotlight generated shadows.

Figure 45: Blinn-Phong specular highlights, directional (enhanced) and spotlight lights.

Figure 46: Shadow resolution tests (PCF enabled): 1024x1024, 2048x2048, 3072x3072, 4096x4096.

Table 2: Frame rate tests based on shadow map resolution.

Shadow resolution: Frame Rate (FPS)

1024x1024 47 - 48

2048x2048 46 - 47

3072x3072 46 - 47

4096x4096 39 - 40

5120x5120 25 - 26

6144x6144 17 - 18

The tests are run using FX-8370 AMD processor and GTX 970 Nvidia graphics card.

5 Conclusion

The project objectives were to simulate smoke and fog, along with lights, objects and shadows included. The smoke has been implemented using a point sprite based particle system, allowing for randomly generated smoke behaviour and fade in and out effects by utilizing age and lifetime of each particle to blend with the background. The fog uti-lizes a plane to define a fogged and an unfogged halfspace and calculate the fog intensity based on camera’s distance to the object. The simulation makes use of a Blinn-Phong lighting model to represent a simplified version of real-life light by combining ambient, diffuse and specular elements to create directional (sun), point (wall lamp) and spotlight (drone mounted) lighting types. In addition to the lighting element, shadows were incor-porated for a better sense of depth perception and directional light’s position in relation to objects in the environment. The shadow quality was improved by smoothing edges with Percentage Closer Filtering (PCF). Additionally to the project objectives, a day and night cycle is included as well as a player controlled drone with realistic flight con-trols (mouse and keyboard), a mounted spotlight, multiple camera angles and collision detection.

In overall, the project requirements have been fully met on time. The milestones set at the beginning of the project have all been successfully achieved as follows:

• ”The simulation must run at no less than 30 FPS.” - the application has been observed to run at a stable 40 FPS.

• ”Achieve smoke with 3,000 particles.” - the particle count amounts to 6,000 par-ticles compared to a result of 2,800 parpar-ticles by Mendez (2013), though a particle count of 20,000 is achievable before performance drops below 20 FPS.

• ”Have at least 4 objects in the environment.” - the scene contains 6 objects, the landscape, boxes, a house, a lamp, a base and a sky sphere.

• ”Have at least 2 light sources.” - the implementation contains 3 lights, which are the directional, point and spotlight lights.

• ”Achieve a fog more realistic than OpenGL fog.” - this milestone is also achieved as the implemented halfspace fog is also distance based, but generates a more realistic representation of fog, while being able to define a plane to separate the space into a fogged and an unfogged halfspace as seen in Fig. 47.

Figure 47: The comparison between OpenGL Fog example from ”in2gpu” website on

”Create a fog shader” and the resulting Halfspace Fog.

The following are the known issues and possible improvements:

• The shadow becomes less accurate the further away it is from the directional light source, since the depth map is resolution limited and cannot correctly record dis-tances of distant fragments, resulted by texels being overwritten. The solution could be to reduce the distance by having a directional light for each object, mov-ing in a synchronized manner to simulate day and night cycle.

• The shadow map bias does not work well at extreme angles since it is fixed to op-erate in a certain range. To improve, a more complex algorithm for adaptive depth bias for shadow maps is recommended and is discussed in papers by Hang Dou and Wyman (2014) and Alexander Ehm and Nischwitz (2015).

• The halfspace fog could be improved further by implementing heterogeneous fog such as by Zdrojewska (2004), creating a hybrid fog system with dynamic ele-ments.

• Bloom could be added to light sources by using Vries (2014) and could be made to interact with fog when the spotlight is shining through it.

• The CUDA programming interface guide by NVIDIA (2010) could be used to move most of the CPU side per-frame processes onto the GPU, greatly improving the general application performance as it will allow for parallelized execution of code.

References

Alexander Ehm, Alexander Ederer, A. K. and Nischwitz, A. (2015). Adaptive depth bias for soft shadows. WSCG 2015 Conference on Computer Graphics, Visualization and Computer Vision, pages 219–228.

Biri, V. and Michelin, S. (2002). Real time animation of realistic fog. 13th Eurographic Workshop on Rendering, pages 1–9.

Giroud, A. and Biri, V. (2010). Modelling and rendering heterogeneous fog in real-time using b-spline wavelets. WSCG Communication Papers.

Hang Dou, Yajie Yan, E. K. Z. D. and Wyman, C. (2014). Adaptive depth bias for shadow maps. Journal of Computer Graphics Techniques, 3(4):146–162.

Hinks, T. (2005). Procedural smoke particle system with opengl 2.0. Linkopings Tekniska Hogskola, pages 1–29.

Lengyel, E. (2007). Unified distance formulas for halfspace fog. Journal of Graphics Tools, 12(2):1–9.

Mendez, R. L. (July, 2013). Realtime smoke rendering with opengl es 2.0. ARM, pages 1–6.

NVIDIA (2010). Nvidia cuda. NVIDIA CUDA C Programming Guide.

Reeves, W. T. (July, 1983). Particle systems - a technique for modeling a class of fuzzy objects. ACM Transactions On Graphics, 2(2):1–17.

UEA (2018). Uea blackboard: Graphics 2 module. University of East Anglia.

Vries, J. D. (June, 2014). Your #1 resource for opengl. LearnOpenGL.

Zdrojewska, D. (2004). Real time rendering of heterogenous fog based on the graphics hardware acceleration. WSCG 2010 Communication Papers, pages 145–152.