Change font size
It is currently Tue Jun 30, 2026 3:37 pm


Post a new topicPost a reply Page 1 of 2   [ 16 posts ]
Go to page 1, 2  Next
Author Message
 Post subject: The Holy Grail plug-in?
PostPosted: Mon Jun 11, 2012 5:14 am 

Joined: Wed Sep 28, 2011 3:28 am
Posts: 96
Hi all,

I'm just watching a few Ipi test renders people have done on my lunch hour and it got me thinking....I think the 'Holy Grail' of all solutions with mocap would be the invention of an anti-collosion plug-in for limbs.
What I mean by that is, a solution to solve those instances where arms and hands pass through the body, when your avatar character is to wide for your BVH.

You can see it happen here: http://www.youtube.com/watch?v=KgcgE5YAud8

No offence to the creator of this btw!...just using it as an example.

Now, I'm a Cinema 4D user, and I've used the collision tag on parented objects a few times, so that they don't sink through each other, and it's a very simple thing to assign.

Why can't I tell an application (eg: Daz, IClone, Ipi etc etc) that the hands are the objects that must not pass through the abdomen etc.

Maybe there's probably one already, and I'll look like an idiot when someone points it out to me!....but hey, I haven't seen one yet.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2012 1:41 pm 

Joined: Mon Aug 03, 2009 1:34 pm
Posts: 2423
Location: Los Angeles
Hi,

I believe iPi does use collision for limbs. I can't look at it right now but somewhere in there is an option to view the collision objects on the tracking character. Is this what you're talking about?

G.

_________________
Greenlaw
Artist/Partner - Little Green Dog | My Demo Reels (2013,) (2015,) (2017,) and (2019)
Image
Watch a one minute excerpt on Vimeo now!


Top
 Profile  
 
PostPosted: Tue Jun 12, 2012 3:55 am 

Joined: Wed Sep 28, 2011 3:28 am
Posts: 96
Hi Greenlaw, thanks for your reply.

When you get a chance, can you paste a screenshot into this thread, showing what you're seeing in Ipi?

Rather than the skeleton colliding with itself, I meant the actual character avatar. But if I could see your screenshot that would help me work out if you've found what I'm looking for.

Many thanks :)


Top
 Profile  
 
PostPosted: Tue Jun 12, 2012 10:12 am 

Joined: Mon Aug 03, 2009 1:34 pm
Posts: 2423
Location: Los Angeles
Sure. Sorry I didn't get a chance to check last night--it's been very busy here--but I'll look tonight. To be honest, I've never actually used this feature to analyze collision, I'm only aware that it's there. Also, I've only looked at it in 1.0, not in 2.0 yet.

I sometimes have collision issues when a character gets down close to the floor and the legs get pushed into odd positions because they can't pass through the floor or body. Obviously this isn't a desirable effect but it does indicate that collision is at work because the legs appear to force their way around the body.

Hmm...I wonder if it would help if self-collision could be 'dialed down' to softer values in situations like this, much the way we can adjust jitter removal sensitivity.

BTW, my daughter's '3 Happy Cats' performance was probably the trickiest example of this I've run into. iPi DMC 1.0 managed to get through the motion data with good results but it took a bit more user supervision than usual. Soon I will try running this data through 2.0 and see if it's any easier to track now.

G.

_________________
Greenlaw
Artist/Partner - Little Green Dog | My Demo Reels (2013,) (2015,) (2017,) and (2019)
Image
Watch a one minute excerpt on Vimeo now!


Top
 Profile  
 
PostPosted: Wed Jun 13, 2012 1:34 am 

Joined: Mon Aug 03, 2009 1:34 pm
Posts: 2423
Location: Los Angeles
Here's the screencap from iPi Studio 2.0 you requested. To enable Collision view, look under View and select Collision Objects. As you can see in the image, this collision objects represent the volume of the limbs, not the bones inside the limbs. Hope this is what you were looking for.

BTW, I'm glad you got me thinking about this. Enabling Collision Objects view might help me analyze and understand what's going on with the '3 Happy Cats' motion a little better and help me improve future capture sessions. After all the time I've used this software, it never occurred to me how useful this feature could be in some situations.

Attachment:
Collision.jpg
Collision.jpg [ 143.26 KiB | Viewed 40618 times ]

