Is 3d Graphics the hardest kind of programming ?

1) Is 3d Graphics the hardest kind of programming ? (I mean compared webdev, database, desktop stuffs in C#/Java etc)

2) How long does it take to be a competent 3d graphics programmer like Carmack for example ? (for someone who isn't new to programming)

3) Do you feel C++ is becoming bloated slowly with newer version or hard to choose as a language to create new project in ? (I mean new project in other field outside of games)

4) Do you think graphics programmer are vastly underpaid for the difficulty and works hours they bring in the industry when we heard story like RedDead2, Ea Spouse etc ?

 

Carmack is not simply 'competent' he's a living god of black magic programming with few equals before or since. His particular type of genius is also one that the typical programmer doesn't even need anymore, due to all the aforementioned libraries that didn't exist in his day. A programmer aspiring to be as good as John Carmack is like a guitarist aspiring to be Joe Satriani: a lofty and worthy goal, to be sure, but your career isn't DOA if you wind up being merely capable. Like other disciplines, it takes about 15 years to be fully qualified to lead a project, 5 years to lead a component or subsystem, and a few months to make meaningful contributions to a project.

 

1.) I don't see graphics/game programming to be especially complex. Building my own 3D design software is something I could pull-off. It's not the complexity of the programming so much that it is the complexity of what you're attempting to emulate is what makes a project potentially difficult.

2.) Well, it's a highly competitive field. It depends on how good you are at what you do, and who you know.

3.) I used to associate C++ as being the predominant language in developing 3D systems, but it depends on what platform you choose to work with. If you want to program your own 3D game engine, I would choose C++, but currently, much of what is becoming popular is C# in conjunction with Unity (a game engine).

4.) Well, labor supply and labor demand are the bottom line. Half of these guys would do it fo free to get their foot in the door. You get burnt out fast; it's either boring as hell or a mad rush, and you're easily replaceable at any given time. The game conventions are fun, though!

 

I agree with @scu8a

3D Graphics programming is not as complex as you think it might be.
But yes, its definitely more complex than other coding things, like a desktop app which connects to database etc.

In a desktop database app, you coded/painted a GUI once.
Now you are not changing the GUI itself, you are merely updating values of elements depending on data you pulled out of database.
Like for a textarea field for example. You opened a text file and loaded its contents in this, or simply update a TextField.

You don't have to do all the drawing here. Libraries for this are already done, you simply called the update command.
Like this:

//declare
JTextField userT = new JTextField();

//update (library will draw the text in the textField component)
userT.setText("This text will be shown");

Real simple work.

In gaming however, "you" are drawing the "whole" GUI again and again, depending on key press.
The entire thing is inside a timer which updates every couple of milliseconds. This is where the actual drawing is done.
You cannot keep this too low, or else program will crash. You cannot keep it too high either, or else game will appear sluggish.
Key presses are merely updating an array, tracking which elements will be drawn, and at what position.

Some time back, I coded a JAVA based 3D car driving game. This was my very first attempt in creating 3D game, after having made a couple of 2D ones.
It had only 3 elements.
The exact horizontal middle of the screen was the horizon. Blue sky above that, and my car and road etc in the bottom area.

1. A car steering wheel, at the bottom center screen.
2. A road, broad near the bottom of the screen, and narrows as it moves towards the center of the screen.
The road was narrowest at the horizon point.
3. An electric lamp post.

In 3D coding, the element which is controllable, that element does not moves away from the center too much. Its the rest of the imagery which changes as movement keys are pressed.

So in my practice game, steering wheel was fixed at bottom center.
When left or right arrow keys were pressed, the code would paint the road slightly to the left or slightly to the right, depending on the key.
It would appear as if the car moved left or right, but in reality, the steering wheel is fixed, its the road which is painted on a different X axis.

When forward key (up arrow) is pressed, the lamp post, which was painted "small" near the horizon,
that changed position.
Its paint Y axis increased, and its height and width increased.
The X axis would either increase or decrease.
If lamp post is to the left of the road, X axis would decrease.
If it was to the right, X axis would increase.

All in all it would appear as if the lamp post is coming closer because car is moving ahead.

This was not a very difficult code, and served as basic layout for something bigger.

Like if you want to add more elements to the screen, a flying bird, a floating cloud in the sky, animals running away from road as car approaches them, etc etc.

The complexity depends on how many elements you want to add, how many frames you want to show, can you load all frames in memory at once or you only load a few when game starts and keeps loading more as it proceeds.
You cannot put too much in memory at once, and you also cannot keep reading files for every key press...

Like if your character enters a room, load its imagery in memory, and now keep redrawing it as the character moves around.

When the character leaves this room and enters another,
do a quick clean up of memory,
load new imagery , reset drawing points, and now keep redrawing this new room as character moves around.

Add sound, add an opponent firing at the character, and you got a 3D shooting game.

The smoothness comes from your calculations.
I am sure you have seen 3D games where an element, lets say a shooting opponent, moved near a wall, and it started appearing as if half that man has passed "through" the wall.

This happens because of calculation errors.

The wall is being painted at 300 x axis, for example.
The man is at 100x.
His body width is 20 pixels, height also 20px.
So image block of this element is 20x20, positioned at 100x40.
Now when this man moves right, towards wall at 300x, you only have coordinates of his position, like this:
100x40
110x40
120x40
and so on.

So once this element has moved till "280x40", you must stop his further movement towards right, as he has already hit the wall.
In a careless code, you will use the limit of 300 to stop movement.
In a better code, you will stop at 280.
On a fixed code, this is easy.

Problems start happening when you are also redrawing the wall because your controllable character is also moving right.
To make the "illusion" that your player is moving right, you will need to redraw the wal leftwards more and more.
Now the X axis of the wall is also changing so you need to adjust physical positions of other elements accordingly.

Its this type of calculations that makes 3D coding complex.

For a lot of stuff you can get libraries to make things easier for you.
But this industry is so competitive that very soon that library will become obselete, cause some other developers came up with a better and smoother display, so you need to get new basic engine modified for your projects, meaning newer libraries which can handle things better.

 

Yes being a competent graphics programmer is hard compared to just "coding" everyday apps, which involved things such as graphics programming and etc

 

3d is one of the simplest programming...