AndrewRayCode
commented
3 weeks ago Thank you for this feedback! The boilerplate code for Shaderfrog 1.0 has a lot of what you're asking for. I haven't added it yet to the second version of the editor.
I also was inspired by your issue to hack together a shadertoy import proof of concept: https://x.com/andrewray/status/1825771064657686588 . This won't get you that far, but might help with some of the boilerplate importing.
Here's some longform background information while I mull over the right way to add boilerplate code.
Brain Dump of Shaderfrog "Standard" Variables
I think it makes sense to at least have a documentation modal or help page that shows the variables/uniforms available in a glsl node. Right now, Shaderfrog Core injects a few uniforms: https://github.com/ShaderFrog/core/blob/bb247b76ad285e2cfcf547da14408331f2a5a704/src/plugins/three/threngine.ts#L716-L718
time: { value: 0 },
cameraPosition: { value: new Vector3(1.0) },
renderResolution: { value: new Vector2(1.0) },And the Shaderfrog Editor updates those values in the scene at runtime: https://github.com/ShaderFrog/editor/blob/c2a713b6ea6afe5ec4f552e9fe271441f04c4bbb/src/editor-engine-plugins/three/ThreeComponent.tsx#L491-L515
(I just added renderResolution to support the Shadertoy import).
For attributes, and varyings like vPosition, there are two aspects here. First off, if you have a Three.js material in your graph, like the MeshPhysicalMaterial in this graph, then the Three.js shader automatically creates variables like vUv and vPosition which are then available in your fragment shader.
These varyings become available to your individual fragment GLSL nodes because, in the end, all of the GLSL nodes are compiled into one big single GLSL program (which you can view, and live edit, on the Shader -> Fragment/Vertex sub-tabs of the editor). Additionally, if you have a GLSL node, when it's compiled to the final shader all of your variables are "mangled" - aka renamed - to make sure they don't conflict with other GLSL source code in the graph, except I hard code that engine variables names like vUv should not be renamed.
So if you have a Three.js shader in your graph, you get these variables for free. If you don't have a shader in your graph, you need to manually assign those varyings in the vertex shader. You can see an example of that by double clicking on the red vertex node in this graph to see its source code: https://shaderfrog.com/2/editor/clp6gohkq0006parh3jr90ym2
Also, Shaderfrog tries to trick Three.js into passing uniforms to the final RawShaderMaterial, so there are also the matrix uniforms available like modelMatrix, and the attributes also come along with the geometry, like position, regardless of if you have a Three.js material in your graph.
This also applies to Babylon, Playcanvas, and any other engine plugin to Shaderfrog.
Boilerplate in the "hybrid graph" editor
I've been thinking for a while about the right mental model for what type of editor Shaderfrog is. Currently, the intention of Shaderfrog is a kind of social shader remixer and GLSL module composition system, where each node in your graph is a standalone effect/shader, and you can trivially replace and remix nodes together with any other from the online ecosystem. For example, it was trivial to take this shadertoy port by another user and multiply in other shaders from the site to make a new effect. You can also see in these graphs there are several fragment (green) and vertex (red) source code nodes.
In that sense, the main focus of my development has been on these social features, and the ability to promote shaders into composable modules. What you're looking for right now is closer to something a standard code editor offers - where you're editing all of the shader code in one file/editor.
I'm saying this because I'm not sure it makes sense to add full boilerplate code to every new fragment/vertex node in the graph. The fragment/vertex nodes right now are intentionally empty because the social composition nature of the graph means there might be many GLSL nodes.
TL;DR with the above context, I see at least three options:
- The initial nodes could have boilerplate, and new users could delete those nodes if they want a fresh graph
- There could be an option in the right click menu to add a "boilerplate" code node, vs an empty fragment/vertex node
- This could be done with documentation, listing the types of each built in attribute/uniform
- Maybe have a more standard "root" node - or repurpose the output node - to include that boilerplate
Bug-Reaper
Finally learned enough GLSL and THREE-flavored GLSL to be dangerous!
Went to port over some of my shader-toys and from what I remember the process went something like this.
I think some upgraded default boilerplate is gonna go a long way for easier adoption:
As always look up to your stuff Andrew, loved the parrallax demo of recent and can't wait to make some dank frogs.