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
the GUI needs structure information, e.g., for picking layers, orbiting the camera, depth testing labels and probably other things. we also need collision information, e.g. for navigation, camera flights etc. collision information are cameras pointing down, to the side etc., the other Infos are ray casts
we have discussed 2 approaches:
rendering the information into a large (screen size) buffer by default, on every frame, copy to CPU, move to gui thread. this costs on every frame, but the GUI thread can read without roundtrip to the rendering thread.
render only a small buffer, e.g. picking point+/- 2px, on demand. the result could be sent back via signal to the GUI thread or consumed inside an interaction in the rendering thread (e.g. collision detection).
method 1 is definitely needed for depth testing labels. separate render passes and small buffer copies for each label are certainly more expensive. method 2 is probably needed for collision detection. orbiting, flying, picking could be done in both ways.
The text was updated successfully, but these errors were encountered:
the GUI needs structure information, e.g., for picking layers, orbiting the camera, depth testing labels and probably other things. we also need collision information, e.g. for navigation, camera flights etc. collision information are cameras pointing down, to the side etc., the other Infos are ray casts
we have discussed 2 approaches:
method 1 is definitely needed for depth testing labels. separate render passes and small buffer copies for each label are certainly more expensive. method 2 is probably needed for collision detection. orbiting, flying, picking could be done in both ways.
The text was updated successfully, but these errors were encountered: