Graphics programming

Anyone here is decent at graphics programming? How did you start? How did you learn shaders? Share your tips plz

Attached: 3d-graphics-water.jpg (619x300, 31K)

Other urls found in this thread:

open.gl/
youtube.com/watch?v=HSmm_vEVs10
youtube.com/watch?v=k12cf15VvV4
paroj.github.io/gltut/
twitter.com/SFWRedditVideos

I started by dissecting an already existing game engine to make my own
Learnt shaders by reading examples, they aren't diffiicult
The hard part is writing an architecture around the annoying procedural rendering pipeline to turn it into something flexible and scalable

Thanks man, if anyone else has some input as well plz provide it

i started learning unity yesterday through their tutorials. when it came to writing player movement scripts i was so fucking lost. since this thread is somewhat related, how do i git gud?

I'm reading vulkan programming it's pretty neat
Is vulkan the future?

I learned OpenGL, but it took time. Most of your time will be spent trying to figure out how the hell all the pieces fit together, and it doesn't help that debugging is a pain. If you go the OpenGL route, first realize that there's the old way of doing things, and the new way of doing things. Many tutorials are old and don't tell you.
The best resource I've found is:
open.gl/
On top of that, be prepared to Google-fu your way to victory.

NOW, from what I've heard, it's best to learn whatever API is native to your operating system. In Windows, this would be DirectX. I hear debugging is great, and it's generally better than OpenGL, though somewhat on the same level of badness in many respects...

I started with simple 2D sprite stuff, then moved on from there after a had an okay grasp on how the principles work. It will take time, and lots of trial and error, but it's well worth the effort. Don't be discouraged if you get stuck for a week(or longer) on a problem, it happens, and it's part of the learning process.

>Is vulkan the future?
maybe
I wouldn't recommend learning it until vulkan is the present

read more, write more, lurk more

Shadow casting will kick your ass.

I started with SDL2, GLEW and OpenGL, first putting a triangle on screen with basic GLSL vertex and fragment shaders, then started getting familiar with vectors and matrices, and vertex arrays, and used that as a starting point.

write your own software rasterizer and your own raytracer if you want to learn how graphics really work. Learning directx or opengl is a matter of understanding the pipeline and not getting caught up in syntax.

For shaders also try to understand the pipeline, where they are used, what are the different stages, the rest is simply algebra and creativity to try to come up with cool shit.

The water in your image is probably a smoothed particle hydrodynamics simulation using position based dynamics. the hard part here is the physics simulation not the water shader which is probably a screen space shader that captures the depth of each particle then blurs it using gaussian blur.

>tfw nasty buffer shadows will soon be obsolete
Realtime raytracing can't come soon enough.

>write your own software rasterizer and your own raytracer if you want to learn how graphics really work
waste of time

It's a meme.

Not really. Buffer shadows are plagued with limitations, but we use them because it's a 'good enough' general purpose solution for shadows. Lighting in modern game engines is a huge pile of jank, and I welcome, with orgasmic glee, the next best thing that comes along.

Yes i know, but i bet there are other ways to cut this cat other than a massive brute force shit that only work on Nvidia.

>The hard part is writing an architecture
This. I was surprised to find that most modern shading techniques are actually very straightforward, with the only thing keeping older games from using them was computational cost.

We use them because they're more efficient. That hasn't changed, so raycasting remains a meme, unless computation power increases by an order of magitude

Spent 5 years making a 3D game engine/library. Started by doing things one small detail at a time.

Terrain:
>render simple heightmap
>interpolate for smoothing
>incorporate blend mapping less blockiness
>then bump mapping for more detail
>then shadow mapping for more detail

Water:
>render simple transparent blue tile
>reflection shader
>refraction shader
>overlap opposite moving maps for ripple effect
>shader and algorithms for things like fresnel effect

Just step-by-step everything until you get a realistic result. Think of something you want to do and look at previous methods of doing so, then methods of optimizing it.

do you have it online?

Oh yeah, the I wrote the entire engine on a component based architecture to make it easier to utilize. Core graphics were OpenGL. 3D models could be parsed from a few different modeling software like Blender.

>other than a massive brute force shit
Yeah, agreed. I think devs are planning on getting around this by using raytracing in very limited contexts(shadows only), plus denoising.
Some cool stuff: youtube.com/watch?v=HSmm_vEVs10

