bugpyFormex - Bugs: bug #42330, Extension of Mesh.normals to...

 
 

bug #42330: Extension of Mesh.normals to return normals at elements?

Submitter:  francesco <francio>
Submitted:  Sun 11 May 2014 12:23:02 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Sep 2014 02:53:22 PM UTC, comment #10: 

You are correct.

So I suggest to compute normals ('exact') and store as Field of type 'elemn'. Then smooth normals is just convert Field to
type 'node', and facet normals is convert to type 'elemc'.
In all cases normalize.

Note that convert back to type 'elemn' will not recover the originals, so it makes sense to keep them stored as elemn,
and return the converted field when needed.

Benedict Verhegghe <bverheg>
Group administrator
Thu 11 Sep 2014 02:32:39 PM UTC, comment #9: 

Fine for me to use only ndim==2, but I am not sure if maybe it is also good to set them for ndim==3 on all the facets of all elements, not only on the border, but it could be more tedious to implement.

with 'averaged nodal element normals' i mean the results of


gt.averageNormals(self.coords, self.elems)


for facet then it is correct as I did?


normals = gt.polygonNormals(self.coords[self.elems])
normals = normalize(normals.mean(axis=1))


 francesco <francio>
Group Member
Thu 11 Sep 2014 02:15:30 PM UTC, comment #8: 

For ndim==3, it would indeed set the normals on the element facets. But it might be better to leave that to the BorderMesh.
I suggest therefore to only set normals for ndim==2.

I think the normals should always be normalized.

'facet' mode is: every face with n nodes has n normals at the nodes. Take the average of these n normals. I do not understand what your 'averaged nodal element normals' is. I guess it is just another representation of the 'smooth' normals? Which would then be the smooth normals (at the nodes) Fieldconverted to the element nodes.
No matter where we store the normals in the Mesh, it would certainly be an object of type 'Field', so that it can easily be converted.

Benedict Verhegghe <bverheg>
Group administrator
Thu 11 Sep 2014 01:44:00 PM UTC, comment #7: 

Hi benedict
in the exampLe you can see how it work with all the changes you want, and the different dimensionalities

ndim<2 normals all aligned to z dir
ndim==2 ok
ndim>2 what we should do here, get the faces? only the border?
the normal for a solid element does not make any sense

A NORMALIZE parameter is needed to convert the fields, i did not use the convertField in setFieldNormals for this reason, otherwise it can be used,

the facet is ambiguous. averaged on the single element normals
or averaged on the averaged nodal element normals?
in the example I decided to use the exact element normals (not averaged). if the user wants the smooth face can convert from 'smooth'.

the only option left out from the previous code is
the AVERAGED normals at each node for each element, (knd of a 'smooth exact') which cannot be retieved in other ways I think if we dont set it explicitly. it can also be useful in some cases

For the storage, i dont know, though if we want to use the convert for the non listed cases i am not sure which way is more convenient


(file #32062)

 francesco <francio>
Group Member
Wed 10 Sep 2014 08:02:45 PM UTC, comment #6: 

It had another look at this code. It would be interesting to implement some of this at the Mesh level, probably as a predefined attribute 'normals', which can then also be used for the rendering. There are some questions to be answered first though:

  • Works for all elements with ndim >= 2 ?
  • What to do for ndim < 2?
  • Too many options: I think three would suffice, stored as a

  Field so they can be converted to other entities.
** 'exact': normals at each node for each element, defined
   by product of two edges of the element ending at that node.
   These are the exact normals for the rendered geometry.
** 'smooth': averaged at the nodes, giving the rendered surface
   a smooth look.
** 'facet': averaged over each element, giving the surface a
   faceted look.

  • The first two do exist now for rendering purposes. Now we would add a third and the normals button could then cycle through the three. 


  • Do we store all three, and select a current, or do we recompute them everytime the selction changes (as is done now).


  • Do we store them in specialized attributes (of type Field),

  or in the Mesh Fields with specialized keys e.g. '_normals_e'
  '_normals_s' and '_normals_f'?

  with a speci

Benedict Verhegghe <bverheg>
Group administrator
Wed 21 May 2014 05:04:19 PM UTC, comment #5: 

Any update on the suggested functions. Where can be included?  somewhere in mesh_ext or in a field to predefine some fields?

 francesco <francio>
Group Member
Tue 13 May 2014 04:00:28 AM UTC, comment #4: 

Hi
In the example in attachment there are 2 functions to set the normals

1 setting the normals directly in the field
2 converts to using convertField.ยต

The latter does not have normalized normals. Maybe we can include a normalization parameter in field.
I am not sure where this should go and if you like the implementation.

(file #31365)

 francesco <francio>
Group Member
Mon 12 May 2014 10:12:56 AM UTC, comment #3: 

Do not add it to the Mesh class: it will only increase the confusion.

If you are working with triangles only: TriSurface has
avgVertexNormals(), and areaNormals()[1] provides the facet normals.

For the Mesh class, you can use a Field instance, which can
then easily be converted. But for plexitudes > 3, how do you define element normals?

The Mesh class should probably get a normals setter, which allows setting by an array/Field or automatically according to a value
- 'smooth': averaged normals at the nodes
- 'faceted': averaged normals at the elements
- default: individual values at the element vertices

Benedict Verhegghe <bverheg>
Group administrator
Mon 12 May 2014 09:53:28 AM UTC, comment #2: 

Hi benedict
sorry I was referring to setNormals.I imagined it was for the GUI.

Though I need element normals/ merged nodal coords in many applications and with the vtk interface so every time I have to mean over the axes. Can I put then a property getNormals which does not store the normals?

 francesco <francio>
Group Member
Mon 12 May 2014 08:05:29 AM UTC, comment #1: 

Is this about the Mesh.normals attribute? It is not clear to me how you can put options there.

The Mesh.normals attribute should always be (nelems,nplex,3), because that is required by the shader programs.

The attribute is set by Mesh.setNormals, which is AFAIK only used in webgl.py. This method is not well documented, becuase the setting of the normals attribute is a quick hack to get some GUI feature working.

Direct setting of the attribute should be discouraged, and we should use the Field class to automatically multiplex the data to the required shape for use in the renderer.


Note that a single normal per element is not very useful, unless the elements are triangles.


Benedict Verhegghe <bverheg>
Group administrator
Sun 11 May 2014 12:23:02 PM UTC, original submission:  


now the normals are returned only at the nodes elements with shape nelems,nplex,3 with options 'auto','avg'. can I put options
'autoAtElems', 'avgAtElems' for normals of shape elems,3
and 'autoAtnodes', 'avgAtnodq' for normals of shape ncoords,3?

francesco <francio>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #32062:  FieldNormals.py added by francio (6KiB - text/x-python)
file #31365:  FieldNormals.py added by francio (7KiB - text/x-python)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bverheg (Posted a comment)
  • -email is unavailable- added by francio (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-11 francio Attached File- Added FieldNormals.py, #32062
    2014-05-13 francio Attached File- Added FieldNormals.py, #31365

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-4333.
    Corresponding source code