You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deprecates the now-unreferenced instanced multidraw rendering paths from #28103, which was superseded by #28404, and does not implement a fallback for Firefox. Instancing is since emulated by appending instances into the multidraw arguments themselves and using indirection for sorting/visibility, which has a fallback implemented for Firefox.
I heavily rely on the multiDrawArraysInstancedWEBGL API in my projects, and the only current way of accessing it is through the object._multiDrawInstances property. Could we reconsider removing this feature?
Preserving access to the full WebGL API within Three.js is always an advantage, and removing support for this functionality would reduce its versatility.
Keeping it available ensures greater flexibility for developers who need advanced instancing techniques like instance multidraw.
This is an unmaintained code path that does not have a fallback for Firefox. Are you aware your projects will not work there? What about the overdraw lack of sorting is creating? Frankly, I think this is about trying to avoid a migration and not in the interest of the project since nothing is unreachable in practice if you implement BatchedMesh yourself and use indirection the three.js API now requires (instancing itself uses indirection, but this is another discussion). If this really were a discussion about low-level API, I have fielded this area quite heavily to enable multi-level mesh streaming with custom renderers and would suggest render methods over private fields or shapes. If you really aren't sure how to accomplish instancing in a custom BatchedMesh, I'm happy to tailor an example, but I maintain the solution we now implement is a strict improvement, and you should be using it.
Yes, but I guess we can consider deprecating it now and fully removing it in 10 releases. By then, WebGPU might finally support multi-draw (as it's still completely broken even on Canary gpuweb/gpuweb#1354 (comment)).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Deprecates the now-unreferenced instanced multidraw rendering paths from #28103, which was superseded by #28404, and does not implement a fallback for Firefox. Instancing is since emulated by appending instances into the multidraw arguments themselves and using indirection for sorting/visibility, which has a fallback implemented for Firefox.