Why is it so hard to learn graphics programming from scratch?

Why is it so hard to learn graphics programming from scratch?

If you want to make a 3D game, people are quick to recommend you use unity or some big cushy engine.
They don't understand how it works underneath, they just take it like a fact of life.

Most GL tutorials gloss over major details and tell you to use glm without ever explaining what glm does or what it's abstracting away.
And most don't really go much further than teaching you how to draw a rainbow triangle.
It does help that modern graphics APIs function are geared toward projective geometry, which is a dead branch of geometry that isn't even taught anymore.

Other urls found in this thread:

en.wikipedia.org/wiki/Bresenham's_line_algorithm
ogldev.atspace.co.uk/www/tutorial27/tutorial27.html
youtube.com/watch?v=Ulxw9G5mdM4
xenharmonic.wikispaces.com/DAWs?responseToken=b44a5bf5179b4e6ea6331e62da67663d
twitter.com/AnonBabble

Because re-inventing the wheel every time is reserved for autists, and competition among autists have made it such that it's no longer worth the time to investigate these things for the average user.

So now you have two types of people:
1 - people who make games thinking it's the easiest thing in the world because you can literally game engine everything

2 - autists competing to see who can make the barnyard animals also known as "group 1"'s job the easiest

If you want to learn from scratch then you wouldnt be using opengl, you would be writing a kernel and then writing instructions directly to your screen in order to get a linear framebuffer pointer, then you can draw pixels directly to the screen.

So I say it depends on your priorities really, you can make your own custom OS or you can use an existing tool which may or may not be of your liking.

>Why is it so hard to learn graphics programming from scratch?

The standard is constantly updating, so most tutorials have out dated API usage.

Most tutorials are based off of C++, which is constantly being updated, so most code is in bad style.

Most tutorials are shit.

en.wikipedia.org/wiki/Bresenham's_line_algorithm

Don't even start without practicing your Linear Algebra first.
Multiply matrices and vectors by hand. Manually construct transformation matrices on paper.
>hurr durr I took LinAlg 5 years ago. I "know" it.
Practice until you can do it in your sleep.
Everything will be a breeze then.

>Why is it so hard to learn graphics programming from scratch?

>the APIs are designed towards quintuple A games, not towards user friendlyness
>the topic requires tons on math stuff
>in reality you sometimes have to cheat
>most docs on both the APIs and the maths stuff sucks, so if you weren't lucky enough to have had a good university course, you're most likely rekt

>people are quick to recommend you use unity or some big cushy engine.
>They don't understand how it works underneath,

Because they know they could spend their entire life making another 3D game engine, and it won't even come remotely close to what's already available on the market.

Ron Gilbert writes his 2D adventure game engines from scratch. The embedded scripting language is DIY too.

This, game engines are more than just graphics programming.
Which is why I chuckle everytime some idiot provides some basic 3D renderer with Lua API or when FrozenByte gets a new lightening renderer.

that image is too accurate

Well, everyone has his vices, I guess.

All GLM is is a library that handles vectors and matrices. It has nothing to do with OpenGL. This is what you should use whenever you find yourself dealing with linear algebra or making a "typedef struct{float x; float y; float z} vector_t;" in a program

You should use it because:
> it's fast (uses SIMD)
> has overloaded operators which is convenient
> will make the math more managable

Projective geometry is still taught in colleges

The whole point of opengl is that they are projecting geometry onto the screen

It just depends on what you want to bring to your industry. Do you want to be an artist or do you want to build the systems and tools artists use everyday? If the former, learn a popular tool and get really good at it. If the latter, dive into the deep end.

So many different engines exist today because of billions of dollars and thousands of man hours.

It's like trying to ask why people don't just DIY their own computers. It's because you can't just solder new CPUs together because you put a clock's guts in a box once.

You want to work from scratch? Try programming simple games in ASM or C on simple little microcontrollers.

>commercial engines
and you've just locked yourself into a box.

Digital Audio Workstations fall apart when you try to break the cultural boundaries. Xenharmonic composers resort to Microsoft Excel because no commercial DAW supports it well.

Try to make a game with non-euclidian geometry or more than 3 dimensions in Unity, and see how far you'll get.

Of course, if all you're after is the 100000th shooting or racing game, none of this matters.

>creating mistuned music
>complaining about lack of support
jk
Anyway, pretty sure all 4d tetrisses and monochrome like games have been exhausted.

So many transformations. Not a fan personally.

And by monochrome I meant echochrome.

kill urself my man

I'm just a beginner and even I know that it would take me years to build up a decent 3D engine when I can simply use what professional teams built for us.

As we say all the time : "why reinvent the wheel?"

Not happy with a particular render? I can simply rewrite the shading process...I don't really care about the rest I know I can't make it look better working alone.

everyone agrees that properly tuned music sounds good

what the fuck does that even sound like?

> being a pleb

You'll notice that all the gaymes that come out of the same engine look the same. the overhead limits what you can do.

You can make an aesthetic game if you know what you are doing. Use techniques like solid colors instead of textures to keep the code simple and fast. strategic Low poly models and heightmaps as well.

>implying textures are a strain on GPU hardware in 2017

>You'll notice that all the gaymes that come out of the same engine look the same. the overhead limits what you can do.
The reason that sometimes games made with an engine look similar to other games made with that engine is because the developers used presets provided with the engine, not because of "overhead".

I made this in C. I'm using SDL2 and manipulating pixel information directly.

There are books on this topic.

They're just as bad as online tutorials.

Scratchapixel is quite good. I'm writing a software 3D engine to get familiar with the pipeline and practice the relevant maths.

How i can draw 10 of these with different positions in one draw call?

bump

What is the thought process behind constructing transformation matrices?
It seems completely arbitrary to me

an arbitrary number of transforms can be queued into a single transformation matrix, and then your vertices can be transformed just by multiplying by it

Because graphics programming actually requires math and most so-called "programmers" have done no Linear Algebra, has never heard of an eigenvector, and only knows "gradient" as that thing that makes website backgrounds look pretty.

That's what the geometry shaders is for.
ogldev.atspace.co.uk/www/tutorial27/tutorial27.html

Why assume it wouldn't be hard?

>great deal of general programming knowledge required
>great deal of openGL / DX API knowledge required
>familiarity with external libraries and tools
>linear algebra, relevant algorithms, basic physics
>logical thinking all around
>...

That's a lot of stuff for 1 person to take in and master, can't really be anything else but hard from the beginning. It's a long process in any case.

The reason games get that "Unity" look is because they use the default Unity shaders and lighting models. The game Inside was built with Unity but they put a bunch of work in writing their own shaders and lighting and it doesn't have that Unity look to it.

But if you're writing your own shades and lighting then you're pretty much just using Unity to load resources and read input. That's hardly why most people use Unity.

>gameobject that takes care of mesh data and dealing with culling

>initialising shaders takes work with Directx but not with Unity

>initialising anything in Directx11 takes a shit load of work

I'd suggest using Unity to make the game then "port" it over to DirectX, that way you have full control of the engine going forward.

youtube.com/watch?v=Ulxw9G5mdM4
Pretty sure, there is also a video with someone using a DAW, and while it looks like it's a pita, apparently it's possible xenharmonic.wikispaces.com/DAWs?responseToken=b44a5bf5179b4e6ea6331e62da67663d

and it only takes half a second per frame