pymomentum renderer: Add create_camera_for_body function to replace build_cameras_for_body. #710
Conversation
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
meta-cla
bot
added
the
CLA Signed
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
6d841c3 to
c6e379d
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
c6e379d to
6f64b38
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
6f64b38 to
7d2ff15
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
2 times, most recently
from
3482811 to
e6e2b82
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
2 times, most recently
from
815f891 to
ff04b8c
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
ff04b8c to
7866fae
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
2 times, most recently
from
7adc9c6 to
12c63bb
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 23, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
12c63bb to
fea5a2e
Compare
cdtwigg
added a commit
that referenced
this pull request
Oct 24, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
added a commit
that referenced
this pull request
Oct 24, 2025
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
fea5a2e to
0a3ab50
Compare
…oad the correct commit data. Differential Revision: D85488266
Summary: Fixed incorrect template-id syntax in the destructor definition of `MultiposeSolverFunctionT<T>`. The destructor was incorrectly defined as `~MultiposeSolverFunctionT<T>()` but should be `~MultiposeSolverFunctionT()` per C++ standard - template-ids are not allowed after the destructor operator. This error was caught by conda-forge builds but not by Meta's internal diff signals because the external pymomentum CI job is currently disabled in GitHub workflows to reduce costs, and internal Buck builds apparently succeed with different compiler flags. Differential Revision: D85457060
Differential Revision: D85474531
…oad the correct commit data. Differential Revision: D85481382
cdtwigg
added a commit
that referenced
this pull request
Oct 25, 2025
…uild_cameras_for_body. (#710) Summary: build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
0a3ab50 to
8bae69f
Compare
Differential Revision: D85311496
…uild_cameras_for_body. (#710) Summary: Pull Request resolved: #710 build_cameras_for_body has bothered me for a long time: 1. It uses torch.Tensors even though it's not differentiable, ideally we're moving the rendering code toward numpy 2. It is batched even though I have literally never seen anyone use it that way, we'd like to move the renderer away from batched operations and encourage people to use multithreading instead if they want to render in parallel (because batching in rendering is basically impossible to use anyway). 3. Because of (2), it is very confusing when you want to create a camera for a multi-frame animation, you have to add a fictional batch dimension or the tensor will get treated as batched and return n_frames cameras, and since you access cameras[0] anyway at the end failures are silent. 4. It uses joint_parameters even though other renderer operations operate on skel_states, and this is annoying when you only have skel_states (I have seen cases where we inverted skel_states to joint_params just to create a camera). 5. The naming isn't consistent with other renderer functions like create_z_buffer. Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function. Reviewed By: cstollmeta, jeongseok-meta Differential Revision: D85170861
cdtwigg
force-pushed
the
export-D85170861
branch
from
8bae69f to
131f78a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary:
build_cameras_for_body has bothered me for a long time:
Therefore I'm proposing this new function "create_camera_for_body" (note the singular "camera"). Since I'm changing the name (to address complaints (2) and (5)), we might as well just add it alongside the existing function, and after we've replaced all uses we can retire the other function.
Reviewed By: cstollmeta, jeongseok-meta
Differential Revision: D85170861