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

Wrong Normals on Exported Models #5

Open
houthakker888 opened this issue Jul 1, 2020 · 8 comments
Open

Wrong Normals on Exported Models #5

houthakker888 opened this issue Jul 1, 2020 · 8 comments

Comments

@houthakker888
Copy link

Hi again, back with more of a question this time: how can I prevent vertices from being duplicated when exporting? If vert count is high enough, even with no islands, verts on seams will be duplicated resulting in incorrect normals.

Is there a good way to fix this? Or is there any way to edit verts/normals directly on the exported files?

@houthakker888
Copy link
Author

houthakker888 commented Jul 2, 2020

After experimenting (and reading the codes), I think it wasn't a problem with the added verts after all. It appears that the addon re-generates normals based on orientation of verts from weighted bone. Adding verts to a mesh changes weights a bit, so borders of vertex groups will have wrong normals. Re-painting weight messes it up completely.

I haven't a clue how this could be fixed tho :(

@houthakker888 houthakker888 changed the title Reduce Dupe Vertices on Export Wrong Normals on Exported Models Jul 2, 2020
@mino-git
Copy link
Owner

mino-git commented Jul 3, 2020

Hi,

  • could you show me a pic of the messed up normals?

  • @ duplicated verts: this is normal when there are uv map islands. If there are no islands, then this should not happen. If you can provide me with a model i can look into it. My tests never produced duplicated verts, but since the algo is a bit complicated it could be.

  • @ re-painting weights: yeah, the addon regenerates normals based on some weighting. This part of the implementation was sort of self-made, since i could not figure out the exact algo of the original models. Again, provide me with a model and i can see what i can do.

EDIT and yeah, i once had custom normals support in the addon. But on skeletal models i could not figure out how to map them to the formats math, since again, i could not figure out how they did the normals algo wise. It was one of those remaining secrets of the formats, so i just came up with an approximated algo.

@houthakker888
Copy link
Author

houthakker888 commented Jul 3, 2020

Here:
normals
normals2

I'd guess that the addon calculates normals from only 1 bone at a time, so when a vertex has multiple weights, this happens. Would it be possible to do all and average?

EDIT actually I think re-importing to Blender might be automatically fixing the normals. They look fine in Blender.

@houthakker888
Copy link
Author

normals
This one is clearer since the earlier one was re-painted and smoothed. Black patches on vertex group borders.

@houthakker888
Copy link
Author

houthakker888 commented Jul 9, 2020

Hi again, I've found a workaround for now:
For some reason, if only 1 vertex has multiple weights, the normals will be fine. If 3 or more vertices in a row have multiple weights, the ones in the middle will have wrong normals. I redid the weights and made sure to have 1 vertex borders, so it works, although the model is not nearly as good as a full repaint would make it.

Hopefully this info will help identify and solve the problem.

EDIT nvm it looked good in Q3MT but not in game :(

@mino-git
Copy link
Owner

mino-git commented Jul 9, 2020

Hi, i'll take a look as soon as possible.

As a sidenote: the formats do not support more than 3 weights per vertex, just so you know. The addon generates a warning in the system console if it finds a vertex which is influenced by more than 3 bones AKA has more than 3 weights.

@houthakker888
Copy link
Author

Thanks, I didn't know that! More than 3 means exactly 3 is good right?

I tried limiting both weight levels and weights per vertex to 2 though, still no good :(

@mino-git
Copy link
Owner

"More than 3 means exactly 3 is good right?"

3 is good.

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

2 participants