_________________
Greenlaw
Artist/Partner - Little Green Dog | My Demo Reels (2013,) (2015,) (2017,) and (2019)
Image
Watch a one minute excerpt on Vimeo now!


Top
 Profile  
 
PostPosted: Fri Jun 15, 2012 2:03 am 

Joined: Wed Sep 28, 2011 3:28 am
Posts: 96
Hey Greenlaw.

When I speak of 'collosion detection' I speak of most commonly hands going through the body - see my example attached from natofor's recent clip.

Again...hope you peeps don't mind me using your pics as examples.

Greenlaw....so you're saying version 2 has sorted this out?


Attachments:
hand sink.jpg
hand sink.jpg [ 144.85 KiB | Viewed 40579 times ]
Top
 Profile  
 
PostPosted: Fri Jun 15, 2012 10:00 am 

Joined: Mon Aug 03, 2009 1:34 pm
Posts: 2423
Location: Los Angeles
No, I'm basically just saying iPi 1.0 and 2.0 already has some form of self-collision build in, but It's probably meant to prevent more egregious penetration issues and not as sensitive to smaller items, like the hands in your posted example.

Maybe it would help if they allowed the user to configure self-collision sensitivity for limbs like they have for jitter removal. In your case, you could use more self-collision sensitivity with the hands, and in my case I could use less in the legs and feet.

Just curious but are you using Kinect? Hands can be a little trickier with Kinect because the volume can get a little 'blobby' when the hands are close to the chest and stomach. When we do our performances we try to be a little more conscious about bringing hands too close to the body.

This doesn't directly apply to your character but with the 'Happy Box' mocap we had penetration through the head because our characters have such huge heads. In Motion Builder, this sort of thing is very easy to fix:

1. create an animation layer,
2. keyframe the hand at a peak position before and after the point of penetration,
3. go to the point of penetration and move the wrist joint to the desired position and keyframe it,
4. hold that corrective position for as long as needed.

If you're using a control rig in your animation program, it should be just as easy to correct. This is a common problem, especially for characters that have non-human proportions. It would be cool if iPi DMC can get similar post-retargeting editing features someday.

All that said, sometimes bringing hands close to the body works just fine. For example, in our very early test seen here, I end the motion by crossing my arms:

http://www.youtube.com/watch?v=G2KLtGsl-L0&feature=plcp

This was done using a very old version of iPi DMC and four PS3 cameras--any correction that was applied was obviously done within iPi Studio. I recall applying this data to 'Sister' as a test, and the arms crossing part worked fine with very little tweaking. Squatting was a little problematic but that was because of the character's grotesque proportions (short arms and legs but huge torso,) but like in the example described above, this was easy to correct using a control rig in another program.

Hmm. I should shoot a similar test now using six PS3 Eye cams and two Kinects to see how the new software compares with this test from two years ago. Should be very interesting.

G.

_________________
Greenlaw
Artist/Partner - Little Green Dog | My Demo Reels (2013,) (2015,) (2017,) and (2019)
Image
Watch a one minute excerpt on Vimeo now!


Top
 Profile  
 
PostPosted: Fri Jun 15, 2012 7:37 pm 

Joined: Fri Oct 30, 2009 9:49 pm
Posts: 21
Location: São Paulo - Brazil
Well, since I was mentioned by Carder in my pict, the one he has shown in his topic questions, I have some observations to make:

Well I have been using two kinects 0x180º calibration.
Besides the hand sinking in whatever part of the body, and the exporting deformations to iclone. I have noticed that the tracking for the right hand (always the right hand) has a lot of problems being tracked. Yes, you are right that when the hand is too close to the body, it can become difficult to be tracked. But that being true, the same should happen with the left hand. With the left hand I can even touch my chest and the tracking will be perfect. So if the left hand tracking is very close to the body and has perfect tracking, why doesn't the same happen with the right hand?
And more... I am standing "T-pose" bringing both arms down, than turning slightly to the side to fetch an object to my right, then I turn back to the front position and repeat the fetching motion, this time, to my left. Result: The right side will lose its tracking completely, but once again, it will be perfect for the left side. Why?


Top
 Profile  
 
PostPosted: Sat Jun 16, 2012 12:12 am 

