Skip to content
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

[Merged by Bors] - Rename Light => PointLight and remove unused properties #1778

Closed
wants to merge 2 commits into from

Conversation

mtsr
Copy link
Contributor

@mtsr mtsr commented Mar 28, 2021

After an inquiry on Reddit about support for Directional Lights and the unused properties on Light, I wanted to clean it up, to hopefully make it ever so slightly more clear for anyone wanting to add additional light types.

@alice-i-cecile alice-i-cecile added C-Code-Quality A section of code that is hard to understand or change A-Rendering Drawing game state to the screen labels Mar 28, 2021
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a very nice little clean-up :)

Copy link
Contributor

@inodentry inodentry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like these changes. Just left a few small comments that crossed my mind.

depth: 0.1..50.0,
fov: f32::to_radians(60.0),
intensity: 200.0,
intensity: 100.0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you are changing the default intensity value from 200.0 to 100.0. Why?

Also, do examples that don't change the default still render OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, not on purpose. I'll revert that.

pub color: Color,
pub fov: f32,
pub depth: Range<f32>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume the original reasoning for why these extra fields were included, was to reuse the same Light type for both Point lights and (future) Spot lights?

I think I like this change. As a user, I think having multiple distinct clearly-named types for different kinds of lights is a good idea.

As for the implementation, I am not very familiar with how differently the different kinds of lights have to be handled for shading. I know Directional/Ambient are special, and those better be their own independent types anyway, but for Point/Spot I am not so sure.

If it's not going to complicate passing of light data and handling in the shader, then this change seems good, also from an implementation perspective. I wonder what the arguments for unifying them into a single type are?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From experience I have a strong preference to not put in unused code like this 'because we'll use it soon'. It's simple enough to put it in the next PR and it's only confusing at this point.

For example, while working on shadowmaps, the above fields needed changing anyway...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think separate types for each light type makes sense, even if point vs spot have some technical overlap. I expect most of the changes in this pr to hold up even when we add spotlights.

pos: [x, y, z, 1.0 / (light.range * light.range)], // pos.w is the attenuation.
PointLightUniform {
pos: global_transform.translation.into(),
inverse_range_squared: 1.0 / (light.range * light.range),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. Having a separate field (with the same binary layout!) rather than overloading the 4th value, is much cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically we waste 3 bytes per light.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is definitely clearer which I think is worth optimizing for, especially in the early days of bevy's renderer. Im down for this change for now. We can revisit later if needed.

Rename inverseRadiusSquared

More renaming

Restore original default intensity for PointLight

Fix layout
@cart
Copy link
Member

cart commented Apr 13, 2021

bors r+

bors bot pushed a commit that referenced this pull request Apr 13, 2021
After an inquiry on Reddit about support for Directional Lights and the unused properties on Light, I wanted to clean it up, to hopefully make it ever so slightly more clear for anyone wanting to add additional light types.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
@bors bors bot changed the title Rename Light => PointLight and remove unused properties [Merged by Bors] - Rename Light => PointLight and remove unused properties Apr 13, 2021
@bors bors bot closed this Apr 13, 2021
jihiggins pushed a commit to jihiggins/bevy that referenced this pull request Apr 18, 2021
)

After an inquiry on Reddit about support for Directional Lights and the unused properties on Light, I wanted to clean it up, to hopefully make it ever so slightly more clear for anyone wanting to add additional light types.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
bors bot pushed a commit that referenced this pull request Apr 19, 2021
Introduced in #1778, not fixed by #1931 

The size of `Lights` buffer currently is : 
```rust
    16 // (color, `[f32; 4]`)
    + 16 // (number of lights, `f32` encoded as a `[f32; 4]`)
    + 10 // (maximum number of lights)
        * ( 16 // (light position, `[f32; 4]`
          + 16 // (color, `[16; 4]`)
          + 4 // (inverse_range_squared, `f32`)
          )

-> 392
```

This makes the pbr shader crash when running with Xcode debugger or with the WebGL2 backend. They both expect a buffer sized 512. This can also be seen on desktop by adding a second light to a scene with a color, it's position and color will be wrong.

adding a second light to example `load_gltf`:
```rust
    commands
        .spawn_bundle(PointLightBundle {
            transform: Transform::from_xyz(-3.0, 5.0, -3.0),
            point_light: PointLight {
                color: Color::BLUE,
                ..Default::default()
            },
            ..Default::default()
        })
        .insert(Rotates);
```

before fix:
<img width="1392" alt="Screenshot 2021-04-16 at 19 14 59" src="https://user-images.githubusercontent.com/8672791/115060744-866fb080-9ee8-11eb-8915-f87cc872ad48.png">

after fix:
<img width="1392" alt="Screenshot 2021-04-16 at 19 16 44" src="https://user-images.githubusercontent.com/8672791/115060759-8cfe2800-9ee8-11eb-92c2-d79f39c7b36b.png">




This PR changes `inverse_range_squared` to be a `[f32; 4]` instead of a `f32` to have the expected alignement
FlyingRatBull added a commit to FlyingRatBull/bevy that referenced this pull request May 1, 2021
ostwilkens pushed a commit to ostwilkens/bevy that referenced this pull request Jul 27, 2021
)

After an inquiry on Reddit about support for Directional Lights and the unused properties on Light, I wanted to clean it up, to hopefully make it ever so slightly more clear for anyone wanting to add additional light types.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
ostwilkens pushed a commit to ostwilkens/bevy that referenced this pull request Jul 27, 2021
Introduced in bevyengine#1778, not fixed by bevyengine#1931 

The size of `Lights` buffer currently is : 
```rust
    16 // (color, `[f32; 4]`)
    + 16 // (number of lights, `f32` encoded as a `[f32; 4]`)
    + 10 // (maximum number of lights)
        * ( 16 // (light position, `[f32; 4]`
          + 16 // (color, `[16; 4]`)
          + 4 // (inverse_range_squared, `f32`)
          )

-> 392
```

This makes the pbr shader crash when running with Xcode debugger or with the WebGL2 backend. They both expect a buffer sized 512. This can also be seen on desktop by adding a second light to a scene with a color, it's position and color will be wrong.

adding a second light to example `load_gltf`:
```rust
    commands
        .spawn_bundle(PointLightBundle {
            transform: Transform::from_xyz(-3.0, 5.0, -3.0),
            point_light: PointLight {
                color: Color::BLUE,
                ..Default::default()
            },
            ..Default::default()
        })
        .insert(Rotates);
```

before fix:
<img width="1392" alt="Screenshot 2021-04-16 at 19 14 59" src="https://user-images.githubusercontent.com/8672791/115060744-866fb080-9ee8-11eb-8915-f87cc872ad48.png">

after fix:
<img width="1392" alt="Screenshot 2021-04-16 at 19 16 44" src="https://user-images.githubusercontent.com/8672791/115060759-8cfe2800-9ee8-11eb-92c2-d79f39c7b36b.png">




This PR changes `inverse_range_squared` to be a `[f32; 4]` instead of a `f32` to have the expected alignement
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants