Ben Supnik Wrote:Yep - exactly what I expected with 6085: - a rounder-than-real life shading. :-)
Yes but I kinda expected that using a 60 degree threshold. Although this part seems to be very round indeed, I didn't realize it because I never seen this part in real life or use it in modelling etc
When I lower the threshold to 30 degree (6085 becomes square then) it messes up (much more often used) parts like the antenna or loudspeaker. So in the end I rather have these 'rare' parts rendering wrong.
Ben Supnik Wrote:I think you may find per pixel lighting makes the lighting effect _worse_...particularly if you use per pixel lighting for what it's really good for: shininess. (The problem with per-vertex lighting is that the fall-off from specular hilights is very steep, so the hilight tends to be contained entirely within one triangle. Once you have that 'sharp' hilight, the induced roundness will make lighting that really looks...well...round.) I hadn't noticed the error on the slope bricks because they look nice for the roundness of the lighting.
It's probably better to first get the smoothing thing to work at an acceptable level before I start playing with my own lighting model then.
Ben Supnik Wrote:Having gone through the coding exercise, I think I can state a 'wish list' of assumptions about the library for a smoothing algorithm:
1. The bit-wise locations of all colocated vertices match exactly - that is, no floating point jitters between vertices that should touch.
2. All faces that form a smooth edge share the (bitwise) same coordinate values and the (bitwise) same transform stack. (In other words, if you want two sub-parts to mesh smoothly, they must be transformed in the same way.)
3. All parts are BFC valid. (Because of this, two adjacent faces will have edges going in opposite directions along the triangle.)
4. Any lines used to indicate a crease have a start and end point that (bitwise) matches the location of the corners of the triangle edge that they crease. (The line does not have to go in any particular direction, as it will always match one of the two triangle faces.)
Like Travis wrote I don't think 1 and 4 are realistic demands, not only from a technical point but it won't be fair to the part authors/reviewers they already have enough to nit pick over I think
3 Is a very realistic demand, and the current library is well on it's way on this. So maybe if some parts smooth weirdly the first helping hand thing part authors can do would be to make the part in question bfc.
4 Is pretty much the point I start the thread for (excluding the bitwise part), I'm not sure how many part will smooth weird when assuming this while it isn't the case. Depending on the amount of parts I might be fixable quite easily for some of the advanced part authors.
I'm going to implement a very rough version of the number 4 base edge handling in my code next weekend or so, maybe this in combination whit 60 degree approach will result in e.g 99% correct smoothing. I could then compile a list of 'problem' parts, that would benefit the most from bfc/nr 4 corrections.
Or maybe someone else has ideas for a completely different approach?