• `modernize-use-default-member-init` and `readability-redundant-member-init`
• Minor adjustments to `.clang-tidy` to improve syntax & remove redundancies
While all the previous fixes to optimizeVertexCache invocation fixed the
vertex transform efficiency, the import code still was missing two
crucial recommendations from meshoptimizer documentation:
- All meshes should be optimized for vertex cache (this reorders
vertices for maximum fetch efficiency)
- When LODs are used with a shared vertex buffer, the vertex order
should be generated by doing a vertex fetch optimization on the
concatenated index buffer from coarse to fine LODs; this maximizes
fetch efficiency for coarse LODs
The last point is especially crucial for Mali GPUs; unlike other GPUs
where vertex order affects fetch efficiency but not shading, these GPUs
have various shading quirks (depending on the GPU generation) that
really require consecutive index ranges for each LOD, which requires the
second optimization mentioned above. However all of these also help
desktop GPUs and other mobile GPUs as well.
Because this optimization is "global" in the sense that it affects all
LODs and all vertex arrays in concert, I've taken this opportunity to
isolate all optimization code in this function and pull it out of
generate_lods and create_shadow_mesh; this doesn't change the vertex
cache efficiency, but makes the code cleaner. Consequently,
optimize_indices should be called after other functions like
create_shadow_mesh / generate_lods.
This required exposing meshopt_optimizeVertexFetchRemap; as a drive-by,
meshopt_simplifySloppy was never used so it's not exposed anymore - this
will simplify future meshopt upgrades if they end up changing the
function's interface.
When wslay receives a message that is too big or cause a protocol error,
it automatically sends a close request to the remote peer but it also
completely stop calling the receive callback resulting in the state
being "stuck" as CONNECTED (even if both client and server have
disconnected).
We now check if we sent a close message and reading has been disabled to
manually transition to the "closed" state with the proper reason.
Previous wording said that @GDScript referred to entries that could be accessed in any script. Although with common sense we could imagine that it is only refering to GDScript specific pieces of code, the wording is a little unclear.
In general there are small changes to the wording which makes it more clear and concise.
Wording change
Tried to match the wording up with my last change which should make it a bit easier to parse at a glance what the docs mean by "from any script"
Changed language from "not specific to" to "which work in any language"
After consulting multiple people the new wording seems easier to parse, even for non coders
Update doc/classes/@GlobalScope.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Co-Authored-By: Micky <66727710+Mickeon@users.noreply.github.com>
