***At the end I contribute to the theory of the tutorial*** Primitives can be defined with pretty simple formulas, formulars similar to what you would use to define them for a raymarching renderer, and the simpler that formula is, naturally the less CPU cycles will be spent, and the simpler the operations involved in the formula, the less "intensive" those cycles are on the CPU, for example division used to be really bad, nowadays you can get away with just about anything with certain limitations, but division, sine waves, and other stuff needs more time to be computed than say adding or multiplying, even if the CPU as in the hardware itself has in it's instruction set dedicated commands for those it's gonna be a bit slower, and you also have to account for the fact we're using C#, which is compiles to MSIL, or just IL if on a platform that's not based on the Windows kernel like any Linux based system or MacOS, IL isn't machine code, it's still binary, but it's interpreted, basically part of the .Net Framework is a very *very* important program that basically runs your IL code that got compiled from either C# or Visual Basic (yes, they're interchangeable for the most part, except Visual Basic lacks lots of features C# does have, like unsafe code), now of course Unity has it's own interpreter, it currently uses Mono which is basically an open source version of .Net Framework that you can use on any platform, not microsoft assosiated, it's by the community, but it's still the same thing, when you compile a C# or VB program, you get an EXE file, the only machine code that file contains really is just for running the interpreter, and it's a tiny snippet of code, the rest of the file is actual IL code that the machine code part of the file specifies to the interpreter, the interpreter's job is, as the name implies, to read the IL code raw, then once the interpreter has read the bit of code it needs currently, say Program.Main(string[] args) method, it then executes a method in it's own code, which is machine code that the CPU can actually understand since the interpreter's written in C++ which well compiles to machine code, this takes a ton of CPU cycles to do, which is why Unity has the IL2CPP compiler which translates your C# code, along with all of Unity's APIs, into raw C++, it also gives you an entire C++ project file, that is essentially Unity and your own code but translated to C++ AND optimized, pointers and everything, along with any asset or anything the project needs to include, and Unity will compile this manually to a project that's written in machine code rather than IL, this significantly increases performance for CPU heavy games, but also takes longer to compile. I know I went on a tangent there, but since we're talking about performance I couldn't help but bring it up. Anyway back on main topic, mesh colliders need much more complicated maths to solve them, you can't just adapt signed distance functions, what if the mesh isn't solid, i.e. has a hole in it? They need to be solved on a per triangle basis, and there isn't really an straight forward way to tell if an object is inside the collider unless it's explicitly gonna be overlapping the surface, since again it may not be solid, if you really want to do mesh colliders, I recommend reading the paper linked at the bottom, it's on a technique to take a triangles mesh and get as an output a signed distance field formula, which you can adapt to make your own "primitive" collider type, but I wouldn't recommend doing that at all, not unless you're gonna optimize it for multi-threading AND everyone who's gonna be running it will do so on next gen Threadripper CPU's oof. TLDR; Meshes can't be hardcoded like primitives such as a cube or a capsule, so they need precomputations for PhysX engine to know how to use them(which is why Unity uses internally, they bought a license for Havok which is a much better engine although it runs on the CPU and not the GPU so it can be more costly to performance, there's a package or something out there for that but by default you get PhysX) and not only that but the mesh can be complex, which in itself means it needs more computations for good collisions. Also don't quote me on Unity using signed distance fields, there's many ways you can go about it, but distance fields are the most comprehensible example so I went with that. If you wanna do real collisions, don't mark your collider as a trigger because triggers are for triggering snippets of code that do something like say finishing a level or activating an automatic door, in fact don't do that with enemies in general, unless you wanna go through them for X or Y reason like say they're made of water or something, and don't use OnTrigger events, use OnCollision events, same as in the tutorial, just replace Trigger by Collision, also as an argument instead of a Collider variable, use a Collision variable, Collider is the Collider component that you added to the object, Collision is a class that contains references to all the objects with a Collider component you're colliding with *if* you have a Collider yourself. From there you can implement your own code for Newton's third law of motion dynamics, but it's much easier if you just add Rigidbody components to both the player and the other object which could be anything, say an enemy, well you don't need to add a Rigidbody to both, if the second object is say a wall that won't be moving, you dont need to, as long as it's not set as a trigger, it'll repell the player and not be affected itself. You can code your character controller to work with Rigidbodies instead of just the Transform, since we're gonna be dealing with physics, you gotta do it in FixedUpdate, which happens every physics cycle and is designed to be called at a fixed rate to prevent jittery physics, for physics cycles, consistency is generally more important than cycles per second, hence the name, Update by contrast, happens every graphics cycle, where consistency is still more important, but not so much and not always, you typically cap it to 30, 60 or 120 cycles per second to prevent jittering, but leaving it uncapped is generally fine. Also in FixedUpdate, use Time.fixedDeltaTime instead of Time.deltaTime, and don't provide it to the Rigidbody in any way, that'll just slow it down a ton because internally it already accounts for it, you will typically use delta time for timers and stuff when you're doing physics. To use the Rigidbody you use functions like AddForce or you set manually the velocity property of it, and usually set it to kinematic to explicitly tell Unity that it should not compute the physics all the time for this Rigidbody, and that it'll be controlled via script. TLDR; For collisions with solid objects, don't mark your colliders as triggers, and make sure at least one of them has a Rigidbody component, and also to control a player with physics control the Rigidbody, not the Transform, and do it in FixedUpdate, and use fixedDeltaTime if you need a delta time. PD: To make a collider of a complex mesh using the simple primitive types for performance's sake, just add multiple Collider components to your mesh and mess with the sizes, radiuses, and positions and what not, haven't tested it but that's in short how you'd wanna go about it ***Links*** Here is the paper I was linking: www2.imm.dtu.dk/pubdb/edoc/imm1289.pdf Docs on some things you need for non-trigger/solid-object collisions: docs.unity3d.com/ScriptReference/Collider.OnCollisionEnter.html docs.unity3d.com/ScriptReference/Rigidbody.html docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html Unity's IL2CPP compiler and it's usage of .Net docs.unity3d.com/Manual/IL2CPP.html docs.unity3d.com/Manual/overview-of-dot-net-in-unity.html The architecture of .Net and CLI's in general www.guru99.com/net-framework.html Collision with signed distance fields and with meshes: www.cocos.com/en/building-collision-detection-using-signed-distance-field gamma.cs.unc.edu/MRC/MRC.pdf

@@IchigoFurryModder bro this has more information in a youtube comment that some long tutorials, read through it all, thank you!

​@@yotam8267 When I do explain something to detail, I like to be very thorough if I'm able to, you should see me when I talk about anything Devil May Cry haha -also just to clarify I'm actually a girl- and I mention it because I'm gonna be commenting on these tutorials like this when I can, and did so in the last three too, I mentioned it the other day too.

@@IchigoFurryModder Nice! But... I don't think most of the people here go that deep. Don't get me wrong - this is some decent piece of information. Working in IT for over 13 years, I've learned to provide people with the simplest information possible - that's what they expect. Anyway, I appreciate your input. Thanks!

@@TheKnightDark That's fine an all, but I think if someone's learning programming to any extend for an actual long term job or just project, it's important to learn the little things so you don't have any problem with anything, if you get deep at least into the basic theory of the inner workings of the algorithms you're using, then you can understand the API very well and ultimately make the best use possible and prevent any kind of issue, and optimize if you need it, like say if you're doing post processing shaders yourself, you'd wanna know the different types of shaders supported by DX, OGL and also Vulkan if you're one of those insane people (joke, no offense intended to anyone using Vulkan, but it's seriously a very confusing to be honest), because well you don't wanna use a fragment shader for post processing if you can help it, a compute shader would be ideal to be able to use thread groups so you can basically render the effect in tiles where each pixel shares the same memory block, which is good for things like say bloom or effects that use some sort of edge detection like sub pixel morphological AA, but that's just my personal opinion on learning anything seriously, even if you're not gonna be writing your own physics engine for instance, it's useful to know how it works internally, the theory of it at least, that's just me, also explaining things deeply prevents confusion, and I reiterate, this is just my personal opinion.

no

Thank you! I'll do my best :)

How about a shield?

Just in case you still have this problem, Colliders and triggers can be enabled and disabled during Gameplay with code or animations

Hahaha, I wasn't planning on it. I'll think about it though. Q&A is probably long overdue. We'll see :)

kaç cm?

yeah me too what

This may is two years late, but the way I went about it was adding objects that are children to the bones in unity. This requires unpacking the model in the scene though, so based on your progress this may not be possible. The objects will move with the bones and should support iks.

It's still not a collider hardcoded into a component, it's arbitrary as in that it has to load it from somewhere, it isn't just defined in the source code like the primitive types which are still simpler anyway, so it still has to precompute at runtime the necessary information to do proper collisions with it, and since it's an arbitrary mesh there's lots of things Unity has to check and account for before passing it to PhysX to do the actual collisions, for example, what if the mesh has a hole in it, what if the normals are pointing inside rather than outside, or if they're messed up in some way, some pointing inwards and others outwards? If it does how would you go about checking if we're inside the mesh's *volume* when we're not overlapping the *surface*? And just in general, the primitives are extremely simple and you can use something like signed distance fields for example to improve performance since you can and probably will hardcode it (Unity did), to do that at runtime with a custom mesh is unholy inefficient, and just in general the maths involved are much more complicated than with an sphere that is defined only by a position and a radius, how do you mathematically define a character even if it's super low poly? It's much better to use multiple primitives if you really want a custom shape, you won't be able to animate a single collider in any remotely efficient way anyway (as in deforming the actual mesh, not messing with the Transform component, that's a trivial task), unless you use signed distance fields which again is a pain both for you and your CPU, for more details check my reply to the pinned comment.

where he puts print("enter") this can be swapped out for any code you want and the interaction should happen.

Also if you wanna move stuff by hitting it with something else, like a bullet or the player itself, you use OnCollision events rather than OnTrigger events, see my reply to the pinned comment for more details, no code provided but the theory's there, it doesn't take a genius to write your own code if you understood the tutorial just fine.

@@IchigoFurryModder I totally understand the concept, it's the application that kicks my butt haha. I'm just not used to Unity. I'll check out your pinned comment though. Thanks!

You're in luck. You just gotta use rigidbody movement. I have a script for you with comments in it to help you undertand it, and instructions to use it. Have fun! using System.Collections; using System.Collections.Generic; using UnityEngine; public class PlayerController : MonoBehaviour { public new Rigidbody rigidbody; // Using new because otherwise you get that ANNOYING inspector message warning us that we're hiding a DEPRICATED property. Don't let "new" confuse you. public new Camera camera; public LayerMask groundCheckMask; // You'll notice that every gameObject has a value at the top of the inspector called layer. A layerMask can differentiate between different layers so that we can do something different depending on the layer of something. public float walkingSpeed = 5f; // Measured in meters per second public float runningSpeed = 10f; // Measured in meters per second public float jumpHeight = 1.1f; // Measured in meters public float lookSensitivity = 300f; // Measured in: inconsistent. It really depends on your own mouse and it's sensitivity public float jumpCooldown = 0.1f; // Measured in seconds. private float timeOfLastJump; // private means it won't show up in the inspector private const float gravity = 9.81f; // Measured in meters per second square (That's the SI unit of acceleration). Const stands for constant and means this variable can never be changed. private float xCameraRotation = 0f; void Start() { Cursor.lockState = CursorLockMode.Locked; // This means the cursor will be locked to the center of the screen. Cursor.visible = false; // This means the cursor will not be visible } void Update() { #region Movement bool leftShift = Input.GetKey(KeyCode.LeftShift); bool spacebar = Input.GetKey(KeyCode.Space); Collider[] supports = Physics.OverlapSphere(transform.position - transform.up * 0.6f, 0.45f, groundCheckMask); // Sorry if this is // confusing. Read the unity documentation on Physics.OverlapSphere. It basically makes an imaginary sphere and checks if // anything would collide with it. Then it returns an array of all the colliders. bool isGrounded = supports.Length >= 1; Vector3 localMoveInput = new Vector3(Input.GetAxis("Horizontal"), 0f, Input.GetAxis("Vertical")); Vector3 moveInput = transform.TransformDirection(localMoveInput); // We must convert our localInput to worldInput because if // our player is rotated, we need to move forward in the players forward. Vector3 moveDirection = moveInput.normalized; // Normalizing our move direction is VERY important because normalizing makes a // vector have a magnitude of 1, so we can't move faster when going diagonally. If you're confused, watch Sebastian Lagues // video about Vectors on KZfaq. Vector3 velocity; if (leftShift) // So if we move while holding down shift, we will move faster { velocity = moveDirection * runningSpeed; } else { velocity = moveDirection * walkingSpeed; } rigidbody.MovePosition(transform.position + velocity * Time.deltaTime); // rigidbody.MovePosition is like transform.Translate // but it doesn't let you move there if something is blocking your path. float timeSinceLastJump = Time.time - timeOfLastJump; // Time.time is the time in seconds since the game started. bool jumpCooldownOver = timeSinceLastJump >= jumpCooldown; bool jump = spacebar && isGrounded && jumpCooldownOver; if (jump) { Vector3 jumpVelocity = new Vector3(0, Mathf.Sqrt(jumpHeight * -2f * -gravity), 0); // This is just how physics works. This // is just the formula for jump height. Mathf.Sqrt returns the square root of a number. Vector3 supportVelocity; if (supports[0].attachedRigidbody != null) // The thing we're standing on may or may not have a rigidbody so we check // and then use its velocity if it has a rigidbody and use 0 if it doesn't. { supportVelocity = supports[0].attachedRigidbody.velocity; } else { // Vector3.zero means new Vector3(0, 0, 0). supportVelocity = Vector3.zero; } Vector3 newVelocity = jumpVelocity + supportVelocity; rigidbody.velocity = newVelocity; timeOfLastJump = Time.time; } #endregion #region MouseLook Vector2 mouseInput = new Vector2(Input.GetAxis("Mouse X"), Input.GetAxis("Mouse Y")); // Gathers mouse input Vector3 lookVelocity = mouseInput * lookSensitivity; // Multiply by look sensitivity so if the sensitivity is higher, // the lookVelocity will be higher Vector3 lookMoveAmount = lookVelocity * Time.deltaTime; // Remember, anything that we want to happen overtime and not // instantly should be multiplied by Time.deltaTime xCameraRotation -= lookMoveAmount.y; // When you do + instead of - the look is inverted for some reason xCameraRotation = Mathf.Clamp(xCameraRotation, -90f, 90f); // This is so we cant look more than 90 degrees up or down camera.transform.localRotation = Quaternion.Euler(new Vector3(xCameraRotation, 0f, 0f)); // Quaternion.Euler is to // convert our vector3 rotation to a quaternion(which is how unity actually stores rotations). transform.Rotate(Vector3.up * lookMoveAmount.x); // Vector3.up means new Vector3(0, 1, 0). This is so we only rotate // on the y axis #endregion } } Okay so to use this: Step 1: Add a capsule gameObject to your scene and name it "Player". Step 2: Create a new C# script called "PlayerController"(It's important that you give it that exact name), and add the script onto the player. Step 3: Copy-paste my script to the PlayerController script. Step 4: I'm sorry about line 78 to 81. KZfaq automatically changes my copy-pasted code to that. Just replace that with this: supportVelocity = Vector3.zero Step 5: Parent the Main Camera to the Player, and set its local position to (0, 0.5, 0). Step 6: Add a rigidbody to the player and check off every rotation constraint. Step 7: In the Players PlayerController component in the inspector, assign the camera to Camera, and the rigidbody to Rigidbody. Step 8: In the inspector, at the top where it says "Layer", click that, then click "Add Layer", add a new layer called "Player", and set the layer of the player to be "Player". Step 9: In the PlayerController component of the player in the inspector, where it says "Ground Check Mask", click that and then check off every layer except for the "Player" layer. Step 10: Read through my code, I put in a lot of comments to help you understand it. Step 11: Enjoy your working first-person player controller.

I'm not *entirely* sure I understand what you're talking about, but here I go anyway: To animate colliders like that for say a sword that's moving, you basically setup a collider as a child object, and you can reference it in your MonoBehaviour to animate it via scripting, or attach it to a bone for skeletal animations, there's not really an efficient way to deform the mesh of a collider, since for collisions it needs some precomputed data specific to the mesh, and if you deform it then that needs to be recomputed and doing that every frame is *really* bad, this isn't counting Transform component's parameters, those are trivial. To deal an specific damage per collider, you can make a TriggerMetaData MonoBehaviour, and when something that it will deal damage to hits it, that object will take data from that MonoBehaviour that just contains data like the specific amount of damage, or type of trigger, you'd typically do this in OnTriggerEnter, or if neither collider involved is a trigger, OnCollisionEnter instead. To do a QTE you're basically gonna pause the player's main script, maybe by disabling it directly, depends on your needs, and you wanna play an start animations, and check for some input and play an animation maybe with an speed depending on that input, and then play another animation for the end, except you'd do two animations, one for Kratos and one for a zombie, and that's the basis, depending on that input you can choose a different animation, just make sure all of the animations fit with that looping animations, and you can repeat this multiple times for longer QTEs with lots of branches and stuff.

@@IchigoFurryModder This was kind of 4 questions that I should have asked separately because each of these have complex answers, so thank you for responding. You answered my questions about complex hitbox systems, animating them and QTEs. My third question was about "finishers" such as kratos ripping apart an enemy in half or a Fatality as done in mortal kombat. How exactly do I go on about that? The animation seem to be super flawless- especially what happens after (like resuming the game), and I was curious how I would implement that idea. Essentially, it is like a "staged event" and here's the link to such an example from God of war 4: kzfaq.info/get/bejne/qsd9l7SU1Keop5c.html. Just a heads up, these are super brutal, so if you have a weak stomach, maybe just say something in the comments and I'll find something more suitable.

​ @Truce Feud Well, really the animation for a finisher in say your Kratos example for instance, you will swap out the mesh of the zombie for a ripped version, in your 3D software of choice , you can use the knife tool to mark in the topology where they'll be ripped, and split the two halfs and fill the holes, and then animate that, probably will need a separate rig, but the idea is that you want the two pieces joined together to be as similar as the full mesh, the transition *cannot* be perfect, but even so, if you do (or your artist does) a good enough job it will barely be noticeable, you can hide the seam in the swap of the mesh with particle effects like drops of blood, and for the animations, it's basically the same concept, you make a separate rig for the ripped mesh that will allow you to move the two sections apart and whatnot, and have it be as similar to the original rig as possible so you can seamlessly swap it out and use practically the same animation in an ideal scenario. After the event is done, you don't need to do much of anything complicated, you want to have an exit animation that ends in a frame that fits the first frame of your character's idling animation, and you just play that, and once it's done then you resume the player behaviour and reinitialize GUI and whatnot, oh also, you wanna animate not just the rig, you don't wanna move the rig anywhere, just rotate stuff around, to move your character you wanna animate the actual object that has your player behaviour, this way when animations like this one finish, the player won't appear to be somewhere they actually aren't and then snap to the proper position and other weird behaviours that you don't want that unless you're making a game for a game jam where the theme is intentional glitches, and that's that, it's mostly the artist's job to make it look good really.

@@IchigoFurryModder Thank you.

Your computer shouldn't be a problem for 3D modeling or Blender. And my first game was made on a Surface Pro 2, so I believe you can still make cool stuff even if you don't have the best machine. Depends on your goal. Do you enjoy 3D or are you more interested in programming? If you like to code then Unity will give you more satisfaction. If you enjoy 3D more, Blender is where I would start :)

also thanks for the tutorial :)

