Hello, I have a fair amount of experience in 2D game programming and have created several games of my own but I want to get into 3D programming, but I have no idea where to start. I understand the basics of how 3D points are projected onto a screen and such but I'm not really sure where the best place to start is when applying it to game programming. I do have an old game programming book I brought a while back but It uses Java3D which I heard isn't the best for games :/ and it doesn't really do a good job of explaining some of the methods. Any help is appreciated, thanks!

Please don't learn the fixed function pipeline. Sure, it easier but in the end you'll eventually end up learning the programmable pipeline. So just save yourself the time and learn the programmable pipeline. I would recommend looking up theBennyBox on youtube, he has a 3D series where you create a game engine from scratch and learn so much about shaders and cameras etc... He's also currently showing you how to utilize the game engine you make to recreate wolfenstein 3D! Very cool but its very low level, so make sure you're ready for it.

No I'm sorry but you're wrong. The programmable pipeline is going to be and has been the OpenGL of the future for a few years now. Shaders coupled with the fact that you can control everything that happens on and behind the game screen allows for amazing graphics capabilities that the fixed pipeline just doesn't have. I doubt you'll find anyone but newbies to OpenGL who will tell you the fixed function pipeline is better. Its easier, but you can do less and immediate mode is slow as well... Balls. Easier isnt always better when it comes to graphics work, and OpenGL is no exception.

OpenGL is a library as name suggets... well - it actually is not as much as it was from the time when the fixed pipeline was abandoned, now it's rather a GPU access point API. It does not much for the user in terms of graphics rendering. It only passess data to the GPU. "Programmable gpu is good for programmers"

Sure it is but it doesn't mean that the fixed pipeline had to be abandoned, It could've been developed alongside the programmable pipeline - to actually provide the standard functionality (like lighting, texturing, bump mapping etc.)

And if You disagree and want to reinvent the wheel of lambert shading everytime You want to display an illuminated cube on the screen - You are free to do so.

"Fixed pipeline is just hard way to do things"

What a bullshit...

GPU's does not have fixed pipeline in hardware anymore so all this fixed function would have to be write with software/shaders. Do you really want that driver makers have to do your grunt work? Writing good and stable drivers for openGL is heck of a job and quality is still not acceptable.

It's not like we have fixed function physics/AI on CPU either and hopefully never will.

Even if the name suggest that it would be Open Graphics Library. It's not. It just interface that evolves alongside with hardware. At the early days it was performance decision to build user level features directly into GPU and to use these features GPU API did have to provide way to interact with such fixed functions. In modern day there are no such fixed function pipeline at GPU level so there is also no need OpenGL have it.

All high level functionality that you mentioned can be implemented using openGL API without any performance loss or hackery so there are no single reason why those should belong to OpenGL itself. Higher level functionality goes to higher level libraries.

You obviously dont understand how hard it is to write code that can put pixels on a screen. You go ahead and do it, then come back and tell us you're thankful for OpenGL. It does not matter what you think a library should do, different people have different opinions. OpenGL provides the user a way to manipulate every pixel on the screen to do something they want, I'm pretty sure thats more problem solving than a library that is simply a wrapper for those low level functions.

OpenGL isn't there to handle 3D lighting, or model loading, or other high-level and game-specific features. If you want these things, you should be using a library built on top of OpenGL like LibGDX or jME.

If this post is true, it sums up how lazy OpenGL dvelopers are. And You dont seem the get any point of what I've said.

1. OpenGL is not a library itself, it's a standard, an API. The implementation happens at the guys who write the drivers.2. The programmable pipeline is complex. It does a lot of work for you. I want you to implement the OpenGL Shading language, which compiles to GPU assembly. I want you to implement Tessellation shaders. I want you to implement all the stuff that a driver has.If you think they're lazy, you could simply lazily write your own driver for a graphics card of your choice, and you'd see how lazy those people are.

If this post is true, it sums up how lazy OpenGL dvelopers are. And You dont seem the get any point of what I've said.

Driver programmers need to adhere to the OpenGL spec. Trying to force fixed-function pipeline alongside new extensions greatly increases the complexity of the spec, and leads to more bugs in drivers and less time for them to work on optimizations and new features.

This is like saying the W3C is lazy for not including a more game-centric API in HTML5 Canvas. It's not up to the W3C to implement this high-level functionality. They write a low-level rendering spec which browsers should be adhering to.

Then, it's up to us programmers to write libraries on top of this technology.

--

