Using Android OpenGL ES 1.1 (HTC Desire)...
The problem I have in general is this:
I have various 3D objects rendered in a complex scene. I want to check if the user has clicked on a particular object. This object may be partially hidden and therefore may appear as almost any shape in the scene. I only want to allow the object to be "selected" if the user clicks on a part of the object that is visible in the scene. This means that I cannot use vector-based calculations for the object intersection since these could not easily take into account the hidden areas of the object.
So I came up with an idea...
I set up the stencil buffer such that wherever the object was visible the stencil buffer was filled with 1s and everywhere else in the stencil buffer is 0. When the user clicks on a particular pixel in the scene I just need to check the stencil buffer to see if it contains a 1 or 0 which indicates if the object was clicked or not.
This works perfectly on a PC, but on Android OpenGL ES 1.1 it seems that I cannot read from the stencil buffer by using glReadPixels() as GL_STENCIL_INDEX is not supported.
Does anyone know if there is a way to read this 0/1 from the stencil buffer? Or can anyone think of a better algorithm for determining if my object has been clicked?
Many thanks
You can implement the same algorithm using color buffer.
Create a FrameBuffer. Render the scene into it, but draw each object with a distinct color. The color doesn't have to be same as the actual color of the object, because what you draw in framebuffer is not for eyes, but only for mouse lookup. Once entire scene is drawn, read the pixels using glReadPixels. When you get coordinates of the mouse from mouse event, look them up in the pixel map. The color you find can point back to the object the mouse is currently on.
It may be more efficient to use stencil buffer, but reading stencil buffer into memory doesn't seem possible in OpenGL ES. On the other hand, this method's advantage is you are not limited to 255 objects as in case of 8-bit stencil buffer.
Related
I'm a newbie in the OpenGL ES world, and learning some basics on 3d graphics on Android OpenGL ES. I'm wondering how to create a image plane that emitting light? This is easy to be implemented in 3d model software like Blender (using the Cycles Render), see the image below for effects I'm looking for. Through some research, I learnt that they may be related to Blur or Bloom effect using shader. But I'm not very sure, and I don't know how to implement them.
As per Paul-Jan's comment, what you want is far from basic in OpenGL.
The default approach for OpenGL is forward rendering. i.e. every time you specify a piece of geometry the calculation goes forwards from triangle to pixels, a function is applied to determine the colour for each of those pixels and they're forwarded to the frame buffer. So the starting position is that each individual pixel has no concept of the world around it. Each exists in isolation.
In your scene, the floor below the box has no idea it should be blue because it has no idea that there is a box above it.
Programs like Blender use a different approach, which in this context could accurate be called backwards rendering. It starts from each pixel and asks what geometry lies behind it. In doing that it explicitly has an idea of all the geometry in the scene. So when it spots that the floor is behind a certain position it can then continue and ask "and which light sources can the floor see?" to establish lighting.
The default OpenGL approach is long established for real-time rendering. If you look at old video games you'll notice evidence of it all over the place: objects often don't cast shadows on each other (or such shadows are very rough approximations), there's only one source of light which is infinitely far away (i.e. it's in a fixed position as far as geometry is concerned; no need to know about the scene really).
So solutions are to invest the geometry with some knowledge of the whole scene. A common approach is to perform internal renderings of the scene from the point of view of the light source. That generates a depth buffer. By handing the light position and depth buffer off to every piece of geometry in the scene they can calculate whether they're visible to the light source. If so then they're illuminated by it. If not then they're not.
Another option is deferred rendering; you do a standard pass of your scene, populating at each pixel the depth, the surface colour, the surface normal, etc. So you get the full scene information broken down into pixel-by-pixel storage from the point of view of the camera. You then pretend that everything the camera can see is everything that there is. So you just need to pass that buffer around for pixels to be able to work out, approximately, which light sources they can and can't see. You can also have different parts of the screen only consider which lights they're close enough to by a broad-phase 2d distance check, which saves time.
In either case we're actually talking about relatively advanced OpenGL stuff.
I want to crop and object my openGL ES application, it should be done in the following manner:
The left is the initial image, middle is the stencil buffer matrix, and right is the result.
From what i have read here: Discard with stencil might have performance issues,
and since the model that will be clipped is going to be rotated and translated, i honestly don't know if the drawn model will be clipped out in the wrong places after these actions.
will it?
So, i thought about depth buffer.
Again, an example:
(This photo was taken from this question.)
Assume that the black square is movable, and might not be just a simple square, but a complex UIBezierPath.
I was wondering about how to use the depth buffer, so that all that is drawn outside the square (or UIBezierPath) will be clipped out, meaning, adjusting all z values of the left out pixels to some threshold value, that wont be shown on screen.
So to summarise:
1) Will using stencil is going to be expensive as stated?
2) Is it possible to use stencil on a rotated and translated object so that it will always will be drawn?
3) Using depth buffer, Is it possible to find out what is inside and what is outside the square (or UIBezierPath) and how? masking it somehow?
4) What is the better approach?
I know it's a lot to answer on but since they all relate to each other i thought it better be asked at the same question.
The stencil buffer is the way to go here. The discard answer you refer to is about using the discard function in fragment shaders, which is very expensive for tile based deferred rendering GPUs (ie basically every mobile GPU).
Using the stencil buffer however is very cheap, as it is present on chip for each tile and does not interfere with deferred rendering.
To summarise:
No.
Yes, the stencil buffer operates in 2D over the whole viewport on the transformed vertices. It will clip the cube after its model transforms have been applied.
Yes, but needless to say this is complicated, somehow sounds similar to shadow volumes.
Use the stencil buffer.
I was trying to render rubix cubes with opengl es on android. Here is how I do it: I render 27 ajacent cubes. And the faces of the cubes which is covered is textured with black bmp picture and other faces that can be seen is textured with colorful picture. I used cull face and depth-test to avoid rendering useless faces. But look at what I got, it is pretty wierd. The black faces show up sometimes. Can anyone tell me how to get rid of the artifacts?
Screenshots:
With the benefit of screenshots it looks like the depth buffering simply isn't having any effect — would it be safe to conclude that you render the side of the cube with the blue faces first, then the central section behind it, then the back face?
I'm slightly out of my depth with the Android stuff but I think the confusion is probably just that enabling the depth test within OpenGL isn't sufficient. You also have to ensure that a depth buffer is allocated.
Probably you have a call to setEGLConfigChooser that's disabling the depth buffer. There are a bunch of overloaded variants of that method but the single boolean version and the one that allows redSize, greenSize, etc to be specified give you explicit control over whether there's a depth buffer size. So you'll want to check those.
If you're creating your framebuffer explicitly then make sure you are attaching a depth renderbuffer.
I've search around and seems that glBlendEquation has some issues in Android, -GL_MAX/MIN is not even listed in the opengles specs
I need to find a workaround to GL_MIN blendEquation mode. Is that possible? I want to write to a color buffer only if the alpha there is greater than the pixel's alpha i'm trying to write. Is it possible to do it without any extension or using more than 1 texture?
The dirty solution I was trying to avoid is this. Using Frame Buffer objects and shaders to emulate the color buffer and the blending mode:
Modify existing shaders to blend the scene with an FBO_1, into FBO_2.
Render FBO_2 to the screen.
The next drawing call swap FBO_1 with FBO_2, as FBO_2 equals the color buffer.
An "unintrusive" and more inefficient alternative is to use 3 FBOs and a shader, and make an additional pass.
Render scene to FBO_1 //without any modification to existing shaders
Blend FBO_1 with FBO_2 into FBO_3 //with new shader.
Render FBO_3 to the screen.
The next drawing call swap FBO_2 with FBO_3. The only advantage of this alternative is that i dont have to modify the existing drawing logic.
I really don't like any of this ideas. I'll gladly accept better answers!
Usually when clearing the frame for a new draw, one uses the glClear() or glClearColor(). But each of those completely removes the previous frame.
I'd like to make the frames disappear gradually, i.e. with each new frame put a semi-transparent overlay on what's already on the canvas. I tried to use the glClearColor()'s alpha parameter, but it doesn't seem to have any effect.
What should I do to achieve this gradual disappearing effect?
If you just want to draw the clear color over the last frame without getting rid of it entirely, draw a screen-size quad over the viewport with the same color as what you'd pass to glClearColor, and skip calling glClear(GL_COLOR_BUFFER_BIT) (you should probably still clear the depth/stencil buffers if you're using either of them). So, if you're using a depth buffer, first clear the depth buffer if need be, disable depth testing (this is important mainly to make sure that your quad does not update the depth buffer), draw your screen-size quad, and then re-enable depth testing. Draw anything else afterward if you need to.
What follows assumes you're using OpenGL ES 2.0
If you need to blend two different frames together and you realistically never actually see the clear color, you should probably render the last frame to a texture and draw that over the new frame. For that, you can either read the current framebuffer and copy it to a texture, or create a new framebuffer and attach a texture to it (see glFramebufferTexture2D). Once the framebuffer is set up, you can happily draw into that. After you've drawn the frame into the texture, you can go ahead and bind the texture and draw a quad over the screen (remembering of course to switch the framebuffer back to your regular framebuffer).
If you're using OpenGL ES 1.1, you will instead want to use glCopyTexImage2D (or glCopyTexSubImage2D) to copy the color buffer to a texture.