Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Sep 2009
Offline Last Active Feb 19 2013 11:51 PM

#4997479 glAlphaFunc in gl20 ? or How do I enable alpha in gl20 ?

Posted by on 05 November 2012 - 01:48 AM

The built in alphaFunc is gone in GL20 because you're expected to replicate it in shader with the 'discard' keyword.

Basically at some point in your fragment shader you'll have:

float alphaMin = 0.1;
if(color.a < alphaMin) { discard; }

This achieves the same effect as alpha testing.

#4915099 Android: OpenGL Finger Paint App

Posted by on 21 February 2012 - 12:48 AM

Are you calling glClear during onDrawFrame or similar function? If you don't call it it should never clear the screen, thus allowing you to continually "add" to the image on every frame.

Unfortunately I'm not sure if the glSurfaceView uses double buffering or how to disable it if it does. This might cause some problems but I'm not sure, you can try without calling glClear and see how far you get.

#4913714 How to process texture indices properly

Posted by on 16 February 2012 - 11:51 AM

I don't personally see anything, maybe you could post more code. Do you have a shader? How do you know that AttribArray 1 is really the texcoord, do you have glGetAttribLocation somewhere, or glBindAttribLocation?

#4913488 How to process texture indices properly

Posted by on 15 February 2012 - 04:20 PM

I'm not sure if that's an adequate general-case solution. In some cases you may actually need to increase the size of the vertex/index buffer with new indices. In an original VBO, you can have a single position vector share two UV vectors. For example if you had a quad consisting of two triangles, with unique textures on each tri, it might look like this:

f 1/1 2/2 3/3
f 2/4 3/5 4/6

Originally you'll have a vbo/ibo of 4 vertices, but you'll end up needing 6 to represent the texcoords accurately. You'll probably need to toss the entire existing IBO and recreate one from scratch.

#4913454 How to process texture indices properly

Posted by on 15 February 2012 - 02:31 PM

Unfortunately processing texture coordinates from obj models is not trivial. In opengl you only get one IBO which must be shared by all buffers (for a given vertex, position, color, texcoord, normal, must all be in the same index of the buffer).

Because obj gives each attribute its own set of indices, you will need to read in the data and rearrange/reindex everything such that all attribute buffers are aligned on a single index.

If you have trouble doing this, just search the forums and I'm sure you'll find hundreds of discussions on the topic. I think pretty much every opengl developer runs into this wall early in their development carrer.

#4853070 proper glUniform use

Posted by on 23 August 2011 - 09:58 PM

So what I did is declare the matrices in the shader as uniforms and made a neat updateMatrices() function for my DisplayObject class that is called everytime a transformation is done to the object (for example when it translates or rotates).

You're probably running into the problem of two objects using the same shader. If you use more than one object with a given shader, then you need to update the matrices each time you change between one and the other.

After some time of debugging I was able to fix this by calling chop the glUniform calls out of updateMatrices and call just before every object is drawn instead. Even though this works, I'm really doubting if I did the right thing here, because what I'm now doing is sending matrix data to the shader even though the values didn't change.

This sounds like a reasonable thing to do to me. Obviously you don't want to send data that you don't have to, but I can't imagine many cases where a single object gets a shader all to itself. I think just updating the matrices before drawing is not a big deal, unless you have unusual use case where it becomes impractical.

#4852858 OpenGL draws Texture incorrect

Posted by on 23 August 2011 - 11:04 AM

Gl.glTexCoord2f(x1, y1); Gl.glVertex2f(x1, y1);
Gl.glTexCoord2f(x1, y2); Gl.glVertex2f(x1, y2);
Gl.glTexCoord2f(x2, y2); Gl.glVertex2f(x2, y2);
Gl.glTexCoord2f(x2, y1); Gl.glVertex2f(x2, y1);

You don't want texcoord to be the same as the vertex coordinates. Textures range from 0 to 1. So by specifying it from 20 to 100 you're squishing and repeating your texture 80 times across the surface.

Try this instead:
                Gl.glTexCoord2f(0, 0); Gl.glVertex2f(x1, y1);
                Gl.glTexCoord2f(0, 1); Gl.glVertex2f(x1, y2);
                Gl.glTexCoord2f(1, 1); Gl.glVertex2f(x2, y2);
                Gl.glTexCoord2f(1, 0); Gl.glVertex2f(x2, y1);

#4851792 [SOLVED] Generic Vertex Attribute

Posted by on 20 August 2011 - 09:27 PM

Have you verified that inVertexPosIndex returns something other than -1? If you get that and pass it to AttribPointer it will probably fail.

I think you're missing the "in" keyword in your shader for this variable (unless this was removed in a more recent version than I'm familiar with).

"vec3 inVertexPos;"

#4851662 Starting with OpenGL ES 2.0

Posted by on 20 August 2011 - 11:04 AM

I think those files may come from the OpenGL ES emulator.

Have you checked out here: http://developer.nvidia.com/tegra-resources ?

At the bottom of the page they have a link for "x86 Windows OpenGL ES 2.0 Emulator", which may be what you need to get started.

#4850636 A little confused about generic vertex attributes...

Posted by on 18 August 2011 - 01:19 AM

So does that mean that generic attributes hold the actual data used by the shader?

Not exactly sure what you mean here, but a generic attribute is basically a point you can bind a VBO to such that the VBO supplies data through that attribute.

And what's the difference between glVertexAttribPointer and the other glVertexAttrib* functions?

glVertexAttrib* (for example glVertexAttrib3f) are kind of like the 'immediate mode' equivalents of glVertexAttribPointer. Its the same thing as the difference between glColorPointer and glColor3f, if you're familiar with the deprecated non-generic attributes. One specifies a VBO as a data source, and the other just sets a constant value. If you had a shader that had a per-vertex color attribute, but you just wanted to draw a red model, then you can just call glVertexAttrib3f(colorIndex, 1,0,0), and this will set the input to 1,0,0 for all vertices if you don't bind a VBO to it.

I guess what I'm really asking is, why would you need a generic attribute to bind to in the first place? Wouldn't the vertex shader analyze the VBO's contents and initialize the attribs off of that?

Shaders don't know anything about VBOs, and VBOs don't know anything about shaders. Attributes are how you link VBOs to specific input variables in your shader. How would the program know which array of floats you want to be the position, which is the texcoords, which is the normals unless you tell it what they are? Setting up attributes is how you send which VBOs to which input variables.

#4817921 The United States Prison Industrial Complex.

Posted by on 31 May 2011 - 10:21 AM

I think that expense is covered by forced labour. If I'm not mistaken putting citizens in prison is a lucrative buisness in the US hence why there's so many prisoners.

I doubt the cost of labor comes anywhere close to compensating taxpayers. In California we have extremely strict 3-strikes laws that lockup way too many people. All the jails are at like 175% of capacity, hence the recent supreme court ruling.

However it is very lucrative, not for the state, but for the prison guards' union. Its quite perverted, but that group is the biggest sponsor of all tough-on-crime laws in the state (three-strikes law was pushed by CCPOA), and they throw more money behind them than any other group. More prisoners = more guards = more union dues.

#4812895 VBOs and Memory

Posted by on 19 May 2011 - 12:34 AM

Can I expect that my extra system RAM will also be used to store these VBOs


is it illegal to allocate more memory in VBOs than my card has?


#4812190 Z Axis Up

Posted by on 17 May 2011 - 07:17 PM

It cant be done from the projection matrix?

Technically, there's no such thing as "the projection matrix". All you really have down at the hardware level is one matrix that transforms a vec4 (object space) to another vec4 (screen space). The idea of a projection matrix is just a nice abstraction for developers to help them assemble this final matrix (by compounding the projection, view, and object space matrices).

But if you consider the concept of a projection matrix, then it makes no sense for it to be there. Projection is only for doing perspective transforms, i.e. transforming what is in front of your face into an image. It doesn't care much about what direction you consider to be 'up', that's for the view matrix to determine.

You can probably stuff a 90 degree rotation into what you're calling your projection matrix, but it doesn't make much sense for you to do so.

#4811794 GPU Texture Designer is going to be released soon

Posted by on 16 May 2011 - 11:46 PM

I don't have a particular need for a texture editor at the moment so I'm not going to download, but one feature I think would be great would be a filter that helps create tileable textures from untileable ones.

I know its not an exact science, and it can be done in photoshop (though I never remember exactly how when the time comes that I need to do it), but a feature like that could be really cool. You'd have to have a lot of user interaction to get it quite right, maybe with some kind of clone tool like photoshop and some lowpass filters to work on color gradients, but to me that seems like it would make a neat tool.

A few more in-use screenshots and documentation on the website would help people get an idea of what they were downloading as well before they commit to installing it. I saw one but some more feature explanation would be nice.

#4811790 How did you learn modern OpenGL?

Posted by on 16 May 2011 - 11:34 PM

Just started out the same way as everyone else with my first glBegin triangle, then picked up VBOs for speed, and shaders cause they sounded fun and cool. Really not much more to it than that.

Looking at the big picture the API is not really a big deal. Whether you're using ancient immediate mode opengl, modern DirectX/OpenGL with buffers and shaders, or something else, the underlying graphics theory is all the same. Once you understand the theory behind things, then the API is just a tool for you to use.

"Modern OpenGL" is just shader syntax and API calls, its the theory that's most important to understand.