Followers 0

# OpenGL Invisible Geometry

## 16 posts in this topic

Does anyone have any advice or tricks/techniques for debugging invisible geometry in OpenGL? I found stuff for Direct3D and when I first started writing my D3D driver for my engine it really helped, but I haven't been able to find anything like that for OpenGL. Only things referencing the word "missing" with the word OpenGL is usually referencing missing DLLs or Extensions or files, or textures, etc.

I can't figure out which piece is the problem, I know I took the matrix functions collapsed them down to a single dimensional array of floats, since everything I read kept saying in memory it's contiguous and you can exploit that (Though I still feel like a transpose needs to be taken ..somewhere...) but now when it comes to drawing just a simple cube, I get nada in my window. The window clears to the right color that I specify, just the cube doesn't show up. The cube is being fed in data from a file (Which uses routines I know work -- as the D3D driver does), the only other "trick" (Other than collapsing the matrices) I had read about converting D3Dmatrices to OGL is after the projection is set (Via a call to glMatrixMode(GL_PROJECTION) and glLoadMatrixf), issue these two gl statements:

glScalef(1, 1, 2);

glTranslatef(0, 0, -1);

I suppose maybe the z value of each vertex coord needs to have its sign inversed (- if + and + if -) or maybe just the meshes position, but I tried that. I have culling disabled, I have lighting disabled. So I ran gDEBugger peeked into the VBO and found that it seems like only half of my VBO is being set, despite breaking in Visual Studio at the end of my loop that feeds the interleaved array -- confirming there are indeed enough floats to fill the VBO yet the "bottom-half" of the list in the VBO, according to gDEBugger, is all NA.

There should be 288 float values for the VBO; here's my calculation of it:

3 points per face

being a cube and working with GL_TRIANGLES, there are 2 faces per poly (I guess this terminology might be backward... eh.)

each point contains 2 texture floats (u and v), 3 normal floats (x, y, and z) and 3 vertex floats (x, y, and z) -- 8 floats per point

2 faces per side * 12 sides = 36

so the end calculation is 36 * 8 = 288 floats in a 1d array; yet in gDEBugger I see only up to line 17 filled in (18, if you count 0 -- which you should), that's half of 36; and only 6 sides. Can a partially filled VBO still render? Or have I found my culprit? (Either way I know it's not good.)

I'm guessing you guys will need some code as it may be hard for you to tell from descriptions; so just lemme know. Any help would really be appreciated, I'm wasting waaay too much time trying to get a single cube to render. Thanks!

-- StakFallT

0

##### Share on other sites

What I usually do is to make it so only that object is rendering in my scene. Just to make sure it's not hiding behind anything or blending with other objects.

Sometimes having large VBOs will make it so objects don't draw.

The best way to problem solving is to simplefy the problem. Take out all un-needed items from your code temporarly just so you have only the bug to deal with.

0

##### Share on other sites

Definitely sound advice...Unfortunately, I actually already followed that to varying degrees. I actually always had it as one object rendering -- deliberately for simplistic debugging. Because the engine is getting so enormous, with a lot of moving (figuratively speaking -- not moving as in objects like plural -- or even singular -- and not moving as in rotating, etc. but moving as in complex) parts, much of the code can't exactly be bypassed without serious rem'ing of stuff, and I've experienced problems with going that route before, you rem out heaps of blocks of code sprinkled across many functions only to forget to un-rem something and bang your head against the wall for hours as to why the D3D driver no longer renders lol

Fortunately I did have a routine I wrote to draw a cube using quads that uses immediate mode OGL(Hand-feeding vertices), specifying position and rotation, and it seems to work but only when I stop using the camera and rendering the model (Which further down the pipeline makes changes to the world transform) which implies it's the matrix math. Great. Just wonderful.   Of all the things that have to be revisited, it had to be the matrix math...Lemme ask this, I originally had data stored in matrices stored as row major. In other words, data that was part of the same set was stored on the same row (I know a lot of math articles on the web like to nitpick about how there's no such thing as LH and RH and in some cases row and column, so forth and so on, hence the big deal I'm making in trying to elaborate on what I mean). Basically a D3D layout for the data in the matrix. I since then collapsed the matrix from .m[0]._0, m[0]._1, m[0]._2, m[0]._3, etc. style down to .m[0], .m[1], .m[2], .m[3], .m[4], .m[5], etc. From my understanding of reading various articles, that should be sufficient for the matrix math API-agnosticism (Even a word? lol)   right?

