Thyrosis, think about it this way. We'll start off with the router. So someone arrives at your URL looking for a blog post. The router nudges the blog controller and says, "Oi someone want a blog post. You can find the post ID here." The controller grabs the ID then goes to the blog model, and says, "Hello blog model, can you see if you can find this blog post for me please?". The blog model takes the post ID from the controller, runs it under the tap to clean it off (just in case someone stuck a bogie on it), then it looks for the post in the database. The blog model finds the post data, grabs it, grabs all the info associated with it, then asks the user model to hand over the info for the author of the blog post. Then it sees it needs to get the user's avatar image too, so then the blog model goes to the image library and asks it to check if the user's avatar file exists, and to create a URL to it. The image library is only too happy to oblige. The blog model now has everything the controller expects, and so it packages it up into an array, and says, "Here you go blog controller. This is all the blog info." The blog controller grabs it, says "Thanks for that mate!" and shakes the blog post view and says, "Oi view wake up! You need to show this to a visitor. Take this array and render your stuff!". The view takes the array and renders it's stuff, and they all live happily ever after.
So you can see the proper relational use between MVC here and also the involvement of other libraries you may have created to do specific tasks that could be re-used in other applications.
While that is the intended way of doing things, CI is very flexible, and doesn't force you to do anything. If you wanted to, you could have done everything, including displaying the HTML output with just the controller, but there wouldn't be any point in using CI at all if you were to do that.
