- Feedback
-
Ideen
+11
Fertiggestellt
Ability to write custom nodes/HLSL
Hi,
I notice the source code is not included, but I'd really like to be able to write my own nodes (not as nodes, but as HLSL). Having written a shader graph for my previous company, I much prefer to write some types of code in shader graphs, and other types in raw HLSL. For instance, a Parallax Occlusion Mapping node or Fur shader node is much easier to write as an HLSL function than to create in a shader graph, as are certain math functions, etc.
Ideally, I'd like in-line node writing (ala Unreal's Custom node), as well as a way to write full blown nodes that appear as if they are part of the native editor. I'd personally rate this higher than being able to create these functions from within the graph editor using nodes.
Thanks!
I notice the source code is not included, but I'd really like to be able to write my own nodes (not as nodes, but as HLSL). Having written a shader graph for my previous company, I much prefer to write some types of code in shader graphs, and other types in raw HLSL. For instance, a Parallax Occlusion Mapping node or Fur shader node is much easier to write as an HLSL function than to create in a shader graph, as are certain math functions, etc.
Ideally, I'd like in-line node writing (ala Unreal's Custom node), as well as a way to write full blown nodes that appear as if they are part of the native editor. I'd personally rate this higher than being able to create these functions from within the graph editor using nodes.
Thanks!
Antwort
Geplant
A code node is planned, but I'm not sure if there will be a custom node system. There are however plans for making nested nodes, which would then be able to act like non-nested nodes in your shaders :)
+1 For custom code node.
If by nested nodes you mean something like XSI compounds or Blenders group nodes I'm all hands and legs for that! But such system potential would be very limited (next to not necessary) if there won't be ability to save such groups and reuse them in many graphs.
Graph/node serialization to/from JSON/YAML/XML/whatever should be quite easy to implement making Shader Forge even better product.
Right now I'm looking forward for more polished and optimized version before buy.
Cheers,
OG
If by nested nodes you mean something like XSI compounds or Blenders group nodes I'm all hands and legs for that! But such system potential would be very limited (next to not necessary) if there won't be ability to save such groups and reuse them in many graphs.
Graph/node serialization to/from JSON/YAML/XML/whatever should be quite easy to implement making Shader Forge even better product.
Right now I'm looking forward for more polished and optimized version before buy.
Cheers,
OG
+2
Oh, saving/loading nested nodes is of course planned as well :)
The inability to write real nodes for the system is really an issue for me. Being able to build nodes out of other nodes is a great feature (and a boon for the less coder savvy part of the community), but woefully inefficient for certain types of shaders. It's also a complex feature to implement correctly if you want those nodes to be able to have nice interfaces.
Being able to type in some HLSL code on a node is also pretty nice, but again extremely limited unless that system lets me provide the full schema for a node and save them for later use. I don't really want to have to pull up a block of code and cut/paste it into every shader that uses that code. If I could drag them into the menu to install them there, then that would at least allow me to build up a library of nodes that I can reuse.
That said, neither of these allow me to easily create game specific nodes which make it easy for an artist to grab a global/constant variable provided by the game and use it in the shader graph. For instance, lets say you're making a music game and want to use the music intensity as an input to many shaders. Under the current system, all of these need to expose a float property and have code written to update that float value for that shader. However, if I can create a 'music intensity' node for them instead, significant amounts of 'hookup' time is saved, and potentially CPU time (I was on a project where doing something like this saved several milliseconds because there were thousands of instances doing this redundant copying).
Being able to type in some HLSL code on a node is also pretty nice, but again extremely limited unless that system lets me provide the full schema for a node and save them for later use. I don't really want to have to pull up a block of code and cut/paste it into every shader that uses that code. If I could drag them into the menu to install them there, then that would at least allow me to build up a library of nodes that I can reuse.
That said, neither of these allow me to easily create game specific nodes which make it easy for an artist to grab a global/constant variable provided by the game and use it in the shader graph. For instance, lets say you're making a music game and want to use the music intensity as an input to many shaders. Under the current system, all of these need to expose a float property and have code written to update that float value for that shader. However, if I can create a 'music intensity' node for them instead, significant amounts of 'hookup' time is saved, and potentially CPU time (I was on a project where doing something like this saved several milliseconds because there were thousands of instances doing this redundant copying).
Antwort
Fertiggestellt
A code node is planned, but I'm not sure if there will be a custom node system. There are however plans for making nested nodes, which would then be able to act like non-nested nodes in your shaders :)
Edit: A code node has now been implemented in Beta 0.28
Edit: A code node has now been implemented in Beta 0.28
Hey Joachim,
Not sure if this would be better in a separate request, but I'll put them here for now:
- Would like the ability to have texture samplers as an input type; this would be very useful for things like parallax occlusion mapping, fur rendering, etc - all which need to sample a texture multiple times.
- Would like to be able to have multiple outputs, so we're not limited to what we can stuff into a float4 and can also label/split the data into logical outputs..
Not sure if this would be better in a separate request, but I'll put them here for now:
- Would like the ability to have texture samplers as an input type; this would be very useful for things like parallax occlusion mapping, fur rendering, etc - all which need to sample a texture multiple times.
- Would like to be able to have multiple outputs, so we're not limited to what we can stuff into a float4 and can also label/split the data into logical outputs..
Customer support service by UserEcho
Edit: A code node has now been implemented in Beta 0.28