-
Notifications
You must be signed in to change notification settings - Fork 38
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
Incorrect object normals #9
Comments
Feel free to write mails to But I think that this question fits nicely here. Offering a method to compute missing normals is definitely in the scope of this library, in the spirit of "Load me this OBJ and give me its contents in a renderable form", because rendering usually needs normals. The details may again be a bit tricky, considering the fact hat OBJ leaves some degrees of freedom: There could be one face containing normal indices, followed by one that does not contain normal indices... But (although some methods already assume some form of regularity) this should be managable. PerformanceRegarding the performance, there have been two things that raised an eyebrow:
Both of them can be sped up significantly, basically by "reversing" the lookup. The idea is to
This is sketched here. Warning - a bit of a mess ahead!This is just hacked down, to see whether it brings the desired speedup. It basically replaces the whole insertion that you did at GoMeta@aefde24#diff-a1796caf057e8f098f0aa00c186c716dL464 , still keeping your method for a very simple comparison:
From a quick test on a slow PC, the output with the "Flower.obj" is along the lines of
So on your phone, the new version should hardly take longer than half a second. CorrectnessThis is a bit harder to figure out. It's hard to see from the screenshot what exactly is wrong there. (I'll have to render the model, but am not my main development PC right now). It looks like some sort of herringbone pattern. Until I can try it out: If you zoom in, can you see whether the triangles are right and wrong alternatingly? When you watch the petals from below, does the pattern seem to be inverted there? It might just be that some normals point up, and others point down. If this is the case, then this is likely due to some faces containing the vertices in clockwise and others in counterclockwise order. This could be an issue in the loader. I'd review the What would seem more likely: Could it be that the online renderer jus assumes that the material is double-sided, whereas yours assumes a single-sided material? You mentioned that the diffuse intensity is basically computed with something like
For a double-sided material, this could roughly and in the simplest case be changed to
(other adjustments in the shader may likely be necessary, though...) If this doesn't help, I would try to create a test case consisting of a 5-vertex face (without normals) and try to reproduce the problem there. |
Thanks for the write-up, what you said about performance makes sense and is exactly why I should not be writing code at 3AM. Funny, as I was walking my dog this morning I thought exactly what you said about the double sided material. I think that's exactly what's going on and I'll confirm ASAP. |
So I think it's wrong to force calculate the normals when missing. From what I've just seen basically the lack of normal in the face definition is what tells us that both sides are valid. So what I did here is check if the faces are missing normals, then in my renderer I pass a boolean to the fragment shader. So now I have:
|
OK, now you're now basically computing the normal on the fly in the shader. I'm not sooo deeply familiar with GLSL, but knew (from a recent issue in another project) that WebGL (and analogously, GL ES 2.0) needs the I'm also not sure whether the implication "no normals -> double sided material" is right. In many cases, information about whether a material is double sided is stored explicitly in the material. (Not in MTL, though...). In any case, I think that the option to compute normals would be nice to have. I have added a commit in a branch at 5d44c02 Before this is moved into
For the latter, the I already know the answer: No - at least not directly, because this would change the behavior of this method in a possibly non-backward compatible way. There could be a If I had to re-write it from scratch, I'd probably implement some of the
I think it's still OK the way it is. But if it's supposed to be extended further, I might consider a refactoring. BTW: I also considered to add some bounding box computation, like you suggested in your (pending) PR. This could be handy for renderers in order to easily implement a "Fit-To-View" functionality (as you also did, as far as I saw). But as I already mentioned, I'd rather implement this as a dedicated step, and not as part of the loading process. |
I agree, I would have it done the same way as the bounding box (in the way you wanted it) so basically something like |
Hey, I'm not really sure this belongs in this library but I don't have a much better way to communicate with you. I found a model https://poly.google.com/view/eydI4__jXpi that does not contain normal vectors for one of the material groups. This makes the model render all black when computing the diffuse color since it's multiplied by the dot product of the face normal and the light direction.
This can be computed by calculating the normal of every face that a vertex is a part of and taking the average of these as the vertex normal. I added code to
ObjUtils.convertToRenderable
that does this but it's slow (about 21.5 seconds on a Pixel phone), even then I clearly did something wrong because the color isn't quite right (I'm still getting some black spots). Here's the commit to my branch where I added the code to inject normals: GoMeta@aefde24Do you know if there's a better way to make sure that all the faces/vertices have the appropriate normals?
The text was updated successfully, but these errors were encountered: