Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Apr 2010
Offline Last Active May 20 2012 07:19 AM

#4812569 Post-processing pipeline and render targets

Posted by on 18 May 2011 - 10:03 AM

yes u have to swap between to rendertragets, it's not allowed to read and write from the same frame buffer.

only exception in OpenGL I know of is if u copy a rectangle of the framebuffer to an other rectangle with glBlitFramebuffer, but the two rectangles aren'T allowed to overlapp

#4810460 Frustrum culling window size at range

Posted by on 13 May 2011 - 05:05 PM

what u need is the field of view angle(call it alpha),
So the screen size at Z x will be: x / (tan (alpha/2)) * 2

#4810222 Particle techniques

Posted by on 13 May 2011 - 08:14 AM

no, if u don't use a simple ADD blend u need to sort particles.

On old hardware u can use of course Textures, which u modify in a shader, for the particle attributes, but with OpenGL 3 u have Transform Feedback with which u can "render" with a Vertex Shader into another buffer object.

Two good resource for GPU particle sorting for once and rendering rediculouse much particles are these two
http://directtovideo.wordpress.com/(take also a look at his demos)

#4808780 Double-buffered VBO vs updating parts of a VBO

Posted by on 09 May 2011 - 06:12 PM

Double buffering isn't needed, u just have to make sure to glBufferData with null first so the Driver can allocate new memory and don't have to stall.

With OpenGL 3 you have access to the Transform Feedback extension, which let u "render" from a Vertex Shader vertices into a Buffer Object.
This let u calculate all the particle movement on the GPU and several million particles are no problem (Sorting on the GPU is also possible but a bit more complicated).
PS: When using OpenGL 3 u can use Buffer objects for your Shader uniforms, take a look at http://www.opengl.org/wiki/Uniform_Buffer_Object.

#4803466 Instancing a good idea for speed in this case?

Posted by on 27 April 2011 - 03:15 AM

Don't load each pin in its own BO, arn't all the pins the excat same model?.
As long all the pins are more or less static there is no reason for instancing so just copy all pins in a single BO so only 1 draw call is needed

#4796387 Only 5.000 Sprites

Posted by on 09 April 2011 - 10:09 AM

some thoughts
1. frames doesn't tell u anything, use ms to compare stuff.
2. try to test if u are filtrate bound, render the particles without updating them every frame.
3. try to shrink your vertex size
4. can u use point spirits instead of your quads? possible if u don't rotate the particles and they face the camera
4.1. experiment with geometrie shaders
5. use instancing, for particles a texture or with OGL3 transform feedback is probably the best

#4796247 Only 5.000 Sprites

Posted by on 09 April 2011 - 02:47 AM

Ok, VAOs are a special kind of OpenGL object. Instead of saving data they save state.
In order to draw something with BOs u normally have to set up a lot of state, like enabling vertex attributes, setting the attribute settings and specifying an element buffer.

These states are set through the following OpenGL commands:
  • glEnableClientState , glDisableClientState
  • all the gl*Pointer functions
  • binding the GL_ELEMENT_ARRAY_BUFFER buffer
good overview over the data structure http://www.opengl.org/wiki/Vertex_Array_Object

If I get rid of all the glEnableVertexAttrib()-binds in the render function, nothing is displayed at all. Thats not the only place I am using a VAO/VBO.

Have u put that code in your VAO initialization? The same spot where u set up all the Attribute info.

#4796169 Only 5.000 Sprites

Posted by on 08 April 2011 - 06:53 PM

First of,
you using VAOs wrong, making them useless in your case.
1. in the render function, get rid of all the client state en/disables and the buffer binds.
You need this only while initialization.
2. in the update function, you don't need to bind the VAO just the buffer.

when a VAO is bound all of these specific OpenGL stats are stored in the VAO instead of the "standard" context(VAO, glBindVertexArray(0);)

also, it don't make any sens to "unbind" a shader, its just extra work. In many case also true for the textures.

Finaly there is something what u can optimize, in your update function.
Instead of your simple glBufferData use this
glBufferData(GL_ARRAY_BUFFER,  size, null, GL_STREAM_DRAW);
glSubBufferData(GL_ARRAY_BUFFER, 0,  size, data);

this lets the driver optimize the upload better and can reduce stalls

#4796081 Textures and sampler states

Posted by on 08 April 2011 - 02:14 PM

no I think only with Opengl4 this is possible atm
u just have to create some data structures in your engine/renderer in which u can save texture parameters and then before using a texture enable all these saved parameters

#4792078 bump mapping vs normal mapping

Posted by on 30 March 2011 - 03:19 AM

yes u would collect some gradients and modify your triangle normal with them.
e.g. check out the sobel filter

#4791100 GLSL Question....

Posted by on 27 March 2011 - 03:57 PM

no there is no guarantee and also in my experience a little change in the code can give very different attribute ids.

Implementations will also differ greatly(drivers etc)

On the other hand you are free to force specified attributs to specific ids.

Normaly you will do this with the following function


(after programm compiling but before linking)

Starting with OpenGL 3.3 I think
you can use directly in your shader the location qualifier

layout(location = 3) in vec4 myAttr;

#4786518 Texture continuity

Posted by on 16 March 2011 - 08:13 AM

I'm using this quite nice addition to normal texture texture blending.

It looks just so much better :-)

#4786111 Efficiently clipping lights in a deferred shader

Posted by on 15 March 2011 - 11:52 AM

just use additive blending (ONE, ONE). U just have to remember that the ambient color only have to be counted in once.

#4785962 Efficiently clipping lights in a deferred shader

Posted by on 15 March 2011 - 03:35 AM

There are two things which should be avoided in GLSL if you want your code to run fast, loops and if clauses.
Even worse if both are combined.

Some GPUs will for example run every possibility of an if statement and deciding afterwards which result they should take.

If you want to use scissor testing just use the fixed function, which will be much faster then anything you can do(on the GPU).

What I would suggest for you is to use stencil testing for the light volumes and frustum culling. Both are very easy to implement, just google them in the context of defered rendering.

#4784820 VAO - Is it necessary to redo setup each time buffer data changes?

Posted by on 12 March 2011 - 08:51 AM

mm, dont really know whats wrong, but here some random stuff.

  • There is no need to generate, bind and submit data to the VBO while the VAO is active, they don't have anything to do with the VAO state
  • maybe check your stride and offset values(both are in bytes) again, look also at teh part of your code which fills your data array
  • use Stream_Draw when you are updating the buffer every frame
  • also when updating use this code, it's faster because the driver has less problems managing the memory
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, size * sizeof(vertex_t),  null, GL_STREAM_DRAW);
glBufferSubData(GL_ARRAY_BUFFER, 0, size * sizeof(vertex_t), vertices);

here is some pseudo code how I do it:
	Generate n BOs
	Bind first	 upload index data
	Bind other BO

	upload vertex data to it
	Loop until all vertex BOs are filled

	Generate VAO
	Bind VAO
	Bind Index Buffer
	Enable Client States

	Bind a BO
	Set all its vertex pointers
	Loop until all Attributs are set
	Unbind VAO

Update/Render Loop:
	Bind BO which data changed
	upload data
	Loop until each BO is updated

	Bind VAO
	Set up render state (Textures, Shader, Uniforms, Lighting ...)
	Unbind VAO