Month: April 2015

So here I am still trudging through learning OpenGL and then using it in LWJGL’s flavor of OpenGL.  All of the books I’ve been using and all of the internet searches I’ve been doing as I learn are related to OpenGL not LWJGL because there is very little information about how to use LWJGL out there.  For those that don’t know, LWJGL is pretty much OpenGL if someone decided to mash 140 lbs of C code into Java.  This conveniently means you can just learn OpenGL and then just learn the extra little bits needed to use it in Java.

I give OpenGL a lot of credit for keeping all of its functionality neatly separated and more or less atomic.  The negative side effect of this is that everything you want to do takes 17 steps.  This gives you a lot of flexibility in how you use everything when making your own engine, but it also means finding information about the “right” or “best” way to do things can be extremely difficult.  This is made even more obnoxious by the fact that there is so much information out there about OpenGL from before everything was powered by shaders (pre-3.2).

I’ve gotten a couple of extremely simple shaders written, compiled, and linked into a shader program.  I’ve created a little bit of geometry (a cube of course) in a couple of different ways (raw vertices, indexed vertices, etc.) and loaded them into the video card.  I’ve attempted to draw that geometry and nothing shows up.  One of the problems is that all of what I’m describing is just plumbing to get anything on the screen with OpenGL and if you have any of it wrong, nothing happens.  Because there are so many places that something could have gone wrong before you have a single thing on the screen, it’s very hard to debug which one went wrong.

My hope is that once I get something working I will be able to make it incrementally more awesome.  Add textures, add lighting, put lots of cubes on the screen at the same time, and so on.  For now, I’m still reading and researching and learning and have nothing to show for it yet…  Hopefully soon though.

I’ve never really coded “to the metal” with a graphics library so this is going to be a bit of me talking out random non-mouth orifices.  Actually, never isn’t fully accurate I suppose.  For the sake of full disclosure I did what seemed like about 20 minutes worth of OpenGL 1.2 when I was in college the first time (16 years ago) and a full course with Direct3D during my second attempt at college (but didn’t make anything like a game).  Direct3D isn’t going to help me much since I’ve chosen Java and LWJGL and a tiny bit of 16 year old experience with OpenGL is as good as having never used it at all.

This inspired another round of buying books.  I actually bought 5 of them, but the important ones for this conversation are “The Red Book” and “The Orange Book.”  More specifically, OpenGL Programming Guide: Eighth Edition and OpenGL Shading Language: Third Edition.  This is particularly amusing for me because when I was learning a little about OpenGL the first time, I actually bought the Second Edition of the Red Book and there was no such thing as a shader.

So here I am, with literally thousands of pages to look over.  I’m not going to pretend that I will read all of these books cover to cover, but I have at least started to pick them over for useful bits and educational potential.  This is a mountain of a learning curve, but it’s a fun one to climb.

Things I’ve pieced together so far…  The graphics pipeline used to be “fixed”.  This means that it always did roughly the same thing all the time.  Over time they made that pipeline more and more configurable in lots of fun ways.  Turning features on and off was the most control you had over how things worked.

Over time, the processors on video cards got more powerful and more parallel and they introduced the ability to program them with small programs called shaders.  Sort of like the ability to configure the pipeline, only way more powerful.  The original shaders were extremely limited in the number of instructions they could do and what those instructions were allowed to be, but were still considered a step up from mere configuration options.

Eventually shaders evolved into general purpose programs and the number of instructions you were allowed to use got large enough for them to be truly useful.  Video card makers saw this as an opportunity.  Why keep around the old fixed pipeline that was buried in configuration items when you could replace it with shaders by themselves?  Why create chips that have specific features that game designers may not even want when you can provide a way to run any features they want and leave the other ones out to avoid wasting overhead on them?  That’s how the “shader pipeline” was born.

And now I have to learn how to use them…  :)

I was hoping to not have to write this post.  I did a fair shake of research on which 3D library I wanted to use, I purchased books, I subsequently read some of those books and parts of other ones, I cleaned my office and found an old book I had sitting around…  And that’s where everything kind of went to crap.

My initial research brought me to the doorstep of JavaFX 8.  There were lots of reasons for this, but the one that I found the most compelling was actually that it was simply “built in” to Java 8.  No extra .jar files, no extra licenses to worry about, just 3D as brought to you by the makers of Java.  It honestly seemed perfect.  This is where I bought books on it and started reading them.

The book that I found buried in my office and that I’m now reading my way through is a book all about the math behind 3D.  A wonderful book on everything from vectors and matrix math to triangle meshes and occlusion.  The side effect of all this delicious learning is that I started to ask questions about how things worked in JavaFX and that’s unfortunately when the cracks started to show.  Each time I read about some other 3D math thing, I learned that it was only partially present in JavaFX.  What I mean by this is that I’m sure it was there and being used under the covers, but it was totally hidden from me.  What I was discovering rather quickly was that JavaFX is likely simply too high level for what I needed.

After a bit more reading, lots of coding that was well below the level of getting pretty 3D things on the screen, and conversations with friends, I started to worry a little that I was heading down the wrong path.  Fortunately, at this point in the project that path was very fixable.  All I’d manage to get on the screen with JavaFX was a single textured block.  Sure, it was a rather pretty block, but it was only one block of the roughly 236,118,324,143,482,260,684,800,000 I was expecting each world to possibly contain.  (If you were running on a server with unlimited storage anyway.)

This in turn led me to ask Google “Java 3D Libraries” and to find repeatedly that if you want to code with full access to the 3D power available in a machine, you pretty much use LWJGL (“Lightweight Java Game Library”).  This change comes with a couple of interesting problems for me.  First and foremost it means I have to learn a LOT more about working with 3D libraries.  JavaFX is a very high level scene graph style 3D engine.  Everything is well hidden from you, so you just tell it where things go in the scene and cross your fingers.  In LWJGL, if you want it to happen, you have to tell it how to do it.  There aren’t magical high level concepts available to help you out.  Part of me sees this as a challenge, and the other part is genuinely afraid that this could be what stops this project in its tracks.

At this point, the next step is to download LWJGL and start trying to figure out how to use it.  To that end, my goal is to get essentially the same picture you see above to happen using LWJGL instead of JavaFX as shown there.  Wish me luck.