Hi guys.

I would like to ask one thing. I have nearly finished the Learning 3D Modern Graphics Programming Tutorial (http://www.arcsynthesis.org/gltut/index.html). I have started to gain a strong foundation Open GL and would like to become more advanced with Open GL. But i am still not a level where i can begin 3D game development. So before i finish the tutorials i wanted to ask some questions since the people on this site provide excellent information and support.

Questions:

1).If i want to create a model loader, how would i create a shader for each one of them?

2).If i wanted to load keyframe animations which have different files, would i have to enter the vertex data for each mesh that does the animation or would i have to use a library?

3).Does Assimp support keyframe animations?

4).Are there any other model loaders/3D animation libraries other than Assimp which are more simpler to use or are better documented?

5). If i include input and i want Open GL to move the model, would the algorithm go something like this:

C-Stands for Command.

C0).Idle State

C1).Input

C2).Checks if a key is pressed or not

C3). If true then checks which key is pressed if false then go back to C0

C4). Checks which key is pressed.

C5). Left is pressed.

C6). Initiate the move action for the left button.

C7). Tell Open GL to move the mesh

C8). Checks how many co-ordinated to move.

C9). Open GL moves the mesh

C10). If Button is still being pressed then continue moving the mesh if false stop moving the mesh.

Sorry if some of these questions confuse you?

1) You should not make shaders assume a one-to-one relationship with models. A model should be able to use the same shader as another model. You'll also combine multiple shaders into a single shader program. And you may wind up using more than one shader program for a single model, especially if you're doing multipass rendering.

2) I don't understand what you're asking here. Keyframe animations smoothly transition from point A that you provide to point B that you provide using time elapsed divided by total time required for transition. It shouldn't be a problem if point A and point B are in different files before you read them into your program. I can't answer what tool you should use other than to say use whatever you feel is best given your restraints and the rest of your toolset.

3) I'd imagine Assimp supports keyframes. Doing a quick google search, it looks like you'd use struct aiAnimation. I don't actually use Assimp though, so this is a guess.

4) If you don't like Assimp, try something else. There are definitely other options. Without knowing why you think Assimp is hard to use and has poor documentation, I can't really make a guess what would fit better. You could also just write your own import code. Model formats are really trivial to parse.

5) You don't tell OpenGL to move things. Generally, you would update your model matrix with the new position for your model, then that new position would get reflected on the screen when you multiply model * view * projection.

1) You should not make shaders assume a one-to-one relationship with models. A model should be able to use the same shader as another model. You'll also combine multiple shaders into a single shader program. And you may wind up using more than one shader program for a single model, especially if you're doing multipass rendering.

2) I don't understand what you're asking here. Keyframe animations smoothly transition from point A that you provide to point B that you provide using time elapsed divided by total time required for transition. It shouldn't be a problem if point A and point B are in different files before you read them into your program. I can't answer what tool you should use other than to say use whatever you feel is best given your restraints and the rest of your toolset.

3) I'd imagine Assimp supports keyframes. Doing a quick google search, it looks like you'd use struct aiAnimation. I don't actually use Assimp though, so this is a guess.

4) If you don't like Assimp, try something else. There are definitely other options. Without knowing why you think Assimp is hard to use and has poor documentation, I can't really make a guess what would fit better. You could also just write your own import code. Model formats are really trivial to parse.

5) You don't tell OpenGL to move things. Generally, you would update your model matrix with the new position for your model, then that new position would get reflected on the screen when you multiply model * view * projection.

Thanks for the reply. I Aprreciate your help.

On question 2 i think i confused myself here as well . i think it is more to do with using a library than Open GL.

I have been to the Assimp website and i find it kind of confusing on how to use their library since it is not very beginner friendly.

I am looking for something else than Assimp however when i google search Open GL model libraries i mostly get Assimp and Collada which i do not know how to use them even though i have looked through the documentation, which still confuses me.

At question 5 thank for explaining things on how i would move a model.

I have started to gain a strong foundation Open GL and would like to become more advanced with Open GL. But i am still not a level where i can begin 3D game development.

Just to remember: OpenGL is a low level graphics API, implemented by your graphics card driver. A game consist of much more than graphics. So, mastering graphics helps with the "eye-catcher part" but doesn't automatically mean that you can write a game.

5). If i include input and i want Open GL to move the model, would the algorithm go something like this:

A game loop is build differently from an application event loop. While the latter one is constructed with the intention to let multiple processes and applications running at a time, a game is intended to take over the machine's resource for best performance. This means especially that it usually does not wait for events (i.e. there is no idle state) but simulates the world all the time. Search the forum and the internet for the keyword "game loop" to find more details.

