[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]

λ - programming

/lam/bda /lam/bda duck
Name
Email
Subject
Comment
File
Password (For file deletion.)

BUY LAINCHAN STICKERS HERE

STREAM » LainTV « STREAM

[Return][Go to bottom]

File: 1435475150086.jpg (6.95 KB, 323x305, triangle.jpg) ImgOps Exif iqdb

 No.7117

Graphics general didn't fare so well on /g/. Lets see how it goes here.

Thread for
- OpenGL
- DirectX
- Mantle
- Vulcan

and the practice and learning thereof!

Some resources for getting started:

- https://open.gl/
- http://www.tomdalling.com/blog/modern-opengl/
- http://antongerdelan.net/opengl/
- http://ogldev.atspace.co.uk/
- http://opengl.datenwolf.net/gltut/html/index.html

Got any graphics projects going lains? Any tips for newcomers? Need help? Let's hear it!
>>

 No.7118

Any reason to use something other than OpenGL?

>>

 No.7123

>>7117
First of all, I love graphics programming, have been learning it from scratch for nearly a year now. Bit strange that /g/ isn't deeply into it, since it seems to me the most exciting thing you can do with a computer.

Second, that triangle should be an official banner for graphics newbies - the hello-world of graphics programming, or like the glider to hackers.

>http://opengl.datenwolf.net/gltut/html/index.html

I learned from this, great book but sometimes it can be very hard to understand. But man was I patient and diligent with it. Currently reading the textures chapter. Up to this point I know all but the "dynamic lighting" and "imposters" chapter indepth

>>

 No.7124

I'm interested in it, but am still learning how2C++ in my spare time.
>>7123
I might have to pick this up and give it a read some day.

>>

 No.7125

I want to get into graphics programming, but I've been waiting for Vulkan. Should I just work with OpenGL until then, or continue to wait?

Also, does anyone have an idea when Vulkan is supposed to be released?

>>

 No.7126

>>7125
I would imagine that having a basis in graphics programming would help with learning Vulkan.

>>

 No.7128

>>7124
Great idea, the examples are also written in C++ and they taught me a thing or two about the language

>>7125
Go ahead and learn you some Opengl, the basics are transferable and the math is timeless. Hence you won't regret investing your time in gl

>>7118a

you could learn to use one of the graphics engines

>>

 No.7138

What do you guys use to get a window and an ogl context up?

Preferably something portable, and for C or Common Lisp.

>>

 No.7142

>>7138
GLFW is a really nice lib for C: http://www.glfw.org/

But as we Lispers know, C is a super-lame blub language. Check out this: https://www.youtube.com/watch?v=a2tTpjGOhjw . This guy's library, CEPL, has a really cool approach to graphics in Common Lisp. I recommend you watch a few of his videos. They're pretty cool.

You can install it with Quicklisp. Here's the project page: https://github.com/cbaggers/cepl

>>

 No.7143

File: 1435551319054.png (489.73 KB, 500x600, tumblr_mqy4iostom1rva5t1o1….png) ImgOps iqdb

oh soykaf city by moonlight is this thread relevant to my interests

I have sdl2 for my android (comp is dead btw) but just... fuarrrk no. Thank you for the links op

>>

 No.7147

>>7142
I was eyeballing that, but it seems unfinished. Maybe I'm wrong.

Since I've never used OpenGL before, I was thinking of first learning OpenGL using C by going through some tutorials, then just using cl-opengl (because it's pretty much a 1:1 mapping to the functions) and writing some basic abstractions so the window and event handling, and some more common and basic uses of opengl stays out of my way.

Unrelated curiosities:
IS that a fuarrrking x window in an emacs buffer? How?

Was the drawing part of his screen recording software, an external program, or emacs?

>>

 No.7148

>>7147
>IS that a fuarrrking x window in an emacs buffer? How?
Just realized that it's just a normal window set to "stay on top".

>>

 No.7155

>>7138
cl-sdl2, or it's more convenient wrapper sdl2kit.

Both allow live-coding, but sdl2kit provides it by "default"

Also cl-opengl is awesome, it has also an automatic read-time conditionals (#+) debugger tags sprinkeled through the code, so you don't have to use gl:error to debug.

>>

 No.7581

Let's share what we are working on:

I'm using the opengl api calls directly for a simple painting program

>>

 No.7591

Does anyone have any good resources for loading .md5 files? I tried for a couple weeks off and on to get md5 loading working in one of my OpenGL engines, and sweet baby jesus it was a pain in the ass.

>>

 No.7602

>>7591
Try Assimp, a C++ library for importing a variety of formats. There are also C bindings.

>>

 No.8570

>>7123
>Unofficial OpenGL SDK
Looks yummy.

>>

 No.8660

>>7581
>Let's share what we are working on:
I'm working on a GLSL debanding shader.


// Wide usage friendly PRNG, shamelessly stolen from a GLSL tricks forum post
float mod289(float x) { return x - floor(x / 289.0) * 289.0; }
float permute(float x) { return mod289((34.0*x + 1.0) * x); }
float rand(float x) { return fract(x / 41.0); }

// Helper: Calculate a stochastic approximation of the avg color around a pixel
vec4 average(sampler2D tex, vec2 pos, float range, inout float h)
{
// Compute a random rangle and distance
float dist = rand(h) * range; h = permute(h);
float dir = rand(h) * 6.2831853; h = permute(h);

vec2 pt = dist / image_size;
vec2 o = vec2(cos(dir), sin(dir));

// Sample at quarter-turn intervals around the source pixel
vec4 ref[4];
ref[0] = texture(tex, pos + pt * vec2( o.x, o.y));
ref[1] = texture(tex, pos + pt * vec2(-o.y, o.x));
ref[2] = texture(tex, pos + pt * vec2(-o.x, -o.y));
ref[3] = texture(tex, pos + pt * vec2( o.y, -o.x));

// Return the (normalized) average
return cmul*(ref[0] + ref[1] + ref[2] + ref[3])/4.0;
}

vec4 sample(sampler2D tex, vec2 pos, vec2 tex_size)
{
float h;
// Initialize the PRNG by hashing the position + a random uniform
vec3 m = vec3(pos, random) + vec3(1.0);
h = permute(permute(permute(m.x)+m.y)+m.z);

// Sample the source pixel
vec4 col = cmul*texture(tex, pos);

for (int i = 1; i <= ITERATIONS; i++) {
// Use the average instead if the difference is below the threshold
vec4 avg = average(tex, pos, i*RANGE, h);
vec4 diff = abs(col - avg);
col = mix(avg, col, greaterThan(diff, vec4(THRESHOLD/(i*16384.0))));
}

// Add some random noise to the output
vec3 noise;
noise.x = rand(h); h = permute(h);
noise.y = rand(h); h = permute(h);
noise.z = rand(h); h = permute(h);
col.rgb += (GRAIN/8192.0) * (noise - vec3(0.5));

return col;
}


Thoughts? I would greatly appreciate any suggestions

>>

 No.9680

http://www.opengl-tutorial.org/

is this series of tutorials good? I read the first 4 tutorials (making a cube with colors) and the one on VBO Indexing to render some fractals. It was a lot of fun but I wanted to make sure that I wasn't screwing myself over by learning bad fundamentals.

>>

 No.9681

I want to write a 3d graphics screensaver for linux. But i have no programming knowledge whatsoever

what do?

>>

 No.9698

>>8660
Looks cool, but I'm having trouble visualizing. Could you post some moving images?

>>

 No.9702

>>8660
awesome, wanted to do something like this as well.
I will take a look at it some other time.

>>

 No.9722

Does anyone know a graphics library or functino (c/c++) where I can just specify the location of a pixel, and then its color? I don't care about all these polygons and gradients, I just want to be able to manipulate an array of pixels.

>>

 No.9723

>>9722
sdl 1.2 would let you do that, not sure about sdl2.

>>

 No.9744

I know there a good quantity on Haskellers here, so that might be interesting. I was doing a project using OpenGL raw bindings (urgh), and it worked more or less well, even if I wanna vomit when I look at my code.

Has anyone tried `not-gloss` [https://github.com/ghorn/not-gloss]? Is it worth to try?

And I just saw it today, there is this really new library called `luminance` [https://github.com/phaazon/luminance], seems nice, and it seems to be willing to add Vulkan support when it's out.

>>

 No.9745

>>9744
>luminance
looks good.
I tried to do some opengl stuff in haskell, and it was kind of horrible, so its nice to see someone give this some attention.

>>

 No.11066

>>7117
The X11 thread is dead, so I'll ask here.

The only feasible and current bindings I'm aware of are XCB.

What would be a good place to start with all of this? Reading the extensive and unwieldy X11 protocol documentation is something I'd rather not do except when I have to.

>>

 No.11068

>>11066
>What would be a good place to start with all of this?
The only winning move is not to play. Use a widget kit or some other higher level library like everybody else.

>>

 No.11069

>>11068
I figured that would be the case.

Should I use motif, gtk, or qt?

>>

 No.11070

>>11069
If you just want a window you can render OpenGL to + user input glfw is pretty easy to use.

A lot of tutorials pick a library to use as a shim for cross-platform development. If you're following a tutorial just use whatever they are.

>>

 No.11075

I'm getting started on glsl, need some knowledge for a js/webgl soykaf I'm doing. The same shaders will be portable to other platforms such as a c-opengl game? Recommended learning resources?

Also, I've always been fascinated about the demoscene. What are the skills required or learning path towards being a demoscener?

>>

 No.11085

>>11075
>The same shaders will be portable to other platforms such as a c-opengl game?
GLES (what webgl uses) is mostly a subset of big GL so porting from GLES to big GL is fairly easy. The primary issue is versions because GLES versions don't correspond well to GL versions, even though pretty much every feature in GLES is present in some version of big GL. Porting from GLES to big GL is much easier than the other way.
>What are the skills required or learning path towards being a demoscener?
You have to be good at a lot of things, or else know people who are, or else have the patience to do things you're not good at. I've tried making demos a few times and I've made some cool effects but when it comes time to add music or choreograph it I lose interest. Also when you watch demos they often seem repetitive, but once you try to make one you'll see that there are usually a ton of different effects crammed into a short time so it takes a lot of work. You might spend days working on an effect that will only be visible for 2 seconds.

>>

 No.11098

>>7117
I really like SDL 1.2 since it's super simple.
They made SDL 2 look more like OpenGL which should make some things easier in the long run but it made it harder to just make something quick.



Delete Post [ ]
[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]