πΌ Internship at SportsImproVR
This internship was not just about building features β it was about solving messy, real-world problems where the solution was often unclear.
I worked on two major areas:
- π₯ Automating motion capture workflows
- πΊ Building a full-body tracking system for VR training
Both required deep technical exploration, experimentation, and decision-making under uncertainty.
π€ Zhangir Before the Project
Before starting:
- Strong systems & low-level programming mindset
- Comfortable building tools and engine-level features
- Limited experience with:
- VR development
- Android builds
- Bluetooth communication
- Motion capture pipelines
Most importantly:
I was used to problems where the solution exists.
This internship forced me into problems where:
The solution might not even be possible.
π¨ My Contributions
π₯ Contribution 1: Video-to-FBX Converter
π― The Goal
The company had a painful workflow:
- Upload video to MoveAI
- Wait
- Download files
- Import into Unity
- Clean up unnecessary data
This process was:
- Slow β³
- Manual π±οΈ
- Error-prone β οΈ
The Vision
βWhat if this entire pipeline was just one button inside Unity?β
βοΈ Challenge 1: Bridging Unity and Python
β Problem
MoveAI only provided a Python API.
Unity uses C#.
There was no direct way to connect them.
π§© Why it was Hard
- Cross-language execution (C# β Python)
- File handling across environments
- Debugging becomes harder across boundaries
π‘ Solution
I started small:
- Created a Python script that writes a file
- Triggered it from Unity
Then scaled up:
- Integrated MoveAI API
- Passed video paths as input
- Returned FBX data into Unity
β Result
A working pipeline:
Unity β Python β MoveAI β Unity
βοΈ Challenge 2: Editor Freezing
β Problem
Each conversion took ~15 minutes.
Unity completely froze during this time.
π§© Why it was Hard
- Unity runs on a main thread
- Blocking operations freeze the editor
π‘ Solution
- Moved execution into background tasks
- Kept Unity responsive during processing
β Result
- Editor stays usable
- Workflow no longer blocked
βοΈ Challenge 3: Sequential Processing Bottleneck
β Problem
Videos processed one-by-one.
10 videos = hours of waiting.
π§© Why it was Hard
- Python parallelism unreliable
- Needed per-task tracking
π‘ Solution
Instead of forcing Python:
I moved parallelism into Unity.
- Each video = separate task
- Independent progress tracking
β Result
- Parallel processing β‘
- Massive time savings
βοΈ Challenge 4: UX Was Terrible
β Problem
- Users had to manually copy files
- No feedback
- No validation
π‘ Solution
I redesigned the tool:
- π Native file browser
- β οΈ Error/warning system
- π Progress bars per video
- π§ Clear UI layout
β Result
From:
βHacky internal toolβ
To:
βProduction-ready pipelineβ
π₯ Final Impact
Before:
- Manual, slow, frustrating workflow
After:
- One-click automation
- Scalable pipeline
- Developer-friendly tool
πΊ Contribution 2: Full-Body Tracking System
π― The Goal
Build a system that tracks the entire human body in VR.
This is critical for:
- Sports training ποΈ
- Motion analysis π
βοΈ Challenge 1: The Tracking Landscape is a Mess
β Problem
There is no single standard solution.
Options included:
- IMU trackers
- Lighthouse systems
- Camera tracking
- EMF systems
π‘ Solution
I performed a full breakdown of:
- Accuracy
- Latency
- Cost
- Reliability
β Result
Identified IMU-based tracking as best balance.
βοΈ Challenge 2: Xsens Was a Dead End
β Problem
Trackers drifted over time.
Even when stationary:
They still moved.
π§© Why it was Hard
- Not a coding bug
- Fundamental hardware limitation
π‘ Solution
- Contacted Xsens support
- Validated behavior experimentally
π¨ Realization
This solution will NEVER work for our use case.
β Result
Pivoted away early β saved huge time.
βοΈ Challenge 3: Bluetooth is a Nightmare
β Problem
Needed to communicate with trackers.
π§© Why it was Hard
Bluetooth LE structure:
Device β Service β Characteristic
- Poor documentation
- Hard to debug
- Platform-specific behavior
π‘ Solution
- Learned BLE architecture deeply
- Built Android test apps
- Scanned and connected to devices
β Result
Successfully detected and connected trackers.
βοΈ Challenge 4: βConnectedβ β βWorkingβ
β Problem
Could connect to trackersβ¦
β¦but received no usable data.
π‘ Solution
- Studied BLE specs
- Identified correct characteristics
- Learned how data is structured
β Result
Understood full communication pipeline.
βοΈ Challenge 5: Choosing the Right Hardware
β Problem
Xsens unusable β needed alternative
π‘ Solution
Researched and proposed:
HaritoraX
Why:
- πΈ Cheaper
- π§ Provides full skeleton
- π Outputs via OSC
β Result
Company adopted new solution.
βοΈ Challenge 6: OSC Pipeline Not Working
β Problem
No data received in Unity.
Silent failure.
π§© Why it was Hard
- No error messages
- Platform restrictions (Android)
π‘ Solution
After deep debugging:
- Found missing Android permissions
- Modified
AndroidManifest.xml
β Result
OSC communication works π
π₯ Final Impact
Before:
- No working tracking solution
After:
- Clear pipeline:
- Trackers β VR Manager β OSC β Unity
π€ Zhangir After the Project
π Growth
Before:
- Strong programmer
After:
- Real-world problem solver
π§ What Changed
- I now think in systems, not features
- I question whether a problem is worth solving
- I make decisions based on constraints, not assumptions
π Key Takeaways
- The hardest problems are uncertain ones
- Engineering = decision-making under ambiguity
- The best solutions often come from changing direction
π Final Reflection
This internship proved that I can:
- Build real production tools π οΈ
- Navigate unknown technical domains π
- Make impactful engineering decisions π―
Most importantly:
I can turn chaos into working systems.