And how does this correlate to order of operations? One site had my head all twisted around; it said if it's row major then it should be pre-order and if it's column major it should be post-order.. Well what happends if you collapse it to 1-dimension? Does it still apply? Can the order of operations in OGL, for transforms, be the same as in D3D so long as the world transform actually sets the ModelView transform in the OGL driver (I have -some- control over how things are handled, I have one abstract class that the drivers derive from and implement their own functions)? I don't really need to have two full sets of matrix functions depending on the driver right? That would be very limiting and insane (Since I'd have to change camera class code, quaternion usage, etc. it would have a very large rippling effect)

Edited by StakFallT
0

##### Share on other sites

[...} without serious rem'ing of stuff, and I've experienced problems with going that route before, you rem out heaps of blocks of code sprinkled across many functions only to forget to un-rem something and bang your head against the wall for hours as to why the D3D driver no longer renders lol

Stop whatever you are doing right now and learn about source control first. SVN, Git and Mercurial (among many others) are completely free to get, use and learn about. Even the simple basics of source control reduce the problem described above to 'exactly nothing'. You can, of course, develop non-trivial software without the aid of version control but that's about as efficient as drilling a hole into your knee and filling it with marmalade before going for the 100m sprint medal.
Even if you don't care about branching or any other more interesting possibilities, the ability to compare and restore code to well-defined commit-points alone is something you cannot really live without after having experienced it.
1

##### Share on other sites

Yeah I originally had it source controlled through svn (didn't have the parts to spin up a whole brand new source server, so I had it locally on an ext. harddrive), problem became was my dev machine also was my normal computer use machine and was running Windows, so anytime I got some kind of virus (Usually the things that got past FF with adblock, noscript, and Sophos were like rootkit grade stuff that would leverage flash and java, seriously nasty stuff -- like wipe drive and start the os from scratch again to achieve any semblance of confidence in the integrity of the computer).So in the past I've had to "move" the repository a few times since the ip address of the local machine (Wasn't using loopback) obviously changed so I had to play around with getting the solution/project to relocate anytime I went through that (Unless I remembered the previous IP address and used that and I kinda remember something about local file paths too with it).  So I figured since the code is in a state of constant flux, make hard backups the old fashioned way (anytime there's a major feature addition), hard copies to the ext. drive. (It was pretty nice at the time to be able to see source diffs and maintain a changelog).

For the past, close to year and a half, I'm actually developing on Linux with VMWare running Windows (For D3D testing) and VBox (For OGL testing) -- eventually I will need to test it on actual installs; but I'm not there yet. Right now, I have these matrix questions (My last reply) that I'm fairly confused about...

0

##### Share on other sites

My personal opinion is, if you are getting virus infections on any kind of regular basis you are doing something extremely wrong.

Edit: Stupid forum ate the second half of my post. Let me try again.
Also, if you are doing a local repository, why don't you use a file:-URL instead of http:-URL? Besides, why should the SVN server care about the IP it's on? We moved an SVN server and it never caused problems. You do have to either SVN Relocate or do a new checkout of your working copies though...

Edited by BitMaster
0

##### Share on other sites

Actually that's why I stressed the point about them being rootkits...It's analogous to say putting grass seed down then a screen overtop of that. What gets through is the nastiest stuff in the case of this analogy it's the strongest blades of grass -- still probably not an overly great analogy. Here's probably a better one, it's like MRCA in the hospitals; the deal with some really bad stuff because their so sanitary; only strongest stuff survives. Which isn't to say it wouldn't necessarily exist anyway (ianad though so I dunno). I used IP so if I did spin up a source server I merely just had to change my own ip set the server to what my IP used to be and I'm off to the races.

I dunno, everytime I did a relocate it always seemed like I had to fiddle with it to get it to work right.

Anyhow, I will reevaluate my decision on using source sooner than later in the meantime; but I feel like we're digressing...

0

##### Share on other sites

My opinion still stands: any kind of malicious code regularly hitting your system points to a serious flaw in your own management of risks: either the software you use, the frequency in which you install updates or other factors (maybe consider doing your 'risky' browsing in a VM).

0

##### Share on other sites

Well that was the idea behind the VMs, I can clone fresh installs and dump down if need be. I run Linux as my host, leaving the SE features intact with tripwire running weekly checks and emailing me; and anything I need Windows for I use VMs. I even have various security designated VMs, my DMZ one is basically anything goes, my dev one is JUST that, I try real hard not to do any browsing with that..etc. So I've taken some drastic steps.Just I didn't bother going into them, because my original intent of the op was to solve the problem with invisible geometry ;)

0

##### Share on other sites

Does your background color happen to be black?

If you are drawing a white cube on a black background... but you forgot to disable lighting... the shaded white cube without any lights in the scene would become as black as the background and thus invisible.

[/random stab in the dark]

0

##### Share on other sites
Nah I have it clearing the window to like a sky blue... The cube should be black (or maybe even full white) but it should show up against the blue
0

##### Share on other sites

bumping with a quick update. I modified my transform making routine that my model class calls so that it also dumps my manually-calculated transform matrix as well as the matrix OpenGL-calculated through the use of glMultMatrixf (and then a call to glGetFloatv), and I got them showing up exactly the same, so I now know my matrix math should be spot on. Still having absolutely 0 luck in getting the VBO to render though. Preferably I'd like to use glLoadMatrix instead of the alternative method of issuing a series of glMultMatrix calls -- or even using glRotate, glScale, etc (Though I think those are for immediate mode drawing right?)

0

##### Share on other sites

Preferably I'd like to use glLoadMatrix instead of the alternative method of issuing a series of glMultMatrix calls -- or even using glRotate, glScale, etc (Though I think those are for immediate mode drawing right?)

gLLoadMatrix, glMultMatrix, glRotate and the other functions of a similar vein are all the same: completely deprecated in modern OpenGL. When they were used, they never made a distinction between immediate mode or not. glRotate was just a fancy way to create a rotation matrix and calling glMultMatrix, the same for the others.
0

##### Share on other sites

