Miguel Pozo pragma37
  • Joined on 2018-04-26
Miguel Pozo pushed to pull-eevee-jittered-shoft-shadows at pragma37/blender 2024-03-22 23:18:55 +01:00
a29db7a750 Merge shadow shift properties
Miguel Pozo pushed to main at pragma37/.profile 2024-03-22 21:17:16 +01:00
20a2b51353 Update reports/2024.md
Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 19:38:03 +01:00
EEVEE-Next: Refactor light data packing

If we consider spot and omni as "point" lights, we could have a LightPointData that both Omni and Spot can be casted to. (There's probably a better name than "point" but I can't think of a good…

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 19:12:35 +01:00
EEVEE-Next: Refactor light data packing

I mean, not the exact same accesor functions, but something along these lines:

#if USE_LIGHT_UNION
private:
  union {
    LightLocalData local_;
    LightSpotData spot_;
   
Miguel Pozo pushed to main at blender/blender 2024-03-22 18:58:17 +01:00
def5f86cae Fix: EEVEE-Next: Material compilation
Miguel Pozo suggested changes for blender/blender#119713 2024-03-22 18:38:20 +01:00
EEVEE-Next: Refactor light data packing

I have mixed feeling about this, TBH.

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:19 +01:00
EEVEE-Next: Refactor light data packing

Not for this patch, but instead of a 3x4 matrix, maybe we could use position + quaternion?

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:18 +01:00
EEVEE-Next: Refactor light data packing

Nitpick, but I'd use if(is_local_light(this->type)).

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:17 +01:00
EEVEE-Next: Refactor light data packing

On the C++ side, I think it would be less confusing to always access the "top-most" type.

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:16 +01:00
EEVEE-Next: Refactor light data packing

This is the final value used in punctual shadows and clipmap directional shadows.

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:15 +01:00
EEVEE-Next: Refactor light data packing

Why use the same tipe for spot and omni lights?

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:14 +01:00
EEVEE-Next: Refactor light data packing

I would use a fully "empty" LightUnion data type, since this can contain sun data too.

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:13 +01:00
EEVEE-Next: Refactor light data packing

Maybe it would be best to not use even more shape names for the falloff type?

Miguel Pozo commented on pull request blender/blender#119713 2024-03-22 18:38:12 +01:00
EEVEE-Next: Refactor light data packing

I find this confusing.

Miguel Pozo pushed to pull-eevee-jittered-shoft-shadows at pragma37/blender 2024-03-21 20:18:10 +01:00
3f991d6be8 Rework parameters
Miguel Pozo created pull request blender/blender#119753 2024-03-21 17:36:10 +01:00
WIP: EEVEE-Next: Jittered Soft Shadows
Miguel Pozo pushed to pull-eevee-jittered-shoft-shadows at pragma37/blender 2024-03-21 17:31:40 +01:00
3f858961d9 cleanup
5dce530e5f Implement all punctual types
a2e2a34866 Scale tracing radius based on jittering scale
2b786e87e2 Apply origin jitter
26dbf2009d Split projection and origin shift
Compare 10 commits »
Miguel Pozo pushed to pull-eevee-jittered-shoft-shadows at pragma37/blender 2024-03-20 20:46:53 +01:00
7bae62ee46 Initial test
e0b413f818 Merge branch 'blender-v4.1-release'
4eab8fae5a Fix #119697: Incorrect update after disabling light linking
3888bdf8b2 EEVEE-Next: Fix transparent shadows convergence
3f10ba244a Cleanup: Use C++ types in view3d_navigate.cc, restore fix from merge
Compare 10 commits »
Miguel Pozo created branch pull-eevee-jittered-shoft-shadows in pragma37/blender 2024-03-20 20:46:52 +01:00