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

Shape converter issues (self-intersecting edges, normals) #8

Closed
assertivist opened this issue Sep 10, 2018 · 7 comments
Closed

Shape converter issues (self-intersecting edges, normals) #8

assertivist opened this issue Sep 10, 2018 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@assertivist
Copy link
Member

see avaraline/avara-level-converter#1 - this is a self intersecting shape

@assertivist
Copy link
Member Author

screenshot from 2018-09-10 11-08-33

@shrizza
Copy link
Contributor

shrizza commented Sep 10, 2018

This may be related to why the inside of missiles look weird. I noticed it's difficult to see incoming missiles because I think the inner red part is either only partially displayed or gone (or maybe not red at all). You can also clearly see a difference when a missile is loaded. Compare:

missile1

To:

missile2

@rherriman
Copy link
Member

@shrizza I think those are two separate issues actually. The inside color of the missile not being correct is related to issues #2, #3, and possibly #9. Issue #2 has the most helpful information on the problem, but the short explanation is that CBSPPart::ReplaceColor is not implemented correctly.

The other contributing problem is the way OpenGL draws polygons that intersect with the camera. As far as I understand it, at least.

@rherriman
Copy link
Member

@shrizza This isn't really the place to talk about this, I suppose, but the issue with fired missiles not lighting up has been resolved by #14.

@assertivist assertivist added the bug Something isn't working label Sep 11, 2018
@assertivist
Copy link
Member Author

I'm adding this here because the converter is in the process of being merged into our repo's scripts directory instead of its own directory.

The missile shape stems from a larger issue during shape conversion for avara--there are self intersecting edges in that shape so the converter has to reorganize the shape to account for new verts added during triangulation to compensate for these self intersecting edges.

Beyond that, from doing experiments with lighting, it seems that some of the models (at least including but not limited to the head model) have improper normals causing lighting to be incorrect:

hector_head_lighting_error

This shows the hector head lit from above, where both sides of the main hull shape should be lit in equal amounts. Clearly the normal is flipped here and is giving the lighting value for the wrong side of the shape.

@assertivist assertivist changed the title Missile lock "X" shape not correct Shape converter issues (self-intersecting edges, normals) May 5, 2019
@assertivist assertivist self-assigned this May 5, 2019
@assertivist
Copy link
Member Author

Updates on this:
The normals being wrong are a side effect of the double-sided face thing. So I'm no longer as worried about that.

The self-intersecting shapes are still a problem. The way I have this set up, each polygon of a BSP is flattened into a 2d plane for the Triangle library to operate on, and give a list of triangles to fill out of the edge/vertices. With these self-intersecting shapes, the library adds new vertices to make the shape regular.

However, it does this in the 2-space of the flat face and not 3-space of the BSP as a whole, so I can't just add the new vertices to the shape, without converting them back into 3-space. This is proving very difficult to do correctly so that the vertices end up in the right places.

What I do currently is take an arbitrary pair of vertices from the face and use that as a vector in the plane of the shape to project all vertices on to a 2d plane. But it seems that the length of that vector has an effect on the scale/position of the resulting projection. I'm gonna try to reach out to some folks to see if there's a better way of making sure that these projections (and their reverse) end up the same every time.

@assertivist
Copy link
Member Author

The normals and stuff look much better now. I haven't seen any graphical bugs with the new converter code.

assertivist pushed a commit to assertivist/Avara that referenced this issue May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants