Sometimes an object needs a cylinder or drum shape with flat ends, and the ends must be unwelded from the sides to make sure that the join renders sharp. In that case, I would expect any sensibly written mesh modeller program to make each end with *n* vertexes round the edge, and one vertex in the middle, and therefore *n* triangle sector faces and nothing else. But one commonly used modeler (Ray Dream Studio, I think) keeps making such drum and cylinder end surfaces like in this image, with an outside part, and an inside part (marked with yellow here), separated by unwelded loose edges (magenta here). The first few times I saw this, I thought it represented some feature of the object that the mesh was a model of. But it turns up over and over again, in all sorts of parts of all sorts of things, and always the inner and outer parts of the drum-end are in the same group and the same material. In a model like e.g. a scuba regulator or a vehicle motor that has many drum and flat-ended cylinder shapes, all these drum and cylinder ends made in this cobweb style instead of as *n* plain sectors, add up to a massive excess of faces making the final geometry file massive. And the inner part being separate means that an automatic polygon-thinner-out can't get rid of the mess properly. PLEASE how can a Ray Dream Studio user stop this from happening and force it to make these drum and cylinder ends in the plain proper simple style with *n* sector triangle faces and nothing else!?!?

I agree that what you've shown isn't anything that I would call "sensible". But I don't think it's "sensible" to do it the way you describe (a whole bunch of really thin "pie wedges") either. Texturing algorithms behave very badly when you have a bunch of really sharp triangles coming together at one point, and that causes a number of unpleasant artifacts. The example you've pictured would make the end from 64 "pie wedges", each with about a 6 degree point. There will be a "spider web" distortion in the center of the textured end. And "pie wedges" are hard on the lighting algorithms, too. The sharper the point, the more errors can arise in calculating a vertex normal at that point. So, if attempting to calculate a face normal, you have to know not to use the "sharp" vertex of the triangle, or there will be errors in the normal, and the lighting algorithm won't illuminate all the "pie wedges" evenly. Cutting up polygons into simpler shapes (triangles and quads) in an optimal manner is refered to as "tessilation", and is one of the hardest problems in computer graphics. It's something that sounds like it should have been solved long ago, but isn't. If you want a more "optimal" tessilation for that end cap, something that will render well, but doesn't take up too many polygons, try this: Start your end cap with a 64 side polygon, like the outer edge. Inside this polygon, draw a 45 side polygon, and connect each vertex of this polygon to either one or two vertices of the outer polygon. Now, you have an annular strip with 45 quads and 19 triangles. But none of the triangles are very sharp. Inside the 45 side polygon, draw a 32 side polygon, and connect them with an annular strip of 32 quads and 13 trianges. Keep this up, a 23 sided polygon, then a 16 sided, an 11 sided, an 8 sided, and a 6 sided polygon. The edges of that can meet at a center point which will only have 6 edges meeting at it. This would yield a 173 face end which would render better than your 64 face version, and better than the original 512 face version, which also suffers from having a bunch of sharp angled facets near the center. My tessilation also works well with mesh deformation algorithms. So I guess my algorithm (which is order of n*log(n)) is the "happy medium" between the original algorithm (order n^2) and yours (order n). Going back to your example above, there is an obvious reason why the yellow part isn't welded to the white part. Look carefully. There are more vertices in the inner border of the white region than there are in the outer border of the yellow. Welding them would mean that some of the yellow quads would become degenerate pentagons, with one side straight. This is, mathematically, very bad. The degenerate vertex has an undefined normal (you end up dividing by zero, if you try to calculate it). But, as I've shown, there are much better tessilations availiable. I would expect a "sensibly written" modeller to allow edges to carry infomation, so an edge could be labeled as smooth, or a crease, an edge, or a dart. A real "object" should be one "surface", so it can have an "inside" and an "outside" and properties like "volume" and "surface area". This whole bit about corrupting the geometry by "unwelding" edges to control how they render is archaic. Labeled edges are so useful. Aside from making it easy to "make sure the join renders sharp", labeled edges allow you to preserve sharp joins when using refinement techniques like subdivision surfaces, or compression techniques like progressive meshes. And they've been well documented for years. What you've shown us doesn't look like a RayDream tessliation. I think RD's normal cylinder end is a triangle fan from one of the edge vertices (not fron the center, like you qould do). The fan from the edge really causes some ugly texturing artifacts. As far as RayDream, it does a lot of things in strange ways, in order to make its deformers work. But it's very inconsistant in the way it makes these decisions. Ciao! Joe

