Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3D Game Shaders for Beginners

github.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: 3D Game Shaders for Beginners

#41

Post by planteen »

Jasper_ wrote: post #36
planteen wrote: post #35

Earlier quoted context omitted.

I have been wondering why WebGL isn't getting updated to ES 3.1 (and 3.2). Good to see at least 3.1 parity is coming: https://www.khronos.org/registry/webgl/specs/latest/2.0-comp... (I didn't know it was on the horizon until I saw your link). I wonder if getting to ES 3.2 is on the horizon as well? That would bring geometry and tessellation shader support.

I refer to the Mali Performance Guide for wisdom into Geometry Shaders: https://static.docs.arm.com/100019/0100/arm_mali_application... > Using geometry shading will generally lead to worse performance, high memory bandwidth, and increased system power consumption. Assert if geometry shaders are used Geometry shaders are not what you want. They should not have been included in GL ES, and I will fight their inclusion…

Yes, I agree the performance is an issue in most use cases, but wouldn't you agree there is value in there being parity between WebGL and OpenGL ES? It's valuable for those of us who work with Emscripten to cross-compile apps for the web.

And there are things like line drawing algorithms that have uses for geometry shaders: https://github.com/paulhoux/Cinder-Samples/tree/master/Geome...

It's not like geometry shaders are specific to OpenGL ES. Desktop OpenGL has them, as does DirectX and Vulkan.

Re: 3D Game Shaders for Beginners

#42

Post by Guthur »

Inityx wrote: post #10
barbwire wrote: post #4

Am I just out of touch with what the kids today are doing, or is this formatting really as bonkers as it seems? int main ( int argc , char *argv[] ) { // ... LColor backgroundColor = LColor ( generateLightColorPart(207, 1) , generateLightColorPart(154, 1) , generateLightColorPart(108, 1) , 1 ); // ... } I can (sort of) see that this makes it easy to comment out parameters - except for the first one...

It's a hacky workaround for languages that don't support trailing commas

And more widely; languages that burden the programmer with such extraneous grammar in the first place.

Re: 3D Game Shaders for Beginners

#43

Post by JacobiX »

aurelwu wrote: post #31
JacobiX wrote: post #26

Earlier quoted context omitted.

I agree with you, however in almost all commercial games that I worked on, we do write our own shaders. For simple shaders, artists use directly a graphical tool included in unity for shaders authoring without writing any code, for complex ones we write our own code.

do you write them completely from scratch or do you write custom nodes for whatever node-based shader editor you use? I am a novice when it comes to shaders but I wonder about the performance difference between hand written shaders vs generated from a node-based editor.

Nowadays it's more valuable to create custom nodes to enrich the node-based editor library. Sometimes we write shaders from scratch if we need to implement some original lighting, materials, etc

Re: 3D Game Shaders for Beginners

#44

Post by whateveracct »

jchw wrote: post #5
barbwire wrote: post #4

Am I just out of touch with what the kids today are doing, or is this formatting really as bonkers as it seems? int main ( int argc , char *argv[] ) { // ... LColor backgroundColor = LColor ( generateLightColorPart(207, 1) , generateLightColorPart(154, 1) , generateLightColorPart(108, 1) , 1 ); // ... } I can (sort of) see that this makes it easy to comment out parameters - except for the first one...

Reminds me of how Elm lists are formatted; I have a hunch it may be something more common in Haskell, but that's pretty much a shot in the dark.

Yeah this is Haskell formatting

Re: 3D Game Shaders for Beginners

#45

Post by abower »

FPGAhacker wrote: post #6
barbwire wrote: post #4

Am I just out of touch with what the kids today are doing, or is this formatting really as bonkers as it seems? int main ( int argc , char *argv[] ) { // ... LColor backgroundColor = LColor ( generateLightColorPart(207, 1) , generateLightColorPart(154, 1) , generateLightColorPart(108, 1) , 1 ); // ... } I can (sort of) see that this makes it easy to comment out parameters - except for the first one...

I write this way to make it easier to see when I’ve missed a comma, and also for editor macros. I’ll often reformat when I’m done so it fits our code review style. Also I’m usually working systemverilog so 5-10 parameters are common and 50 or more isn’t rare.

If you do a lot of adhoc sql with an editer that supports multiline editing, it allows for pasting in big lists of text and quickly formatting it, trailing commas and ragged edge right data suck to edit in bulk.

Re: 3D Game Shaders for Beginners

#46

Post by danbolt »

kragen wrote: post #19
barbwire wrote: post #4

Am I just out of touch with what the kids today are doing, or is this formatting really as bonkers as it seems? int main ( int argc , char *argv[] ) { // ... LColor backgroundColor = LColor ( generateLightColorPart(207, 1) , generateLightColorPart(154, 1) , generateLightColorPart(108, 1) , 1 ); // ... } I can (sort of) see that this makes it easy to comment out parameters - except for the first one...

In languages that don't allow trailing commas, I prefer this comma-first style. It makes it easy to avoid missing or extra commas, which shortens my feedback loop a bit. But I usually don't use it, because a lot of people react the way you do, and I want you to be able to read and enjoy my code despite your irrational and bizarrely extreme prejudice.

I had never really thought about commas that way, but I can totally get why someone would want to use this style now. Thank you for taking the time to explain it!
Post reply on HN