This isn't working properly at the moment, since the state gets set for the *next* object, causing significant artifacts. I wasn't entirely sure whether to restore the "proper" behavior or not, since applications may be relying on one or the other behavior, but enabling this feature for shaders is a minefield and it's a lot better to just tell people to use p3d_ColorScale instead.
This lets one use multiple ShaderTerrainMesh tiles effectively, with Panda automatically disabling ones that are certainly not in view. It may be worth an attempt to call `set_bounds_type(BoundingVolume::BT_box)` or set `bounds-type best` in Config.prc to get a tighter volume.
Rather than xforming after the fact, which does not work properly for boxes, we need to apply the transform to the vertices around which the box is generated.
Fixes#506
- DisplayInformation now gives the list of display modes returned by XRRGetScreenResources if RandR 1.2 is supported, which is apparently more reliable than the previous XRRSizes/XRRRates approach.
- Switching fullscreen on X11 to the current resolution on the CRTC that the monitor is on will make the window cover the CRTC properly, rather than forcing the window to have an origin of (0, 0).
- Passing in the pipe's display width/height is commonly done to go fullscreen at native res, but this may not correspond to a real display resolution. It now detects when this is done, and interprets this as "go fullscreen at the native resolution on the current CRTC".
Fixes#575
This is done by collecting bounding volumes for each camera in a scene, and then only rendering a shadow camera if at least one of those bounding volumes overlaps with the shadow camera bounding volume.
Closes#560
This is an extension of the fix in 9a40febdb9, but that only applied when the light was passed to the shader via LightAttrib, and not via shader inputs.
ParamNodePath is not the ideal place to put this, but it's convenient (and probably more efficient than putting it into ShaderAttrib).
We actually need to leak this lock, because we need to call this at static destruction time, and we can't guarantee static destruction order.
This reverts commit afed80e83a.