I used Ray Dream Studio 5 for awhile, I remember it making quite a lot of really bad gemetry, typically it would have a polygon with a edge common to two others, just like what you show, as soon as you moved it the slightest bit a hole would open. It had a lot of other problems too, plus there was a lot of problems seeing what you were actually doing, I don't know if 5.5 is/was any better, and I never tried Canorama (?) it's replacement.

The "Upgrade" to Ray Dream is Carrara. It does a nice job of getting the right amount of detail (verticies and polygons) without a bunch of extras. It does allow you to set the detail level and you can actually go in ant do a point by point edit if you need to, along with decimating and increasing poly counts on spicific areas as well as the whole. But the program is not as user friendly and as nice IMHO as Infini-D (The first before Ray Dream). And I do a lot of my props for Poser in Infini-D and have never had this problem. The "cap" of my cylindars only have one center vertici. James

Attached Link: http://www.silvermage.net/3d/buckrogers/salvus.zip

If the render is smoothed, presumably at the place where 64 pie-wedges meet, surely the renderer would use one normal there, which is the average of the normals to all 64 triangles. It seems to be the old battle betwen maximum realism and keeping mesh file side within bounds. I once made a scene with 4 of my Gerry Anderson UFO series ailen in spacesuit in, and I would not have thankful if each alien had been say 5 megabytes big! In my case, I have never needed 64 corners. My model at this link (and on the Poser FreeStuff) has plenty of tubes and other cylindrical stuff, and I use 32 vertexes round if the part is big, like the oxygen cylinder, and 16 vertexes round elsewhere. It depends on how closely people are going to look at the model.

Anthony, the bigger problem is not lighting, it's texturing. That has little to do with normals, and everything to do with reduced precision math. Let me walk you through a typical 3d rendering, and you might see what I'm talking about. Let's do lighting first, though, since you seem to have some understanding of that. Assume the model has already been broken down into triangles. One "face normal" is calculated for each face. Now, for a "reasonable" triangle, one with no particularly sharp points (say no angle sharper than 10 degrees or so) you can take the verticies in pretty much any order and get a fairly accurate normal. But if one angle is very sharp, then two of the edges start to look like parallel lines. If you pick those two edges, all the dynamic range of the floating point calculations is used up dealing with the small angle, and there is a rather annoying amount of error in the normal. Now, you're right, for the vertex in the center of the big polygon, there are 64 face normals being averaged, so the errors tend to average out. For the 32 sided polygon, you're still dangerously close to being "too sharp". This depends on what you're doing the rendering on, of course. If you're doing everything in double precision (100 bit or more) floating point, you're probably fine. If you're doing it on a reduced precision math system (like the Poser renderere, or a hardware graphics accelerator) you're going to get artifacts. OK, so now you've got one reasonably good vertex in the center. There are still 64 around the edge to deal with. And each of those verticies gets its vertex normal calculated from just two face normals. So there's little hope the error averages out. Actually, the law of averages says 1/2 will have "destructive interferanc" and be left with less error. The other half will actually contribute to each other's errors. So the edge normals can be rather "wavey". Which is definitely going to show up in your lighting calculations. Remember, we're talking production rendering, not "game rendering", where we do such silly things as use vector quantizers on the normals to save memory. At least for the 512 face "original" these screwey normals are confined to a relatively small area of the center of the end cap. Now, as far as texturing. Most graphic toolkits have a variety of mapping modes. Cubic, cylindrical, cylindrical with end caps, spherical, etc. Since the object IS a cylinder with end caps, it makes sense to use that mapping mode. So each skinny pie wedge of the end cap maps to a skinny pie wedge of the texture map. Now, texture maps are low resolution, integer coordinate systems. Ad as we get close to the pointy edge of a triangle, it's very easy for the integer math to end up a whole pixel off. Even with texture interpolating filters, these errors are enough so that the edges of the texture wedges do not match up, giving rise to the classic "spider web" artifacts. One cure is to increase the integer precision. This means increasing the size of the texture map, to minimize the effect of a one pixel error in texturing. Of course, if you're worried about memory utilization in your model sizes, think of what kind of trouble you're going to get into by increasing texture map sizes. The tessilation I mentioned (which is a real tessilation, in use in my own graphics applications, today, and probably other peoples, since it's such a basic concept I can't believe I'm the first to "invent" it) only has 2 or 3 times the polygon count of yours for practical sized objects, yet will render with no texture or lighting artifacts, and works very well with any type of mesh deformer you care to throw at it. I hope I'm not misassessing your level of knowledge of these subjects, but you seem to be a relative beginner in 3D programming. Would you like me to recommend a couple of good books or places where you can dig for some information on the basics?

