LDraw.org Discussion Forums

Full Version: Question about edges
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Question to the part experts:

Do the edge line main points (nearly) always share a point with normal triangle and quad points. Or do they often ''float' between normal geometry points?

I would like to know this in relation to the current library, not the latest authoring specs.
Generally they are placed on surface edges. Possible exception is when they are used as decoration. Though this is not a very good practice, I have commited this a few times, such as the grip on the latch of NXT cover, or to simulate the complex surface on back of Power Functions XL motor. It has been used also to mark the separation between parts on assembly, where separated parts should have been used.
Thanks, so aside from the decorative ones do normal edges always follow triangle and quad sides.

For example could something like this happen in the current library

Code:
x~~~~0~~~~~~~~~0~~~~~x
      \       /
       \     /
        \   /
         \ /
          0
This being a single type 2 line and a single type 3 line (there will be more triangles in real parts off course this is an 'zoom' if you like)

Or will it allay be guaranteed to be like:

Code:
x~~~~X~~~~~~~~~X~~~~~x
      \       /
       \     /
        \   /
         \ /
          0
Being 3 type 2 lines and a single triangle.

The reason I would like to know this is for the smoothing function I'm working on. It would be very helpful to assume any two triangles can be split by a edge line using the same shared points of the triangle.

I need this information to calculate normals for the triangle vertices. If I can not assume this the alternative would be to do line point intersection tests for all triangle and line data. Which will be much much much slower, and as a result I need to seek an alternative approach.

ps: I'm looking into this at the moment completely unhindered by knowledge of how apps like LDView handle this, just to see if I can come up with something on my own. Smile
Code:
x~~~~0~~~~~~~~~0~~~~~x
      \       /
       \     /
        \   /
         \ /
          0
Sorry, I forgot this case. Yes, that probably happens a lot. Actually my own Isecalc does create this quite frequently.
Speaking of Isecalc, it is also used to create the edge line that marks the intersection between two interpenetrating surfaces. In that case, edge lines are indeed "floating" in the middle of surfaces (but there is no need for smoothing anyway!)
Bit disappointing this means my current approach isn't usable unless you go use OpenCL or something.

Quote:(but there is no need for smoothing anyway!)

My plan was to take the indexed triangle soup data to average the normals of triangles sharing a point unless one or more of them are separated by an edge line, in which case a second vertex using a different normal would be added.

So if a certain point is used by 3 triangles the normal for the resulting vertex would be the average of those three triangle (flat shading) normals. But if one of those triangles is separated from the other ones by an edge only the other two will be used to average a normal, using the 3rd one by itself (also correcting the indices etc off course).

But I have to look at it in a different way now Sad
Hi Roland,

I peaked at the LDView code (and Travis gave me some hints) but I won't spoil the mystery for you. :-)

I will add that it would be nice to have a semi-official smoothing algorithm; the flip side of smoothing is that if several programs implement smoothing, an author might want to modify a part to get high quality visual output; if we all pick different smoothing heuristics, it won't be possible to make the library look good everywhere.

To that end, I think it wouldn't be crazy to declare that smoothing _requires_ that lines and triangles share vertices in order for the line to create a 'crease' - it would seriously lower the computational work required to calculate the smoothed normals because you could rely on a bitwise index of vertex coordinates; without that you have to do a geometry test and at best use a spatial index - a lot more work for the CPU and developer.

If there were some official-ish policy on smoothing, we could code something manageable and authors could make parts work if desired.

Cheers
Ben
Totally agree with you!
My only reference now is LDView, and I try to get things nice looking with it. It would be great if all viewers behaved coherently.
When implementing this for my POV export in LDView, I went with infinitely long representations of all edge lines, and checked if triangle edges lined up with those. Assuming a match is found, you can then see if the triangle edge is within any of the segments that correspond to the infinitely long line. (I think I actually skipped this second step, but doing so is probably bad.)

Note: LDView's realtime 3D view uses conditional lines to indicate "smooth", and does its smoothing based on that. LDView's POV export does what you propose (which is probably better).
It would be nice to have an universal guide line.

As a result to Philippe's answer above I decided to try my original approach but without using any edge information at all. So by just looking at angles (acos'ed dot products actually) to decide to group stuff or not.

It works remarkably well, so well in fact I'm kinda glad I dropped the edges approach Smile

[Image: smoothTest1a.png]

This is using the (ludicrously wide) angle threshold of 60 degrees, could probably lower that to 30 or so, haven't decided on that.

Downfall is things go 'weird' with high details on a curved surface, like minfig heads which seem to have a crumbled paper thing going on. I'm not complety sure this is the result of the general algorithm or a minor bug on my side.

[Image: smoothTest1b.png]

But in general this approach's results ares very acceptable given the cost. Could probably optimize things to bring it at a loading level only slightly slower then the current LDCad loading times.

If we are serious about helping smoothing by introducing rules on the library, some kind of hint system would be most useful. Like: these following triangles all lay on a curved quad. A bit like the texture projection hints. This would make it possible to generate normals based on a common (cylinder) center instead of the surrounding triangle normals.
Looks very good indeed!
Quote:If we are serious about helping smoothing by introducing rules on the library, some kind of hint system would be most useful. Like: these following triangles all lay on a curved quad. A bit like the texture projection hints. This would make it possible to generate normals based on a common (cylinder) center instead of the surrounding triangle normals.
Very interesting idea! If it could be retrofitted easily - at least on minifig heads - it would be a great improvement.
Pages: 1 2 3 4