Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Where to start with 3D?  (Read 3039 times)
0 Members and 1 Guest are viewing this topic.
Offline samcp12

Junior Member


Medals: 1



« Posted 2013-09-23 18:47:13 »

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!

 Cool
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #1 - Posted 2013-09-23 19:26:57 »

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.

Offline pixelapp

Junior Member




Pixelapp


« Reply #2 - Posted 2013-09-23 19:27:57 »

http://www3.ntu.edu.sg/home/ehchua/programming/index.html

Cloud games and fun.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pitbuller
« Reply #3 - Posted 2013-09-23 21:50:36 »

It would be nice if OpenGL has kept the fixed pipeline developed along the programmable pipeline. There would be no hassle to write shaders for almost everything.

Shaders are just small programs. Programmers write programs. Programmable gpu is good for programmers. Fixed pipeline is just hard way to do things wrong.
Online Jimmt
« League of Dukes »

JGO Kernel


Medals: 133
Projects: 4
Exp: 3 years



« Reply #4 - Posted 2013-09-24 17:59:59 »

Keep it civil, please...
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #5 - Posted 2013-09-24 19:19:15 »

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.

Offline pitbuller
« Reply #6 - Posted 2013-09-24 21:30:47 »

"Programmers write programs."

Seriously? I thought they write poems.

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.

There are software libraries that emulates full fixed function pipeline using shaders. Why you don't use those?
https://code.google.com/p/gles2-bc/
Offline pitbuller
« Reply #7 - Posted 2013-09-24 22:43:53 »

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

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #8 - Posted 2013-09-25 01:00:03 »

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. 

Offline davedes
« Reply #9 - Posted 2013-09-25 01:43:07 »

This post sums it up pretty well:
http://stackoverflow.com/a/1218469

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Cero
« Reply #10 - Posted 2013-09-25 11:11:19 »

You should realize that this has nothing to do with being lazy. Those were all conscious decisions that were agreed upon.

Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #11 - Posted 2013-09-25 11:36:14 »

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.


See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline davedes
« Reply #12 - Posted 2013-09-25 13:51:37 »

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

Offline Jeremy
« Reply #13 - Posted 2013-09-26 12:17:19 »

Am I the only one here who thinks that way too many threads on JGO turn from a question, to a controversial tip of advice, into an argument all in the same thread?

This really isn't appropriate for this thread at all...

Anyway, this thread outlines explicitly why OpenGL can't be compared to DirectX (just an FYI)

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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline davedes
« Reply #14 - Posted 2013-09-26 12:28:27 »

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.

Offline Cero
« Reply #15 - Posted 2013-09-26 13:18:03 »

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 different
I guess you dont know where opengl comes from, who made, why and when
it 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

Offline samcp12

Junior Member


Medals: 1



« Reply #16 - Posted 2013-09-26 20:15:44 »

Ok, I have no idea what you guys are even talking about but thanks for the links  Tongue
Offline pitbuller
« Reply #17 - Posted 2013-09-27 08:24:22 »

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.

Everyone should read this http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ and learn how modern hardware works and compare that knowledge to openGL api. Drivers are really complex.

lukasz1985: You seems to have no experience using shaders for actual production. So stop trolling.
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #18 - Posted 2013-09-27 10:35:44 »

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.

Offline davedes
« Reply #19 - Posted 2013-09-27 13:02:14 »

There is no "1:1 mapping of machine code." You think glTexImage2D exists in assembly? Roll Eyes

Take a look at the spec and tell me it would be "easy" to implement your own graphics driver that adheres to it:
http://www.opengl.org/registry/doc/glspec43.core.20120806.pdf

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.

Offline Cero
« Reply #20 - Posted 2013-09-27 14:07:26 »

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.

Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #21 - Posted 2013-09-27 21:05:45 »

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!

Offline Cero
« Reply #22 - Posted 2013-09-27 21:15:23 »

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 assembler
Just 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

Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #23 - Posted 2013-09-27 22:39:42 »

Ok, thanks for pointing that out, I'll work on it. Im sorry for being rude, I didnt mean to be.

Offline Cero
« Reply #24 - Posted 2013-09-28 01:20:35 »


Offline pitbuller
« Reply #25 - Posted 2013-09-29 19:34:24 »

Ifyou still think openGl/direcX(rendering part) drivers are not doing anything for you just look to this http://www.eurogamer.net/articles/digitalfoundry-could-amd-mantle-revolutionise-pc-gaming
It's more console kind, true low level API.
Offline gouessej
« Reply #26 - Posted 2013-09-29 19:48:32 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (20 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (28 views)
2014-09-21 23:33:17

BurntPizza (64 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (42 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!