From: Ari H. <ahe...@an...> - 2001-07-25 21:13:36
|
Playing with Scherer's Mesh class based on the faces object, I realized that drawing heightfield meshes might be a pretty common application. Right now faces is extremely poorly optimized for this (using the Mesh class anyhow): vertices are not correctly shared between polygons, and setting up the mesh from the data is extremely slow (since it turns the Mesh into polygons one vertex at a time in Python, for a 30x30 Mesh that's 900 polys and 3600 vertices in the inner loop. This was by far the most expensive part of a heightfield demo I wrote; by comparison calculating fractals heightfield data is very cheap. A mesh object would be pretty easy to write that took a rectangular x 3 matrix (i.e. a rectangular matrix of vectors). This would be faster to render as well as faster to construct. Any thoughts/requests? Ari |
From: Matthew K. <koh...@an...> - 2001-07-30 20:58:35
Attachments:
wireframe_heightfield.py
wireframe_parametric.py
|
On Wednesday, July 25, 2001 17:13 -0400, Ari Heitner wrote: > Playing with Scherer's Mesh class based on the faces object, I realized > that drawing heightfield meshes might be a pretty common application. I agree, and I've actually been playing around with this for a few weeks. Attached are two programs that plot wireframe surfaces constructed out of curve objects. The first, wireframe_heightfield.py, allows the user to input a function of x and y which is plotted as a heightfield. The second, wireframe_parametric.py, plots a series of parametric curves based on a vector function. It can produce closed surfaces like spheres, ellipsoids, cones, etc., depending on the vector function. Of course, these programs suffer from the fact that they produce wireframe outputs, which do not provide the 3D visual cues that smooth surfaces do. But it may be useful to Ari, David, and others working on this problem to take a look at the way these programs do the math to plot surfaces. In any case, anyone is free to use them in any way they wish. -Matt |
From: David S. <dsc...@vy...> - 2001-07-25 21:20:44
|
I thought about this (in fact, I did it once). It might not be a bad idea. However, note that my faces.index proposal would take care of the inefficiency and perhaps some of the difficulty of use (a wrapper could set up the index array for a mesh, and then you would just use the same [x,y,0:3] position array. The sample code I wrote for constructing triangles is absurdly slow; I didn't intend anyone to do anything useful with it. It's basically intended as a tutorial on how triangle rendering and shading work. Realistic applications can probably do the same things in parallel with Numeric. Dave > -----Original Message----- > From: vis...@li... > [mailto:vis...@li...] On > Behalf Of Ari Heitner > Sent: Wednesday, July 25, 2001 5:14 PM > To: vis...@li... > Subject: [Visualpython-users] proposed mesh object > > > > Playing with Scherer's Mesh class based on the faces object, > I realized that drawing heightfield meshes might be a pretty > common application. Right now faces is extremely poorly > optimized for this (using the Mesh class anyhow): vertices > are not correctly shared between polygons, and setting up the > mesh from the data is extremely slow (since it turns the Mesh > into polygons one vertex at a time in Python, for a 30x30 > Mesh that's 900 polys and 3600 vertices in the inner loop. > > This was by far the most expensive part of a heightfield demo > I wrote; by comparison calculating fractals heightfield data > is very cheap. > > A mesh object would be pretty easy to write that took a > rectangular x 3 matrix (i.e. a rectangular matrix of > vectors). This would be faster to render as well as faster to > construct. > > Any thoughts/requests? > > > Ari > > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > http://lists.sourceforge.net/lists/listinfo/visualpython-users > |
From: David S. <dsc...@vy...> - 2001-07-25 22:39:16
|
I wrote: > I thought about this (in fact, I did it once). It might not > be a bad idea. I should add this: a "mesh" object like Ari described would be useful for much more than height fields. For example, a surface of revolution or extrusion is also a mesh: ################## from visual import * def mesh(pos): "Stand-in for mesh object (wireframe rendering)" pos = array(pos) for i in range(pos.shape[0]): curve(pos=pos[i]) for j in range(pos.shape[1]): curve(pos=pos[:,j]) def surface_of_revolution(length, radius): circle = arange(0, 2*pi+0.2, 0.2) count = len(radius) pos = [ [ vector(i*length/count, radius[i]*cos(theta), radius[i]*sin(theta)) for theta in circle ] for i in range(count) ] return mesh(pos) def extrusion( points, displacement ): pos = [ (point, point+displacement) for point in points ] return mesh(pos) surface_of_revolution( 10, [5,1,1,1,1,2,3,4,5] ) extrusion( [ vector(0,0,0), vector(1,0,0), vector(0,1,0), vector(0,0,0) ], vector(0,0,1) ) ################### mesh would be accessible to more people than faces. It wouldn't, however, be as general for people who want to play with new primitives or *especially* model import. Dave |
From: David S. <dsc...@vy...> - 2001-07-25 21:22:21
|
> for a 30x30 > Mesh that's 900 polys and 3600 vertices in the inner loop. For a 30x30 2-sided mesh it's 29x29x2 = 1682 quads, 1682x2 = 3364 triangles, 3364x3 = 10092 vertices. Dave |