-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style consistency pass on Spatial, Fog, CanvasItem, Sky, Particle shader pages #9746
Conversation
a001c9d
to
43f478b
Compare
Looks great so far! I agree with your style guideline |
43f478b
to
ca6fb9d
Compare
Does Godot have a standard term for local/model space? Within the Spatial Vertex Built-ins table, I see both "local coordinates" and "model space". I suppose if both are commonly used, it's better to keep references to both in the docs? |
a5727a9
to
3359dd0
Compare
I would standardize on "model space" because it matches the naming of |
"Local space" or "local coordinates" does match the naming convention for local coordinates in CPU-side transforms. If we standardize on "model space", there should still be a few mentions of "model / local space" to make the connection. At some point all the different spaces should be documented in one place, so that single explanation can be linked to. Another complication: the CanvasItem page uses "local space" as the main description. Should a different standard be applied to CanvasItem shaders since they are more of an on-ramp for new shader users? In any case, I'll put the maximal standardization of "model space" into the draft and we can see how it looks. |
67dbbd7
to
46c4464
Compare
@@ -260,14 +263,14 @@ Below is an example of a light shader that takes a CanvasItem's normal map into | |||
+----------------------------------+------------------------------------------------------------------------------+ | |||
| in float **LIGHT_ENERGY** | Energy multiplier of Light. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the references to "Light" I left alone. I am not familiar with 2D shaders - do these refer to the LIGHT
built-in, or a 2D light node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refers to a 2D light node, (technically a "light instance" I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed these into links to Light2D and it's properties.
|
||
+---------------------------------------------+---------------------------------------------------------------+ | ||
| Built-in | Description | | ||
+=============================================+===============================================================+ | ||
| in vec4 **FRAGCOORD** | Coordinate of pixel center. In screen space. ``xy`` specifies | | ||
| | position in window. Origin is upper-left. | | ||
| | position in window. Upper-left of the screen is ``(0.0,0.0)``.| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsure about this change. The CanvasItem page seems more beginner friendly than the Spatial page. "Origin" is a term that may be unfamiliar.
17edb70
to
0723c00
Compare
This one's ready for review. I can also clean up the guidelines themselves if we think we'll be reusing them. I think it's a fine outcome if these pages get cleaned up once and we don't formalize the style guidelines anywhere. |
|
||
+---------------------------------------------+---------------------------------------------------------------+ | ||
| Built-in | Description | | ||
+=============================================+===============================================================+ | ||
| in vec4 **FRAGCOORD** | Coordinate of pixel center. In screen space. ``xy`` specifies | | ||
| | position in window. Origin is upper-left. | | ||
| | position in window. Upper-left of the screen is the origin, | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
position in window or in viewport?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not that familiar with 2d coordinate spaces and shaders, I'll investigate this and clarify
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured the original incorrectly stated window instead of viewport.
@@ -238,18 +241,19 @@ Below is an example of a light shader that takes a CanvasItem's normal map into | |||
| Built-in | Description | | |||
+==================================+==============================================================================+ | |||
| in vec4 **FRAGCOORD** | Coordinate of pixel center. In screen space. ``xy`` specifies | | |||
| | position in window. Origin is lower-left. | | |||
| | position in window. Lower-left of the screen is the origin, ``(0.0,0.0)``. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, is that window or viewport?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the description for both instances of FRAGCOORD to match observed behavior. This still might be technically a little incorrect, though?
@@ -260,14 +263,14 @@ Below is an example of a light shader that takes a CanvasItem's normal map into | |||
+----------------------------------+------------------------------------------------------------------------------+ | |||
| in float **LIGHT_ENERGY** | Energy multiplier of Light. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refers to a 2D light node, (technically a "light instance" I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems great to me. There are a few outstanding comments from huwpascoe's review. Should be good to merge once those are resolved.
0723c00
to
c980f10
Compare
bb2704e
to
a363655
Compare
I made another round of changes for all of the outstanding comments. Would appreciate another correctness check on the changes! |
a363655
to
1cdc9de
Compare
Besides the resolved comments, I also changed how ranges were described in most cases in the spatial shader built-in tables.
|
This comment was marked as resolved.
This comment was marked as resolved.
1cdc9de
to
4e02ee3
Compare
+-----------------------------------+------------------------------------------------------------------------+ | ||
| in vec3 **LIGHT** | Light vector, in view space. | | ||
+-----------------------------------+------------------------------------------------------------------------+ | ||
| in vec3 **LIGHT_COLOR** | :ref:`Light color<class_Light3D_property_light_color>` multiplied by | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! |
Resolves #9745
Also looking at the text in #9691 as a guide for some of these changes.
Formalized style guidelines:
VERTEX
.true
if...", "true
when...", etc.1.0
,false
,ENUM_VALUE
. Ints are1
. Floats are styled as1.0
.light()
function" in the body and in built-in tables. Use of "the light function" or "a light function" are also okay, if it improves readability. Avoid "the light() function" (without code style).unshaded
render mode". Avoid "render_mode" in the body of the page.Other, opinionated, changes made by this PR:
VERTEX
, call it "vertex position" where possible. ctrl+f "position" should surface VERTEX.ALBEDO
's description somehow.