Closed jfcameron closed 3 years ago
none, per-entity and per triangle are realistically what would be wanted. However maybe a user provided functor is the way to go, since there could be novel problems with very simple solutions.
Blending a 2d scene for example would only require sorting by depth. or maybe no sorting at all, if the user was able to instead increment their depth while iterating a scene's transulcency set. This would require that the user can extend try_add
strategy could be global (context wide) or scoped to a camera, since transparency sorting is done with respect to the current camera. I think adding a param to the camera factories makes sense. could have static "built in" sorters in the camera class, a none, per-entity and... per triangle. The problem with per triangle is that I dont want to duplicate vertex data in RAM (library currently uploads to VRAM then throws away the copy). however if the user is provided a functor, then they could do the work to keep the required data in memory. Entity could hold a user pointer, where the user could store the required tri data.
this story has become the more concrete ticket #56
currently transparency sorting is done on a per-entity basis in webgl1es2_scene.cpp. The user should be able to either select from a variety of strategies or provide their own implementation.