1 hour ago, tyree said:

you dont seem to realize this. but giving an object physics turns it into nothing more than a life less block. being moved by math. and that is, what it looks like to the viewer. life less math. that resembles animation in no way. realism has no place in animation. unless your doing a simulation. but a simulation is not animation. architects simulate buildings, lights, weather. when someone tries to recreate an accident. they duplicate/simulate everything to be as real as possible. but that is the absolute, complete opposite of animation

Thanks for the viewpoint.

Specifically, how would you synchronize the walking / idle / running / jumping animation so that it looks smooth with the location of the avatar. I use physics and blending. How would you do it? Translation? A combination of physics and translation?

I've done non-physics controllers as well...

https://answers.unity.com/questions/282687/which-is-better-for-player-movement-physics-or-tra.html

Thanks

thats simple dont use physics at all. you just need to know when something collides with a surface and to not go thru it. physics is not needed for that

as far as animation have the character run forward, walk forward and jump forward. in your 3d program. do not apply physics once in unity

in truth  motions do not have to be blended, just interesting. they can have hard cuts from one motion to the other. if the motion is interesting, but in your 3d program you could have the character go from idle to walk. idle to run, walk to run. and you would not need to blend it in unity. it would already be done. you just tell it to play

but again you dont need to do this. the motion can have hard cuts. you would simplify the process a great deal. if you seperate the purpose of the engine. from the purpose of the 3d program. the engine is for interactivity, collision, checking distance to trigger an event 

the 3d program is for everything else. build the world, do the animations  add life to everything in general. here is something you probably never considered. in your 3d program animate a bullet going forward. then in your engine, give it tracking code that points it in the direction.of whatever target.

for something like that. its just as easy to do thru code. but what if you want the bullet to go forward then left or right, then make patterns and once its finished attack the target.thats not so simple thru code. but you could animate it 5 minutes. that is what your 3d program is for. to build something no one has seen before. and build it more often than not quickly.

3 hours ago, tyree said:

thats simple dont use physics at all. you just need to know when something collides with a surface and to not go thru it. physics is not needed for that

as far as animation have the character run forward, walk forward and jump forward. in your 3d program. do not apply physics once in unity

in truth  motions do not have to be blended, just interesting. they can have hard cuts from one motion to the other. if the motion is interesting, but in your 3d program you could have the character go from idle to walk. idle to run, walk to run. and you would not need to blend it in unity. it would already be done. you just tell it to play

but again you dont need to do this. the motion can have hard cuts. you would simplify the process a great deal. if you seperate the purpose of the engine. from the purpose of the 3d program. the engine is for interactivity, collision, checking distance to trigger an event 

the 3d program is for everything else. build the world, do the animations  add life to everything in general. here is something you probably never considered. in your 3d program animate a bullet going forward. then in your engine, give it tracking code that points it in the direction.of whatever target.

for something like that. its just as easy to do thru code. but what if you want the bullet to go forward then left or right, then make patterns and once its finished attack the target.thats not so simple thru code. but you could animate it 5 minutes. that is what your 3d program is for. to build something no one has seen before. and build it more often than not quickly.

 

Tyree, thank you for your input and viewpoint on this. I am definitely in a different place. I won't be able to implement a non-physics / animation at this time. Just trying to make small incremental steps to get the most out of my time and effort

Going from Swift to Unity3d was a major change in paradigm for me and it took a year to make the transition and feel competent.

I'll have to try your philosophy on a different game. But I definitely appreciate your input. Thanks!