Blogs
 


  Oddworld Forums > Blogs > Manco


Rate this Entry

Quaternion Slerp

Posted 03-28-2015 at 04:00 AM by Manco
After a week messing about with Unity and following various tutorials I’m starting to feel like this is a thing that I could actually start getting good at with enough practice.

The tutorials I’ve covered so far include some essential stuff like how to make your player character move, how to make collectible objects and count them on a GUI, how to make enemies and make them spawn randomly, and even a little bit of how to use raycasts which are basically the workhorse to use for everything from line of sight to platform detection to shooting a gun.

Admittedly, a lot of it hasn’t fully sunk in yet. I can reliably script in basic movement controls but a lot of the more advanced stuff I still need to practice a lot more to get it down pat. This is tough, because most of the tutorials I find just run through the code you need to write without explaining the nuts and bolts of why it works and how to plan out what you need to do.

I found one great set of beginner tutorials where the guy running them would take you step-by-step through each new piece of code, and push you to try and think out your approach and study the documentation for what you need. This approach works really well, but unfortunately he only has a dozen or so videos covering the basics.

The hardest thing is when you hit a brick wall. I spent most of yesterday just trying to get a third-person camera that follows the player without rotating the wrong way if the player stands on a slope, but I couldn’t work out how to do it. This was when I discovered the wonderful terminology in the title – Quaternion.Slerp is relevant somehow but for the life of me I don’t know what it actually does.

Still, there’s nothing that fills you with pride more than seeing your little purple cube running around collecting red and green spheres.
Total Comments 18

Comments

Phylum's Avatar
Is this your first real foray into programming? Or just game programming? As good as the Unity tools are jumping into 3D, like you said, has some huge brick walls that are hard to overcome. Mathematics in 3D space AND designing game systems are very different topics, and learning both at once is pretty stupid in my opinion.

This is coming from the dude who got stuck indefinitely on his OpenGL work when none of my 3D transformation matricies worked. Eventually it got to the point where I understood the API enough that I was just focused on the 3D math and it still never worked :c
Posted 03-28-2015 at 04:16 AM by Phylum

Manco's Avatar
Yeah the only programming I’ve done before this was a basic intro to C# by writing console applications, which gave me an intro to variables, floats, booleans, and if statements; which I looked at right before jumping into Unity. Before then the only coding I’d done was markup.

The math hasn’t been too tough to start, for me the biggest struggle is how the documentation often assumes you just know how everything should work and doesn’t provide a good explanation or example code to help you out. That plus googling for questions about Unity normally just turns up some forum posts with people going “here’s my completely obtuse and uncommented code to do that for you” makes trying to solve problems with being spooned tutorials really tough.

The brick wall for me is less to do with the math and more to do with not being able to figure out which bits of code I need to do something. I can make the game camera follow the player but I don’t know how to alter its rotation, for example.
Posted 03-28-2015 at 04:29 AM by Manco

Phylum's Avatar
In lots of cases you probably don't know how to do these things or understand the Unity functions because you don't understand the math. 3D geometry is complicated. There are still formulas and stuff to plug into, but there's also a level of understanding and conceptualization that hard to wrap your head around.

Unity does give you tools to get around lots of the really complex parts, but like you I found them poorly documented/generally confusing to the point that not understanding how the math worked was still prohibitive to me. Relying on community spaghetti code is very bad practice.

Also learning C# syntax in the context of console applications isn't learning programming.

Unity is good because it can make you feel like you're running before you learn to walk, but you'll hit some limitations as you scale up unless you have more knowledge. You're tackling programming, game programming and (some) 3D geometry all at once. I can only recommend taking a step back and breaking those things down into smaller, easy to learn sections.
Posted 03-28-2015 at 05:51 AM by Phylum

Manco's Avatar
:
In lots of cases you probably don't know how to do these things or understand the Unity functions because you don't understand the math. 3D geometry is complicated. There are still formulas and stuff to plug into, but there's also a level of understanding and conceptualization that hard to wrap your head around.
I think this is partly true, especially for the camera and character movement stuff I’ve been butting my head against, but there’s still plenty of stuff I don’t get because I don’t know what bits of code I need to use to talk to Unity properly. I know what I can use things like triggers and raycasting to accomplish but the tough part is figuring out the right code to use to call those features. Even if I did know more of the math behind it, working out how to translate that into the scripts I need is another step.


:
Relying on community spaghetti code is very bad practice.
Yeah I’ve made a point of not blindly copypasting other people’s code, and instead using tutorials, explanations and the docs to figure out how to make things work.


:
Also learning C# syntax in the context of console applications isn't learning programming.
It showed me how the code is structured and a few basic applications of the fundamentals. That’s enough to get me started.


:
Unity is good because it can make you feel like you're running before you learn to walk, but you'll hit some limitations as you scale up unless you have more knowledge. You're tackling programming, game programming and (some) 3D geometry all at once. I can only recommend taking a step back and breaking those things down into smaller, easy to learn sections.
The trouble is figuring out practical ways to break these down. Learning more basic C# programming would be easy, but how do you break apart game programming and 3D geometry?
Posted 03-28-2015 at 06:43 AM by Manco

Job McYossie's Avatar
I demand pictures of your game
Posted 03-28-2015 at 12:24 PM by Job McYossie

Manco's Avatar




Posted 03-28-2015 at 01:48 PM by Manco

Phylum's Avatar
To learn programming, buy a book on any OO language. Java Concepts by Cay Horstman is fantastic. I'd coded for a few years before then, but it completely changed how I think about structuring programs and solving problems.

Learning game programming comes more naturally once you've generally done programming for longer, because you're not going to have to learn many new tricks to solve problems. Even with something as good as Unity I really don't think diving in to full 3D stuff is the best way to learn.

There are lots of ways to learn about 3D geometry, but a good practical one is probably to incrementally implement a 3D system with functions like QuarternionSlerp() for yourself. This is vaguely what I was working towards with my 3D training, but I got caught up in the rendering for reasons unknown.

Unity is a great tool for making some of the entry-level stuff easy, but bigger projects are still hard and complicated.

It's definitely cool working in an environment that lets you get stuff done though. You have something more interesting to show there than I do from years of programming
Posted 03-28-2015 at 02:13 PM by Phylum

Manco's Avatar
The problem is I don’t really learn anything from books – I have a stack of various “Learn ___” books and I’ve never gotten very far with any of them, and non-interactive tutorials are just as bad. With code I know that the best way for me to learn is by doing – it’s how I started with HTML and CSS and I know I’m pretty damn good at that.


:
There are lots of ways to learn about 3D geometry, but a good practical one is probably to incrementally implement a 3D system with functions like QuarternionSlerp() for yourself.
How would I go about doing that?
Posted 03-28-2015 at 03:50 PM by Manco

Shade667's Avatar
I never learnt the programming side of unity, just the art side. Since very few people can both program and do art (its why developers are split into artists and programmers, with very little overlap).

I dont understand alot of what ur saying, but I understand enough to kinda visualise whats going on. Looks good so far.

Can you link those beginner tutorials? I migth want to make use of them in the future.
Posted 03-28-2015 at 04:00 PM by Shade667

Manco's Avatar
It’s the tutorials linked in this thread on the Unity forums – they’re very basic scripting concepts and they’re not the most polished or professional videos, but the guy has a talent for breaking down code into manageable chunks and telling you what each part does, and they’re very interactive tutorials too.

It’s best to go through them in the order they’re linked, as each video builds on what you learn in previous ones.
Posted 03-28-2015 at 04:09 PM by Manco

Shade667's Avatar
Ill keep it in mind when I get a computer.
Posted 03-28-2015 at 04:33 PM by Shade667

Phylum's Avatar
I've never learned anything from a book titled "Learn X" either.

There are plenty of bad instructional books in the world, much like anything. If you intend to learn programming solely from videos you might run into problems - I've learnt from them but 90% of my knowledge comes from written articles and books. I'm sure the quality and quantity of videos is getting better each day though, so I might just be out of touch with the current state of things.

