Skip to content
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

Why create a "global_part_neighbor" in the function "find_neighbor" in the skeleton.py? #30

Closed
ANYMS-A opened this issue Jun 11, 2020 · 9 comments

Comments

@ANYMS-A
Copy link

ANYMS-A commented Jun 11, 2020

Hi,
I was recently reading the source code very carefully in order to understand the whole pipeline of your work.

I was kind of confused that why init a variable named "global_part_neighbor" in the in the function "find_neighbor" in the line #373 of the models/skeleton.py?

Besides, why append a "edge_num" into those global_part_neighbor's list in line #375?

Many thanks!

@PeizhuoLi
Copy link
Collaborator

PeizhuoLi commented Jun 13, 2020

Hi,

Line 373 is because we treat the global position channel as an "extra joint" and it shares the neighbor of the root joint, which is exactly global_part_neighbor.

For line 375, the "neighbor" relation is symmetric, so we add the extra joint (its index is edge_num, the last one) to the neighbor_list of its neighbors.

Hope this will help.

@ANYMS-A
Copy link
Author

ANYMS-A commented Jun 15, 2020

Hi,

Line 373 is because we treat the global position channel as an "extra joint" and it shares the neighbor of the root joint, which is exactly global_part_neighbor.

For line 375, the "neighbor" relation is symmetric, so we add the extra joint (its index is edge_num, the last one) to the neighbor_list of its neighbors.

Hope this will help.

Got it !Thank you so much for the answer!

@ANYMS-A ANYMS-A closed this as completed Jun 15, 2020
@ANYMS-A
Copy link
Author

ANYMS-A commented Jun 21, 2020

Hi, I recently found that there might be a mistake when calculating the neighbors of the "global_part_neighbor".

e.g. If you read the .bvh file of "BigVegas", you can use debug mode of the IDE to found that the 22th element of the list which returned by the "find_neighbor" function is not the neighbors of the root joint(if you draw a graph of these 23 bones). It should be [0, 1, 4, 5, 8, 9], but got [0, 1, 2, 4, 5, 8, 9] instead.

I thinks it is because: at first, the index of the root joint is 0, but the "edges" eliminate the root joint, so when we obtain the neighbor_list after the for loop in line #370 of the skeleton.py, the mistake occurs.

global_part_neighbor = neighbor_list[0].copy()

is not the neighbors of the root joint. I think it represents the neighbors of the "LeftUpLeg" of the "BigVegas"'s skeleton.(you could draw out the skeleton graph of the "BigVegas"'s 23 bones to verify it.)

@ANYMS-A ANYMS-A reopened this Jun 21, 2020
@PeizhuoLi
Copy link
Collaborator

Thank you very mush for providing your findings! I think it's indeed a bug and we'll fix it later.

@ANYMS-A ANYMS-A closed this as completed Jun 30, 2020
@fire
Copy link

fire commented Dec 14, 2020

Can you describe a way for fixing this? I can retrain my models.

@PeizhuoLi
Copy link
Collaborator

global_part_neighbor should be all the edges(armature) that contains joint with index zero. This condition should be used instead of a copy of neighbor_list[0].

@jdbodyfelt
Copy link
Contributor

So if neighbor_list = [] how can this be fixed?

@fire
Copy link

fire commented May 17, 2021

@PeizhuoLi I'm having trouble with neighbor_list = []

@PeizhuoLi
Copy link
Collaborator

Could you provide more details on how to reproduce this error? Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants