-
Notifications
You must be signed in to change notification settings - Fork 100
Multiple cameras and renderers per single scene #51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
src/potree.ts
Outdated
camera: Camera, | ||
renderer: WebGLRenderer, | ||
cameras: Camera[], | ||
renderers: WebGLRenderer[], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imho, this should be kept backwards-compatible. We could do something like
cameras = Array.isArray(cameras) ? cameras : [cameras];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The typing could also be set to
OrthographicCamera | PerspectiveCamera | OrthographicCamera[] | PerspectiveCamera[]
src/potree.ts
Outdated
priorityQueue: BinaryHeap<QueueItem>; | ||
} => { | ||
const frustums: Frustum[] = []; | ||
const cameraPositions = []; | ||
const frustums: Frustum[][] = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit worried about the garbage due to creating all these arrays each frame.
Sorry I typically have prettier fire automatically on commit so I might have left some badly formatted or semicolon-less lines in there |
I've put together a fairly quick and primitive implementation of re-using the same point cloud scene in multiple WebGL contexts. Without this change, you have to designate a "key camera" that will determine the point load/unload and the other camera(s) just has to live with what it gets. I took the stance that all passed cameras need to be of the same type for simplicity sake but this could be accounted for. Also that cameras and renderers are 1:1 since that fits my use case. Not sure if this is too different and should be kept as a fork or not so I didn't polish it much
Some things that would need to be improved still are the
updateMaterial
function that's looking for perspective frustum params, plucking theminDistance
andmaxScreenPixelRadius
efficiently, making a real example, and cleaning up function arguments.