I want to make a small 2D game in C++. I need to know how to actually render the game. I understand the basics behind opengl, you load vertices into an vbo, load the textures into a vbo and then you can use a draw call using a shader to interpret it. But how do I actually do it in 2D. Do I really only need a vbo storing a single square, and then all the textures, with which I use gltransform to change based on the details of the sprite I am rendering? How do I actually reference the texture I need for the sprite if it is all in one big vbo?
Do you really want to implement this yourself? There are a lot of free libraries out there that do this for you, and are quite good at it (e.g. SFML, SDL, cocos2d-x etc.).
If you're worried about performance issues or something along those lines, then stop, because you're most likely wrong.
If, however, you want to learn how it's done, then by all means do it... but it's still a good idea to install one of these free open source libraries and look at their source code, as it's been in use (in production!) for quite some time now.
I know it's not a direct answer to your question, sorry if it doesn't help you.
Related
Context
I'm a beginner in 3D graphics and I'm starting out with Vulkan, which I already know it's not recommended save it please, currently working on a university project to develop the base of a 3D computer graphics engine based on the Vulkan API.
The problem
Example of running the app to render the classic 2D triangle
Drawing a 3D mesh after having drawn the triangle
So as you can see in the images above I want to be able to:
Run the engine.
Choose an object to be drawn.
Close the window.
Choose another object to be drawn.
Open the same window back up with only the last object chosen visible.
And the way I have been doing this is by essentially cleaning up the whole swap chain and recreating it from scratch once the window is closed and a new object has been chosen. Now I'm aware this probably sounds like terrorism for any computer graphics engineer but the reason I'm doing this is because I don't know a better way, I have just finished the vulkan tutorial.
Solutions tried
I have checked that I do a vkDestroyBuffer and vkFreeMemory on the current vertex buffer before recreating it again once I choose a different object.
I have disabled depth testing entirely in case it had something to do with it, it doesn't.
Note: The code is extensive and I really don't have a clue of which part of it could be relevant to the problem, so I opted for not cluttering the question, if there is an specific part you think it might help you find the solution please request it.
Thank you for taking the time to read my question.
A comment by user369070 ended up drawing my attention to the function I use to read OBJ files which made me realize that this function wasn't cleaning a data structure I use to store the vertices of the object chosen to be drawn before passing them to the vertex buffer.
I just had to add vertices = {}; at the top of the function to solve it.
I used opengl 2 years ago. In one afternoon I read a tuto, I drew a cube (and then learned how to load any 3d model) and learned home to move the camera around with the mouse. It was easy, less than 100 lines of codes. I didnt get the pipeline completely but I was able to do something.
Now I need to refresh opengl for some basic stuff, basically I need to load a 3D model (any model) and move the model around, with the camera fixed. Something I thought would be another afternoon.
I have spent 1 day and have nothing working. I am reading the recommended tuto http://www.arcsynthesis.org/gltut/ I dont get anything, now to draw just a cube you need a lot of lines and working with lots of buffer, use some special syntax for shaders.... what the hell I only want to draw a cube. Before it was just defining 6 sides.
What is going on with opengl? Some would argue that now is great, I think it is screwed.
Is there any easy library to work with Something that would make my life easier?
GLUT - http://www.opengl.org/resources/libraries/glut/
ASSIMP - http://assimp.sourceforge.net/
These two libraries are all you need to make a simple application where you import a model (various formats). Read it's documentation and examples to get a better understanding on how you can "glue" OpenGL and ASSIMP to work.
Documentation
As to is OpenGL more hard to comprehend? No. What I've learned in recent years from OpenGL is that GFX programming is never simple or done in a few lines of code, you have to be organised, you have to be careful and even a simple primitive (e.g cube) needs to have more than 100 lines of code to make it decent and flexible (for example if you want more subdivisions on your polygons or texturing).
If you learned it only two years ago, then the tutorials were extremely outdated. Immediate Mode has been known to be deprecated for a very, very long time. Actually the first plans to abandon it and display lists date back to 2003.
Vertex Arrays have been around since version 1.1, and they have been the preferred method for sending geometry to OpenGL ever since; in immediate mode every vertex causes several function calls, so for any seriously complex object you spend more time managing the function call stack, than doing actual rendering work. If you used Vertex Arrays consequently since their introduction, switching over to Vertex Buffer Objects is as complicated as just inserting or replacing a few lines.
The biggest hurdle using OpenGL-3 is in Windows, where one has to use a proxy context to get access to the extension functions required to select OpenGL-3 capabilities for context creation. However again no big hurdle, 20 lines of code top. And some programs, like mine for example, create a proxy GL context anyway, to which all shareable data is uploaded, which allows to quicly destroy/recreate visible contexts, yet have full access to textures, VBOs and stuff (you can share VBOs, which is another reason for using them instead of plain vertex arrays; this might not look like something big, at least not if the context is used from a single process; however on plattforms like X11/GLX OpenGL contexts can be shared between X11 clients, which may even run on different machines!)
Also the existance of functions like the matrix manipulation stack led people into the misconception, OpenGL was some matrix math library, some even believed it was a particularily fast one. Neither is true. The removal of the matrix manipulation functions was a very important and right thing to do. Every serious OpenGL application will implement their very own matrix math anyway. For example any modern game using some kind of physics engine used to directly use in OpenGL (glLoadMatrix, or glUniformMatrix) the transform matrix spit out by the physics calculation, completely bypassing the rest of the matrix functions. This also means that the sole reason to have multiple matrix stacks (GL_PROJECTION, GL_MODELVIEW, GL_TEXTURE, GL_COLOR), namely being able to use the same set of manipulation functions on several matrices, was obsoleted and could have been replaced by something like glLoadMatrixSelected{f,d}v(GLenum target, GLfloat *matrix). However Uniforms and shaders already were around, so the logical step was not introducing a new function, but to reuse existing API, which had been used for this task already, anway, and instead remove what's no longer needed.
TL;DR: The new OpenGL-3 API greatly simplyfies using it. It's a lot clearer, has fewer pitfalls and IMHO is also more newbie-friendly.
You don't have to use buffer objects. You can use the deprecated immediate mode. It will be slower, but if you don't really care then go ahead and use OpenGL the way you used to. NeHe has some excellent tutorials on OpenGL 1.x stuff.
Swiftless has some good tutorials (only a few very basic ones) on OpenGL 3.x and 4.x, but the learning curve is, as you've found, very steep.
Does it have to be openGL? XNA offers an ability to draw 3d models without breaking your back.. Could be worth a look
I'm new to graphics, and I have to make a model of a building for an assignment using only GLUT or OpenGL.
Basically the school building's model( only the exterior portion) is to be made, and I have no clue where to start. Upto now I have drawn polygons, other shapes using GLUT, nothing in which there are multiple shapes. All the drawing upto now is using lines, or points, or polygons and mathematics.
Could you please give me an idea of how to go about it?
Update: I just want to know what steps I can follow to get it done. Some reference links would be awesome!
You could use modeling programs to create your model, and then use tools such as COLLADA to get your model into OpenGL.
The problem with hand-coding a complex object like that is that it takes a great number of lines of code just to define the vertices of the object.
People usually use 3D modeler software to build complex 3D objects, like Maya, 3DSMax or Blender and then export them in a format to be read into your OpenGL application.
Think about what you want your building to look like, and think about what kind of triangles you need to render in order to make that. You can either draw the entire thing in some sort of modelling software, and then import it into OpenGL, or you can come up with the triangles/textures yourself and do it by hand in OpenGL.
The exterior of the building will probably have a similar texture on the whole thing (brick, etc), and then there will be windows, doors, and a roof. Maybe some sort of sign that says "School Building". Take this all into account, what exactly you want your building to look like, and then think about what textures you will need to draw these things.
For example, say you're doing a brick building that is in the shape of a box, with a door and a few windows. I'd use one texture for the brick, and first draw an entire wall of brick. Then, I'd use a grey/blue looking texture for the window, and draw it over the brick wall. Then I'd do the same (different texture) for the door.
Just think about the design, and then just try things out - experiment. Good luck!
I once had a simillar homework. I did it by creating the models with Google SketchUp, then export the models to .3ds file and use my program to render it.
I choose Google SketchUp because it's the easiest to use among those tool I tried. Plus, they had a discount for students. You could also use Blender, which is free but take too much time to learn IMHO. 3dsMax is too expensive to pay for a homework.
To load the model into my program, I used Assimp library.
Just learning the basics of OpenGL for a class and was looking for something challenging and interesting to try and draw. Any suggestions?
Aiming to photorealism (just plain models, lights, materials, textures, etc.) is one thing, but what is even more interesting in my opinion is demoscene and all kinds of non-photorealistic effects. The idea of a demo is to program some nice animated graphics that automatically change from one effect to another or tell some sort of a story, and have a background music. Here you can find some videos. Just take a look at what some others have done and use your imagination. That's the funniest part of 3D programming in my opinion. Of course what you'll first program would be something extremely simple when compared to those videos on youtube, but everyone has to start from somewhere. Simple also doesn't need to be ugly. Some random suggestions:
mathematical shapes with sin(), cos(), etc.
alpha blending, especially addition blending (glBlendFunc(GL_ONE, GL_ONE);)
terrain rendering
read 3d model data from a file. (Wavefront .OBJ is a relatively simple one)
feedback effects with glCopyTexImage2D, which copies pixels from screen to a texture (in real life you shouldn't use this because it's too slow, but when learning the basics it's ok)
etc...
You might consider building an OBJ viewer. You will get the experience you're looking for, and it's a pretty good project for a beginning 3D graphics programmer, in terms of difficulty.
I believe opengl has built in shapes such as a teapot that you can call and have it draw. For starters, I'd stick with easy shapes like squares, circles, and cones. Try drawing a wireframe model first since that's the easiest, by using either quadstrips ,triangles or just poly lines. After you've gotten that down, learn to set up lighting and materials so you can draw a solid model.
At school we had a very interesting assignement to get started with OpenGL that I will share. The long term goal was to modelize a living room so you basically have to draw:
A table.
Two chairs.
A carpet.
A sofa
Some stuff that you might find interesting to add on the table for
instance a TV!
When you have all the things done, try to polish the scene a little bit by adding some lighting effects!
Hint: for all the objects you simply need to start with a basic rectangle. Then you can construct your scene step by step using translations/rotations.
So I've got this class where I have to make a simple game in OpenGL.
I want to make space invanders (basically).
So how in the world should I make anything appear on my screen that looks decent at all? :(
I found some code, finally, that let me import a 3DS object. It was sweet I thought and went and put it in a class to make it a little more modular and usable (http://www.spacesimulator.net/tut4_3dsloader.html).
However, either the program I use (Cheetah3d) is exporting the uv map incorrectly and/or the code for reading in a .bmp that ISN'T the one that came with the demo. The image is all weird. Very hard to explain.
So I arrive at my question. What solution should I use to draw objects? Should I honestly expect to spend hours guessing at vertices to make a space invader ship? Then also try to map a decent texture to this object as well? The code I am using draws the untextured object just fine but I can't begin to go mapping the texture to it because I don't know what vertices correspond to what polygons etc.
Thanks SO for any suggestions on what I should do. :D
You could draw textured quads, provided you have a texture loader.
I really wouldn't worry too much about your "uv map" - if you can get your vertices right then you can generally cludge something anyway. That's what I'd do.