Another Camera Question
Hiya
So Iev been thru a bunch of the tutorial on this site so far and have a little openGl world and movement set up. Based alot around the lesson 10.
Now so far the movement is setup as the camera is static but the worl moves around it (just like in that lesson)
Is this standard programming? Or would it make alot more sence to havethe world static and the camera move about.
Im wondering what is the benefit of each before I progres further.
If the world gets more complex would not rotating,translating all its elements get resource intensive at draw time?
any help comments welcom
Thanks
-LW
-------------------LordsWarrior-------------------
As i understand it you can do both. Either keep the camera completely static and just translate the gamestate (piece by piece or all at once etc) or use gluLookAt to point the camera somewhere..
I suggest both.. it depends on the type of game you are making. In a side scroller i'd just tranlate the world, in an FPS i'd do both, have WASD translate your character through the world and the mouse to pivot around in gluLookAt
Hope this helps.
I suggest both.. it depends on the type of game you are making. In a side scroller i'd just tranlate the world, in an FPS i'd do both, have WASD translate your character through the world and the mouse to pivot around in gluLookAt
Hope this helps.
-----------------------I wanna know everything....I wanna do something that matters.
speed wise it doesn't matter.
but, having the world static and moving the camera can make moving thing in the world easier.
This is because when you call glLoadIdentity it's still in the corect camera position and not in some nullified camera position.
im not entierly shure it's easy enough, i have to test that a little.
but, having the world static and moving the camera can make moving thing in the world easier.
This is because when you call glLoadIdentity it's still in the corect camera position and not in some nullified camera position.
im not entierly shure it's easy enough, i have to test that a little.
www.flashbang.se | www.thegeekstate.com | nehe.gamedev.net | glAux fix for lesson 6 | [twitter]thegeekstate[/twitter]
gluLookAt is just a utility function that modifies the model view matrix. So there never is a "camera" that you move. Rather, all vertices are multiplied by the model view matrix. So really, either way you do it, it is the world that is moving, not the camera.
-----BEGIN GEEK CODE BLOCK-----Version: 3.12GCS/M/S d->+(++) s+: a19? C++++ UL++ P+++ L+ !E W+++ N+ o++ K? w!O M-- V? !PS PE Y+ PGP t++ 5+++ X R tv+> b+(++)>+++ DI+++>+++++ D++G e>++++ h! r y?------END GEEK CODE BLOCK------
This last comment poses an interesting question for me. When making a multiplayer, fps game, would every player then have their own static camera with their own moving world and the other players' models being simple avatars to depict the relative position of the cameras in the other players' worlds? I realize that the player models would be avatars anyway, but I had never really thought of the world moving around the camera. That would make a lot of sense though.
Yes Im guessing that is correct..each player has the world transform at drawing time.
But each player would have a world translate, orientate variable that would be different.
I guess?
-LW
But each player would have a world translate, orientate variable that would be different.
I guess?
-LW
-------------------LordsWarrior-------------------
how glulookat works can be found here.
It's just some tranlsating and matrix multiplication. glulookat is just a faster way to do it that doesn't involve you messing with the math involved (although the math stillg ets done).
It's just some tranlsating and matrix multiplication. glulookat is just a faster way to do it that doesn't involve you messing with the math involved (although the math stillg ets done).
[size=2]Darwinbots - [size=2]Artificial life simulation
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement