yang686526

meshproc and shellproc data?
meshproc and shellproc data?
hello
i am a newbie to 3d data, could someone please explain (or direct to me a source that explains) the format of the data returned in the meshproc and shellproc functions of odgigeometrysimplifier.
i have to feed the data to our viewer application which takes in only polylines and triangles, so i might need to convert the data into that format.
please also advice if i am looking in the wrong place to start with.
thank you
krishna

format of parameters of odgigeometrysimplifier::shellproc() and meshproc() is same with acgigeometry::shell() and acgigeometry::mesh(). it is thorough documented in objectarx reference, which you can download for free from autodesk website.
odgigeometrysimplifier lets simplify shells and meshes to triangles and polylines. if you want to have them simplified, you shouldn't override these functions. odvectorizeex sample (when m_dumplevel == maximal_simplification) contains example of getting simplified data.
sincerely yours,
george udov
documentation of arx for the shell function
virtual adesk::boolean
shell(
const adesk::uint32 nbvertex,
const acgepoint3d* pvertexlist,
const adesk::uint32 facelistsize,
const adesk::int32* pfacelist,
const acgiedgedata* pedgedata = null,
const acgifacedata* pfacedata = null,
const acgivertexdata* pvertexdata = null,
const struct resbuf* presbuf = null) const = 0;
nbvertex input the number of vertices in pvertexlist
pvertexlist input an array of vertex points
facelistsize input the number of entries in pfacelist
pfacelist input an array of 32-bit integers
pedgedata input pointer to an existing acgiedgedata object
pfacedata input pointer to an existing acgifacedata object
pvertexdata input pointer to an existing acgivertexdata object
presbuf input pointer to a resbuf used to attach extended entity data to an acdbsolid entity when converting between old and new hatches; for normal usage, this parameter should be set to null
pedgedata points to an acgiedgedata object that contains arrays of color, layer, visibility, line type, and selection marker settings for the edges. each of the arrays in the acgiedgedata object pointed to must either be null or must have the same number of elements as the number of edges.
pfacedata points to an acgifacedata object that contains arrays of color, layer, visibility, line type, and selection marker settings for the faces. each of the arrays in the acgifacedata object pointed to must either be null or must have the same number of elements as the number of faces.
pvertexdata points to an acgivertexdata object that contains a flag indicating vertex orientation on faces and a pointer to an array of vertex normals. the array of vertex normals must either be null or must have nbvertex elements.
the hatch solid (and regular hatch pattern) use the shell primitive during worlddraw. when a saveasr12 operation is in progress, the worlddraw routine uses the presbuf parameter to attach extended entity data onto the acdbsolid entity so that the original solid hatch can be reconstructed during a conversion from old to new hatches. for normal usage, this parameter should be set to null.
note as the const qualifiers indicate, acgi does not change or delete the parameter array or objects. the caller is responsible for the memory they use.
this function uses the various objects passed in as parameters to generate and display a shell primitive.
a shell's geometry is based on a set of vertices that are used to make faces (and holes in faces). minimally, a list of vertices must be specified and a list of how the faces are made using the vertices. faces may share vertices with other faces (however, the example given below does not show this).
the advantage in using a shell instead of a mesh is that a mesh cannot have holes, cannot have disjoint regions, and cannot have faces that are n-sided. the shell can have all of these.
the edge, face, and vertex data are optional parameters, but if you have face data, you must specify edge data. if you have vertex data, you must specify edge and face data. use null for unused parameters if they are required.
the face list pfacelist defines the faces and any holes that might be in them. in a face list, a face is defined by a set of numbers. the first number must be the number of vertices in the face, the following numbers must be the indices of the vertices making up the face; if the face is a hole, then its number of vertices must be entered as negative. any holes in a face must immediately follow the definition of the containing face. a hole must be coplanar and completely inside a face (not touching an edge), otherwise, the results are unpredictable.
an edge is determined by walking around the face in the order listed in the face list. for example, if the face list contained 3, 0, 1, 2, this would define a face having 3 vertices: vertex 0, vertex 1, and vertex 2., and which has edges from vertex 0 to 1, vertex 1 to 2, and vertex 2 to 0.
in an edge data list for a shell, the edges are listed sequentially from face (or hole) to face (or hole) as they are ordered in the face list.
the ordering of shell face data is the same order as in the face list but omitting any holes.
warning you will lose any edge, face, or vertex data that you may have applied to the shell if a shell face has 5 or more edges or if it has any holes. as the shell is being sent out for display, it will be divided into triangles, which is slow.
a return value of adesk::kfalse (that is, 0) indicates that the primitive has been successfully stored in the graphics database. a return value of adesk::ktrue indicates that the operation has been terminated and the application wants to get control back as soon as possible.
example:
here are three sketches of the same shell that has two faces and one hole (a hole is a kind of face):
vertex indices edge indices face indices
here is an example of producing such a shell in a worlddraw() method:
adesk::boolean someentity(acgiworlddraw* pwd)
{
// set up the vertices.
const adesk::uint32 numverts = 9;
acgepoint3d *verts = new acgepoint3d[numverts];
// ....set the vertices to values that will make such a picture above....
// set up the face list -- a set of 'count and vertex indices' per
// face. note that holes have a negative count and they must
// immediately follow the face that contains them.
//
static adesk::int32 facelist[] = {3, 0, 1, 2, -3, 3, 4, 5,
3, 6, 7, 8};
const adesk::uint32 facelistlength = 12;
// set up the edge data.
//
acgiedgedata edgedata;
static short colors[] = {1, 1, 5, 2, 2, 2, 3, 4, 5};
edgedata.setcolors(colors);
// set up the face data. note that a hole is not
// considered in face data.
//
acgifacedata facedata;
static short colors[] = {1, 3};
facedata.setcolors(colors);
pwd->geometry().shell(numverts, verts, facelistlength,
facelist, &edgedata, &facedata);
delete [] verts;
return adesk::ktrue;
}in this example the vertices are set to locations that make them display as above. the face list pfacelist is then created to define the faces and any holes that might be in them.
the edge data has set this face's edges to colors 1, 1, and 5, respectively.
the face data is color 1 for the first face and color 3 for the second face (the hole is ignored).
best regards
chudomir
and that of mesh() function
virtual adesk::boolean
mesh(
const adesk::uint32 rows,
const adesk::uint32 columns,
const acgepoint3d* pvertexlist,
const acgiedgedata* pedgedata = null,
const acgifacedata* pfacedata = null,
const acgivertexdata* pvertexdata = null) const = 0;
rows input number of rows in mesh
columns input number of columns in mesh
pvertexlist input array of vertex points (must be rows x columns points)
pedgedata input pointer to an existing acgiedgedata object
pfacedata input pointer to an existing acgifacedata object
pvertexdata input pointer to an existing acgivertexdata object
pedgedata points to an acgiedgedata object that contains arrays of color, layer, visibility, line type, and selection marker settings for the edges. each of the arrays in the acgiedgedata object pointed to must either be null or must have (row - 1) x column + row x (column -1) elements.
pfacedata points to an acgifacedata object that contains arrays of color, layer, visibility, line type, and selection marker settings for the faces. each of the arrays in the acgifacedata object pointed to must either be null or must have (row -1) x (column - 1) elements.
pvertexdata points to an existing acgivertexdata object that contains a flag indicating vertex orientation on faces and a pointer to an array of vertex normals. the array of vertex normals must either be null or must have row x column elements.
note as the const qualifiers indicate, acgi does not change or delete the parameter array or objects. the caller is responsible for the memory they use.
this function uses the various objects passed in as parameters to generate and display a mesh primitive.
a mesh is any m x n array of 3d model coordinate points. if the user wishes, the faces, edges, and vertices can be individually adjusted for types of attributes (using the arrays in pedgedata, pfacedata, and pvertexdata).
vertex indices face indices edge indices
the above three figures show an example 4 x 3 mesh's placement of vertices, faces, and edges. here, there are 4 rows and 3 columns. there are row x column vertices, (row - 1) x (column - 1) faces, and ((row - 1) x column + row x (column - 1)) edges. this example is quite flat; however, the vertices can be placed anywhere in model space. this example could be twisted like a ribbon in 3d. if any of the faces have vertices that are not in the same plane, then the face is treated as two triangles whose common edge is always invisible. the control as to which of the opposite corners of the face are used to divide the face into two triangles is currently not available to the user.
the order of a mesh's edges is determined by "walking the rows" and then "walking the columns." the above example drawing for edge indices visually explains the order.
the order of a mesh's faces is determined by "walking the rows." again, the above example drawing for face indices explains the order.
a return value of adesk::kfalse (that is, 0) indicates that the primitive has been successfully stored in the graphics database. a return value of adesk::ktrue indicates that the operation has been terminated and the application wants to get control back as soon as possible.
here is example code for the above mesh:
adesk::boolean someentity::worlddraw(acgiworlddraw *pwd)
{
// set up the list of vertices in the array in the order given
// above--row by row.
//
acgepoint3d *vertexlist = new acgepoint3d[4 * 3];
// ...initialize the vertexlist points to look like the mesh drawn
// above...
// set up the edge data--make the row colors 1, 2, 3, and 4;
// make all of the columns color 5.
//
acgiedgedata edgedata;
static short edgecolors[] = {1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 5, 5, 5,
5, 5, 5, 5};
edgedata.setcolors(edgecolors);
// set up the face data--make the upper left face color1, upper
// right face color 2, and the rest color 5.
//
acgifacedata facedata;
static short facecolors[] = {1, 2, 5, 5, 5, 5};
facedata.setcolors(facecolors);
// note again that if there were no edge data, then null would
// replace 'edgedata', below.
//
pwd->geometry.mesh(4, 3, vertexlist, &edgedata, &facedata);
delete [] vertexlist;
return adesk::ktrue;
}
best regards
chudomir
thank you george and chudomir
i cant seem to find a dumplevel setting in any of the examples(odvectorizeex doesnt seem to have antyhing too.) could you please direct me to the proper location. also how do i get the triangles, what functions are called, or need to be called to access this data?
thank you
krishna
the dumplevel setting is in our latest 1.12 pre-release code only--a beta 1.12 version should be available within a week or 2. also, 1.12 will contain better documentation for the simplifier object.