:
How would I go about doing that?
My method for learning 3D was to start with rendering, and get my head around the mathematics of that because there are a lot of matricies and vectors. It was kind of like a refresher from highschool, with some new "matrix formulas" added in for standard operations. Obviously before I could do that I had to work through some basic OpenGL tutorials, and more or less copy and understand code by wrote to get the feel of how OGL actually works. Working with a Java binding turned out to be really good, because some things didn't translate well from the C examples to Java so I had to do some really weird problem solving, which even involved delving into the source code of the library once or twice. One I had that under control, I stepped away from the tutorials and designed my own basic OpenGL system, which worked in 2D but failed for reasons still beyond me in 3D. My knowledge of the OpenGL systems let me do all kind of cool things, like hack in fixed vertecies for a cube that was displaying incorrectly, and then colourise them by their 3D position (x, y and z >>> r, g and b) to double check everything was working (it was). At that point I would have had the API and the rendering mathematics under control, and I could gradually implement more and more functionality with rotations and stuff.

Basically you could implement a system like that in Unity but it would be cumbersome and pointless. If you don't need to actually write your own OpenGL renderer for a project like I did you can just find a 3D rendering library and code things around that.

Alternatively just google for articles on 3D geometry in games and read them. It's hard to really take that stuff in without your own hand-written playground to test things out, in my experience at least. Still reading about how people design systems like the one in Unity couldn't hurt your understanding, even if you don't take in every line and every bit of maths.


Either way I don't want to discourage you, and I'd hate to think that I'd done that with any of my posts so far. Just my 10c on learning this stuff, and learning in general really. 3D game design is complicated, but if you enjoy noodling in Unity then noodle away. It may not be an efficient way to learn, but you'll find ways to learn what you need to over enough time.
Posted 03-28-2015 at 07:47 PM by Phylum

Shade667's Avatar
Learning from books is the same as watching a tutorial. Only difference is one is audio, and one is text and pictures. Theyre both presenting knowledge in the same way.
Posted 03-28-2015 at 10:31 PM by Shade667

Job McYossie's Avatar
No they are not.
:
Only difference is one is audio, and one is text
for many people this difference is HUGE. Reading a book for some people just doesn't do it because even though the raw information is being presented it doesn't quite click just with words. Being able to SEE an example can make a world of difference for some people.
Posted 03-28-2015 at 11:43 PM by Job McYossie

Shade667's Avatar
Both are the same for me. I need someone there next to me to learn effectively. If I hit a wall, audio doesnt help me more than text.



(I hate forgetting that i have to type this twice)
Posted 03-29-2015 at 12:03 AM by Shade667

Manco's Avatar
:
Either way I don't want to discourage you, and I'd hate to think that I'd done that with any of my posts so far. Just my 10c on learning this stuff, and learning in general really.
Well I’m a little confused now because in one post you told me not to run before I can walk, and in another you tell me I need to figure out how to build my own 3D rendering system. I have to be honest, that sounds crazy hard and I don’t see how it would be more helpful than learning about the theory and applying it to existing 3D software.


:
Learning from books is the same as watching a tutorial. Only difference is one is audio, and one is text and pictures. Theyre both presenting knowledge in the same way.
Allow me to introduce you to Neil D. Fleming’s VARK model. I’m a V-K combination learner.
Posted 03-29-2015 at 01:17 AM by Manco

Phylum's Avatar
Oh, I was just describing my plan for learning the math behind it. I didn't mean that was the only way! There are much better ways for people who don't need to roll their own renderer for a really specific project. I think I was just trying to describe my thought process of breaking it down into steps.

e: I've been thinking a lot lately about how people learn, and how to teach things to people, as well as how to break bigger tasks down into smaller pieces. Basically everything I've posted here is born from crazy, partially-formed ideas that are trying to jam their way out of my fingers.
Posted 03-29-2015 at 01:44 AM by Phylum

Manco's Avatar
Ah, that makes a little more sense then! I think I’ll be looking into learning some of the core math behind 3D then – I’m familiar with the concept of the X-Y-Z planes and some of the basics surrounding that, but after watching some more Unity tutorials it’s pretty obvious that I’m going to need to know more about Quaternions and cross-products to really get where I need to go.

I found a tutorial with a very thorough implementation of a 3D third-person platformer camera (styled off Wind Waker) and there’s no simple solution to it – the basic gist of it was that you need to work out the direction the player is facing versus the direction the camera is facing, and based off that adjusting the tilt of the controller thumbstick would determine the direction the character moves in relation to the camera. It was pretty slick, but requires way more math than I initially thought it would.
Posted 03-29-2015 at 02:30 AM by Manco

 

Recent Blog Entries by Manco





 
 
- Oddworld Forums - -