Wiz wrote: I would expect a "sensibly written" modeller to allow edges to carry infomation, so an edge could be labeled as smooth, or a crease, an edge, or a dart. .OBJ format as defined for Wavefront does carry that information: for each corner of each face there is a vn line which states the normal there (as well as a vt texture map coordinate), and also there are s lines which divide the object into "smoothing areas". But Poser ignores these vt and s lines, and they are not represented by anything in Poser mesh .RSR file format. I suspect that Bryce ignores them also. But if one angle is very sharp, then two of the edges start to look like parallel lines. Uhh. In my own attempt at writing a simple renderer (as used in my MAKEOBJ and FACES), when rendering a triangle face, I treat the face's normal as bring at right angles to the plane of the face, and I do not directly consider the directions of the edges. (If a face has more than 3 corners, I treat it a triangle at a time.) If I ever go as far as to program them to render with smoothing, I would likely put the normal at each vertex to the average of the normals to the faces that meet there. Would you like me to recommend a couple of good books or places where you can dig for some information on the basics? That would be useful. Please state the publishers and the ISBN numbers. This whole bit about corrupting the geometry by "unwelding" edges to control how they render is archaic. I know that, and it is a nuisance when mesh-editing the model. That is why I wish that Poser had a user-settable maximum smoothing angle like Bryce has. ... giving rise to the classic "spider web" artifacts. That likely depends on how likely it is that that particular cylinder-end or drum-end will ever be rendered with a pattern using the vt values (which in Bryce is called "parametric mapping"), rather than all the same color. In texture mapping as implemented in my MAKEOBJ, if I go from one face to another, the (equation for where on the texture map to read the color from) always changes continuously and not by steps, if all face-corners at the same vertex have exactly the same vt value (or point to the same entry in the vt table), so spider-web type breaks in the pattern should not occur. My release of MAKEOBJ includesd all of its source form.

AA said ".OBJ format as defined for Wavefront does carry that information:...But Poser ignores these vt and s lines" (elipses mine). I think you mean that Power ignores the "vn" vertex normal lines. It certainly uses the "vt" texture lines. Vertex normals are of no use to a mesh deformation program like Poser. Every time you pose a figure, you alter the orientation of the faces (changing their face normals) and their size (and a "good" vertex normal is computed from a weighted average of face normals) so every time you pose, you need to recompute the vertex normals. The .obj format doesn't have a real concept of "edges". The "smoothing group" lines work at the "face" level, you still have to do a lot of computations to find out if an edge is a crease, or a dart or a corner. (I use Hoppe's terminology). IMO, smoothings groups were a major "hack" and should never have been part of the .obj format. "I treat the face's normal as bring at right angles to the plane of the face, and I do not directly consider the directions of the edges." Well, the definition of a normal is that it is perpendicular to the plane of a face. The "normal" way of calculating a normal is the cross product of two vectors that lie in the plane. For a triangle, any two edges are vectors defining the plane, and should yield exactly the same normal, given sufficient mathematical precision. The problem is that the cross product involves multiplying components of the vectors, then adding them, something you don't want to do in floating point. If the products of the multiplications vary greatly in magnitude, then the addition produces substantial errors in a reduced precision (real time or fast math) environment. So you want to pick the "right" two of three possible edges for calculating your normals. It's fairly common to do a simple comparison of edge lengths before calculating a normal. And you really should consider the direction of the edges, lest your normal point inside the object, instead of outside. "I wish that Poser had a user-settable maximum smoothing angle like Bryce has" The "user settable smoothing angle" is as archaic as making "sharp" edges by "unwelding" geometry. For a human model, you will find places where a fairly sharp corner (maybe 30 degrees) is still something that should be smoothed (posettes fingers are full of thise spots) yet a shallower angle (lip edges, for example, or areola) is a "crease" that must be preserved. And there are places where edges disappear into flat surfaces (darts) that you simply can't find with a smoothing angle. But, if you really want it, Nate Robbins has some nice source code for software that applies variable smoothing angles. And it's a nice starting point for openGL, which you really need to get into. Fair warning, his algorithm is O(n^2), and you can reduce to O(n*log(n)) simply by sorting all the verticies by their x, then y, then z coordinates, and using the sorted list as a rough guide for the distance detection function. http://www.xmission.com/~nate/smooth.html "That likely depends on how likely it is that that particular cylinder-end or drum-end will ever be rendered with a pattern using the vt values (which in Bryce is called "parametric mapping"), rather than all the same color." Always plan on texture mapping and making sure your geometry will support a texture map well. Even if you don't use such a map yourself, your renderer will, when rendering the image. Renderers create tons of maps, shadow maps, lighting maps, radiosity maps. If the figure has a texture map, they use it. If not, thet apply a basic mapping algorithm like cube or spherical mapping. Most indespensible book I have right now: Real-Time Rendering, by Tomas Mler and Eric Haines, ISBN 1568811012. This book probably does a better job of explaining just about everything you need to get a major 3D app together than just about anything else I've seen. The book has its own web site: http://www.realtimerendering.com/ Another goodie: Digital Character Animation 2 : Essential Techniques, George Maestri, ISBN 1562059300. This book is wonderful. Explains things like mesh deformations, character creation, and the basica of animation, in a totally software independent way. It's as applicable to Poser as it is to Max and Character Studio. The "2" refers to it being the second edition, not the second volume of a set. And I've got to send you to Hugues Hoppe's homepage. Sorry, Hugues is at Microsoft these days, but they host all his cool stuff, including his doctorial thesis. Many book length .pdf files you can download. Some of the most clear and lucid explanations of subdivision surfaces, mesh simplifications, and surface reconstruction that I've ever seen. http://research.microsoft.com/~hoppe/ And I'm still working my way through your MakeObj source. Your coding style and mine are so different that reading your code is slow going for me. (Your code isn't necessarily better or worse than mine, just really different). But we've got to get you using openGL, and maybe wxWindows. If you've never written a GUI based 3D application, and had the same code compile on Windows, Linux, an SGI, and a Mac, you just don't know what you're missing. Have fun. Joe

