0
\$\begingroup\$

So, I'm having a bit of an issue with transforming a GO after instantiation in the way that I want.

I have a main GO. On death, it spawns secondary GOs. All GOs involved are kinematic (because the AI controller moves them). So I use lerps to move the secondary GOs on instantiation in a sort of fountain pattern. However, because of the static movement, they get pushed through walls and other surfaces.

I thought I'd try using physics for this with a ForceMode.Impulse push, but to do that I have to make it non-kinematic. To do that, I also have to set it's mesh to be non-convex. Making the mesh convex causes a ~1000ms delay on instantiation while the PhysX engine parses the mesh.

So... what other options do I have? Is there any other way to use the basic transform lerps and still have it not pass through walls? I'm assuming that the direct transform is causing collision to not happen. Or maybe because I'm disabling the CharacterController until it reaches it's end position (otherwise it tries to move right away using AI).

\$\endgroup\$
4
  • \$\begingroup\$ Can you show us what these secondary GameObjects look like? It sounds like you might not need the full per-polygon fidelity of meshcolliders to make the kind of effect you're describing, which could open up some simpler & more efficient options. \$\endgroup\$
    – DMGregory
    Commented Sep 6, 2017 at 22:26
  • \$\begingroup\$ They are miniature version of the primary GO. Both are gelatinous cube creatures. They use skinned mesh renderer to support blendshapes (they wobble, melt, congeal, and other various things). So far as I understand, I need the collider setup this way to map to the mesh as it moves for collision (including hit collisions for attacks). They look like this (except the secondary GOs are smaller versions): labyrintheer.com/wp-content/uploads/2017/09/… \$\endgroup\$ Commented Sep 6, 2017 at 22:34
  • 2
    \$\begingroup\$ If the monsters are very nearly cubes, I'd lean toward using BoxColliders for them, at least for their physics interactions with the floor & walls. These are vastly cheaper and more predictable. If you need the added fidelity of polygon-perfect collisions for combat, a collider on a separate layer used solely for that purpose may do well for you. (Bear in mind, humanoid characters in many games are just a capsule for the purposes of environment collisions, and fighting game attacks are often literally rectangles — we need surprisingly little detail for most circumstances) \$\endgroup\$
    – DMGregory
    Commented Sep 6, 2017 at 22:41
  • \$\begingroup\$ So would you recommend using a simple box collider, disabling isKinematic for the duration and using force, then re-enabling isKinematic once they are where they need to be? \$\endgroup\$ Commented Sep 6, 2017 at 23:48

2 Answers 2

1
\$\begingroup\$

Food for thought but, 1) how are you detecting collision? If using OnCollisionEnter() try using OnTriggerEnter() and vice versa. Works for me sometimes. 2) Maybe try giving the secondary objects a ForceMode.Impulse away from the walls when they are near them? Try tracking the distance between walls and secondary objects and when the distance is near do ___. Slows down performance a bit (or a lot depending on how many secondary objects you have) but one out-of-the-box way to do it

My suggestion as per distance: create an array of gameObjects that stores the transform of each wall. Make a function that, each time it is called, iterates through the array of walls and calculates the distance from ith wall to the player. If distance between the two is less than 'x' then return true.

bool calculateDistance(gameObject[] wallArray){
for(int i = 0; i < wallArray.Length; i++){
if(distance between player and wallArray[i] < 'x') //x being arbitary value
 then return true;
}
return false;
}
\$\endgroup\$
0
0
\$\begingroup\$

It can be useful:

1) make a memory load of the objects you are going to use. This would be, if you are going to have to use the "Instantiate" for many objects and that causes you to lose FPS, it is common to load the level do the "Instantiate" of (for example) 10 GO and deactivate them, save them in a list and where you previously used the "Instantiate" call a method that searches the list in the first GO off and returns it activated. (this is used a lot and this method will become part of your toolbox)

2) Use physical layers to prevent objects that we do not want to collide, collide. Create layers in the Object inspector, and assign them that layer, then from the layers configuration table unselect the layers that we do not want them to collide. (When you have a pc with Unity available, edit the post, if you need help creating the physical layers)

\$\endgroup\$
1
  • \$\begingroup\$ Thanks @NorbyAriel - I'm now trying to figure out a secondary issue related to all of this. I do have layers setup (and configured in the physics settings). I've debated using a pool for objects, but it's possible for many of them to be instantiated throughout the scene over time, so the pool would need to be unwieldy. As it is, I'm changing to use physics-based movement and disabling agent.updatePosition and agent.updateRotation. Working some kinks out of this and then maybe won't have some of the other issues on the secondary mobs. :) \$\endgroup\$ Commented Sep 11, 2017 at 19:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .