Hey,
I have been rather silent on the Torque 6 front of things. That said - Going to try and be more active from now on.
Improving the Shader Authoring Pipeline -
I feel that there needs to be a drop down menu for each shader "type".
So that people can get faster feedback on the shaders within the material editor.
This should also be modular so that contributors can add their own shaders in a very easy fashion.
Starter Shaders in Torque 6
The Shaders in Torque 6 are not the best yet. They can be better. A better diversity of "Starter Shaders" would help this and show off the potential of Torque 6.
The following Shader types would be great to have in torque 6.
Clothing Shader
Hair Shader
Toon Shader
Skin Shader
Foliage Shader
Basically what i am suggesting is bunch of "starter shaders" for lack of a better term that are built into torque 6. These can act as a starting point for shader work in the editor.
Programing Work flow
I am unsure if this is planned but some form of visual scripting support would also be greatly appreciated.
Unreal Engine 4 makes heavy use of it and it makes working with it allot faster work flow wise.
That said - I would recommend looking at Crown which has a Visual Scripting engine in both LUA and C++. I am unsure of the license though. If we do go the Visual Scripting route I think that LUA would be the best choice. Due to its wide spread use in the games industry and documentation overall.
Also - Sorry if this comes off as a bit blunt. Just want the best for Torque 6.
- HeadClot
Suggestions for improving the shaders, shader authoring pipeline, and programing work flow for Torque 6
Moderator: andrewmac
9 posts
Page 1 of 1
@
HeadClot : the things you are suggesting are actually the opposite of the path I choose to take. Let me explain. I've used T3D and UE4 to make personal projects and I use Unity at work. Having experienced these three major engines I feel I've been able to judge them for their strengths and weaknesses.
With T3D for materials you get a single master material to utilize. This becomes limiting if you want to do anything outside of the regular stuff. There is custom materials but in the end it was rarely utilized and a bit confusing. Unless you have the time to dig into how the system works you won't be able to stray too far from the status quo. Gameplay programming is accomplished through TorqueScript which serves it's purpose well. The lack of an entity/component system once against constrains you to work with the gameplay objects T3D provides. You can combine them with prefabs.
With UE4 for materials you have a node based system that generates a final shader for usage in materials. Its simple, its flexible, and you can implement just about any material shading technique you can come up with without having to learn shaders. It uses visual scripting (blueprints) primarily for gameplay code with a fallback on C++ when you need to write more involved code. Similar to T3D you can arrange multiple gameplay objects into what is a essentially a prefab, though also called blueprints.
With Unity for materials you select a shader and those shader properties are exposed in the editor in a manner similar to T3Ds. You fill out the fields for the material and you move on. If you need a variation on a material that's more complex you can duplicate its shader and rewrite portions of it, etc. For gameplay implemention you have a flexible entity/component system and you write scripts in C# or Javascript.
Having used all three engines for various projects and various teams this is the conclusion I've come to: Artists don't like writing shaders. Programmers don't like visual scripting.
The plan for T6 is a mixture of the best (in my opinion) of all three engines: Node based material system so artists can have freedom to create complex materials without learning how to write shaders (all the shaders you mentioned can be implemented via the node based materials.). Entity/Component system with TorqueScript (and possibly C# eventually) scripting to implement gameplay code. C++ and plugin system and unified shader language for advanced users who want to extend the engine beyond its original capabilities. I think this combination will make everyone happy and maximize productivity.
I hope this reply isn't discouraging. I welcome all my ideas and design decisions to be challenged. I just hope I made a good case for my position.
With T3D for materials you get a single master material to utilize. This becomes limiting if you want to do anything outside of the regular stuff. There is custom materials but in the end it was rarely utilized and a bit confusing. Unless you have the time to dig into how the system works you won't be able to stray too far from the status quo. Gameplay programming is accomplished through TorqueScript which serves it's purpose well. The lack of an entity/component system once against constrains you to work with the gameplay objects T3D provides. You can combine them with prefabs.
With UE4 for materials you have a node based system that generates a final shader for usage in materials. Its simple, its flexible, and you can implement just about any material shading technique you can come up with without having to learn shaders. It uses visual scripting (blueprints) primarily for gameplay code with a fallback on C++ when you need to write more involved code. Similar to T3D you can arrange multiple gameplay objects into what is a essentially a prefab, though also called blueprints.
With Unity for materials you select a shader and those shader properties are exposed in the editor in a manner similar to T3Ds. You fill out the fields for the material and you move on. If you need a variation on a material that's more complex you can duplicate its shader and rewrite portions of it, etc. For gameplay implemention you have a flexible entity/component system and you write scripts in C# or Javascript.
Having used all three engines for various projects and various teams this is the conclusion I've come to: Artists don't like writing shaders. Programmers don't like visual scripting.
The plan for T6 is a mixture of the best (in my opinion) of all three engines: Node based material system so artists can have freedom to create complex materials without learning how to write shaders (all the shaders you mentioned can be implemented via the node based materials.). Entity/Component system with TorqueScript (and possibly C# eventually) scripting to implement gameplay code. C++ and plugin system and unified shader language for advanced users who want to extend the engine beyond its original capabilities. I think this combination will make everyone happy and maximize productivity.
I hope this reply isn't discouraging. I welcome all my ideas and design decisions to be challenged. I just hope I made a good case for my position.
I'm not personally a big fan of node-based programming. It has its uses (like creating conversation or quest trees), but as a general programming tool it always feels very cumbersome to me.
I like the idea of "template" or "starter" stuff that can be built on as well as standing as an example.
I like the idea of "template" or "starter" stuff that can be built on as well as standing as an example.
Well with time there will be countless examples of how to utilize the material system to do fancy things. This is why there's stuff like the color changing stanford bunny in the example project. I will include lots of materials for people to play with and build on.
Julius wrote:Sound like something that could be ported from AMD's OpenGPU initiative starting in January.
Actually, AMD's GPUOpen is just features like TressFX (hair), ShadowFX (shadows), AOFX (ambient occlusion) and GeometryFX (physics) being open sourced to compete with nvidia's GameWorks. You can be assured I will be taking a look at all of those for integration when the source is released. However, unless I misunderstood, GPUOpen isn't relevant to the topic at hand. It contains no tools for shader authoring or visual scripting.
andrewmac wrote:@HeadClot : the things you are suggesting are actually the opposite of the path I choose to take. Let me explain. I've used T3D and UE4 to make personal projects and I use Unity at work. Having experienced these three major engines I feel I've been able to judge them for their strengths and weaknesses.
With T3D for materials you get a single master material to utilize. This becomes limiting if you want to do anything outside of the regular stuff. There is custom materials but in the end it was rarely utilized and a bit confusing. Unless you have the time to dig into how the system works you won't be able to stray too far from the status quo. Gameplay programming is accomplished through TorqueScript which serves it's purpose well. The lack of an entity/component system once against constrains you to work with the gameplay objects T3D provides. You can combine them with prefabs.
With UE4 for materials you have a node based system that generates a final shader for usage in materials. Its simple, its flexible, and you can implement just about any material shading technique you can come up with without having to learn shaders. It uses visual scripting (blueprints) primarily for gameplay code with a fallback on C++ when you need to write more involved code. Similar to T3D you can arrange multiple gameplay objects into what is a essentially a prefab, though also called blueprints.
With Unity for materials you select a shader and those shader properties are exposed in the editor in a manner similar to T3Ds. You fill out the fields for the material and you move on. If you need a variation on a material that's more complex you can duplicate its shader and rewrite portions of it, etc. For gameplay implemention you have a flexible entity/component system and you write scripts in C# or Javascript.
Having used all three engines for various projects and various teams this is the conclusion I've come to: Artists don't like writing shaders. Programmers don't like visual scripting.
The plan for T6 is a mixture of the best (in my opinion) of all three engines: Node based material system so artists can have freedom to create complex materials without learning how to write shaders (all the shaders you mentioned can be implemented via the node based materials.). Entity/Component system with TorqueScript (and possibly C# eventually) scripting to implement gameplay code. C++ and plugin system and unified shader language for advanced users who want to extend the engine beyond its original capabilities. I think this combination will make everyone happy and maximize productivity.
I hope this reply isn't discouraging. I welcome all my ideas and design decisions to be challenged. I just hope I made a good case for my position.
Nah, not discouraging at all. I wrote this while half asleep so I was not using my brain fully.
That said - I do see the value of Visual Scripting at the very least for prototyping by lone artists. I realize that I am asking too much in the initial post especially with the shader bit.
I know that Unity is going to add a visual scripting feature in the near future according to their road map at least. Maybe we can use Torque Script 2 for a basis for Visual Scripting? While programmers can code in Torque Script 2.
Either way just a thought.
@ HeadClot I like the idea of a visual scripting addon that generates torquescript (or jumps right to generating torquescript bytecode) in the form of a plugin. Much like how Unity has node based materials via addons like ShaderForge. I just wouldn't want to go full blown like UE4 and make all scripting a visual based system.
andrewmac wrote:@HeadClot I like the idea of a visual scripting addon that generates torquescript (or jumps right to generating torquescript bytecode) in the form of a plugin. Much like how Unity has node based materials via addons like ShaderForge. I just wouldn't want to go full blown like UE4 and make all scripting a visual based system.
Yeah - That is what I love and hate about UE4. Super empowering to artists and the like. But at the same time you got to do everything in the editor in visual script to get something done :\
9 posts
Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