5) You don't tell OpenGL to move things. Generally, you would update your model matrix with the new position for your model, then that new position would get reflected on the screen when you multiply model * view * projection.

This, except that the order should be "projection * view * model" in OpenGL.

I am aware Open GL is mainly for the graphics and that there are many more things then just the graphics in a game. But Graphics are the first thing to building a game so that is why I started with Open GL. I know that a low-level graphics API is not enough to make a game at all.

I am going to be using Open GL(Including GLEW,GLFW,GLM etc.) + Bullet Physics + CEGUI + Gainput to make a basic third person camera game that i will use as a base for my game, i will later upload it on this forum if anyone wants to use it.

I have one last question though. Out of a 100%, how much of Open GL code goes into a graphics intensive-game?

Thanks for the questions though they helped me not get confused.

But Graphics are the first thing to building a game so that is why I started with Open GL.

You may do so with respect to the implementation, but you must not do so with respect to planning. This is because the rendering pipeline must be designed with the overall structure in mind. How to delimit the graphics rendering sub-system to the others? Do you want to use graphics rendering jobs or direct rendering? If the former, do you want to use double buffered rendering queues? This and similar stuff define how the rendering need to be implemented.

Out of a 100%, how much of Open GL code goes into a graphics intensive-game?

"Graphics intensive" is not expressive; it just means that you want to use less textual representation. There is no mention of AI, multi-player possibility, input device support or configurability, animation system (besides you seem want to use rigging), the story, or other things. Not to mention that also inside graphics a wide range of possibilities exists: Forward rendering or deferred rendering, PR vs. NPR, material layering or not, what shadow method, … In fact I assume that nobody can give you a halfway exact estimation for your game.

Sorry for the vague questions that i have said. I should have said how much out of a 100% Open GL code goes when creating a 3rd Person game with 1 Actor wich can move around and jump around a plain map.

I want to create a base for my game so that later i can add more things to my game.

Currently i will be using Open GL with:

-Gainput ( Input ).

-Bullet ( Phyiscs ).

-SoundTouch ( Audio ).

-Life AI ( A.I)

Currently what i am searching for is a:

-Model Loading library other than Assimp.

-3D Character Animation Library.

However, i will start with creating my game after learning more about computer graphics and Open GL.

You'll spend very little time on input unless you're doing something crazy.

You'll spend just as little time on audio. You just send the sound when you want it to start.

Physics can take up a lot of time or minimal time. It depends how realistic you are going to be, what objects you're applying it to, etc.

AI will probably take quite a bit of time, especially when you lump in pathing and everything else.

Graphics consume as much time as you're willing to give.

Your physics will never be 100% accurate, your AI will never be as smart as it could be, and your graphics will never be as pretty as they could be. All three of those have no end, so set yourself very clear goals so you have an end to the work.

You might also try using an engine instead of doing everything yourself. I think Unity is the popular choice. If you think that might work, I'd recommend a new thread in the proper forum (not OpenGL).

You'll spend very little time on input unless you're doing something crazy.

You'll spend just as little time on audio. You just send the sound when you want it to start.

Physics can take up a lot of time or minimal time. It depends how realistic you are going to be, what objects you're applying it to, etc.

AI will probably take quite a bit of time, especially when you lump in pathing and everything else.

Graphics consume as much time as you're willing to give.

Thank you very much for your help. I think i will learn graphics first, physics second, input third and audio last.

Currently i am very good at designing a game (story,characters,lore,weapons and landscapes etc.). I also am an expert in music i know how to play The Guitar(Electric and Bass),Drums and Keyboards/Piano's and creating a composition etc.

I also took a course in 3D animation and modelling.

Your physics will never be 100% accurate, your AI will never be as smart as it could be, and your graphics will never be as pretty as they could be.

You might also try using an engine instead of doing everything yourself. I think Unity is the popular choice. If you think that might work, I'd recommend a new thread in the proper forum (not OpenGL).

I highly disagree, i know the game that i will make will have :

-Amazing physics with good colision detection

-Amazing graphics ,

-A witful A.I ( The enemies are going to be literraly brutal with no mercy and leave litlle Openings ).

There are plenty of resources available to create a Amazing game in the limitless realm of the interenet that can make a individual create anything because anything is possible.

Give-up does not exist to me and I do not want to use Unity yet because i want to code a 3D game engine/game myself so that i have a very deep understanding of everything works and what goes in a actual game. I also like to work alone so i like doing everything myself since i love a challenge and i hate easy things.

Anyway thank for your reply .