But Poser ignores these vt and s lines" (ellipses mine). I think you mean that Power ignores the "vn" vertex normal lines. I meant vn. Sorry, mistype. What is openGL and wxWindows and GUI?

And I'm still working my way through your MakeObj source. Which Windows compiler do you use? I use Borland C++ 4.52 . if an edge is a crease, or a dart or a corner I thought that there were 2 sorts of edge :: you want to smooth across it, or you don't. But you list 3 types. What do these names mean? I know "dart" as: (1) a small missile, usually as in the game of darts; (2) in dressmaking, a V-shape in the cloth which is sewn over itself to shape the garment.

Attached Link: http://www.wxwindows.org

OK, in reverse order, openGL and wxWindows and GUI... GUI - Graphical User Interface. All the stuff on the screen that makes up the program. Your large split window with grid lines, dual cursors, and a row of menu buttons above is your GUI. It's how the program interracts with the user. Morpher's dual list boxes, drag and drop between them was its GUI. wxWindows is a C++ class library, what's commonly called an "application framework". It has classes which you can use for application objects, message handling, dialogue boxes, windows layout, etc. http://www.wxwindows.org You use Borland C 4.5. Borland's application framework is called OWL, the Object Windows Library. It's a very nice framework, and takes a lot of the drudgery out of getting a program running. I've noticed that MakeObj is an old style Windows program, written entirely in C, anc contains tons of case statements to handle Windows messages. If you wrote it as an OWL program, you'd have a nicer looking GUI, with much, much less work. You could have based your program on a tTwindow class, and just cleanly added a menu and drawing functions, and had to do a lot less UI work on your program. Microsoft's framework is called MFC, the Microsoft Foundation Classes. Personally, I've used both OWL and MFC, and find OWL much more logical, consistant, and easy to use. Both OWL and MFC are only for Microsoft Windows. You can't easily take an OWL or MFC program (or your program, for that matter) and complie it on a Linux machine or a Mac. wxWindows is an incredibly rich class library. It looks wuite a bit like OWL. But it's "cross platform". If I write this line in my program: wxMessageBox("error", "The file couldn't be opened") I'll get a nice Windows message box if I compile it on Windows, a GTK or Motif message box on UNIX, and a proper Mac box on a mac. All from one line of code. There's an OS/2, BeOS, WinCE, etc. version of wX. It's better than Java for "write once, run anywhere". And there's wxPython, but I've never tried tying that into Poser ProPack. Do you remember Morpher, the original morph management utility. I wrote the first version in OWL, and the second version in wX. Version 2 would compile with my Borland C++ 5 on Windows, GCC on Linux, and we even once tried to compile it on a friends Mac. There are other cross platform libraries, some are commercial, like PowerPlant (from MetroWerks) and others are free, like V and Amulet. But I think wX is the best. openGL is the Open Graphics Language. It's a relatively low level API for talking to your graphics hardware. You call openGL functions to place your camera and lights, and then you can render objects. It supports primitives like triangles, quads, strips of triangles or quads, triangle fans, etc. And arbitrary polygons, as long as they're convex. It supports texture mapping and fog too. openGL will do these things with your graphics hardware, if the hardware supports it. I use a geForce 2, and have written openGL programs that pust around about 10 million polygons/second. http://www.opengl.org openGL is platform independent, and comes preinstalled on MacOS 9 and X, Windows 98, NT4, 2000, and ME, Linux, SGI IRIX, BeOS, etc. And it's as fast (or faster) than the propriatary 3D APIs like DirectX or Quickdraw3D. openGL is based on SGI's propriatary GL, so you can understand why it was built to be fast and versatile.

