Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

最後の投稿 - ページ#321

  掲示板

TheEmu
Joined in Jul 2012
7424 投稿

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

iStripperに関する全て
October 24, 2022, 5053 アンサー
@Z22

Sure, that works as intended.

But if you omit "uniform: some cak, float, 1.0" from the second then it will be as if you had specified "uniform: some cak, float, 0.1" rather than "uniform: some cak, float, 0.0" (its default vaue) which is what you would get if you had omitted both of the uniform: causes.

Not much of a problem if you always fully define all inputs to each instance of a shader, but even then it complicates maintenance and incremental development both of .scn files and of shaders because changing something in one place may need to have a different modification made elsewhere.

As a simple case consider your example as a starting point. Now modify the shader to optionally use a second uniform which could properly default to a value of zero but which you want to have a non-zero value for one of your uses. You will have to specify the uniform in both of the scene nodes in which you use the shader. Not much of a problem for this simple case, but much more of a nuisance in complex scenes where the two instances may be hundreds of lines apart in the .scn file.

In complex scenes altering the order in which the nodes are declared can, and often does, affect the values of uniforms seen by the shaders unless every uniform used by each shader is explicitly declared in each node that the shader is used in. Some of my shaders use a significant number of uniforms to provide optional parameters and having to reset them after using one with a non-default value is a ***** - especially if I am only doing so for debugging purposes.

It also means that you can test two pieces of the .scn file in isolation, find that they both work as expected, but that when combined one of them is no longer producing the expected result.

The problems arise because in the code processing the ,scn file (not in the code running the shaders) there is effectively a global variable for the uniform. This means that local changes have ramifications outside their natural scope and need to be "corrected" somewhere else in the source.

Note, this also results in user defined uniforms behaving differently to system defined ones such as gl_Color. For the latter any changes made to them in the .scn file (via color: or Opactity: clauses) are local to the node in which the change is made.

Note also, for me all of this is no more than a nuisance. I know what the potential problems are and how to avoid them (and I can recognise them when I make a mistake). But for others, particularly those with little or no programming background, there can be real difficulties in understanding why changing one thing in a scene can have a large effect on something else that is apparently unconnected with it. This will be especially so if two different shaders, doing completely different things, just happen to have an input parameter provided by a uniform with the same name.
Wyldanimal
モデレータ
Joined in Mar 2008
17165 投稿
Previous ページ#321