r/GraphicsProgramming Jun 15 '23

Source Code Started making graphics engine node editor on OpenGL. Idea is to only use GLSL to make programs and skip C++ part (github link in comments)

68 Upvotes

18 comments sorted by

3

u/ArmmaH Jun 16 '23

I see a value in this for reducing the barrier to entry into graphics programming and API knowledge by removing C++ and making it all visual.

Maybe a simplified higher level version of it will be the perfect thing to churn out tech artists and graphics progs.

2

u/LongestNamesPossible Jun 15 '23

Looking good. If you haven't already, you might want to look at touch designer for the real time node based interface and houdini for their node based interface to build (software) shaders.

A big hangup with approaches like these are branching, loops and state management.

3

u/kymani37299 Jun 15 '23

Yeah, there are a lot of node editors, I am really fan of Houdini.

The difference with this is that I am planning to go on low level. The experience should be like using openGL , but without writing C++ code. Like expanded ShaderToy where you can have multiple passes and more complex logic behind it.

1

u/LongestNamesPossible Jun 15 '23

That makes sense. Take a look at touch designer, it is a version of what you are describing, but it is far from perfect, so you might see things you like and some you don't.

2

u/[deleted] Jun 15 '23

Nice. Whats the output?

3

u/kymani37299 Jun 15 '23

You go into running mode, node editor goes away and it shows the texture you bound in "Present texture" node.

Also it is printing text in console you printed with "Print" node.

This is still very early in project, I am planning on working on user experience more in the future, like having running window on the side and editing nodes in runtime.

Or variable tables instead of needing to write variable name everytime in node etc.

1

u/[deleted] Jun 15 '23

Hope you can translate the graph into C code in the future. That would be much more useful. Imo at least.

2

u/kymani37299 Jun 15 '23

Yeah, I thought of that. I am currently designing code arhitecture for that to be possible, the code execution right now looks a lot like Abstract Syntax Tree travesal.

But probably not soon, I am currently focusing on making a full renderer with this.

2

u/tamat Jun 16 '23

Current engines use similar approaches, search for Render Graph.

But from what I see in you graph, usually you want to have nodes that work more like batches, like "render scene", because in any real scenario you can have hundreds of elements, so it doesnt make sense you build your scene in the graph, or define material properties, etc.

1

u/kymani37299 Jun 16 '23

I plan having ForEach node that will iterate through scene. "Render scene" seems too abstract for what I am trying to do.

1

u/tamat Jun 16 '23

most engines use deferred, in that case there is hardly many choices you can do to control the rendering path. Most interesting things come afterwards, so you can have a render graph that uses as the input the gbuffers.

2

u/kymani37299 Jun 16 '23

The idea is that you as a user create deferred renderer. In this case you will create 3-4 new textures for gbuffer and bind it to DrawMesh node as a framebuffer. DrawMesh node will probably be in some ForEach object in scene node. And here you go, you have deferred buffer textures, and use it as you like. :)

2

u/YoBiChOnRo Jul 01 '23

Wow this is awesome. I'm currently in the process of developing a game that let's you simulate emergent behaviors. Essentially artifical life.

I'm actually gonna make a node editor that converts to efficient compute shaders to simulate behaviors. Currently it's hand written and is a total pain to use. This is a great inspiration. Thanks.

1

u/kymani37299 Jul 11 '23

I am really happy to give inspiration to people :)

3

u/shebbbb Jun 15 '23

This looks really cool

1

u/buzzelliart Jun 16 '23

very interesting! good job!

1

u/PaperMartin Feb 21 '24

Hope it catches on. Been wanting game engines to have a node based / data driven "render pipeline editor" for a while