Timing Yang

@___skylark____ Thanks!

@TimingYang99 Congratulations! This is incredible, especially within almost half a year of SAM 3D Body coming out

🎉 Update: Our paper Fast SAM 3D Body has been accepted to ECCV 2026!

🎉 Update: Our paper Fast SAM 3D Body has been accepted to ECCV 2026! yangtiming.github.io/Fast-SAM-3D-Bo…

@carlosedubarret @pablovelagomez1 it will in youtube or just github video-demo.

@TimingYang99 @pablovelagomez1 That will be amazing. Are you planning to release on youtube, or it will be a paper? If you are going to do the youtube route, can you share the channel so I subscribe?

SAM3d Body CPP in CEB SAM 3d Body addon + DroidSlam It made the process 10x faster and decreased the GPU usage from 14gb to 7gb 🤯 Here is a test (not the best footage, but you get the point 😊)

@carlosedubarret @pablovelagomez1 Another advantage of Fast SAM 3D Body is flexibility. Through our provided run_demo.sh, users can easily adjust inference settings and choose their preferred trade-off between speed and accuracy. We are also planning to release a video demo comparing 3DB, Fast 3DB, and the C++.

Wow, thanks a lot for the detailed information. I just did a test, and at least on my pc, fast sam3d gives a significan speed up and lowers the mount of VRAM use. In my opinion, its best to have all options available. For quick test, CPP might be a nice use, and if the result is not good enough, use fast sam. I always thing the best solution depends on what we need, so I think both solutions are great, for each scenario.

@pablovelagomez1 @carlosedubarret Overall, the speedup appears to come primarily from simplifying the original pipeline rather than from C++, ONNX, or TensorRT itself. Fast SAM 3D Body was designed as a balance between speed and accuracy, while the C++ makes different trade-offs to prioritize runtime speed.

@carlosedubarret Also have you tried fast sam3d body?

@pablovelagomez1 @carlosedubarret The C++ version also removes MoGe-based camera estimation and instead approximates camera parameters from the image size, making the estimated camera parameters dependent on the input resolution.

@pablovelagomez1 @carlosedubarret 2. The C++ version also removes the IntermPred module, an important component in our original design that helps improve body pose estimation accuracy. Without it, body pose predictions can become less accurate and tend to be underestimated in scale.

@pablovelagomez1 @carlosedubarret 1. The C++ version removes the dedicated hand decoder, so it no longer performs explicit hand prediction and instead relies on body decoder placeholders for hand outputs.

@pablovelagomez1 @carlosedubarret As the author of Fast SAM 3D Body, I compared the C++ with ours. The speedup mainly comes from removing the hand decoder, IntermPred, and MoGe camera estimation. This significantly reduces accuracy, removes dedicated hand prediction, and makes camera estimation less reliable.

Two months ago, I vaguely posted a number: 0.9 FID, one-step, pixel space. Now it is 0.75, and can be even lower. Many wonder how. I thought it might end as a small FID prank: simple and deliberate. It started with one question: can FID be optimized directly, and what does it reveal? Introducing FD-loss.

@carlosedubarret Thank you for your interest. Could you please share the configuration you used in run_demo.sh? Using different configurations might lead to varying FPS and accuracy.

Quick test done with Fast SAM 3d Body (BTW, it wasnt realtime fast on windows) took me 4 minutes to make this 6 seconds video.

@ChongZitaZhang Exactly! The original MHR conversion requires 300 iterations, which is a total bottleneck for real-time tasks. We replaced that process with a few MLP layers to strip away the latency while keeping the accuracy.

you know it is serious when the number is 10426x

@iam_shimon It is pity. They are different architectures, so we don’t prepare to work on SAM 3D objects.

@TimingYang99 Nicee! Do we have the same method working for SAM 3D objects? This can make the pick and place perception system much better.

🚀 Fast SAM 3D Body — accelerating SAM 3D Body for real-time human mesh recovery! ⚡ 10.25× faster 3D body estimation ⚡ 10,426× faster MHR→SMPL conversion ⏱️ ~65ms end-to-end 🤖 Deployable on humanoid robots #Robotics

@jackadoresai This depends on the capabilities of SAM 3D Body, which we have fully inherited. Additionally, we support multi-view input, which helps mitigate occlusion issues to a certain extent.

@TimingYang99 65ms end-to-end is wild. Real-time body estimation finally viable for humanoids. Curious how it handles heavy occlusion.

@jimezsa thank you

@TimingYang99 65ms is crazy

📄 arxiv.org/abs/2603.15603 🌐 yangtiming.github.io/Fast-SAM-3D-Bo… github.com/yangtiming/Fas…