My problem with them has to do with how they severely limit a game's visual style. Buffer shadows merely darken things by some absolute value, which gives things a cartoony look. They also have trouble solidly connecting to objects that intersect each other, and resolution troubles that require extra layers of complexity.
youtube.com/watch?v=k12cf15VvV4
We're getting there, it's only a matter of a couple years before the hardware is fairly standard and powerful.

Nah, it was just a project I did to add to my portfolio and gain abstract programming experience.

I did make a post on a forum about it at some point, but it was a couple years ago and before a lot of the more advanced graphics shit was added. Here's the pic from the demo back then. Took maybe 10 minutes to create IIRC

Attached: 20180925_174907.jpg (1043x678, 191K)

That was testing the fresnel effect (reflection:refraction based on angle relative to plane)

>Buffer shadows merely darken things by some absolute value
you can make buffer shadows do whatever you want
we can already do real time raycasting, it's just slower, so you're always going to be able to get more fidelity out of tradtional approaches, until things become so fast that it doesnt matter anymore

Buffer shadows are just a input value you can use for anything you want.
Any sane regular rendering engine use the result as a mask to covering the light related to the buffer, so the indirect light pops out of it correctly.

Actually, yeah. After I posed I realized I was probably wrong. Looking at the lighting in Uncharted 4 as an example, it's pretty damn impressive. I think I'm just used to shitty, no good implementations of it.

It's only around the half of the last generation that the developers got their shit together and learned how to properly use shadow casting.

Okay but only because you said plz. Start by learning Java. Then learn to load an image and display it in the screen. If it doesn't take you should give up here, else go onto OpenGL or another API.

Have solid geometry/trig background.

I'm programming in Vulkan and would not recommend it for beginners. If I didn't have a few years in OpenGL I'd really struggle

Keep trying for years you fucking newb. Anything worth doing takes time and effort.

I highly recommend following some textbook which runs you through building your own engine with some library (probs OpenGL)

I'm trying to learn Vulkan so I can write a Wayland compositor + DE + widget API from the ground up with modern technology. Build it for Linux natively and exclusively; a lot of jank in modern software is portability code. I probably won't get very far but it'll be a great learning experience. And, hell, maybe I'll get something usable enough for my own needs, and that'll be good enough for me.

this post is so Jow Forums

I started by jumping straight in with Vulkan and it has been very difficult.

Currently, I feel as if I'm at a disadvantage because any discussion about graphics usually refers to OpenGL conventions and since I'm not familiar with OpenGL, I don't have that reference to translate things into Vulkan.

paroj.github.io/gltut/


this is a reference gl;hf

Attached: 01.gif (160x160, 38K)

use openGL
you may have been trained as a consumer to always desire the latest and shiniest thing but when it comes to picking technology to work with you should choose things that are tried, tested, popular and well-documented

Way too late for that.

it isnt

it is, incel

I could port my full renderer in a few weeks if I needed to, if you've just started you can switch

I've read multiple Vulkan books and have an engine with 10,000 lines of code.

looks good, thanks.

I'm surprised there are multiple Vulkan books
If you have something that's just a renderer and it's 10,000 lines you have some serious refactoring to do

One of the appeals of Vulkan for me is that i can actually read every book on it because there's on a few right now. I'm also interesting in possibly doing a paper on it in the future if I do my masters so it's good to get in early.

10,000 lines is the engine and all its libraries that I've written. It's in plain C...

>It's in plain C...
you have my condolences

Pussy bitch. I bet you don't even write your own data structures.

i do

Are there any jobs in this field?

What I love most about water is caustics. It makes me feel comfy to sit in my pool and look at this thing.

Attached: file.png (852x480, 638K)

>youtube.com/watch?v=k12cf15VvV4
that looks nice but why do they have neutral spanish in a mexican setting

The thing that blows my mind about that youtube video, is that the vast majority of people think the shadows done currently look better because they are CRISP. They don't understand how real life works.

Not many. Even less outside of research positions at universities and places like Oculus.

As a game dev maybe, but then you need to find a studio big enough to have a dedicated graphics programmer. I can't imagine it'd be fun trying to get a job solely as a graphics programmer. Especially outside of the US/some European countries.

>learn how something works
>a waste of time

and this is how you end up with fuckstains publishing games made with unreal engine that look and run like shit despite having the game equivalent of a jet engine powering them.

I want to learn vulkan and implement something. Should I use C++?