Hi everyone !
Pretty new to game dev, I’m wondering how OpenGL/DX technologies can be useful ? I’m interested in the subject and I read some papers about it but… I don’t understand.
I mean, ok great, you can generate a cube, place texture on it but let’s admit it : it’s pretty 90’s style. I think you can maybe do some little post-processing with OpenGL using the same way I learned in school (blurring effect through a PHP library, foreach pixels do XXX etc.) but again it’s not very… ergonomic ? I’m sure it can do more !
Now, far from Wolfenstein3D, we are in 2016 with graphic interfaces, 3D softwares like 3DS/Maya/etc. , we even have game engine like UE4 and some postprocessing are directly integrated in it.
Soooo… What is OpenGL/DX concrete uses ? Does it ‘complete’ the project to achieve a great looking scene ? Is it… ‘vital’ ?
Everything that UE4 renders to screen is done via HLSL shaders. Material editor just outputs HLSL. Understanding what happens underhood is not necessary but it’s greatly useful when solving problems or optimizing.
You can use HLSL directly inside the Material Editor using the “Custom” node, however, it should Only be used when you can’t achieve something with the material editor, as the Custom node isn’t optimized like the material editor.
Custom node’s only don’t get parameter constant folding. But everytime math is based on variables that are not know at draw call level Custom nodes is just as fast. Many times you can do optimizations on hlsl level that are tricky or impossible on node level.
My understanding is, not exactly. Writing code in a custom expression node is primarily for when you want to do something that isn’t as easy or may even be impossible in the node graph, for instance using a FOR loop or doing some more complex math which would just be really messy in the node graph. If what you want to do can be done within the node graph, it should be done in the node graph because most of the time the node graph is just more efficient as the compiler does some tricks to optimise your “code” that you “write” in the graph, where if you were to write code in a custom expression node, the compiler just uses the code you wrote and does nothing to do it. If you were to take some code and convert it to a series of nodes, the nodes’ll likely be more efficient due to the compiler optimising it.
In other words, to my knowledge, no. Writing code should only be done in the cases where you can’t do it in nodes otherwise, such as using a FOR loop or some complicated maths that would be messy in the node graph. And even then, you have to optimise your code yourself as the compiler doesn’t touch it in terms of optimisation.
If you think it is 90’s, you may be misunderstanding shading. It is mathematical, procedural - that’s the power. No need to have large games, as most everything can be drawn real-time with little or no saved textures
Some question about optimization of custom nodes. As per the documentation “Constant folding is an optimization that UE4 employs under the hood to reduce shader instruction count when necessary. For example, an expression chain of Time >Sin >Mul by parameter > Add to something can and will be collapsed by UE4 into a single instruction, the final add. This is possible because all of the inputs of that expression (Time, parameter) are constant for the whole draw call, they do not change per-pixel. UE4 cannot collapse anything in a custom node, which can produce less efficient shaders than an equivalent version made out of existing nodes…”.
Will UE4 collapse in the same manner a custom node whose all inputs are constant for the whole draw call? If yes, how can I check this?
I think the meaning at that paragraph was to collapse at the calling of the custom node, not the inner instructions from it. A custom node in the final HLSL code will be just a copy and paste from what you have written and the optimizations must be done by yourself, ie: fragment the code in multiple custom nodes. FYI the material graph greatly helps in the process of folding, while to do the same process with a custom node contents would require a separate parser, which would introduce a new weak spot in the whole process.
Thanks for the answer, I think the “collapse” term is misleading. In other words, I would like to know if the instructions of a custom node will be executed for each pixel or only once if all of the inputs of this custom node are constant for the whole draw call. As far as I know there are pixel and vertex shaders and the output of a vertex shader is the input for a pixel shader. In my understanding, UE material editor do the work for us, deciding which part of a material nodes forms the vertex shader and which part forms the pixel shader. If all of the inputs of an expression formed by a group of material nodes are constant for the whole draw call, then UE places corresponding instructions in the vertex shader (or somewhere else) rather than in the pixel shader. That’s how I understand what the constant folding is. So, what happens if I change the Sin function in the documentation example by a custom node that only accepts Time as input. Will corresponding instructions be placed into the vertex or pixel shader? How the pixel and vertex shaders are designated in HLSL?
My understanding and corroborated by practical jobs is that the custom node with constant input will run once for the entire draw call, since theoretically same input will result in same output, but there could be something we are not aware of, so I would call help on answering this from [USER=“3043181”] Wright[/USER]
Unreal’s constant folding mean that material networks are evaluated, and any inputs on any pins, that are evaluated as constants, are collapsed to such. This is the only part of optimization you are missing out when using custom node.
There is no kind of decision about vertex/fragment shader you are mentioning. If a node is used in pixel shader related material inputs, it will be part of pixel shader. If it is part of vertex shader material inputs(world position offset, custom UVs, vertex interpolator), it will be part of vertex shader.
If some parameter depends only on the camera position I can compute its value in a blueprint, using certain algorithm and then pass it to the dynamic material instance. But it is not very convenient solution if the same algorithm should be used in the material to calculate final pixel color (something like this:
Color = Func(CamPosition, (0,0,0)) + Func(CamPosition, PixelPosition)