A "crease" is where polygons come together. A corner, as it were. "smoothing groups" are creases. They can be classed as peaks or valleys for A "dart" is where a crease "ends" in the middle of a flat surface. Kind of hard to describe. The vertex that terminates the dart has shared normals for the smooth side, and individual normals for the crease side. And, of course, there's a "edge" where the mesh ends, and you fall off the edge of the world. Look at Hoppe's web site. The subdivision surface paper has nice illustrations. Ciao! Joe

Attached Link: http://www.buckrogers.demon.co.uk/software/spatrl.zip

Another graphics program that I wrote is a 2D graphics game game that I wrote, called SPATRL (Sea Patrol 1, at this link, about a Sea Patrol suction-dredger-sub cleaning up an incursion of unauthorized scuba divers). I wrote it in DOS to get the best speed and bypass all the overheads that Windows causes. (OK, I know that it needs a better dialog for the user to set up its running parameters.) In it, I found it quite easy to display an image at an angle to movie speed, a job which the writers of Corel Draw refussed to attempt.

Attached Link: http://nehe.gamedev.net/tutorials/lesson36.asp

I'll have to see where I can find a dos box to run it on. It won't work in an NT4 command prompt. Why would you want to play a movie at an angle in CorelDraw? As far as "overhead" for windows, if you use something like openGL, you're talking pretty intimatly to the graphics hardware, windows overhead isn't a problem. Just to give you an idea of what's possible, here's a nice tutorial on how to texture a 3D object with a playing movie, in real time, with openGL. http://nehe.gamedev.net/tutorials/lesson36.asp And a spiffy screensaver that does just that. http://3dacid.com/vexture.html Ciao! Joe

SPATRL will run correctly in full-screen DOS mode under Windows 95 & 98. If Windows 2000 or Windows ME can't run DOS full-screeen, that is a pest and a misfeature. Why would you want to play a movie at an angle in CorelDraw? If the sub or the divers are going up or down, they must be displayed at an angle. In Corel Draw, I was referring to superimposing images moving them about to find the best position and the one on top is at an angle.

Well, Windows NT 4 and Windows 2000 are designed so users can't poke directly at registers or into memory. If your program tries to do that, they will stop it. That is not "misfeature". It is a necessity in an operating system that is designed to run very large programs for very long periods of time (months or years) without rebooting. The rest of Windows, 95, 98, and ME, are all just a whole bunch of service packs heaped on Windows 3.1, which is a shell over DOS. So, if you need DOS, it's there for those programs. Corel can rotate, skew, and deform (with a pretty cool grid deformer) any bitmapped image. So I'm not sure what you're trying to do that Corel can't handle.

So I'm not sure what you're trying to do that. Corel can't handle. The version of Corel Draw that I bought, could rotate etc, but it would not display an image as I rotated it, but only after I called it to assemble the complete image. That was many years ago.

OK. I didn't look to see if Corel gave you a real time preview while you rotate or skew an image. It doesn't (even in version 9). And I bet it never will. You can paste a bitmap of virtually any size in Corel. I've had drawings that incorporated 1/2 dozen 40 meg scans from slides. When these images update, it takes a few seconds, even on a 1.2 gigahertz machine. I'd hate to see a preview moving in 5 second "jerks" as I rotate the image. Now, it would be nice if it generated a low res (fast rotating) preview image from the high res image, instead of using a grey box...