Continued from the above Rendering 8
Regarding the difference between metals and non-metals, they can all have specular highlights, and the specular highlights of metals are dominated by a dominate, while non-metals are not like this, they also have diffuse. This is mainly reflected in the fact that their whole ball still has Lambert's brightness when facing the light and darkness when facing the light, while the metal does not have this phenomenon at all, and the overall brightness is relatively uniform.
Regarding the color, the main thing is that the metal highlights will have color, whether it is direct or indirect.
First of all, consider what the essence of projection is to block the light for you, so that you receive less light, so your overall brightness is darker than the part that is not in the shadow.
The highlight here is still the ambient highlight, and it is only affected by the amount of ambient light at this time.
As above, a metallic ball is blocked by a pillar. Although it is blocked, our ambient light comes from all directions, so it can only block part of it. What we consider here is the highlight, which is the complete specular reflection light. That is to say, at each point we see its highlight, its incident light must be in a specified direction. If the light in this specified direction is blocked, then the highlight at this point will indeed be dark, otherwise it will not be affected at all.
And here it is indeed getting darker. The darkened part is the pillars reflected in the metal ball. If we point some light, we can see the light reflected by the specular surface. This is naturally affected by the color of the pillar itself (determining how it reflects light) and its light conditions.
So here is a physically correct result.
Consider impurities.
This is the discussion of some probes. When the position is not in the middle, we need to make a separate one to get a more realistic effect.
But in fact, it’s not right to do one alone. What we actually want to get is the ambient light around each fragment. But if we have one probe for each object, all our fragments share this one, and each fragment will default to It is at the position of the center probe, so the record is not completely accurate, but this error is no longer considered, and the effect is already quite good.
When we replace the ball with a flat surface, the effect is as above. In fact, this deviation from reality is quite large.
The reasons for the above formation are actually similar to the previous analysis of the ball. We only need to analyze. According to the actual situation, we look at a certain point and what its reflected light path should be. And it's fine when the actual sampling is done here.
For example why it becomes thicker, take:
For the part that should not reflect the pillar here, our line of sight is roughly facing it now, so when we calculate its reflection, we will think that it is in the center, and then the pillar will be displayed after sampling the cube. And only those reflection points whose original viewing angle is more biased to the sides
For example, at the boundary point here, our line of sight is connected to the past, and the incident light should come from the upper right. When this point is placed in the center for sampling, the sampling is from the upper right, so the sampling cannot reach the pillar.
And those with relatively small deflection angles should not be reflected to the pillars, but when they are placed in the center, they will be sampled to the pillars, so more areas are sampled to the pillars, so the pillars become thicker when viewed.
In addition, the pillars are shortened under the current viewing angle.
From this point of view, it becomes longer, and it is always analyzed in this way.
Of course, the position of the probe placed here will also have some influence, whether it is facing the pillar or not.
When the angle of view is shifted, bigger problems arise, but they are all analyzed in the same way.
In fact, the approximation here wants to have a good effect. In fact, there are two situations: either the reflected object is far enough, so that there will be no too much error if the fragment is considered to be sampled at the center.
Either the ball or the surface is small enough, and when it is placed in the center, even if there is such a situation that it is not in the center but is considered to be the center, the deviation will not be large due to the small distance.
This is also the reason why the effect of the ball is better than that of the surface. it is small.
In short, the reason for all this is that when sampling, we translate our actual sampling light to the center before sampling, which brings some errors.
We need to use the blue line below to infer green instead of using blue.
That's what it says here.
In general, it is the point of intersection.
But the black frame outside is our ideal, and it doesn't have the actual size, but its actual size can be whatever it is.
Modifying the offset of the probe box will cause the entire box to shift. Note that when sampling, the environment is always sampled at the position of the ball. The effect of the box offset is that the objects in the box have changed. The role of the box is Let the objects inside the box use this probe.
There are many things worth referring to in the blog. A replica of the game effect.
(119 messages) Unity Shader!!!_puppet_master's Blog-CSDN Blog
After we correct the reflection direction as described above, there will actually be a requirement, that is why the box of the probe should be consistent with the boundary of our scene, (in order to ensure this consistency, sometimes our probe needs to put Then the scene is in the center, and the center after box alignment may not be the center of the scene. At this time, the offset option that was not understood before is needed.)
Going back to this picture, first of all, there is no doubt that the blue light below is the correct reflected light, but the question is: the image at the intersection of the blue light and our cubemap box is really the image seen by the actual reflection ?
This is not necessarily the case.
If there is such a purple ball in the space, then the image of the ball is stored at the intersection point in the cubemap, but judging from the reflected path below, this should not be seen from this perspective at all.
besides:
If so, assuming there is nothing between the purple ball and the center point, then the image at the intersection will record the image of the ball again, but if we extend the blue direction line below, what we see will not be this Purple ball, this is not the case either.
So when is it correct, that is, when the purple ball is placed on the border of the box, so that the cubemap stores what is actually seen in the blue reflection direction.
This also requires that the boundaries of the entire box and the map are coincident, and there is nothing inside the boundaries.
for
this option. The difference is what's outside the box.
If we say that part of our mirror is inside the probe area and part is outside the probe. According to our algorithm above, we think that all the things sampled by the cubemap are placed on the edge of the probe range, which does not have much effect on the effect of the skybox.
If you don't enable the box projection option, then just follow the process, and we can get the following conclusions:
This part is out of range, the fragment they calculate is outside, and the minimum calculation time is a negative number, so the cubemap they sample is the lower half of the entire box, which is reflected on the ground instead of the sky, so The effect here is obviously wrong.
And if checked,
The above is not out of range, carefully observe the difference with the following out of range:
There is stretching here, and a closer look at the right border shows that the right side is enlarged a bit.
So the conclusion is to check it. After it exceeds the range, it will enlarge the corresponding side of the cubemap. In fact, this is also the function of this option, which is to ensure that the part beyond the probe range still reflects the correct position information of the cubemap. That is to say, the exceeding range still reflects the information stored in the upper half of the cubemap, and it will not be said to be shot down like refraction. (However, because the position is out of the boundary, and the cubemap storage is considered to be information on the boundary, the effect of reflecting objects on the boundary outside the boundary is also a bit strange, and the final result may not be correct. It may be that your object itself is outside the boundary , he thinks it is on the boundary, and our reflection reflects him outside the boundary, which may be correct. But this situation should not be involved, whoever puts the mirror outside the frame in leisure.)
Unity reflection from entry to deviation (BoxProjection to Fake Interior) - Zhihu (zhihu.com)
Here, as long as the mirror is within the range of the probe, the effect will be correct, and if you want the symmetrical connection state above, you need to adjust the size carefully, because the pillar must be on the boundary, and the mirror must suffer with pillars.
There is one point of adjustment here: that is, we let the pillars be on the boundary, and the pillars have thickness. How should they be on the boundary to obtain an almost perfect effect?
This actually means that we think it is on the boundary, if it is actually on the boundary, then the effect must be completely correct.
In fact, it is: thinking it is on the boundary means that the surface we see at the center point is on the boundary. Then when placing it, just make sure that the surface you see in the past is on the boundary.
This is the perfect answer.
Of course, the ground should not appear in the mirror here, which can be achieved by adjusting the height.
At this time, the effect of changing to the reflection of the ball is also good, and it has successfully made the ball in different positions have different reflections.
In fact, this explains the function of the box projection outside, that is, whether this option is checked or not, it should correspond here. If it is checked, the w component will be greater than 0, otherwise it will be less than 0.
So this function is: whether it is corrected or not. (Its original function is to let us use macros, and then there is this conditional judgment in the macro. But this function is definitely not just such a judgment. According to our previous comparison, there are related differences.)
In addition, the if judgment here, the if branch in the shader will be optimized, leaving only one assignment judgment:
But if we want to keep this branch, just tell the compiler.
In order to have a better reflection effect on the outside of the box we just tried, the two tried here are not perfect:
One is to directly expand the range, but since the center of the sampling is inside the box, the reflection effect of the outer balls on their surface is still something inside, and the effect is wrong:
Another way of operation is: add one more probe, but this will cause problems in the transition, and the transition is a mutation.
Then start interpolation:
But the above wording is wrong. Here, the second texture sampling needs to rely on some things of the first one.
The bug that turned black before, in fact, after careful consideration, we have seen this black ball before, that is, the metalness and smoothness were pulled to 1, and then it became like this. In fact, the sky ball is still black here, which means that the sky ball has no effect, which is why the intensity coefficient of the ambient light reflection here is written as 0.
There is still a problem here, that is, we have two probes. When the intensity multiplier on the top is changed to a smaller value, such as half, we move a ball in the middle of them. When the ball moves to the place where they overlap , the brightness is suddenly brightened. I don’t know the reason for this problem. You can change the intensity multiplier above to be larger, such as 0.9 or more, and 1 is fine.
What's even more strange is that when we adjust the intensity multiplier to 0, everything should be black, but the border is still bright. Impressed. . . .
Related blend settings.
After the mixing is completed, it is considered that sampling requires a lot of work, and sometimes there is no need to sample the second cubemap at all, so a judgment is made between sampling. Don't do useless work.
Some platforms are being optimized here, and some platforms cannot be mixed.
To achieve an infinite reflection effect, the mirror on the ground needs to be changed to static.
More Reflection
————————————————————————————————————————————————————————————————————————————————————
RENDERING 9
If you want to create a custom GUI, you need to use C# operation, the general operation process:
Make sure our class is inherited from ShaderGUI.
He is a new version of the GUI class.
After we have customized C#, drag it to the material, and if we want to play a role, we have to declare the shader:
This sentence is added at the end of the text.
After the declaration, all that remains is to override the function, which determines how to show on the material panel.
Here we want to imitate the standard coloring and writing.
Then for a single attribute, you must first get this attribute, so that the displayed thing is linked to the attribute value.
Then for text or tool tip, GUIContent is created.
For color tint, this is linked to attributes and needs to be created in combination with attributes
The scale and offset are quite special. You don’t need to make a separate variable, just create a function directly.
In fact, three things are defined here in one line. From the perspective of the function interface, these three things are irrelevant.
There are roughly two types of things we display in the panel, one is attributes, and the other is supplementary text.
In fact, the format here does not need to write supplementary text. That is, there is no relationship between supplementary text and attributes. The attribute creation here requires attribute objects, and then unity will create the corresponding GUI according to the type. Then you supplement it by adding some text next to it.
For offset, it is special, it is an attribute, but it is an attribute attached to other attributes, so it is a bit special here.
Regarding the label, a package simplification can also be performed here. You only need to pass in the attribute, so that the display name can be automatically obtained internally according to the attribute, and then passed in the tool tip.
Here, normal adds pictures, labels, and bump scales. These are all basic operations. The attributes and labels are now calling functions, and then just get a line.
There is one thing that needs to be said here: the bump scale of the standard will only be displayed after the normal map is correctly assigned, so a judgment can be added here.
There are two points here: one is that when the attribute and label are obtained through the function and added to the editor, the function it uses changes.
Secondly, it was said that the label description and attributes are completely independent, and this is not complete. The parameters here do allow the label to be specified, but tint does not need to be specified.
Maybe specify a label for one line? ?
Then here achieve an alignment effect by changing the indent level.
At this point, the first set of maps is completed, and the following is the second set, and the gameplay is the same.
This is the overall code structure, and then Domain and DoSecondary themselves
Here is actually a question about metalness, because our metallic attribute is directly applied to the entire model, that is to say, all the metalness on the surface of the entire model is the same, which affects the performance of the material.
Therefore, the metallic map appears, and for each texel, a specific metal degree is set.
This kind of noScaleOffset here is useless, because the whole is for the default ShaderGUI, and we now use our own defined GUI.
After adding the metalness map here, we need to change the calculation method of metalness, so a function is encapsulated here.
Also tweak the GUI a bit.
This is the overall code structure, and then Domain and DoSecondary themselves
Here is actually a question about metalness, because our metallic attribute is directly applied to the entire model, that is to say, all the metalness on the surface of the entire model is the same, which affects the performance of the material.
Therefore, the metallic map appears, and for each texel, a specific metal degree is set.
This kind of noScaleOffset here is useless, because the whole is for the default ShaderGUI, and we now use our own defined GUI.
After adding the metalness map here, we need to change the calculation method of metalness, so a function is encapsulated here.
Also tweak the GUI a bit.
There is another detail in the GUI here, which is just the opposite of the bump scale that was processed before. Here, there is no need for a value if there is a texture, and the value is used if there is no texture.