I have a Terrain with a path drawn using Path Painter. (The terrain is uneven and contains trees).
The trees next to the marked places are added manually as objects. The marked places show the shadow of these trees. I have a problem here. During the game, Cubes are loaded and fall from the top. At these points, sometimes there is no collision and the Cube falls below the Terrain.
In short, it is sometimes the Collider Terrain that does not work where the shade of the tree is. What could it be? After building the game there is also this problem. I ran Unity several times etc.
The shadows do not interact with the collision at all. Are the cubes moving too fast? When a Rigidbody is not set to continuous as #harry said, sometimes the physics engine can 'miss' that they were supposed to collide.
Related
I have a car with 4 wheels, the wheels have their meshes and colliders separated with only 2 Empty GameObjects. As in [Car>Wheels>(WheelMesh+WheelCollider)]. The script works just fine but then I run the program and I am met with a car who's wheels are just awkwardly spinning. And to make matters worse even though I have perfectly aligned the Meshes with their Respective Colliders, what my eyes witness is just weird wheels who's mesh glitch into the ground. How do I correct it, or how to properly align or.. How do I directly link the colliders to their meshes?.
I tried to re-align the colliders and adjust their size to fit the mesh, I was expecting the mesh to move with the collider, but the mesh just does not sit with the collider, though the collider works fine.
My best suggestion will be to separate physic from model. You need to Have separate object for mesh and collider and after each LateUpdate update position of the mesh object.
I would be better if you can provide screenshot of hierarchy and how collider/model looks like.
I've been having difficulty implementing enemies with a billboarding system for a while:
For a new project I'm reusing some animated sprites from an old static camera shooter game I made. It consisted of shooting projectiles and hitting enemies advancing towards your position. The enemies were capsules which had an animated plane in front of them.
I wanted to go a step further and make a raycast system that would detect if the impact on a plane is on the alpha part of its texture. I achieved it using a SpriteRenderer and a plane that matched the size of the sprite which receives the impact of the Raycast.
The problem comes with the movement of the enemies. If I use Rigidbodies this conflicts with the plane which detects the impact, since I have to use a non-convex Mesh Collider for RaycastHit.textureCoord (With Convex colliders it doesn't return the correct position). I need Rigidbody based movement for the enemies to push each other when colliding.
I tried using Transform Movement, since the error does not occur, but this allows enemies to pass through each other and occupy the same space.
I started investigating navMesh but I'm not sure if it is possible to avoid collisions.
I started to place a group of trigger colliders on the enemy mimicking the shape of the sprite. But this makes it difficult for me to detect collisions when enemies do certain animations (Some enemies jump diagonally or their animations are a bit jittery).
I would like to keep the impact detection system for the sprite, but maybe there is another way to check the texture at the impact location.
I think my options are:
With rigidbody based movement: separate the animation and hit detection system from the enemy movement. And make the billboarding effect teleport to the object constantly.
With Transform movement: Detect if they are overlapping and move them in opposite direction to the overlapping to simulate the collision.
With motion based navMesh: I'm not sure if it will be useful to me, since the characters jump and I also believe that a Mesh Agent ship cannot simultaneously be an obstacle. I understand that the navMesh cannot be generated in runtime.
Leaving texture based detection and using the trigger colliders group: Animate the colliders to also follow the animations. Or simplify everything to a large collider, losing precision on impact.
-Find an alternative method to detect the impact coordinates in the texture, avoiding using RaycastHit.textureCoord and therefore Mesh Collider. (Although I would like to keep the impact detection system as it is, maybe there is a similar approach for the same result).
The reason I have not yet delved into these solutions is because I would like to keep the system simple. I'm trying to avoid separating the enemy into 2 gameobjects, simulating collisions or animating collider positions. I honestly don't know which way to go in order to move forward with the project.
so I have this game in which I have destructible terrain. my setup is that when terrain is destroyed a part of the terrain texture is made transparent, to act as a crater. after any kind of change takes place, I delete the polygon collider on the texture for the terrain and create a new one in order to recalculate the terrain, but obviously this is very taxing on processing power. is there a way to reset the polygon collider without having to do this?
in addition, the polygon collider is not very accurate and I've been told that pixel perfect collision is not possible in unity, but I hold out hope. is there a way to increase the accuracy at least?
here is an example of my problem:
Collider recalculation is expensive, and there's no way around it in Unity, you can't even do it asynchronously.
It depends on your exact situation, but for a Worms-type game with dynamic terrain destruction, I wouldn't use polygonal colliders/Unity physics engine at all.
I'd create my own pixel-perfect collision system that would rely only on the underlying terrain texture.
You already have the terrain data, checking for collisions could be done with Bresenham's algorithm.
Here's a tutorial: http://gamedevelopment.tutsplus.com/tutorials/coding-destructible-pixel-terrain-how-to-make-everything-explode--gamedev-45
I would recommend setting up cluster-based colliders in this case. How do you calculate the area of texture that becomes transparent? If it has a fixed size, you can create a one big collider, which consists of many smaller (hexagon shaped maybe?) sized colliders, whose size equals to the area of texture made transparent.
After you make the texture transparent, you simply destroy the cluster. Though you would have to make the hex(if this shape you choose) grid for every map.
This would be harder to implement in procedurally-generated maps, but it is still possible, as there are no dynamic colliders at the moment.
I'm making RTS project on Unity3D.
I created terrain with Unity's standard Terrain tool, and added textures of grass, mood etc. on it. Then, for creating "man-made" objects of terrain (roads, sidewalks, road curbs etc) - I'm created this objects in separate assets, and placed on terrain.
And I have one issue with this solution. On moving camera away from the terrain, terrain's texture(e.g. mood) are flickering under roads, sidewalks and other objects. AFAIK, this bug caused by insuficcient accuracy of floating-point coordinates in Unity3D engine (?).
Now, as I concerned, my approach to creating terrain objects is not correct. I must create one mesh with terrain, and all manmade objects in 3D modeling software, and then create UV-map for texturing all of it. Is this approach correct? If "yes", is any special approach for modelling and texturing so large and complex object as terrain?
I had the same issue time ago and I solve it by increasing camera's near plane value. I had many objects on the plane that were flickering when moving the camera and was due to having the near plane value at 0.01. I change it to 0.5 and none of the objects where flickering anymore.
I hope this helps!
EDIT: This is now a rather simple question. I have a 2D sprite that really needs the precision of a polygonal hitbox. The 2D, tile-based world around it uses a tile Mesh for efficiency reasons, and thus has a Mesh Collider.
Before, the tiles in the world were each GameObjects with Box Colliders and Rigidbody 2D's, and the ship and the tiles collided just fine. Now that I am using a Mesh Collider, however, they cannot collide. (I have read that this is because one is 2D and one is 3D.) So what should I do to get collisions (preferably with rigidbody physics) between a polygonal ship and a 2D tile mesh? [end edit]
In a 2D, tile-based, procedurally-generated, chunk-based exploration game (in Unity 4.5), I have a player ship which uses a Rigidbody 2D and a Polygon Collider 2D for collision detection.
This worked fine back when I used a Rigidbody 2D / Box Collider 2D for world tiles. However, this is horribly slow, so I replaced the discrete blocks with a tile mesh, using a Mesh Collider and other associated paraphernalia.
The problem is: I simply cannot get collision detection to work. I have tiles on the x-y plane, and the collision mesh (I can see it in the Scene View, so I know it works) consists of four rectangles perpendicular to the tile. (If you can't visualize this, I don't blame you. See here.)
What have I looked at so far? Well, I verified that the (2D) ship actually passes through the collision boxes in the Scene View. Also, neither of the colliders "Is Trigger".Since there seems to be no official documentation on how to actually use meshes (is there? Where?), I can't find out whether Mesh Colliders and Polygon Colliders actually can interact. Because one is 2D and one is 3D, does this not work? If so, then what should I do instead? I tried using a Box Collider [3D] for the ship, but this didn't work either. I could have potentially made a mistake here, though.
Am I supposed to handle the collision manually (with the OnCollisionEntered [or something] method)? Before, the rigidbody2D objects handled everything automatically. Otherwise, is there any other possible reason the collision might not work?
Well, I'm quite disappointed there seems to be no built-in way to do this in Unity. My solution was to attach a GameObject to the player that would read the block data from the world and create (pooled, of course) real but invisible "collider blocks" with Box Colliders 2D in a small area around the player, such that the player could collide with blocks near them. It works great, and I also implemented an algorithm to spawn rectangular collider blocks over groups of blocks; this eliminates the "ghost pixel" bug in the 2D physics engine.
Uni2D plugin (https://www.assetstore.unity3d.com/en/#!/content/3826) automatically creates 3d colliders (as a group of mesh colliders) from any 2 texture with transparency. A bit expensive but works.