• Create Account

# Invisible Geometry

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

16 replies to this topic

### #1StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 24 June 2013 - 08:22 AM

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

### #2martyj2009  Members   -  Reputation: 135

Like
0Likes
Like

Posted 24 June 2013 - 09:12 AM

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.

### #3StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 24 June 2013 - 10:34 AM

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, 24 June 2013 - 10:37 AM.

### #4BitMaster  Crossbones+   -  Reputation: 8647

Like
1Likes
Like

Posted 25 June 2013 - 01:08 AM

[...} 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.

### #5StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 25 June 2013 - 06:56 AM

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...

### #6BitMaster  Crossbones+   -  Reputation: 8647

Like
0Likes
Like

Posted 25 June 2013 - 07:05 AM

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, 25 June 2013 - 07:09 AM.

### #7StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 25 June 2013 - 07:31 AM

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...

### #8BitMaster  Crossbones+   -  Reputation: 8647

Like
0Likes
Like

Posted 25 June 2013 - 07:35 AM

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).

### #9StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 25 June 2013 - 07:49 AM

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 ;)

### #10Servant of the Lord  Crossbones+   -  Reputation: 33412

Like
0Likes
Like

Posted 25 June 2013 - 10:26 AM

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]

It's perfectly fine to abbreviate my username to 'Servant' or 'SotL' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames -

### #11StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 25 June 2013 - 10:43 AM

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

### #12StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 27 June 2013 - 08:48 PM

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?)

### #13BitMaster  Crossbones+   -  Reputation: 8647

Like
0Likes
Like

Posted 28 June 2013 - 12:44 AM

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.

### #14StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 28 June 2013 - 07:15 AM

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?)

### #15BitMaster  Crossbones+   -  Reputation: 8647

Like
0Likes
Like

Posted 28 June 2013 - 07:29 AM

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.

### #16StakFallT  Members   -  Reputation: 308

Like
0Likes
Like

Posted 28 June 2013 - 08:30 AM

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, 30 June 2013 - 07:47 PM.

### #17BitMaster  Crossbones+   -  Reputation: 8647

Like
0Likes
Like

Posted 01 July 2013 - 01:40 AM

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, 01 July 2013 - 01:40 AM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS