bugpyFormex - Bugs: bug #42327, pgf.gz in webGL scene have too...

 
 

bug #42327: pgf.gz in webGL scene have too many nodes

Submitted by:  gianluca de santis <gianlucadesi>
Submitted on:  Fri 09 May 2014 02:03:10 PM UTC  
 
Category:  None Severity:  1 - Wish
Item Group:  Feature request Status:  Postponed
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 12 May 2014 01:05:50 PM UTC, comment #4:

What I wrote in part 1) of https://savannah.nongnu.org/bugs/?42327#comment1 was not entirely correct: the OpenGL shader language supports indexed buffers, and our new rendering engine can make use of it. However, there can only be one index for both vertex coordinates and colors (and for texture coordinates as well). Thus, when using 'vertex' color, all vertices have to be specified for all elements (coords as well as colors). This also applies to 'element' color, which is a pyFormex color mode not supported by GLSL, and therefore expanded to 'vertex' color.

However, in 'single' or 'no' color mode, the index can be used, and it would be sufficient to store the common vertices of the elements only once, and use a proper index. This would also work for a 'node' color mode, which we currently do not have in pyFormex, but which might be a useful addition (now that we have the Field class) for rendering field data (e.g. during post-processing).

The WebGL exporter actually exports the actors from the rendered scene, not the Geometry you created. For the reasons explained above, these actors may contain more vertices than the original Geometry that was rendered, and colors will have been multiplexed likewise. Because of this, the created .pgf files for WebGL rendering may have quite different contents than when you save the Geometry in PGF format yourself.

Benedict Verhegghe <bverheg>
Project Administrator
Fri 09 May 2014 04:57:23 PM UTC, comment #3:

Here is an example of how to change your example code to using the Field class:

Benedict Verhegghe <bverheg>
Project Administrator
Fri 09 May 2014 04:51:32 PM UTC, comment #2:

An extra note to my previous comment, part 1) :
The WebGL application (like the OpenGL shaders) only draws triangles. Thus each quad is split into two triangles for rendering purposes.

Benedict Verhegghe <bverheg>
Project Administrator
Fri 09 May 2014 04:02:00 PM UTC, comment #1:

1) OpenGL shaders executed on the GPU require that the coordinates of all vertices for all elements be specified in order. Therefore, the coords of a Mesh are expanded in pyFormex for rendering purposes. It is the expanded set that is saved to the PGF file for the WebGL rendering, because the (default) WebGL application (http://feops.ugent.be/pub/webgl/fewgl.js) does not do the expansion (yet). We can only change this when/if FEops would change their webgl application.

2) The color specification in pyFormex can be one of:
- a single color for the Geometry: 1 color,
- one color per element: nelems colors,
- one color per vertex for each element: nelems * nplex colors.
But not 1 color per node in a Mesh.

To overcome this restriction, Fields were added. Fields can be specified per node, per element or for all element vertices, and conversion between these formats is available. In future, we might use Fields to specify color (and for normals as well).

For now, you will have to do some things yourself.
- either low level, as you have done,
- or using Fields: define a field 'val' on the nodes, convert it to element vertices, and use that as color. The conversion step could then be left out in future, when it is automatically performed by the pyFormex renderer.

Benedict Verhegghe <bverheg>
Project Administrator
Fri 09 May 2014 02:03:10 PM UTC, original submission:

1) when exporting the scene the mesh in the pgf.gz includes ALL ELEM NODES, like a Formex (see attached example)
2) in order to draw a nodal field (with a single value at every node) you could just give mesh.ncoords() values.
Why should you give val[obj.nelems] ? This last case is the most
general and it would only be needed if a mesh would be
made of 'unconnected' faces colors, with
sharp color changes of adjacent edges.

Or maybe there is a reason for this.

gianluca de santis <gianlucadesi>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #31344:  geomFile_colors.py added by gianlucadesi (2KiB - 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 gianlucadesi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-09 bverheg Severity2 - Minor => 1 - Wish
        StatusNone => Postponed
    2014-05-09 gianlucadesi Attached File- => Added geomFile_colors.py, #31344

    Back to the top


    Powered by Savane 3.4