Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ptsfa!well!jfoust From: jfoust@well.UUCP (John Foust) Newsgroups: comp.sys.amiga Subject: Re: Interchange program for Sculpt 3D and Videoscape3D Message-ID: <4391@well.UUCP> Date: Sat, 7-Nov-87 03:51:24 EST Article-I.D.: well.4391 Posted: Sat Nov 7 03:51:24 1987 Date-Received: Mon, 9-Nov-87 07:09:27 EST References: <3557@ccicpg.UUCP> <4382@well.UUCP> <4386@well.UUCP> Lines: 167 Summary: long msg and refutation Why, yes, Leo, I did ask you once about this in person, and you gave the same answer. But let me elucidate for the crowd... While writing the InterChange VideoScape convert module, I found a number of nasties in both VideoScape and Sculpt. For example: I used the objects on the VideoScape disk as my primary set of test data for InterChange. By closely examining these files, I found non-planar polygons in VideoScape. How such an polygon will be rendered is no doubt deterministic, but the manual has little to say about this. When InterChange converts an object, should I allow non-planar polygons? How can I convert these objects for other programs that are less tolerant of slop in their data? (Of course, Sculpt gets past this by using triangles, which makes a lot of graphics a lot easier. Also, my tiling algorithms work on non-planar polygons.) As for Sculpt's apparent indecision about coordinates, it threw me for a loop, too. It apparently loads and saves objects relative to the cursor, if you do a "Load Object" or "Save Object." Loading a .scene file will always work, and the coordinates are absolute. As for .scripts, if you create the whole scene within a single script, then you get the precision you want. Or you could return the cursor to a fixed spot between loads. As for moving objects to get ersatz animation out of Sculpt, I suggest we both wait for lessons from Ken Offer, the guy who did the Kahnankas and RotAmiga scenes for the BADGE contest. He uses .scripts exclusively. At COMDEX, he showed another animation that blows the socks off both of those. It is a little perpetual motion boing ball factory scene. There's a unicycle in there, too, someplace. As for Sculpt and points, it will only create a point once. It will only allow one triangle at a given set of vertices. So when my program converts coplanar coincident polygons to Sculpt, I put both in the .scene file, but Sculpt only listens to one. As for the problems of object size relativism, I came up against that wall, too. Niether program has a "meter", so all coordinates are relative to each other. For each scene, you determine the standard unit meter size. If you want to move objects between scenes, you will need to resize objects unless you use the same meter for all scenes. InterChange does its best to fit the object to the universe size of the destination file type. Without a meter, objects will always be relatively sized. VideoScape will allow any number of polygons (or surface details) at a given set of vertices. The surface details will be rendered in the order of their description in the GEO file. The polygons - hmm - who knows. Sculpt does wacky things when you've got two very nearly coincident polygons, too. They aren't rendered quite right. Allen exploits this in the HouseAndYard file. The windows are two surface details, not one. First a black square, then a blue one. The black square is rendered, then the blue one, at the same endpoints. *But the blue window is still surrounded by a black border.* Why? What about the way VideoScape clips polygons? It uses a very crude method. It first checks the centroid of the polygon. If the centroid is not visible in the viewing window, then the polygon is not drawn. So if you create a table top, and zoom in to an object on a corner of the table, the table top disappears. Also, it fails the most primitive traditional tests for overlapping polygons, such as interlocking rectangles. It is clear that these trade-offs were made for rendering speed, not user-friendly or even programmer-friendly creation of objects. What does the VideoScape manual say about this? Break up your polygons into smaller polygons if this happens. Hmm. Time to start up 'ed', and break out the graph paper. Or in your case, re-write the program. Sculpt is much nicer about this. In its Painting mode, where it renders objects as shaded, non-ray-traced polygons, it does a complete painter's algorithm and correctly clips intersecting and overlapping triangles. Also, it picks a palette that most closely resembles the scene given the current lighting and object orientation. In other words, a Sculpt Painting mode picture of a VideoScape scene looks much nicer than VideoScape. (Sculpt Painting mode can render your unicycle in about three or four minutes, compared to about a minute for VideoScape.) If you want to create complex objects, it is very difficult to create planar polygons, especially if the object has a subtle shape. Thinking about 3D slopes is one answer, but it is not an easy technique. This business of specifying the outward normal of the polygon takes a lot of mental energy, too. Same goes for specifying points in counter-clockwise order. What are computers for? VideoScape uses the vector cross product of the first and last segments of a polygon as the direction of the outward normal. The manual just tells you to avoid considering a concave vertice as the first point. This is a user-friendly way of explaining a cross product and its relation to the outward normal. However, some objects on the VideoScape disk use the deeper understanding of cross product to provide the orientation of the polygon. In other words, the points are listed in clockwise order, but a concave joint is listed first, so the polygon is oriented correctly anyway. Leo, you are quite unusual to be able to write C programs that induce VideoScape to have motion blur and Newtonian physics. You also have good directorial skills, as does Allen Hastings. Most people don't. Graph paper is not a user interface. Do-it-yourself C programs are not a user interface. Aegis should not have sold VideoScape for $199 without a user interface for making objects. They have announced an object editor destined to ship in four or five months, priced at $149. Meanwhile, I'll try to sell InterChange to everyone else who owns VideoScape. I think most people do not understand three-dimensional trigonometry. Out of the estimated 7,000 people with VideoScape, how many can do what you do? To me, the ultimate proof that most people have trouble with VideoScape is the dearth of user-created objects. I expected to see objects uploaded and shared between users within weeks of VideoScape's release. I also expected to see animations with objects other than those from the VideoScape disk. I have seen very few examples of totally fresh VideoScape animations. On top of object creation, add the troubles of entering camera motion files. Again, you need a 3D mental image, and there is no user interface for making motion files. I see a pattern here. I'll agree that VideoScape is more amenable to sophisticated users. However, the manual doesn't elucidate the methods of the program as if only sophisticated people were to be using it. It doesn't describe the exact limitations of the program. Instead, it pretends that making 3D co-planar polygons on 2D graph paper is the most natural thing in the world, and leaves people guessing about why their table disappears. I posit a fundamental limit to the size of a human-generated VideoScape object. After a certain number of points, and presuming that the object may someday need to be changed, manipulating the object will become impossible without an object-editing tool. Some example VideoScape objects list the same point several times. It is obvious that their creator wanted to add more polygons, but didn't want to add or change the enumerations of the vertice list. Allen Hastings stopped creating objects on graph paper months ago when his friend Stuart Ferguson wrote this object editing program. How can you hand-check a VideoScape GEO object for problems like non-planarity? How can anyone examine a GEO file? Or how could you find a bug in your enumeration of the vertice list? Without a tool to enumerate the vertices for you, it is impossible with more than a few dozen points. I have considered writing such a tool. I have in-house routines to do it. Consider Leo's unicycle. (I have converted it to Sculpt form.) The fork and seat has 1669 points and roughly 1400 polygons, with some polygons having as many as 36 vertices. (Most had 4 vertices.) The wheel has 1576. The whole unicycle becomes 5012 triangles when converted to Sculpt. By contrast, the Lotus car from Hastings' animations has only 554 vertices. Isn't this a little overkill for an object that is ultimately rendered with about twenty pixels across? Come to think of it, isn't this overkill for a program that only allows eleven colors? (VideoScape only allows eleven colors for polygons, plus variations such as "unshaded polygon" and "wireframe polygon" of the same colors. When it renders the scene, it dithers to get shades of those eleven colors. In the next rev, VideoScape will add two more colors, for a grand total of thirteen, as well as a hatch-dithered "transparency" color. Did you notice the colors are fully IBM compatible? I wonder if VideoScape will be ported to the PC. :-) The selection of colors is completely arbitrary, unless you consider that it may be ported to the IBM. The limitation on the number of colors is completely unnatural and arguably criminal on the Amiga. (How should InterChange map 4096 Sculpt colors to eleven VideoScape colors? Actually, Sculpt supports 24 bits of color, not just 12.) Speaking of ports, Bill Volk has ported the ANIM of "The dream goes berserk" to the Mac II. Yes, VideoScape is great, quick and dirty, but it's not user friendly in the least. As the marketroids at Aegis describe it, "it is a sophisticated program," implying, of course, that if you don't understand it, you obviously aren't sophisticated. To me, that sounds like a BS excuse for marketing a program without a user interface.