And yes, it is all about laziness. Your own laziness, for holding onto the deprecated fixed-function pipeline.

OpenGl isn't like DirectX in that DirectX implements a library of APIs targeting game developers. It even supported loading .x models natively. (That said, writing and parsing other model formats usually isn't all that difficult.)

The library includes DirectPlay for networking, DirectSound for audio, DirectInput for external controllers etc...

OpenGL is not DirectX and it never will be. OpenGL is a graphics library for interfacing with your graphics device, if you want something more powerful, look for a game engine etc... If we had it loading models for you it would muddy up its purpose of being a general purpose graphics library.

lukasz1985 you seem to think OpenGL is something it is not. If you want a game framework, you should be using something built on top of OpenGL like JME.

OpenGL isn't there to make your game for you. It's there to provide a low-level rendering specification that drivers will be able to implement uniformly. Let's say for a second that OpenGL is an extremely complex library with model-loading, normal mapping, a scene graph, etc. But then every driver would also need to implement those functions. And, in reality, you would end up with a lot of drivers that don't, a hell of a lot of inconsistencies between drivers, and a lot more bugs. Plus, the driver programmers would be spending their time implementing the high-level functions rather than focusing on delivering performant and optimized new extensions.

Its a very thin API layer between high level code and gpu assembler.its one line to push a texture to the gpu. in gpu assembler or whatever its kinda complex with internal formats and whatnot

but yes its basically a driver api, just that opengl works with all gpus the same whereas the actual hardware implementation can be differentI guess you dont know where opengl comes from, who made, why and whenit never wanted to be more, because there are benefits to separating layers

but yeah, this is also why I would never use opengl directly, unless for a few calls, you really want to have a framework on top of that to be productive

OpenGL does awful lot of things. It's virtualizes whole hardware from you. It's nothing but thin layer, if you don't believe ask any console developers who actually use API's that are just thin layers.

OpenGl have to to lot error checking, validation, memory managin and even garbage collecting.

Anyways; you seem to be stuck in the past. You can continue using Fixed-Function and you'll get the same limited feature you're familiar with. Or you can join modern GL drivers and start programming your own shaders; ones that might be more complex or more optimized than what the fixed-function provides.

If you think GLSL is bad, be glad you aren't writing AGAL which is part of Adobe's new Stage3D.

If you find yourself repeating a lot of code, then you should be re-using it as a library. This applies to all aspects of programming, not just OpenGL and graphics programming.

Quote

So why would manufacturer not provide the OpenGL compliant drivers if that is the one of the leading standards? This would drop the card from the market, right? (if not taking direct3d into account)

Don't be naiive -- this stuff happens all the time. Look at mobile or WebGL bugs for examples of things not working according to the spec.

Dude. Shut up and let it go we get it, you don't like OpenGL because it has "identity" issues. No one wants to hear it anymore.

Sometimes you talk too much, opiop65. You shut up now.

What? What have I ever said that would make you say that? I'm sorry for saying shut up, I was a little grumpy but other than that I stand by my response. I'm sick of this whole OpenGL sucks because it doesn't have classes to make the library higher level. We all know what OpenGL is, and trying to convince me that it isn't a high level library has no point because everyone knows that already!

Dude. Shut up and let it go we get it, you don't like OpenGL because it has "identity" issues. No one wants to hear it anymore.

Sometimes you talk too much, opiop65. You shut up now.

What? What have I ever said that would make you say that? I'm sorry for saying shut up, I was a little grumpy but other than that I stand by my response. I'm sick of this whole OpenGL sucks because it doesn't have classes to make the library higher level. We all know what OpenGL is, and trying to convince me that it isn't a high level library has no point because everyone knows that already!

Well besides being rude and contributing nothing to the discussion (just dont leave a comment if all you gonna say is shut up),time and time again you talk as if you really now your shit, which is far from the truth.lukasz1985 is probably 28 years old and has A LOT more experience than you.You are saying stuff like

Quote from: opiop65

You obviously dont understand how hard it is to write code that can put pixels on a screen.

As if you are coming from the Atari age and now how to code a game in assemblerJust take a step back

People who are open to opinions and want to learn are a lot easier to talk to than know-it-alls

I think there are people who dont want to mess with programmable pipeline too much - the example with matrices implementation on the client side is the example - there are probably people that possibly dont want to involve in advanced math concepts and hardcore linear algebra.

There are some interesting helpers in JOGL 2 to "replace" this kind of features, for matrices and immediate mode.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org