A lot of places I been reading, call it immediate mode; only reason I called it that -- the term seemed to kinda make sense though. So if you don't use LoadMatrix, MultMatrix, or Rotate (as well as the others), then what does one use? Obviously there's a projection and a modelview projection (That my camera class uses); but then I have to transform my model also into modelview. What's the "bridge" between doing my matrix multiplication for the model's properties, to bringing them into modelview? (And now that I think about it, how does that integrate with the vertices I've pushed to the VBO? Do all vertices of the model have to be transformed and then pushed into the VBO?)

0

##### Share on other sites

In modern OpenGL you set the camera matrices as uniforms for the shader. Depending on the OpenGL and shader version you are using the shaders might be able to access the old pipeline's modelview and projection matrix.

How do you create your OpenGL context? How do you initialize it? For example if you are requesting a forward compatible context instead of a compatibility context you will have the old functionality disabled by the driver.

0

##### Share on other sites

Oh. well that kinda turns my view (No pun intended) on its side. Didn't know  shaders were the only way to do camera matrices (As far as being modern OpenGL compliant I mean). I always thought shaders were only for hardware accelerators; which is fine... I mean I'm on one, I expect users of the engine to be on one etc. But I thought using shaders would mean only accelerator-powered machines would be able to run the engine. I didn't want to force myself into a corner and only write for accelerators; as there can be a rare moment that a software based renderer would be useful; for that though I guess I'd just write another driver class and utilize the deprecated stuff huh?

As for the creating of the OpenGL context; basically all of my window settings, application hWND, etc. are all stored in a settings class and then passed to the OpenGL driver that creates the MFC Window (For now I have it rolled into the driver; bad design I know, but being one person I have to go where my immediate needs take me). In addition to creating the MFC window via the standard CreateWindowEx MFC call it then (A few lines later) calls wglCreateContext and then wglMakeCurrent; checks the extensions and sets the VBO function pointers if the card manufacturer driver has that feature.Then it calls glViewport, glMatrixMode(GL_PROJECTION),glLoadIdentity(), gluPerspective with the appropriate parameters. Then it makes two more calls after that: glMatrixMode(GL_MODELVIEW),glLoadIdentity() (Figuring the camera class will pick up from there).

EDIT 1: Looked back over my reply and saw a couple of spelling mistakes: Meant -> mean, and right -> write (herp derp lol)

EDIT 2: Here is what my matrix dumps look like:

Dumping Old OpenGL generated ModelView matrix...
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

That's after the camera has been set.

Dumping Manually generated Model transform (Without spatial-transforms) matrix...
m[0]: 40.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 40.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 40.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: -5.0000000    m[15]: 1.0000000

That's the combination of all the matrix functions for the model (Without multiplying by the camera model-view or the projection matrix).

The scale of the model is (40, 40, 40)

The position of the model is (0, 0, -5)

and there's no rotation

So the model transform looks spot on if my understanding of OGL matrix layout locations are correct (I think I'm referring to what they call the data storage of the matrix?) -- Yet I get nothing except the blue screen that I'm clearing the window to.

EDIT 3: 06/30/2013 ~2:35PM EST

Here's some more in-depth data dumps (Hopefully it helps). To keep the post from being too spammy, I'm encasing them in code blocks, despite them not actually being code.


[Cube-Test Statistics]:
'Unique' Vertex List:
[   0]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[   1]:    X:-0.980615139    Y:5.96046448e-008    Z:-0.987541199
[   2]:    X:-5.98050165    Y:4.95865297        Z:-0.987541199
[   3]:    X:-0.980615139    Y:4.95865297        Z:-0.987541199
[   4]:    X:-5.98050165    Y:4.95865297        Z:-6.10226059
[   5]:    X:-0.980615139    Y:4.95865297        Z:-6.10226059
[   6]:    X:-5.98050165    Y:5.96046448e-008    Z:-6.10226059
[   7]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059

Model Point Vertices:
[   0]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[   1]:    X:-0.980615139    Y:5.96046448e-008    Z:-0.987541199
[   2]:    X:-5.98050165    Y:4.95865297    Z:-0.987541199
[   3]:    X:-5.98050165    Y:4.95865297    Z:-0.987541199
[   4]:    X:-0.980615139    Y:5.96046448e-008    Z:-0.987541199
[   5]:    X:-0.980615139    Y:4.95865297    Z:-0.987541199
[   6]:    X:-5.98050165    Y:4.95865297    Z:-0.987541199
[   7]:    X:-0.980615139    Y:4.95865297    Z:-0.987541199
[   8]:    X:-5.98050165    Y:4.95865297    Z:-6.10226059
[   9]:    X:-5.98050165    Y:4.95865297    Z:-6.10226059
[  10]:    X:-0.980615139    Y:4.95865297    Z:-0.987541199
[  11]:    X:-0.980615139    Y:4.95865297    Z:-6.10226059
[  12]:    X:-5.98050165    Y:4.95865297    Z:-6.10226059
[  13]:    X:-0.980615139    Y:4.95865297    Z:-6.10226059
[  14]:    X:-5.98050165    Y:5.96046448e-008    Z:-6.10226059
[  15]:    X:-5.98050165    Y:5.96046448e-008    Z:-6.10226059
[  16]:    X:-0.980615139    Y:4.95865297    Z:-6.10226059
[  17]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059
[  18]:    X:-5.98050165    Y:5.96046448e-008    Z:-6.10226059
[  19]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059
[  20]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[  21]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[  22]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059
[  23]:    X:-0.980615139    Y:5.96046448e-008    Z:-0.987541199
[  24]:    X:-0.980615139    Y:5.96046448e-008    Z:-0.987541199
[  25]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059
[  26]:    X:-0.980615139    Y:4.95865297    Z:-0.987541199
[  27]:    X:-0.980615139    Y:4.95865297    Z:-0.987541199
[  28]:    X:-0.980615139    Y:5.96046448e-008    Z:-6.10226059
[  29]:    X:-0.980615139    Y:4.95865297    Z:-6.10226059
[  30]:    X:-5.98050165    Y:5.96046448e-008    Z:-6.10226059
[  31]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[  32]:    X:-5.98050165    Y:4.95865297    Z:-6.10226059
[  33]:    X:-5.98050165    Y:4.95865297    Z:-6.10226059
[  34]:    X:-5.98050165    Y:5.96046448e-008    Z:-0.987541199
[  35]:    X:-5.98050165    Y:4.95865297    Z:-0.987541199

Model position: (0,0,-5)
Model scale: (40,40,40)
Model rotation: (0,0,0)

Dumping rotation matrix X...
Values:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping rotation matrix y...
Values:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping rotation matrix z...
Values:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping rotation matrix...
Values:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping scale matrix...
Values:
m[0]: 40.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 40.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 40.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping translation matrix...
Values:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: -5.0000000    m[15]: 1.0000000

Dumping OLD OpenGL ModelView matrix...
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Dumping Manually generated Model transform (Without spatial-transforms) matrix...
m[0]: 40.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 40.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 40.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: -5.0000000    m[15]: 1.0000000

Begining Model-to-scene transformation

Retrieved OpenGL Projection Matrix:
m[0]: 0.99984771     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 0.99984771     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 0.99984771    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: -5.0000000    m[14]: 10.0000000    m[15]: 1.0000000

Internal Engine Camera View Matrix:
m[0]: 1.0000000     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 1.0000000     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 1.0000000    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: 0.0000000    m[14]: 0.0000000    m[15]: 1.0000000

Proj x Camera_ViewMatrix matrix:
m[0]: 0.99984771     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 0.99984771     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 0.99984771    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: -5.0000000    m[14]: 10.0000000    m[15]: 1.0000000

ProjView x Model Matrix:
m[0]: 39.9939079     m[1]: 0.0000000     m[2]: 0.0000000     m[3]: 0.0000000
m[4]: 0.0000000     m[5]: 39.9939079     m[6]: 0.0000000     m[7]: 0.0000000
m[8]: 0.0000000     m[9]: 0.0000000    m[10]: 39.9939079    m[11]: 0.0000000
m[12]: 0.0000000    m[13]: -200.0000000    m[14]: 395.0000000    m[15]: 1.0000000

EDIT 4: 06/30/2013 ~9:51PM EST Kept looking at my data dump in the previous edit and wondering how the number of points could be the same count as the 'unique' vertices. It's because I duplicated the for loops in the data dumps and didn't change the upper limit control loop variable. I apologize; this should be correct now. I didn't bother doing another redump since I played around with the model scaling and its position a bit which would change the values of the matrices (Still haven't had any luck though; so the posted dumps are still ok to work with as the vertex positions haven't changed just the model's matrix values -- not even the math behind the matrix multiplication routines)

Edited by StakFallT
0

##### Share on other sites

I would strongly suggest downloading GML. It's header-only, so there are really no excuses. Compare the result of its old OpenGL pipeline replacement functions with yours.

And while there are implementations of OpenGL which are designed to run in pure software you should think very carefully before you aim for those. Consider this: Your average smartphone or tablet renders using OpenGL ES. OpenGL ES 2 (which you could nowadays safely assume to be the default) is largely equivalent to OpenGL 2 (restrictions to this statement apply if you dig deeper), just without the fixed-function pipeline.
Even the 25/35\$ Raspberry Pi does OpenGL ES 2.

There are really only three scenarios where you should seriously consider doing software rendering:
1) it can be difficult to have good graphics hardware on servers, especially if you want a cheap one.
3) your users don't install graphics drivers.

