Jump to content


Member Since 21 Jun 2013
Offline Last Active Apr 22 2017 09:18 AM

Topics I've Started

OpenGL performance tips

09 March 2014 - 02:28 AM

Hi all,


For my engine I need to render a bunch of different meshes, including an alpha pass.
Currently the way I do it is fairly straight-forward:


- I have one big vertex and index buffer in which I load in all my mesh data. During the render phase I use this to "instance" my geometry.

- I have frustum culling to neglect scenery that doesn't need to be drawn

- During the update part of the game-loop, I create a render-queue, which sorts the meshes so they can be drawn more efficiently


- At render-time, I bind the large mesh-buffer one time before drawing any meshes

- Drawing is done by going through the render-queue. I bind the correct texture_2D_Array for the mesh and I draw the mesh with glDrawElementsBaseVertex. Thus I just pass in the correct index to draw a certain mesh, using one and the same buffer (instancing)

- I disable the buffer at the end of the render loop

- After all opaque objects were rendered, I do the alpha pass in a similar way, also using the big buffer. Although in this case I cannot sort them mesh per mesh, since they are sorted by depth.


- I use one and the same shader-program for drawing all these meshes, and only one sampler2DArray at texture index 0. The array contains a diffuse map and an optional bumpmap.


I'm finding that with the current setup I'm not quite getting the performance I'd like to get. Therefore I'm hoping to receive some tips on how this sort of mesh-rendering problem is usually tackled by more experienced programmers. For example, is it common-practise to use just one shader-program for rendering all meshes? Or is there a much more efficient way that would remove the need to always re-bind the correct texture when switching between meshes?


Any suggestions are very welcome!


Terrain texturing: multi-texturing + brush tool

23 December 2013 - 01:44 PM

Hi all,


I'm at the point at which I'd like to implement a brush to paint terrain, so I'd like to bounce some ideas and thoughts here and hopefully come up with a proper implementation strategy. I'm using OpenGL for graphics.


My goals are:

- allow the user to paint up to for example 16 different terrain textures, with an alpha value of his/her choosing

- allow texture splatting for up to 4 overlapping textures of alpha values < 1, any other layers painted ontop with an alpha < 1 would be ignored (but you could paint over it by using an alpha = 1, although I'm open to other suggestions here)



I've done some research on the internet, and read over a bunch of tutorials. But the tutorials and information I found usually just covered multi-texturing using a pre-determined height algorithm, so I'm not entirely sure how to deal with terrain brushes.


For texture splatting, it seems to me I could just send in an extra vector of glm::vec4, each value corresponding to RGBA to determine the texture splatting. However I'm not sure how to accomodate information corresponding to the 16 possible textures.
I would send in a texture array for these, but how would I know which four textures to use in the texture splatting? Would I need to use another vector of glm::vec4, which stores the index of the texture to use? Or are there better, more efficient ways to go about this?


Any good resources on creating terrain brushes I'm overlooking here, that aren't limited to just a few textures but describe the general case of x textures?


Much thanks in advance!


Game Physics for moving objects

24 November 2013 - 04:40 AM

Hi all,


Let me elaborate a bit on what I mean with moving objects.
Basically I have some code in my vertex shader that offsets my meshes each frame, to create a "swinging" motion. Currently used for trees, grass, and the likes.


I am now wondering what I should do about collision meshes. Should I offset the vertexes on all my collision meshes each frame as well? Or would it be better to limit the "swinging" motion of my objects, and just use a static collision mesh that never has to get updated? What's some common practises for this case?


I welcome any advice on the subject!


PS: using BulletPhysics, should it be of importance.




How to manage game actors vs scene graph

03 November 2013 - 06:52 AM

Hi all,


I've just started implementing a component-based game actor class, but was wondering how best to keep track of my game actors in my gamestate.


For rendering, I already have a SceneGraph with a quadtree that chops my terrain into chunks, as well as stores "meshInstanceNodes" in its leaf nodes. I would basically like to have something similar for my game actors, however I'd like to keep the rendering quadtree encapsulated for purely rendering.


Should I make another quadtree to store my game actors in the current gameState? Or is it also acceptable to store gameactors as a Node in the sceneGraph (even though the sceneGraph was created for rendering things only)? What is generally speaking a good practise for storing game actors as opposed to their sceneGraph rendering representatives?



Advice on creating a dll from C++ project and use it in C# winForms project

15 October 2013 - 11:27 AM

Hi All,


Straight to the point: I have an OpenGL C++ application which features things like a scene graph, scene nodes, some custom made GUI widgets that allow the user to place scene nodes and adjust their properties. However, using this custom GUI doesn't seem like the ideal way to develop an editor in the quickest way possible. It's rather cumbersome upon adding in new features. Ideally I'd like to use Windows Forms to quickly prototype new editor functions.


I'm currently wondering how I would best somehow wrap up this C++ code into perhaps a .dll, and then reference this in a C# project using Windows Forms, I am also wondering what requirements I need to keep in mind to make this migration as smooth as possible.


The main question I'm having most trouble with at the moment is how to embed my scene rendering into a windows form. Is such a thing possible, or would I need to create my window by calling some of the C++ code?


Any advice or helpful tips would be greatly appreciated!