Quite simple: Vector2 input = new Vector2(Input.GetAxis("Horizontal"), Input.GetAxis("Vertical")); if(input.magnitude => 1.0f) input.Normalize();

@@IchigoFurryModder Yes I know how to do it of course. There’s just a lot of beginners watching and it’s pretty easy to make the mistake of not normalizing movement, so I want him to address it.

That's one of the reasons I made a wrapper for the input system, where I internally normalize it so I don't have to worry about it, I also have an animation curve for dead zone control.

@@IchigoFurryModder You know, I don't think you should normalize your input variable, that should just be the pure input. Instead make a seperate vector2, called direction, and set that equal to input.normalized. It's best to keep the names of variables matching with what they should contain, and to change things, don't corrupt those variables, just make new ones.

Thing is, I'm explicitly working only with inputs that realistically need to always be normalized if they happen to be a length of 1 or more, I'm not yet doing anything with the mouse, but when I do I can handle it that way, it's quite trivial with my setup, just a bit annoying because I have to go through one or two hoops with the new Input System package since it has so many features, most of which I'm realistically not gonna use.

What do you mean by taxing ? Also if you could answer another question, why do we use capsule collider for characters Instead of mesh colliders ?

It does actually

No it doesn’t

We're almost done with the Unity series. Just a few more videos and we'll be back in 3D :)

@@TheRoyalSkies I'm talking about his ad's that come up on game Dev videos, haha.

Not everyone, I certainly am, I'm pissed that I can't set the render scale to 4 or even 8, and it's *internally* capped to 2

You liked the comment, DOES THAT MEAN YOU’RE GONNA DO IT???!!!!!