Let me see if I understood. If I use multiple viewports I can create several "cameras" in my OpenGL application. Right?
Well, I have an object that can be seen in the viewport 1, but not visible in the viewport 2. If I want the subject appears in both viewports then ...I must draw double!
That means that if I have two objects, if I have two "cameras", I have to draw these objects twice. So everything I have in my scene, I must have to draw double.
Is this okay? Is there another way to split the screen without duplicating objects?
Is this okay?
Yes, that's how it goes.
Is there another way to split the screen without duplicating objects?
You're not duplicating objects. You can't because there's no such thing as an "object" in OpenGL. OpenGL is just a sophisticated kind of pencil to draw on a framebuffer. There is no scene, there are no objects, there are just points, lines and triangles drawn to a framebuffer.
All you do is draw several pictures of the same thing from different points of view, just as you'd like do it using a pencil on paper.
Related
In Blender and many other 3D modeling programs, there are 3D manipulator widgets (handles) which look like this.
However, as you can see, these widgets consist of polygon handles and lines connected to them from the origin point. However, in OpenGL, draw calls like
glDrawElements or glDrawArrays can use only one primitive mode (such as GL_TRIANGLES, GL_POINTS, GL_LINES, ...) per single draw call.
So in order to draw the 3D widgets consisting of triangles and lines, it needs at least two VBOs, one for polygons and one for lines. However I think it's pretty awkward to make draw call twice for that. (Or, without instancing or merging VBOs, we need 2 draw calls per one axis.)
Is it possible to draw both lines and triangles in single draw call in a case like this? There won't be too much performance penalty for drawing widgets though, but I'm curious if there is an efficient method to draw it.
Is it possible to draw both lines and triangles in single draw call in a case like this?
Yes, you could use geometry shaders. These would allow you to emit new output primitives that don't have to match the input primitives.
Is it worth it in this case? I would suggest not, it would be horribly complicated for little benefit.
Use a single VBO/IBO for all the axi's geometry data. Include a colour in the vertex data then draw the three axi's lines in one call, then draw the three axi's boxes in another.
I'm developping a 3D application using OpenGL.
I have a misconception about a part of the following post: OpenGL VAO best practices
I'm not sure about the meaning of the term 'batch' in this post.
Does it means for each object of the scene ?
So does it suggest to create a VAO for each object of the scene or several objects ?
Does a batch refers to several objects sharing the same materials, transformations and shading ?
A batch is simply a, well, "batch" (=bunch) of primitives, i.e. points, lines or triangles drawn by making a single glDraw… call. There's no deeper maging behind this.
Does it means for each object of the scene?
No. OpenGL doesn't know what a "model" is. This concept goes totally beyond what OpenGL does. OpenGL merely draws points, lines or triangles to the screen, and that's it.
So does it suggest to create a VAO for each object of the scene or several objects?
No, it suggests that you create VAOs and VBOs in such a way, that you can coalesce the maximum number of primitives (= triangle | line | point) that can be drawn with a minimum number of glDraw… calls into a single VAO/VBO.
For example say you'd render a warehouse full of cardboard boxes, where each box has a (slightly) different shape (think of the self service section in an IKEA store; I'm pretty sure those look about the same in every store around the world): Despite being of different shape the boxes have a lot in common: Their color, the texture, etc. So what you would do is put all those boxes into a single VAO/VBO and draw them all together using the same texture and shader through a single, or a handfull of glDraw… calls.
So I have a cool program that renders a pretty cube in the centre of the screen.
I'm trying to now create a tiny cube on each corner of the existing cube (so 8 tiny cubes), centred on each of the existing cubes corners (or vertices).
I'm assuming an efficient way to implement this would be with a loop of some kind, to minimise the amount of code.
My query is, how does this affect the VAO/VBO's? Even in a loop, would each one need it's own buffer or could they all be sent at the same time...
Secondly, if it can be done, what would the structure of this loop be like, in terms of focusing on separate vertices given that each vertex has different coordinates...
As Vaughn Cato said, each object (using the same VBOs) can simply be drawn at different locations in world space, so you do not need to define separate VBO's for each object.
To complete this task, you simply need a loop to modify the given matrix before each one is rendered to the screen to change the origins of where each cube is drawn.
I'm on an OpenGL project.
I have some objects (just say 2) made of the same transparent material (alpha = 0.2, for example). The two objects intersect.
How can I make the intersection part look the same as other part (without border, no different color), so the too objects will look like as one?
I'm not sure if you would really want to do it. I will answer anyway, but first let me tell you why I think you don't want that.
In real life, imagine a red stained glass and a blue one. If you look at them in a way that they partially overlap, the overlapping part clearly has a different color (purple). If you get 2 red glasses and look at them so that they have overlap, the overlapping part is more red. That's exactly what is happening in your OpenGL program.
Now in general, when you have multiple transparent objects, you need to sort them based on their distance from your eye and the direction you are looking at. Then you draw them from farthest to closest. This is not a simple task by itself! Think of 2 objects that cross.
One way of achieving what you want is to sort the transparent objects, but draw from closest object to the farthest. This way, you practically don't allow transparency on the same pixel to be done twice. Not a good idea.
Another way would be to do something very specific to these objects of special kind. I say special kind because apparently two of them overlapping doesn't make any changes! You can do what you want by drawing to the stencil buffer instead of the draw buffer, then draw a rectangle with the color you want over the whole screen, but matching only that stencil.
So I have what is essentially a game... There is terrain in this game. I'd like to be able to create a top-down view minimap so that the "player" can see where they are going. I'm doing some shading etc on the terrain so I'd like that to show up in the minimap as well. It seems like I just need to create a second camera and somehow get that camera's display to show up in a specific box. I'm also thinking something like a mirror would work.
I'm looking for approaches that I could take that would essentially give me the same view I currently have, just top down... Does this seem feasible? Feel free to ask questions... Thanks!
One way to do this is to create an FBO (frame buffer object) with a render buffer attached, render your minimap to it, and then bind the FBO to a texture. You can then map the texture to anything you'd like, generally a quad. You can do this for all sorts of HUD objects. This also means that you don't have to redraw the contents of your HUD/menu objects as often as your main view; update the the associated buffer only as often as you require. You will often want to downsample (in the polygon count sense) the objects/scene you are rendering to the FBO for this case. The functions in the API you'll want to check into are:
glGenFramebuffersEXT
glBindFramebufferEXT
glGenRenderbuffersEXT
glBindRenderbufferEXT
glRenderbufferStorageEXT
glFrambufferRenderbufferEXT
glFrambufferTexture2DEXT
glGenerateMipmapEXT
There is a write-up on using FBOs on gamedev.net. Another potential optimization is that if the contents of the minimap are static and you are simply moving a camera over this static view (truly just a map). You can render a portion of the map that is much larger than what you actually want to display to the player and fake a camera by adjusting the texture coordinates of the object it's mapped onto. This only works if your minimap is in orthographic projection.
Well, I don't have an answer to your specific question, but it's common in games to render the world to an image using an orthogonal perspective from above, and use that for the minimap. It would at least be less performance intensive than rendering it on the fly.