(1) is seldom an issue - most servers don't need good (or any) graphics cards and if they do you usually have a budget where they are affordable. My day job is in a field where average usually non-gamer users encounter 3d graphics. Extremely seldom you run into (2), frighteningly often you encounter (3) though. I think we can safely assume that people actually interested in games will somehow manage to get graphics drivers installed though.

Edited by BitMaster
0

## Create an account

Register a new account

Followers 0

• ### Similar Content

• Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
• By DaniDesu
#include "MyEngine.h" int main() { MyEngine myEngine; myEngine.run(); return 0; } MyEngine.h
#pragma once #include "MyWindow.h" #include "MyShaders.h" #include "MyShapes.h" class MyEngine { private: GLFWwindow * myWindowHandle; MyWindow * myWindow; public: MyEngine(); ~MyEngine(); void run(); }; MyEngine.cpp
#pragma once #include <glad\glad.h> #include <GLFW\glfw3.h> class MyWindow { private: GLFWwindow * windowHandle; int windowWidth; int windowHeight; const char * windowTitle; public: MyWindow(int windowWidth, int windowHeight, const char * windowTitle); ~MyWindow(); GLFWwindow * getWindowHandle(); void createWindow(); void MyWindow::destroyWindow(); }; MyWindow.cpp
#include "MyWindow.h" MyWindow::MyWindow(int windowWidth, int windowHeight, const char * windowTitle) { this->windowHandle = NULL; this->windowWidth = windowWidth; this->windowWidth = windowWidth; this->windowHeight = windowHeight; this->windowTitle = windowTitle; glfwInit(); } MyWindow::~MyWindow() { } GLFWwindow * MyWindow::getWindowHandle() { return this->windowHandle; } void MyWindow::createWindow() { // Use OpenGL 3.3 and GLSL 3.3 glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); // Limit backwards compatibility glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // Prevent resizing window glfwWindowHint(GLFW_RESIZABLE, GL_FALSE); // Create window this->windowHandle = glfwCreateWindow(this->windowWidth, this->windowHeight, this->windowTitle, NULL, NULL); glfwMakeContextCurrent(this->windowHandle); } void MyWindow::destroyWindow() { glfwTerminate(); } MyShapes.h
#pragma once #include <glad\glad.h> #include <GLFW\glfw3.h> class MyShapes { public: MyShapes(); ~MyShapes(); GLuint & drawTriangle(float coordinates[]); }; MyShapes.cpp
#include "MyShapes.h" MyShapes::MyShapes() { } MyShapes::~MyShapes() { } GLuint & MyShapes::drawTriangle(float coordinates[]) { GLuint vertexBufferObject{}; GLuint vertexArrayObject{}; // Create a VAO glGenVertexArrays(1, &vertexArrayObject); glBindVertexArray(vertexArrayObject); // Send vertices to the GPU glGenBuffers(1, &vertexBufferObject); glBindBuffer(GL_ARRAY_BUFFER, vertexBufferObject); glBufferData(GL_ARRAY_BUFFER, sizeof(coordinates), coordinates, GL_STATIC_DRAW); // Dertermine the interpretation of the array buffer glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3*sizeof(float), (void *)0); glEnableVertexAttribArray(0); // Unbind the buffers glBindBuffer(GL_ARRAY_BUFFER, 0); glBindVertexArray(0); return vertexArrayObject; } MyFileHandler.h
#pragma once #include <cstdio> #include <cstdlib> class MyFileHandler { private: const char * fileName; unsigned long fileSize; void setFileSize(); public: MyFileHandler(const char * fileName); ~MyFileHandler(); unsigned long getFileSize(); const char * readFile(); }; MyFileHandler.cpp
#include "MyFileHandler.h" MyFileHandler::MyFileHandler(const char * fileName) { this->fileName = fileName; this->setFileSize(); } MyFileHandler::~MyFileHandler() { } void MyFileHandler::setFileSize() { FILE * fileHandle = NULL; fopen_s(&fileHandle, this->fileName, "rb"); fseek(fileHandle, 0L, SEEK_END); this->fileSize = ftell(fileHandle); rewind(fileHandle); fclose(fileHandle); return; } unsigned long MyFileHandler::getFileSize() { return (this->fileSize); } const char * MyFileHandler::readFile() { char * buffer = (char *)malloc((this->fileSize)+1); FILE * fileHandle = NULL; fopen_s(&fileHandle, this->fileName, "rb"); fread(buffer, this->fileSize, sizeof(char), fileHandle); fclose(fileHandle); buffer[this->fileSize] = '\0'; return buffer; } VertexShader.glsl
#version 330 core layout (location = 0) vec3 VertexPositions; void main() { gl_Position = vec4(VertexPositions, 1.0f); } FragmentShader.glsl
#version 330 core out vec4 FragmentColor; void main() { FragmentColor = vec4(1.0f, 0.0f, 0.0f, 1.0f); } I am attempting to create a simple engine/graphics utility using some object-oriented paradigms. My first goal is to get some output from my engine, namely, a simple red triangle.
For this goal, the MyShapes class will be responsible for defining shapes such as triangles, polygons etc. Currently, there is only a drawTriangle() method implemented, because I first wanted to see whether it works or not before attempting to code other shape drawing methods.
The constructor of the MyEngine class creates a GLFW window (GLAD is also initialized here to load all OpenGL functionality), and the myEngine.run() method in Main.cpp is responsible for firing up the engine. In this run() method, the shaders get loaded from files via the help of my FileHandler class. The vertices for the triangle are processed by the myShapes.drawTriangle() method where a vertex array object, a vertex buffer object and vertrex attributes are set for this purpose.
The while loop in the run() method should be outputting me the desired red triangle, but all I get is a grey window area. Why?
(Note: I am aware that this code is not using any good software engineering practices (e.g. exceptions, error handling). I am planning to implement them later, once I get the hang of OpenGL.)

• By KarimIO
EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
Update: No crash occurs if I don't draw, just clear and swap.
static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));
• By Tchom
Hey devs!

I've been working on a OpenGL ES 2.0 android engine and I have begun implementing some simple (point) lighting. I had something fairly simple working, so I tried to get fancy and added color-tinting light. And it works great... with only one or two lights. Any more than that, the application drops about 15 frames per light added (my ideal is at least 4 or 5). I know implementing lighting is expensive, I just didn't think it was that expensive. I'm fairly new to the world of OpenGL and GLSL, so there is a good chance I've written some crappy shader code. If anyone had any feedback or tips on how I can optimize this code, please let me know.

uniform mat4 u_MVPMatrix; uniform mat4 u_MVMatrix; attribute vec4 a_Position; attribute vec3 a_Normal; attribute vec2 a_TexCoordinate; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { v_Position = vec3(u_MVMatrix * a_Position); v_TexCoordinate = a_TexCoordinate; v_Normal = vec3(u_MVMatrix * vec4(a_Normal, 0.0)); gl_Position = u_MVPMatrix * a_Position; } Fragment Shader
precision mediump float; uniform vec4 u_LightPos["+numLights+"]; uniform vec4 u_LightColours["+numLights+"]; uniform float u_LightPower["+numLights+"]; uniform sampler2D u_Texture; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { gl_FragColor = (texture2D(u_Texture, v_TexCoordinate)); float diffuse = 0.0; vec4 colourSum = vec4(1.0); for (int i = 0; i < "+numLights+"; i++) { vec3 toPointLight = vec3(u_LightPos[i]); float distance = length(toPointLight - v_Position); vec3 lightVector = normalize(toPointLight - v_Position); float diffuseDiff = 0.0; // The diffuse difference contributed from current light diffuseDiff = max(dot(v_Normal, lightVector), 0.0); diffuseDiff = diffuseDiff * (1.0 / (1.0 + ((1.0-u_LightPower[i])* distance * distance))); //Determine attenuatio diffuse += diffuseDiff; gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - vec3(u_LightColours[i]))*diffuseDiff))); //The expensive part } diffuse += 0.1; //Add ambient light gl_FragColor.rgb *= diffuse; } Am I making any rookie mistakes? Or am I just being unrealistic about what I can do? Thanks in advance
• By yahiko00
Hi,
Not sure to post at the right place, if not, please forgive me...
For a game project I am working on, I would like to implement a 2D starfield as a background.
I do not want to deal with static tiles, since I plan to slowly animate the starfield. So, I am trying to figure out how to generate a random starfield for the entire map.
I feel that using a uniform distribution for the stars will not do the trick. Instead I would like something similar to the screenshot below, taken from the game Star Wars: Empire At War (all credits to Lucasfilm, Disney, and so on...).

Is there someone who could have an idea of a distribution which could result in such a starfield?
Any insight would be appreciated

• 12
• 28
• 14
• 11
• 34