Page 2 of 3
Posted: Mon Dec 13, 2004 7:45 am
theeth wrote:
ideasman wrote:There isnt any good way to get this data directly from blender right now. face.no will always give you a flat shaded face and the vertex no will always give you an interpolated vertex normal.
How are you calculating it?

Couldn't you just compute the smoothed edge normal from both smoothed vertice normals and then compare to the face normal and apply the angle threshold to check if it's smooth or not?

I don't see why that would be slow.

Martin
Its an extra step, comparing vert normals- generating normals for both etc
And when its all in python its not that fast either.
But your right- its not exactly slow, its just somthing that would be
1- Nicer if it was wysiwyg
2- Nicer if it was done in blender (not python per experter)

Posted: Mon Dec 13, 2004 11:52 am
But shouldn't you take the angle of the face normals that are on each side of the edge?

Posted: Tue Dec 14, 2004 12:01 am
joeri wrote:But shouldn't you take the angle of the face normals that are on each side of the edge?
Yes, thats what I do- 2 adjacent faces-
find the angle between there normals-
if its over the limit then dont smooth=
Else add them together and normalize.

The algo is simple, but its not as good as the autosmoothing code which takes face area into account.

IMHO a manual edge delimeter is better then Both since you can see whats going on and you export 'as is'
If you want to use some funky autosmoothing to set the edge hardness, you can do that that too- with the added aadvantage that you can manually edit it after,

Posted: Tue Dec 14, 2004 2:38 am
ideasman wrote:
joeri wrote:But shouldn't you take the angle of the face normals that are on each side of the edge?
Yes, thats what I do- 2 adjacent faces-
find the angle between there normals-
if its over the limit then dont smooth=
Else add them together and normalize.
Now, correct me if I'm wrong, but there's no way to get the faces adjacent to a given face in the API in a constant time, so you effectively have to loop over each face and compare vertices. Therefore, your autosmooth algorithm is O(n**2), one pass for each faces and an inner pass on all the faces to find the adjacent.

The one I just told you is in O(n), only the outer pass on each faces. While it's true that you'd have one additional vector addition, you don't event need the inner loop so you're winning in all cases.

Martin

Posted: Tue Dec 14, 2004 6:09 am
theeth wrote:
ideasman wrote:
joeri wrote:But shouldn't you take the angle of the face normals that are on each side of the edge?
Yes, thats what I do- 2 adjacent faces-
find the angle between there normals-
if its over the limit then dont smooth=
Else add them together and normalize.
Now, correct me if I'm wrong, but there's no way to get the faces adjacent to a given face in the API in a constant time, so you effectively have to loop over each face and compare vertices. Therefore, your autosmooth algorithm is O(n**2), one pass for each faces and an inner pass on all the faces to find the adjacent.
it sure seems easy enough to write one [I've done it twice]

the algorithm I like is to create a dictionary of 2-tuples for edges [put both combinations of verts in it], refrencing either some edge class or simply a list of faces...

I have two autosmoothing scripts [they attempt to apply an auto smooth based on the angle across edges] which do this.

but what my scripts do is generate the duplicate verticies necescary to look correct, it doesn't simply modify normals. This makes the mesh much more difficult to edit however.

which reminds me, I need to fix the newer one [make it run at equal or faster speed as my old one]

Posted: Tue Dec 14, 2004 9:10 am
That's all nice for autosmooth.

But it should be a tool. Press autosmooth button, get a number to type and that's the angle that used for smoothing/hardning. Then I "go in" and select the edges I want to be hard anyway and press the "hard" button. select the edges I want to be smooth and press the smooth button.
Or something like that

Posted: Tue Dec 14, 2004 12:02 pm
as you are talking about normals and edge harden, there is a tip/feature used by play-station/GameCube game creators :
The 3D engine automatically apply smoothing, and its speed depends on the number of vertices. Now imagine that you want to do a sharp corner : the only way is to use an edge harden on the corner's edge, but an edge harden duplicate the vertices. (A) So you get unused extra vertices. In cases like that, they uses thoses extra vertices to add faces so they have nices bevels. But the smoothing will change the vertices normals and your walls won't look flat anymore (B) The tip is to manually rotate the vertices normal to align them with the faces. the result is in (C) : flat walls, rounded bevel, with the same fps as in (A)

But now it is not possible to do such things in blender. It would be nice to add this with the edge-harden, or making an unique tool to adjust edges softness and vertices normals.

Posted: Tue Dec 14, 2004 4:24 pm
z3r0_d wrote:
theeth wrote:
ideasman wrote: Yes, thats what I do- 2 adjacent faces-
find the angle between there normals-
if its over the limit then dont smooth=
Else add them together and normalize.
Now, correct me if I'm wrong, but there's no way to get the faces adjacent to a given face in the API in a constant time, so you effectively have to loop over each face and compare vertices. Therefore, your autosmooth algorithm is O(n**2), one pass for each faces and an inner pass on all the faces to find the adjacent.
it sure seems easy enough to write one [I've done it twice]

the algorithm I like is to create a dictionary of 2-tuples for edges [put both combinations of verts in it], refrencing either some edge class or simply a list of faces...
Yes, this would work faster than an inner pass (didn't know that BPython impleted a constant __hash__ for vertice). You'd have two outer pass though, one to build the dictionary and one to apply autosmooth. This is O(n) too and the time difference would be between adding two vectors and addition/lookup in the dict. The difference should be minimal, but vect addition is probably faster.

Martin

Posted: Tue Dec 14, 2004 10:23 pm
Manual normal editing is the best option, I propesed 2k euro as a code bounty, but nobody is interested.

for the most controle mabe you could have these edge flags per face's vertex.

Its like a normal mode toggle per vertex, per face, rather then actually controlling the normal angle its self.

Each faces corner could have one of the following flags.
Flat: Use faces normal
Smoothed: Use vertex normal (a product of all the faces normals that use that vertex)
Rounded: Uses the normal of the adjacent face (a face that shares an edge), this means that the smoothing would actually meet the flat face rather then going half way and then clipping at the flat face.

One of these 3 options per faces.v would allow almost all conceivable options.
- Cam

Posted: Wed Dec 15, 2004 1:20 am
I like the concept as you have explained it ideasman. However, there are three problems I can forsee.

First, there is a data-size hit that some may not like as each face will have to have at least an extra char per vertex. I don't really think this is an issue, but Isee the whole "memory issue" crop up in conversation all the time, so I mention it for completeness.

The second & third issues, which I think are more crucial, deal with your "rounder" option.

A) Which face does the vertex normal map too? Two of them will share an edge with the face in most manifold cases - so does the normal map to both?

B) Performance hit. The current internal structure of the mesh objects/structs in Blender is not conducive to "quickly" finding adjacent faces that share a vertex. When rendering many of these faces - the performance hit will become noticeable without at least a decent restructure of some mesh internals.

Thgat being said - I have been looking into using the "crease" variable of the MEdge data structure for this purpose. As I assume that people would like the data to carry over from polygon to subsurf editing - a max value in this variable could indicate a "hard edge" in poly mode & I then only need to write some changes to the rendering code. What do you guys think?

Posted: Fri Dec 17, 2004 2:25 am
I just wanted to add my input here, being a game developer that writes the data export/import and model tools for our engine. (To be featured at the IGF, at the GDC 2004! Be there!)

I'd just like to note that auto smoothing by an angle factor is never good enough for all situations, as we discovered in our first art pass for our game. There are always edges that fall just inside the threshold that the artist wants 'hard', and adjusting the threshold would always cause stuff the artist wanted soft to harden too. Its imperative that manual control over edge hardness is provided.

Second, a note about the data:

From a game developer's standpoint, the only things that matter are the vertices, and the triangles. Hard edges and soft edges are mostly meaningless to a video card - the hardness and softness is represented by vertex normals. To a game dev the way the edge is defined as hard (be it smoothing groups or otherwise) is meaningless - all we want is the hardness to be reflected by the vertex normals.

Any internal storage of hardness and softness, whether it be by 'smoothing groups' or 'edge properties' is eventually translated to vertex normals for rendering.

In other words, if Blender were to be modified to allow the definition of an edge to be hard or soft, it would be useless to game developers unless it reflected directly on the normal of the vertex that the Blender interface gives to us when we ask it for the vertex normals.

Just a FYI - 3D Studio Max 6.0 makes this error with their vertices. You can define a face as being in a different group, and their renderer will render the hard ege, but if you write MaxScript to export the vertex, the 'vertex normal' exported will still be an average of the surrounding faces... you have to actually write your own "Smoothing-groups parser" to decide what normals to trust.

In summary,

* As a game programmer, I have first hand experience that our artists require the ability to set an edge as hard or soft manually, else it Just Doesn't Look Right to them, and that adjusting the auto-smoothing value never quite does it justice

* As a tools programmer for models importing into the game, I'd like for the 'final' vertex normals (which include the creases) to be available for python script export. IE, if Blender can render the creases, that same vertex normal data should be available for export. This sounds like an obvious request, but MAX got it wrong, and I'm hoping blender can do it better than that.

I hope this information is useful in some way. Now if only I could solve the Closed/Open curve issue...

Posted: Thu Dec 23, 2004 12:05 am
Right, that was my reasoning too when i wondered if it isn't a vertex property. For a real time engine there are only vertices with their data and connectivity. Besides, the 3d view also uses a hardware api, so there are already multiple vertices created if there are several properties (like uv coords or normals) or you wouldn't see anything. if those are stored in the mesh datablock or updated when a modification is made i don't now.

How you edit those trough the gui however is a different thing. Why limit the control, just create several, of which smooth edge may probably be the most handy indeed.

Vek, for 3d studio, have a look at the Edit Normals modifier...

Posted: Thu Dec 23, 2004 2:17 pm
I'll add that it'd be simply great if the OBJ importers imported the hard edges from OBJs(actually smooth groups) that comes from Wings or other softwares. Once there's already internal support for the feature.

Wings3d's OBJs save this info.

Posted: Thu Jan 27, 2005 11:10 pm
Just a bump now that development has started again, as the general feeling for this thread was that it would be a good idea, and not too much work.

Posted: Fri Jan 28, 2005 12:59 am
Rahu wrote:Just a bump now that development has started again, as the general feeling for this thread was that it would be a good idea, and not too much work.
You have started devlopment on this feature? Or have I misunderstood?