The current flag did not work because float shader flags are not
supported. It was also not very useful because it was per-shader
and did not use the alpha cutoff property of glTF materials.
Instead, let's turn the shader flag into an enable/disable boolean,
and add a scalar material property named "alphacutoff" that gets
read by the glTF importer.
When the alphaCutoff flag is enabled, the material property will be
compared against the pixel's alpha value to decide whether it should
get discarded.
- When calling lovr.graphics.stencil, the color mask is initially
disabled, and gets restored to its initial state afterwards.
- However, when it's restored, it uses lovrGraphicsSetColorMask, which
just sets shadow state that doesn't make it all the way to GL until
another draw is done.
- The consequence of this is that if you call .stencil and then don't do
a draw, any clears that happen will use the old (disabled) color mask,
preventing the color buffer from being cleared.
- The solution here is to lower the color mask change down into opengl.c
where it can directly hit OpenGL.
Vector methods are extended to receive vectors as individual numbers
for each of x,y,z,w component. The vector objects are still supported
as well.
Previously only single value scalar was supported. This change maintains
backward compatibility.
```
v = vec3():add( 1, 2, 3 ) -- both do the same
v = vec3():add( vec3(1, 2, 3) ) _/
v = vec4():mul( 2 ) -- x component is a default for y, z
v = vec4():mul( 2, 2, 2, 2 ) _/
v = vec2():lerp( 2, 2, 0.5 ) -- in lerp, dot, cross, distance
v = vec2():lerp( vec2(2, 2), 0.5 ) _/ all components are mandatory
```
- You were able to write a Blob to a ShaderBlock
- Using ShaderBlock:send(Blob, offset, size)
- It was not flexible enough and it was broken
- The data was read from `offset` bytes into the Blob.
- The data was written to the beginning of the Buffer.
- The Buffer was flushed at `offset` bytes into the Buffer.
- This commit changes the signature of the variant
- to ShaderBlock:send(Blob, srcOffset, dstOffset, size)
- and hopefully fixes the behavior.
- Also why is this entire commit description a bulleted list
If you create and destroy objects quickly (using :release), malloc
might give you the same pointer. When we look up this pointer in
the userdata cache, it'll give you an invalid Proxy/pointer, which
throws an error like "Calling 'fn' on bad self".
When collecting objects, remove them from the userdata cache.
Start is mainly used for setting up graphics-related stuff, since it
was created to perform setup after the window/graphics module is
initialized. Since the display driver is the only one doing rendering,
it makes sense to only call start on the display driver.
...also fixes a bug where start is getting called twice.
- We need some headset initialization to happen upfront
- But we still want some delayed initialization for when graphics is ready
- Go back to headset initialization happening when module is required
- Add lovr.headset.start that can be used for post-graphics init
lovrCheck is a new way of performing runtime assertions.
It's identical to lovrAssert, except it's compiled out if
LOVR_UNCHECKED is defined.
It is meant to be used for non-mission-critical validation, for
example proper usage of types passed to the Lua API. lovrAssert
should still be used to check return values from platform APIs.
- Use incoming depth settings to determine whether depth test should be
enabled or disabled (wtf)
- Always track state.depthTest, even if depth test is disabled
- Previously, animate was converting from oculus basis to lovr basis.
- Not all hand models are animated.
- Instead, apply the compensation in newModel.
- This means that both animated and non-animated models have correct orientation.
- Verified that regular getPose is returning correct rotation as well.
- Previously, animate was converting from oculus basis to lovr basis.
- Not all hand models are animated.
- Instead, apply the compensation in newModel.
- This means that both animated and non-animated models have correct orientation.
- Verified that regular getPose is returning correct rotation as well.
If a Texture is created from a handle, that means someone else created
it, so we expect them to destroy it. We were always destroying handles,
and I guess this was usually okay because glDeleteTextures is idempotent.
However, we're seeing a crash in the Oculus driver when OVR is torn
down. Presumably it is trying to access its swapchain textures after we
destroyed them. Not sure why this wasn't an observable issue before,
maybe it's a new regression. Still, it makes sense to only delete the
GL texture handle if we were the one that created it.
We don't need to check this for the renderbuffer since we always own those.