The task is to create a bunch of 3D prefabs with rigidbody and mesh colliders in specific box-shape area, so all of them would not be overlapping each other, after which they should fall to the surface beneath. If I set random position for each object, sometimes (especially if there are a lot of objects to create), some of them are being created too close to other, so they push each other while falling, and everything turns into a mess.
Is there a way to create these objects with at least minimal space between each other, so they could physically interact after they have fallen? Please, take into account, that spawning box is big enough to contain necessary amount of objects, no need in huge amount of them, but still the number of objects could be different each time.
One solution would be to make the box Collider smaller for instance if the object scale is (1,1,1) the collider would be (0.95f, 0.95f, 0.95f) or something similar. Of course only if you generate your cubes in a grid like system. After the first collision try to change the collider size again. If the problem persists try to make the colliders bigger and add a physics material with 0 friction.
Assuming you have big enough area for your objects, the dirtiest but the easiest solution (not meddling with bounding boxes etc.) would be to split the logic into two phases and using triggers to reposition the object randomly.
In the first phase, the generation phase, the object renderers are not active and the colliders are active.
Generate an object.
If the collider triggers an overlap and we are in the generation phase, reposition or respawn the object.
In the second phase, make renderers active and make them fall, disable colliders etc.
Related
My question is quite simple. How do I make a cube which has other game objects inside of it, and can detect when those objects collide with sides of the cube. I can just use a collider for each of the sides but I want to be able to shrink and grow the cube while the program is running. If I used a collider for each of the sides I would have to move each of them individually. Is there a way to use just one collider on the cube?
Place six flat cubes around with a thin collier box and then make parent them to an empty game object.
I am currently working on a classical fps game, I want to be able to generate larger numbers "enemies", ideally in the hundreds. Though this may not be feasible. I am hoping to use physics and Rigidbod[ies] for these enemy models.
Obviously the nice solution would be to have mesh colliders on all these models but I'm pretty sure that will affect performance. So my alternative idea was to instead set them up initially with box colliders while they are atleast X distance from the player and then once they enter that radius around the player to switch (via enabling and disabling) these box colliders to mesh colliders.
Is this possible to do and what are the implications? My initial tests caused the model to lose its collision detection with the floor, and so drop through the environment.
Are there are performance implications to switching (enabling/disabling) colliders/if this would even make a difference?
Lastly if none of the above, is there a better solution to this problem that is performant?
The most common practice I know is using multiple primitive colliders under the same rigidbody; I believe this is much more efficient than using mesh colliders, plus, as an added bonus you can even very easily handle special hits (headshots do x2 damage, leg shots slow enemies down) since you know exactly which collider was hit.
Here is an example of how they did it back in the day in Counter Strike
Notice that you will have to place each primitive collider correctly on the bone structure for it to move correctly during animations.
I think you should have two colliders for your ennemies :
1) A persistant box for physical interaction. (This collider would be on a separate layer, colliding only with the physical space.
2) Then, you would have your flexible box / mesh collider. Instead of swapping colliders, enable/disable them. If it is too far, try enabling the box, and if too close, enable the mesh collider. I think enabling and disabling is better for performance than removing and adding components at runtime. Plus, since you already have an 'environmental collider', swapping isn't an issue for the movement of your ennemies.
Hope this helps.
I'm prototyping a climbing system for my stealth game. I want to mark some edges so that the player can grab them, but I'm not sure how to approach it. I know I can add separate colliders, but this seems quite tedious. Instead, what I'd like to do is to mark mark the edges in the mesh. Can this be achieved? How?
You're probably better off storing that edge data externally (that is, elsewhere in your running game than in the mesh) in an accessible format, that said, if you truly want to embed it INTO the mesh...
Tuck the metadata into Mesh.colors or Mesh.uv2 like #Draco18s suggests. Most shaders ignore one or both of these. Of course, you'll be duplicating edge/face level info for each vertex on the face.
When a player tries to "grab" an edge, run your collision test, grab the face, grab any vertex on the face, and look up your edge/face info.
You could also, for example, attach your edge metadata collection to a script attached to the mesh's game object. So long as you can access your collection of edges when you need to perform the test, where you store it is an implementation detail.
If you have the ability to add nested objects in your mesh, you could create a primitive box that represents the desired ledge and collider size. When you import the mesh in Unity, the child mesh object will appear as a child gameObject with its own MeshRenderer. You can disable the MeshRenderer for the ledge and add a BoxCollider component to it. The collider will be automatically sized to match the primitive mesh.
Blender Nested Objects example
Unity Nested Objects example
I have 5 gameobjects on my scene, all having a collider attached to it.
Now I don't know why - but my first top layer (a starBtn) sometimes fail to detect a mouseClick?
It's in 2d.
I detect all raycastHits and store the hits in an array - I then check all layers of all of them and return the one at the top layer. The one I need to call anaction/function from. My top layer is a square sprite.
Is there a best practice for this or a way to ingnore a collider area if an object in from of it is overlapping?
Cheers
Ps: I willadd code to this question in an hour or so.
Ok. What I had to do to solve this was to add a z-value to each object with a collider.
Then cycle through each objects' z-value - storing the highest value. Although this is 2d.
I'm having a problem with Physics! I have imported an object which a bridge from 3ds max to unity 5 ,but the problem is that whenever I want to walk through on it ,I just fall down. It's like there's nothing called BRIDGE! I know there must be a problem about Physics. But how to fix it ?!
When importing a model into Unity it does not have any Collider.
Even though using auto-generated "MeshColliders" is an option
I highly recommend not to use them.
You never need such highly detailed colliders in a game.
Instead, you have to
Add the colliders manually
Here is a little step by step guide
This is the imported model (made with blender) without any collider whatsoever
First thing to do is add a new box collider to the components
as shown in this gif
The next thing to do is scaling the box collider
by either entering the values manually or using the drag/GUI version like I do in the gif below
(you probably know that already but the mode can be changed to orthographic by licking the small cube in between the cones in the upper right)
If necessary you can add as many "detail" collider as you want
by repeating the steps. Sometimes sphere or capsule colliders might fit better but keep in mind that they have a higher resolution!
In this case i added another box collider representing the upper part of the car:
Thats all you need to make things collide with your object
Right now you only have a MeshFilter, MeshRenderer, and Animator component attached. You walk through it because the mesh is only being rendered. In order to add collision, add a MeshCollider component to it.
Joe offers another way to do it with box colliders. There is a bit to know about both methods:
Box colliders will take more time to set up (rather than just adding a
component) and will have less precision. They will have faster performance.
Mesh colliders do not collide well with other mesh colliders.
However, this is often not an issue. If a mesh collider has the
"convex" checkbox checked then it will collide just fine with other
mesh colliders. Small items and any convex-shaped meshes should have
"convex" checked.
For something like your bridge.. it depends on your game. If you are doing a top-down game with limited mobility (no jumping) then box colliders may work for you. If you are making a first-person game then I would strongly suggest mesh colliders. If you decide to use box colliders then you must set them up carefully. Otherwise, physics may not match up with what the player sees!
Do not worry about performance at this time. Worry about it later IF it becomes an issue. With the physics upgrade in Unity 5, it probably won't be.