We've come to the end of this project and will not do anymore improvement or implementations, but we are very satisfied and happy with the end result.
fredag 10 mars 2017
Raycast check
We added a raycast check from the projected ball to fix a bug that made the glass fall even if the ball didn't hit any glass.
This happened because we used the position from were the ball entered the box trigger collider and called a overlaps sphere from that position. So if the ball entered at a position that didn't have any glass it would still call the overlaps sphere which resulted in glass around from where the ball would pass through would drop.
This is now fixed with using raycasting from the ball when entering the trigger collider. If the raycast doesn't register a hit with a shard object the program won't call the overlaps sphere and the glass won't drop.
söndag 5 mars 2017
Solving the "hovering glass" problem
As out attempt to solve the "hovering glass" problem didn't work out due to its enormous complexity we tried another implementation that could possible remove the issue.
The idea is that for each ball that hits the glass a point is stored with the same position from the ball collision. If another ball hits the glass within a minimum range, they will be connected. As more and more points are connected they will eventually form a full circle (of connected dots). What will happen then is that everything that is inside this circle will fall.
The idea is that for each ball that hits the glass a point is stored with the same position from the ball collision. If another ball hits the glass within a minimum range, they will be connected. As more and more points are connected they will eventually form a full circle (of connected dots). What will happen then is that everything that is inside this circle will fall.
We did a similar implementation, but it's not as optimal as the original idea. What this implementation does is similar by the fact that it stores points, but for every point a center point is calculated. From this center point a OverlapSphere is called which makes everything in the center fall down. This solution works in some cases but in other cases the glass will still be in the air, or at least parts of the glass.
Here is the glass simulation before and after the implementation of this new feature.
The balls represent the collision points. Green balls are collision points and the red ball the the relative center.
We are working on an improved version of this implementation which we hope will be finished before the final project day.
lördag 4 mars 2017
Improved framerate
We successfully improved our framerate of the simulation by adding a lifeTime script onto the shards that falls from the cracked pane.
When the shards get's below a specified point, a timer starts that will change some components:
- Removes the shard's RigidBody
- Makes the shard static
- Removes the script itself to cease updating each frame for this shard.
This improves framerate after all of the shards has been knocked down from the frame:
When the shards get's below a specified point, a timer starts that will change some components:
- Removes the shard's RigidBody
- Makes the shard static
- Removes the script itself to cease updating each frame for this shard.
This improves framerate after all of the shards has been knocked down from the frame:
Issues with isAnchor script
A problem with our implementation is that it's possible to leave shards hanging in the air by shooting projectiles around the glass pane, since they never registers a hit they will never fall down.
We tried to implement some code to fix this bug by first adding a script onto all shards which holds some information about the shards:
List<GameObject> neighbors
bool anchor
neighbors is a list of pointers to all the shards that is touching this shard. We initialize this list in a "Awake" method for all the shards.
the anchor boolean value tells if the shard is touching the frame in any way, (touching top, down, left or right part of the frame).
Using this information we tried to implement a recursive method that would check if the shard and it's neighbors where supposed to fall or not depending on the currently "placed" shards (shards not moved by projectile). This implementation proved to be a lot harder than we initially thought though and it's possible that we will not be able to make it work in time for the final project version.
We tried to implement some code to fix this bug by first adding a script onto all shards which holds some information about the shards:
List<GameObject> neighbors
bool anchor
neighbors is a list of pointers to all the shards that is touching this shard. We initialize this list in a "Awake" method for all the shards.
the anchor boolean value tells if the shard is touching the frame in any way, (touching top, down, left or right part of the frame).
Using this information we tried to implement a recursive method that would check if the shard and it's neighbors where supposed to fall or not depending on the currently "placed" shards (shards not moved by projectile). This implementation proved to be a lot harder than we initially thought though and it's possible that we will not be able to make it work in time for the final project version.
Improved implementation complexity
We have successfully improved the complexity of our implementation by doing multiple changes:
- We have both the cracked and the un-cracked version of the plane already in the scene at start, when switching we enable one and disable the other.
- Each shard already have a rigidbody and a mesh-collider from the start now, the mesh collider is set to convex, and the rigidbody kinematic is set to true for all shards (to keep the shards from falling down by themselves).
- We have created an invisible trigger box that checks for the projectile that covers the whole original pane instead of a script on each shard. It functions the same as the previous shard script; it takes the position of the projectile and finds all shards around it by using Physics.OverlapSphere, and then sets the rigidbody kinematic to false for all of the shards. This improves calculation times a lot compared to our earlier implementation!
We also made the pane thinner by scaling down the un-cracked pane and the shards in the x-axis.
- We have both the cracked and the un-cracked version of the plane already in the scene at start, when switching we enable one and disable the other.
- Each shard already have a rigidbody and a mesh-collider from the start now, the mesh collider is set to convex, and the rigidbody kinematic is set to true for all shards (to keep the shards from falling down by themselves).
- We have created an invisible trigger box that checks for the projectile that covers the whole original pane instead of a script on each shard. It functions the same as the previous shard script; it takes the position of the projectile and finds all shards around it by using Physics.OverlapSphere, and then sets the rigidbody kinematic to false for all of the shards. This improves calculation times a lot compared to our earlier implementation!
We also made the pane thinner by scaling down the un-cracked pane and the shards in the x-axis.
Fracture Success!
We got the pane to shatter based on where we hit it:
The implementation works by having a non-cracked and a cracked pane switch out when the non-cracked pane's trigger collider registers a hit from the projectile. Each shard in the cracked pane has a trigger box collider which will check for a projectile, and when it finds one it will use a "OverlapSphere" to find all shards around it using the projectiles position, and then apply a rigidbody, remove the box-collider, and apply a mesh-collider.
This is a pretty crude and un-optimized implementation though, and we will work on making it work and look better from now on.
The implementation works by having a non-cracked and a cracked pane switch out when the non-cracked pane's trigger collider registers a hit from the projectile. Each shard in the cracked pane has a trigger box collider which will check for a projectile, and when it finds one it will use a "OverlapSphere" to find all shards around it using the projectiles position, and then apply a rigidbody, remove the box-collider, and apply a mesh-collider.
This is a pretty crude and un-optimized implementation though, and we will work on making it work and look better from now on.
Change of material
We decided to add a reflection probe and change the metallic property of the glass material to make it reflect the background like a mirror:
This was mostly an aesthetic decision.
torsdag 2 mars 2017
Assets
We downloaded some free assets to make the scene look a little more realistic. We didn't want to put too much time into making a good looking scene so we implemented the first we found that looked good enough.
The assets we have downloaded is:
"Prototype materials pack", made by Burak Taban & Dream Reaper Studios
https://www.assetstore.unity3d.com/en/#!/content/65136
"Wispy Skybox", made by Mundus Limited
https://www.assetstore.unity3d.com/en/#!/content/21737
The assets we have downloaded is:
"Prototype materials pack", made by Burak Taban & Dream Reaper Studios
https://www.assetstore.unity3d.com/en/#!/content/65136
"Wispy Skybox", made by Mundus Limited
https://www.assetstore.unity3d.com/en/#!/content/21737
söndag 26 februari 2017
Demo Scene
We created a demo scene where we can work and test our implementation of the shatter system:
This scene was made to be simple and small. There's ground, four walls and a glass pane in the middle of the scene surrounded by a wooden frame.
We added a fps-controller from the standard assets to be able to walk around the scene. And we also wrote code so that you are able to shoot a small ball projectile from where you are aiming with the camera:
We added a fps-controller from the standard assets to be able to walk around the scene. And we also wrote code so that you are able to shoot a small ball projectile from where you are aiming with the camera:
Start of Project
We have now started the work on this project.
The main objective is to create a "fracturing" pane, which is a thin box that will break into small pieces when hit with another object. We will try to achieve this by using pre-defined points on the plane and use them to break the pane, a similar system can be seen here:
What we want to do differently compared to this video is that we want to be able to decide where and how the object will fracture based on the impact point position.
The main objective is to create a "fracturing" pane, which is a thin box that will break into small pieces when hit with another object. We will try to achieve this by using pre-defined points on the plane and use them to break the pane, a similar system can be seen here:
What we want to do differently compared to this video is that we want to be able to decide where and how the object will fracture based on the impact point position.
Prenumerera på:
Kommentarer (Atom)