A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Editor & General Support' started by willgoldstone, Apr 13, 2018.
Been doing that since I dunno, 3.5... It's always been possible.
Animations in new 3p character will be build around playables or mecanim?
Lol, fair enough! -- I wasn't sure about that at first until I did some animation controller "hacking" to get my own system like this working with Humanoids, but I'd still like to see your approach and if it's easier / more performant than what I'm using now.
I mainly just meant that there are aspects of this kind of system (when working within the limitations of Mecanim) that aren't so straightforward (and seem impossible) without using a modified form of the Legacy system (and losing the humanoid functionality) or rolling your own solution entirely (with hacks) to maintain it. Without blendtree hacks, writing transforms directly, (or entirely rewriting the Legacy animation system while "hacking" Mecanim so that I can still use Mecanim's humanoid stuff... <__< ;;; ), it can be daunting to play with things like realtime custom animation curves or setting the bones to react to player physics without setting up a ragdoll specifically for this first. This is something that I (and others) once thought was impossible ( especially with Mecanim standing over us with its large, brooding presence), but it isn't -- It's just really painful to re-implement (from my own experience) an entirely custom animation system (that does mostly the same thing Mecanim does) for something others are already doing.
That said -- I definitely still feel like this would be a very valuable thing to include inside of a 3d character controller, and I'm not really sure it would fit anywhere else. With C# Animation jobs, this kind of animation has actually become a lot more straightforward since it allows one to more-easily implement things like springs and pose-matching on the individual joints without worrying about fighting with Mecanim or Legacy anymore.
Seems like it'd be a great opportunity to show this off to potential users of said functionality by providing it in a working example / prototyping controller that actually uses it as a real-world tool and example simultaneously. Everyone who uses said controller would then know how to (properly) modify it if they ever wanted to change up its behavior. They'd have it right in front of them already.
@willgoldstone Yeah maybe i'm just a simple man, but i was hoping that we get a generic responsive and stable third person character controller assets, extended feature can be added later after the release as an update. Guess that's not gonna happened anytime soon?
Hey all, will spend some time over the next two weeks clarifying everything and get you another decent full update and if not an early drop then a detailed description of what's coming as the MVP of the project, part of what has slowed us down has been scope definition, and as that's on me to fix - I apologise again for the delay to this. Also will be addressing the other questions above, just haven't had time this weekend to jump on, not ignoring the discussion going on here, keep it coming, get back to you asap!
Any news regarding a release date yet ? is an early drop available ?
Im wondering how the work with the "AAA Adaptable Camera" is going and which games you're looking at for inspiration. The camera is very important for third person games and the current standard asset camera controls is really sluggish and quite bad in many ways. It feels way too hard to modify the existing camera when building a new third person camera controller, at least for an amateur/semi intermediate coder. This feature would be amazing, and I hope it's still planned for the release.
Not sure if you've tried it, but Cinemachine is a really great camera system that pretty much does anything you'd want it to do. If you combine it with Timeline Playables, it can do even cooler (gameplay-related) stuff that you probably wouldn't ever expect.
I may be missing something here, but I can't think of a single in-game camera feature Cinemachine can't handle. If you look at some of the earlier demos of it (such as the one with the mouse in it opening a treasure chest), it does third-person cameras extremely well (and intuitively too!)
Oh, haven't looked into that actually! Thanks for the reply, I'll try it out!
Hi folks just checking in for another quick update. We now have a controller we're feeling more confident with. We're refining the cameras tomorrow, and we are also getting a lot better locomotion results and in better shape than when last I wrote you all. Current status -
- Third Person Character - walk run and toggle to sprint in and working, strafe mode also implemented
- First Person Controller - in and working, needs camera tweaks
- OCC (Open Character Controller) - this is our C# replacement for the PhysX Character Controller component. We are making a demo scene that shows how this works abstracted from animation using a capsule so that you can see how this works specifically with its Move and Grounded functionality. As part of the demo scene we'll also provide a setup of the existing CharacterController component so that you may compare and contrast and hopefully understand how to migrate your existing stuff if you so wish.
Expect more news end of the week!
Is that Open Character Controller... open source? Or does the name reference something else?
Really cool work, glad to see you're replacing the PhysX Character Controller. It's been around a while, and shows it's age. I believe someone mentioned on the forums that there still are comments in the implementation that reference Quake?
We're using the CharacterController right now, but movement is very simple as of now, so it'll be easy to switch over. I'll do so right as it's available, and let you know how it works.
I definitely want to hear more about this one.
Is this, by any chance, the "Zelda-BotW-esque" controller we've been hearing hints at? -- Could a decent SM64-style controller be built upon this base-controller?
Definitely a good question, @willgoldstone -- Also, even if it isn't, would the source be modifiable by us, or would we at least have access to change (and even disable and reimplement or override) some fundamental parts of it if we wished?
"Open" sounds very good to me.
@willgoldstone OCC, okay you got my attention. Can we get beta release please ?
I'm currently working with the Invector Basic Locomotion Free third person controller in a prototype, making my own modifications to it. I'm really looking forward to try the new Unity one, also in regards to customization!
Pretty sure it's a character controller where you decide what it is. You give it a move and it will move, just much better than the built in Physx prototype CC:
Such hungry people. The almost-annoying thing about all this is I've finished my own char controller which let me tell you guys something you already know: it's very tricky
Indeed -- imo a character controller definitely needs to be more than a sphere/capsule that has an impulse force applied to it when you press a button. Technically, such a collider could work for very simple cases, but in reality, there's plenty of other problems with that approach. Mainly in very common cases where input, physics, and animation don't jive (which everyone struggles with at some point.) This is especially painful in a naive approach to writing a character controller.
The biggest question-mark to the value of an "open" character controller is how well does it solve this problem -- the intersection of physics, animation, and input -- and for how many use-cases?
In the area where input, physics, and animation collide simultaneously is where such a controller should focus the most effort. I've seen no better solution to this than approaches like the ones taken in SM64, Overgrowth, or BotW.
The "responsive-but-physics-based-animation" approach is exactly why I think BotW is a perfect (modern) example of a truly great (basic) third-person character controller. Its animations are generally based on the movement of the base physics-collider (like the controller in the Overgrowth GDC video I posted above). In addition, the BotW controller also allows for "normal" (absolute) animations too (in certain contexts), letting the designer supply physics-based animations wherever needed (while specifying what animations -- and even parts of animations -- should be automatically handled by physics) while also supplying the movement inputs (to control the physics) that also are to be handled by the controller (while letting the designer "design" any desired overrides of the physics, animation, or inputs, allowing them full control of the resulting movement or animation from any accepted inputs -- such as from inputs based on rules.)
If the controller is too "open", what's the difference between writing everything myself versus using the one provided for me -- especially if it only provides a capsule collider and some "Input.GetAxis" statements that I'll eventually have to change anyway? -- This is the main reason nobody actually uses the current "character controller" in production: its entire approach to physics, animation, and input generally all has to be changed anyway, and there's not enough there that keeps me from not just rewriting one myself (that I have full control over). This is the reason I wanted clarification on what "open" actually means in this particular case -- and I know I'm not the only one.
I do have faith though! -- I'm sure these guys wont let us down!
true, trying to create a responsive character controller giving me headache :s
As promised, an update for y'all.
So we spent a bunch of time with the engineering team and Cinemachine teams working together to find some best practices of how we make sure the characters we ship behave in some of the ways we described, and are extensible for combat scenarios too.
The main inspiration we're looking at for camera control vs player control is a mix of Zelda Breath of the Wild, and Metal Gear Solid V. These games have a truly free look camera (character runs in all directions and can even run towards the camera vs a The Division, Fortnite or Last of Us where the character tends to face camera direction at all times), but snap the camera in tightly to where the camera is looking at the moment of 'aiming' (which becomes strafed movement). One of the challenges we have right now is we're keen to make sure we can support things like locked on aiming - in which the rules of input vs camera direction changes - the player is no longer rotating with the camera, but orbiting an object for example. Like @hippocoder said, this is all tricky.
What I'm hoping we'll get to by end of next week is something playable we can share for early feedback with you all, I can't promise it, as we're discovering new additions and avenues to try all the time, but it's definitely going in the right direction in terms of us making sure its as malleable as it can be for your needs.
Also just to pick up on the questions from @awesomedata - the OCC (open character controller) thing is specifically about the physics - replacing the 'CharacterController' component - I understand this is confusing when we're using 'Controller' to mean the whole asset - animation, physics, prefab etc. But when I say OCC I mean the physics component with its Move and Grounded stuff.
Anyhoo, more to come, watch this space. cheers all!
OCC is what I wish to nibble at. Please give :'(
So about kinematica? will these cross or are the same or competing things?
also networking will this have integration with whatever "New unity multiplayer features" will be eventually called.
Poor @willgoldstone - bet he is regretting being the champion of one of the hardest things to please people with.
That's exactly the kind of clarification we needed -- thanks @willgoldstone !
So since this is going to be physics-enabled, is it possible we can turn off lock-on aiming and over the shoulder aiming (as well as customize its behavior)? It would definitely be nice to be able to have a vanilla physics controller that also has other features such as maybe a "Cover" system (or any other "arc/jump/move/translate to this position/orientation" style of physics controller behavior) when we need them. Entirely overriding the physics (and input controls) at certain points like this will be absolutely critical in any use-case I can imagine for a physics-controller.
Also, would it be possible to grab values directly from the physics controller and throw them in a C# Animation Job so that we can more easily control our animations (and the new input system too?) with the controller at least?
I am not able to use the additional downloads option to download additional assets
The below link says "File not found", same for both MAC and WIN downloads.
Throwing more chaos ...
What about skidding? when we suddenly change direction? I mean it's a specific blend animation/direction control that's kinda tricky to do, specifically allowing turning while skidding. See mario 64 for references.
I think this was handled in Overgrowth by simply tilting the root of the character backwards at its center of mass (in accordance with the actual location of the underlying physics rigidbodies associated with the character's pivot point.)
This reminds me...
Speaking of having a "center of mass" property to check:
As you can see, a "center of mass" property (based on an assignable weight for each limb we'd like to assign weight to) would be vital to have exposed for animation purposes.
That video shows just how important such a concept actually is to animation!
When I say we need this to be part of the default character controller, I definitely mean it. D:
In regards to how to implement a "center of mass" component -- That video explains it very well actually. However, going straight "Humanoid" might be better-served as an "option" than the default/only approach. This is because some "bones" wouldn't care to assign any meaningful weight to the center of mass (e.g. from clothes or hair for example), so these could simply be ignored or "masked out" (i.e. not have any index or weights to check). We could manually add these bones (or the "mask" for these bones) by dragging the bones selection rectangle (visually) from the avatar to a little numerical field in a window to assign their weights all at the same time (for individual limbs/portions of the character.)
These "weights" that contribute to the "center of mass" would be evenly distributed for, say, an arm's entire length. If we wanted to weight the arm at 3 lbs, then we would drag the bones from the arm into a slot beside a number field that's set to 3.0, and it would distribute this 3 lbs of "weight" across the individual bones based on a curve (for example, if the bicep was extremely large, distribution down the bone-chain would be top-heavy and taper down to the hands based on the curve -- and individual bones that are considered "parallel" to each other in local-space would take on the same values, which judging from the Mecanim algorithm, you already have a method of determining nearby bones and the nearby spatial orientations/relationships on an arbitrary rig -- You can just use that!)
From this data we generate (assuming we're using a center-of-mass calculation), we can deal with the animation ourselves.
Humanoids would have this data preset based on how much each part of the average human body weighs -- but with maybe baby/child/adult, weight-amplifier, and gender components to tweak it a bit. This would work for dwarfs, all the way up to the Hulk, and the characters would move responsively and realistically the entire time.
Hi, what is this in reference to? if you're looking for the old standard assets, they are on the asset store.
@willgoldstone when will this be available ? do you have a dates or a beta ?
Any update on this? I'd be excited to play around with this however rough it currently is.
Hey folks we're still trying to get things into a better shape before firing it over to you even in what I'd consider beta form. Sorry for the continued delays, nailing this stuff is tough, even in basic form. We want it to feel good and work in a sensible manner that supports current tech like Cinemachine etc and we're going fast as we're able. Patience please! Will keep posting here soon as I can.
Yep remember folks, it probably isn't on the roadmap. It's just will foolishly dipped his pinky toe into the murky shark infested waters of the forum and now people will hold him to ransom
(And yes controllers are really hard - estimate it took 400 or so hours for mine).
Thank you for the update will
Are you going to have a "walking/running/strafing- bakwards" animation working in the new controller? I remember it werent in the previous one and I had some hard time integrating my own animations in the animatorcontroller. Dunno if the problem was with the animation or animcontroller.
Do you plan on making the controller dynamic I.E easy to add or change the animations in the controller?
It would also be nice with easy access to slope movement limit, I can recall if it was in the previous character, the thought just popped into my head while writing this.
Thanks for your amazing work Will and for not breaking down after all of our questions
We're getting there. And yes we're now fixing our approach to strafe which was initially not where it needed to be - too snappy and clearly wrong in our approach to blending. We're in a better place now and just replacing a few animations - once the strafe is locked down I wanted to get a beta package out to you all as soon as possible so you can stress test it and break it in all kinds of fun ways. As for slope limit yes I am pretty sure we have controls for everything like that you would expect.
I'll post a new thread and link to it here when the beta is ready so you can all feedback in a new space.
You might have mentioned it before, but this beta will be distributed through the packman, right? Will there be any Unity version requirement? Like 2018.2, 2018.3 beta, etc?
Thank you for the update Will! Just in time and can't wait to test it.
Will you fix the download link for 2018 Standard Assets for the mac? All I get is 2017 standard assets from the store and they don't work right in the latest Unity.
Hello Will. Damn, i feel like some hungry wolf walking around in circles but i'm just excited and interested about what you guys made and how it may look like.
Aside the silly question for some little update, i want to share i little experience i made. Last week, i had the chance to play Conan Exiles for the first time and saw a nice feature (not the wiener stuff..) that i figured was a cool gameplay addition. You can climb along walls with your character without having big informations on the wall (it's probably a system were the character "sticks" on a wall that exceeds the slope limit) - You can even jump from a cliff, then pressing space to slide down a wall till you "stick" on it again to climb the rest of the way up down left right (WASD). I'm not saying it should be a must have, but would be nice if we could implant certain systems like this on top of yours. (maybe in a modular way, not sure)
And even this might have nothing to do with your work - but are there any news on the Kinematica front or do you work together with the unit responsible for this biggie?
Thanks and have a good week! Sorry about bombarding you with questions - we stopped our current root-locomotion character development to test our game-pitch with your upcoming solution and probably switch over.
Hey everyone, so a quick update as I'm taking forever to update you and that's not cool.
We've been in major refactor mode for a while and redone a few of our animations that had issues. I've made a quick video that shows you what we have but doesn't get into project and architecture yet as its mid refactor - simple as that. I mostly wanted to prove we weren't kidding when we said we've been working on this! it exists! it's just been in re-make hell for a little while.
So apologies to those of you keen to try this, our most recent internal review a few weeks ago with industry vets in the company suggested we were overly complex, which was impacting UX too (many clicks to simply get the character working in a new scene for example, we want one or two) and also overly complex approach to some of the architecture due to design decisions I am responsible for so - my bad, and we're on way to a less complex approach now, and also now looking at reducing complexity added by need to support the existing input system. Our new input system is nearing Preview status at this point, and so we're planning to battle test it with this project and will know either this week or next if that'll be a success - we don't want to compromise on these assets working across platforms.
Anyway, here's the video - sorry its brief and not my usual standard audio / presentation wise, its just for internal stakeholders and this forum so its scrappy, just wanted to get it out to you asap.
Looking forward to your questions, of which I expect many. Please understand that mid refactor I won't go into detail on architecture - we're looking to ship a polished version of what is in the video, with male and female avatars and solid cinemachine config first. So 'where my climb at?!' is not the best line of question at this stage.
Cheers all, expect more updates soon as we polish and thanks for all your patience so far.
Hi so we're at a point now where we're evaluating moving back to the New Input System which will require 2018.2.10 at least at this early stage, but it's unclear if we'll be able to back port - the new system is so much more flexible compared to the old, we consider this a better approach than dumping something on you guys that has similar issues (the infamous Cross Platform Input) to the old Standard Assets.
@willgoldstone well i don't ask much though, 3 stuff
2. stable ground collision
3. you know that movie "The Extendable"?
Okay i just realize you also have FPS Character Controller. is there gonna be a solution to handle FPS Mesh Rendering (Hand and weapon) that support world lighting and shadow? I know that part are totally out of topic, i'm just wondering.
This look really promising!
My honest opinion is: it looks like you're doing it in the right way keep it as simple as possible to configure and to undestand.
Do not add a tons of genre specific feature which are only going to hurt the asset, just a simple climb/jump thing no inventory, no gun things etc.
Just one request: make it as simple as possible to expande, adding a simple animation should not be a pain in the 4ass and make as much documentation/examples as you can.
Video looks great. Ship it.
One thing you can consider putting in, is a toggleable noclip mode. It's very useful for testing levels.
It looks great! The first person jumping and the timing of the landing roll looked very bland, but those are things that needs to be adjusted per-game, so I think it's best to leave them as simple as they are in the standard assets.
The video shows alot of potential, thank you Will for taking the time to making that for us!
How have you worked since the video in this ~months time?
(enemy shoot and cover and move)
@willgoldstone Is there any new progress there?We're looking forward to see beta release.
Hey everyone, just checking in - we've been working on refining a few things and still have camera issues to resolve. I'm reviewing the project today with the team but we've all been busy with Unite LA and working on our roadmap and other presentations. Sorry for radio silence since the video, more news later today.
Hey @willgoldstone, any update on this? Looking forward to try out the new Character controller
Yes... looking to see if there is an update as downloading the existing Standard Assets seems to not always cooperate with 2018.3b