part 15926 (eye ball)
2014-07-07, 20:44 (This post was last modified: 2014-07-23, 6:32 by Philippe Hurbain.)
2014-07-07, 20:44 (This post was last modified: 2014-07-23, 6:32 by Philippe Hurbain.)
part 15926 (eye ball)
Alias now on Parts Tracker at http://www.ldraw.org/cgi-bin/ptdetail.cg.../15926.dat.
Chris (LDraw Parts Library Admin)
I'm guessing you're viewing it in LDView. The faceting is almost certainly due to a bug in LDView (for which I've not found a solution with acceptable performance). Simply put, LDView's smooth shading doesn't work right when there are two adjacent co-planar triangles, and those triangles lack a type 5 line between them. However, in my opinion, adding a type 5 line between them would be wrongheaded, because LDView's behavior is definitely a bug, and the extra type 5 line would serve no purpose other than to improve the visual quality in LDView, while slowing down rendering in all viewers (including LDView).
My shading algorithm uses the presence of type 5 lines to indicate edges that should be smooth-shaded. Two adjacent co-planar triangles (or quads, or combination of the two) share an edge, but should not have a type 5 line between them, because there is no situation in which that line would contribute to the shape's outline. However, if the other edges that share a vertex with the co-planar edge are supposed to be smooth shaded, then the co-planar edge between them needs to also be smooth shaded.
My only attempt to fix this so far simply inserted entries in my list of type 5 edges used for the smooth shading (but not for drawing). Unfortunately, it turned out to be prohibitively slow. One of the reasons it was so slow was that it was done after the part had been flattened. Moving the implemenation up the chain before that would make it much faster, since the O(n^2) nature of the algorithm would have much smaller values of n. However, doing that required a lot more effort, since I would need new data that I passed around the various segmented portions of LDView, and I just never got around to it. (Also, I don't know for a fact that it would perform acceptably.)
A better algorithm would use the presence of color 24 type 2 lines to indicate edges that should be creases, but that's not something I've gotten around to implementing in LDView for its 3D rendering. Also, the current algorithm can be useful to parts authors, because it can alert them to missing type 5 lines.
My only attempt to fix this so far simply inserted entries in my list of type 5 edges used for the smooth shading (but not for drawing). Unfortunately, it turned out to be prohibitively slow. One of the reasons it was so slow was that it was done after the part had been flattened. Moving the implemenation up the chain before that would make it much faster, since the O(n^2) nature of the algorithm would have much smaller values of n. However, doing that required a lot more effort, since I would need new data that I passed around the various segmented portions of LDView, and I just never got around to it. (Also, I don't know for a fact that it would perform acceptably.)
A better algorithm would use the presence of color 24 type 2 lines to indicate edges that should be creases, but that's not something I've gotten around to implementing in LDView for its 3D rendering. Also, the current algorithm can be useful to parts authors, because it can alert them to missing type 5 lines.
I use the type 2 approach in LDCad, but it will still cause a 'crumbled paper' look due to the fact the pattern breaks the curve of the sphere.
This because all polygons are flattened to the n facets resolution of the sphere and thus causing slightly different normals for their vertices.
You could prevent this (i think) by using a facet resolution for the whole sphere that matches the smallest detail of the pattern. But it would inflate the part size (primitive count) considerably.
Alternative is off course using a texture.
This because all polygons are flattened to the n facets resolution of the sphere and thus causing slightly different normals for their vertices.
You could prevent this (i think) by using a facet resolution for the whole sphere that matches the smallest detail of the pattern. But it would inflate the part size (primitive count) considerably.
Alternative is off course using a texture.
I have used another method to create patterns that avoid this issue, using careful placement of triangle vertices following the pattern (mesh must indeed be fine enough locally). Meshmixer has tools to do this rather ealily, but it remains a nightmare and can be used only for simplest patterns (that's the method I used to separate the sections of Friends arms). I intend to use the same method also for Friends sandals, as the pattern extend in 3D, making usage of LPC a nightmare too...
Edit: For this kind of pattern, it turned out not so hard (the pattern needs nonetheless to be done by hand, eyeballing the pattern... See the result here.
Edit: For this kind of pattern, it turned out not so hard (the pattern needs nonetheless to be done by hand, eyeballing the pattern... See the result here.
Quote:Adding normals to loose triangles/quads isn't going to help, besides those are extremely easy to calculate on demand.Are they? I think that part of the problem comes from surfaces in pattern laying on flat surfaces (triangles of the relatively low resolution 4-8sphe). If each of those tiny surfaces got normals on each vertex from mathematical sphere and shading derived from that, overal result would be smoother?
The problem with patterned parts isn't actually (imho) the lack of normals but the uneven distribution of triangles and the semi flat surfaces you mentioned.
I don't know for sure but I think even if you modeled a similar part using e.g. blender it would still not look smooth purely as the result of the 'weird' (pattern) triangle placement.
Personally I think these kinds of parts are best off using textures. Maybe even move the vector based pattern to the texture (from an all y=0 .dat source), so software can generate a texture of any quality merging the best of two worlds.
I don't know for sure but I think even if you modeled a similar part using e.g. blender it would still not look smooth purely as the result of the 'weird' (pattern) triangle placement.
Personally I think these kinds of parts are best off using textures. Maybe even move the vector based pattern to the texture (from an all y=0 .dat source), so software can generate a texture of any quality merging the best of two worlds.
Philippe Hurbain Wrote:Yep... and what about viewers/editors/tools to generate normals?
In the case of the parts that need it most, it would actually be quite easy to add normals since they're usually based on spheres which have a very well defined center. Indeed there is some French guy who seems to be able to write the sort of code that would be required to project a pattern onto a normaled sphere in his sleep
I'm not promising a full solution, simply arguing that it would be nice to have a downgradable triangle with normal building block to use when appropriate, and that the way to do it would be to extend the LDraw format.
Tim
Philippe Hurbain Wrote:No taboo, but compatibility must be kept with existing parts and tools! And some new tools/viewers able to use these new possibilities must be available. If you have suggestions...
Yes i think it's not hard at all: you define a new comment extension, that define the (per vertex) normal of the following tri/quad:
0 NORMALS v1x v1y v1z v2x v2y v2z v3x v3y v3z [v4x v4y v4z]
It should always come right before each triangle or quad line.
That's it. Old tools will ignore it and keep calculating their normals, new tools can take advantage and avoid reimplementing complex and buggy smoothing algorithms for the thousandth time.
To sanitize the library i suggest the following:
- Take the best looking smoothing algorithm available today (LDView, i guess)
- extract and refactor the smoothing algorithm code to a tool that spit out normals
- feed the library to the tool to automatically add NORMALS to all tri and quad
Maybe it's a little more complex to take into account subparts etc, but it's still a very easy program.
Some new experiments... I regenerated the eye using the following process:
- Recreate a regular flat pattern using LPC (file eye1.dat)
- Retriangulate it (I used Meshmixer for that) to get a more regular triangulation (file eye2flat.dat)
- project it without slicing (using Projector) on a hires 48-sphe (file eye-form-hr.dat)
- Regenerate the condlines with Edger2
- Improved the result, by flipping local concave areas using Flipper
Here is the result for comparison...
Drawbacks: file is larger, though the number of triangles not much larger, there are more conditional lines since there is little or no coplanar areas. And the eye is slightly bulging (average diameter of a hires spere is larger than the one of a lores sphere!).
Now I doubt that this process could be easily adapted to other shapes...
I have not yet tried to create a texmap version.
- Current eye design, completely done by projection with LPC , condlines derived from lores sphe primitives (file eye-original.dat)
- Same file, condlines regenerated with Edger2 (file eye-original-newcl.dat)
- New projection method, before concave area tweaking (file eye2projcl.dat)
- Same, after tweaking (eye2projtweaked.dat)
Drawbacks: file is larger, though the number of triangles not much larger, there are more conditional lines since there is little or no coplanar areas. And the eye is slightly bulging (average diameter of a hires spere is larger than the one of a lores sphere!).
Now I doubt that this process could be easily adapted to other shapes...
I have not yet tried to create a texmap version.
Philippe Hurbain Wrote:And the eye is slightly bulging (average diameter of a hires spere is larger than the one of a lores sphere!).
It doesn't look to be bulging to me, but since eye2projtweaked.dat doesn't contain the rest of the sphere, that could be why.
The "average" diameter of the low-res sphere primitive might be smaller, but this is purely an artifact of the faceting. As far as I can tell, the shared points are exactly the same in the high-res sphere and the low-res sphere. The low-res sphere may appear smaller due to the fact that it has less facets, but every point in it is the right distance from the center (1.0 LDU, accounting for rounding).
The pathological progression of an LDraw sphere simplification would probably be an octohedron (one step down from LDView's lowest-quality curve quality setting), and that would indeed appear significatnly smaller than a perfect sphere incscribed on its vertices, but trying to substitute in a bigger one would lead to significant problems.
Yes, faceting problem is what I meant, and indeed the vertices of lores sphere are located exactly on hires vertices, or the projection would have given bad results. As for the bulging effect, you can see it on eye2projcl.dat where the pattern central area meet the 4 lores triangles on each end of the 2-8sphe shape.
I'll update the part (full sphere) when time permits.
I'll update the part (full sphere) when time permits.
« Next Oldest | Next Newest »
Users browsing this thread: 8 Guest(s)