Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Mar 2014
Offline Last Active Yesterday, 02:28 PM

Topics I've Started

OpenGL Streaming Text

11 June 2014 - 03:27 PM

Hey everyone, just wanted to find out how everyone else would tackle this problem in the industry...

In my effort to convert my engine to newer OpenGl standards, I'm moving my text renderer from Immediate mode to using vertex buffers.


I've made a Text class which you create and pass a String to it's constructor along with other arguments... this object will generate a Vertex Array Object, and a Buffer Object and render the quads/triangles needed to draw the string of text into the buffer.

This works... until I need to change the text, like with a live FPS counter for example.


I have a setValue() function/method which lets me change the value of an existing Text object, by simply generating a new vertex array, and using glBufferData to swap it in the VAO. Problem is, it's losing all of the pointers to the vertex data, I have a feeling this is because glBufferData actually replaces the buffer altogether losing the pointers... 


I've tried using glBufferSubData() but that still shows the same symptoms (Quads are drawn all over the game in random places and colours, totally nonsense).



Basically, can someone tell me whats the best way they know of rendering live text in OpenGL nowadays? :)


 - Jonathan

Immediate mode text alternative.

20 May 2014 - 02:16 PM

I'm moving away from Immediate mode rendering and display lists, and started using vertex buffers... but I've hit a problem when it comes to rendering text.


For example when drawing my FPS meter, the value changes all the time, so currently my text render sends a texture mapped quad to the GPU for each character, and this works exactly as I want... but if immediate mode rendering is deprecated... how am I supposed to draw data that changes every frame?


Surely using buffers would be a bit overkill? What does everyone else use for this?


 - Jonathan

glUniformHandleui64ARB - Invalid Operation

09 May 2014 - 04:30 PM

So I've started learning about ARB_Bindless_texture, allowing me to use memory pointers for textures instead of binding to the limited texture units.


I currently load my textures into the GPU, read the handle using  ARBBindlessTexture.glGetTextureHandleARB(tex[i]);


and then bind that to a sampler uniform later on when rendering. Although I get an "Invalid Oparation" opengl error when calling glUniformHandleui64ARB() to link the texture with the sampler... in the documentation, it says:


The error INVALID_OPERATION is generated by UniformHandleui64{v}ARB if the
sampler or image uniform being updated has the "bound_sampler" or
"bound_image" layout qualifier.


But I don't properly understand what this means... I've never heard of a 'bound_sampler' qualifier...


Please could someone more experienced help me out with this one... I'm stumped as the documentation is very limited at this point.



SPEED: glUniform Vs. uniform buffer objects.

27 April 2014 - 11:20 AM

So recently I dropped all support for legacy openGL matrix functionality from my 3D engine, and instead of GL_MODELVIEW for example, I'm uploading my view matrices to a Uniform Buffer Object to be shared and accessed by my shaders. But as stated in a previous post, this caused a huge FPS drop (from 1000 to 100). I've managed to get this number up towards about 400 by trimming out as many matrix calls as possible (like transforming meshes before drawing, I've now transformed the vertices before uploading to the GPU), but I'm still not happy with the performance.


Would regular glUniform calls be quicker than using buffer objects, for example, when I bind a shader, I pass the current view/projection matrices as a uniform, rather than using the UBO's.


This would mean each shader would have it's own copy of the matrices rather than the global (UBO) ones...


Does anyone know if glUniform() calls are faster than UBO calls? (Which have proven to drop FPS quite significantly).



Terrain painting, working 4 texture limit

25 April 2014 - 04:39 AM

For my engine, I'm working on the terrain painting functionality in the world editor program. I'm using texture splatting to render my terrain chunks, this gives me a 4 texture limit on individual chunks... and until I find a better technique for texturing, this is how it's going to stay.


In my editor I have a large range of textures to choose from, and currently when you paint onto the terrain, the engine searches through the Chunk's 4 textures, if it finds the one that we're currently painting.. then it just adds to that channel.


But, the problem comes if we have 4 textures painted onto a chunk.. and we try painting another... currently my engine finds the texture with the least coverage and swaps that over to the one we're painting... which works, but sometimes it means swapping a texture that I'd rather not lose (it may have less coverage.. but it's more important.. like a thin path to walk on or something).


I'm just wondering how other engines /programmers address this problem of painting with limited textures, without hassling the level artist too much?