Joined: Mon Aug 03, 2009 1:34 pm
Posts: 2423
Location: Los Angeles
For what it's worth, I avoid the 180 degree setup because I seem to get far more trackable results when using the 90 degree setup. To me, the 180 degree setup appears more susceptible to IR interference and could be less accurate. My primary test case was the two '3 Happy Cats' sessions--the 90 degree session tracked fine with only a few difficulties involving collision (described elsewhere) but the 180 session was almost completely untrackable. Granted, the motions my daughter made for each session were not exactly the same but I think they were similar enough to be a fair test.

Other factors can vary quality as well, such as the environment and the type of motions being tracked but between 90 vs. 180 degree setups, I really am getting better results with 90, at least in the few comparison tests I've done. My guess is that the volume overlap that exists with 90 degrees gives Studio a more accurate shape to work with; when you record with full 180 degrees the volume overlap does not exist at all. Also, with 180, the signal strength probably isn't as constant as when you record with 90--for example, with 180, when you walk towards one device, the signal may get stronger but it proportionately gets weaker with the other device; with 90 degrees the strength between the two devices may stay a little more balanced as you move between them. That's just a guess though--be advised that these are unscientific observations and you should probably take my ideas about this topic with a grain of salt.

As for why the left hand seems more trackable than the right in your example, I don't know the answer--I haven't seen that problem here and I can't even guess what may cause that. Note: to date, I've only recorded data using iPi DMC 1.0. Just wondering, could this be a new Studio 2.0 problem? Or was your example tracked using Studio 1.0? I'll try to do some controlled tests tomorrow using 2.0 and Kinect and let you know if I notice anything like this.

(Yay! I finally have a day off so I can spend it working.) :)

Just curious but when you make your T-Pose, do you directly face a Kinect or do you have your arms pointed towards each Kinect? When I did my 180 degree test, I faced one device directly. When I do my 90 degree recordings, I face the left side Kinect, though I don't think it really matters which one you face. I think I've also tried facing the space between the Kinects, though I can't remember if that was better.

Back when we did 'Happy Box', I believe I faced the space between the two Kinects and the devices were only about 60 degrees apart--I haven't compared to see if this was any better as I assumed a full 90 degree would be better. That said, at 60 degrees there is even more volume overlap which might improve accuracy but only when facing the devices--obviously, there is increased risk of occlusion errors as you narrow the range of visibility.

Note: I just checked this video from last year and it does look like I faced the space between the two devices. It also looks like my range was even narrower than 60 degrees. Surprisingly, this configuration worked fine even for the 'chainsaw dance' shot where 'Sister' spins around several times. I don't recommend going less that 60 degree though--better to go full 90 if possible.

BTW, it may seem to make sense that you would have less chance of occlusion errors using the 180 degree setup but because you're recording depth, occlusion isn't nearly as problematic with 90 degrees as you might think. When recording depth from 90 degrees (as opposed to just 2D video), you're getting nearly complete 360 coverage--you almost have to make a conscious effort to hide things from both Kinects to produce occlusion problems.

Anyway, this is just my personal experience and opinion. Hope some of this is helpful but please continue to report your experience as I'm curious to learn why we're getting different results.

G.

_________________
Greenlaw
Artist/Partner - Little Green Dog | My Demo Reels (2013,) (2015,) (2017,) and (2019)
Image
Watch a one minute excerpt on Vimeo now!


Top
 Profile  
 
PostPosted: Sat Jun 16, 2012 8:28 am 

Joined: Fri Oct 30, 2009 9:49 pm
Posts: 21
Location: São Paulo - Brazil
Ok. Thanks for your feedback. As soon as possible I'll do some more trials with 180 and 90 as well.
Since the recorder compression is far better and smaller, maybe I can send, a small capture with video and fbx or bvh, for us to study it.
By the way, the "T" pose always facing my main kinect, in my case, camera 01.
What I have noticed, that if I attach a small piece of cardboard, a bit bigger than my hands, I have perfect tracking. But it isn't nice to start attaching things all over.
Best Regards

Toby


Top
 Profile  
 
Display posts from previous:  Sort by  
Post a new topicPost a reply Page 1 of 2   [ 16 posts ]
Go to page 1, 2  Next


Who is online

Users browsing this forum: No registered users and 177 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  


Powered by phpBB® Forum Software © phpBB Group
610nm Style by Daniel St. Jules of Gamexe.net