harald@ccicpg.UUCP ( Harald Milne) (11/02/87)
I forgot to mention this product literature I got with my Sculpt 3D
upgrade. Syndesis sells a program that allows one to use the Sculpt 3D editor
to create objects for VideoScape 3D. It also allows one to make HAM ray-traced
VideoScape 3D scenes with Sculpt 3D. The interchange programs are separate
multitasking modules. They say they will add more modules in the future to
enhance all Amiga 3D programs.
The company is:
Syndesis
20 West Street
Wilmington Massachusetts 01887
(617) 657-5585
--
Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG)
Irvine, CA (RISCy business! Home of the CCI POWER 6/32)
UUCP: uunet!ccicpg!haraldjfoust@well.UUCP (John Foust) (11/07/87)
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.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (11/10/87)
[ Insert CBM 2000 flamage here. ] You know, it's weird. Every time I say that I find VideoScape easier to use than Sculpt, people look at me like I come from another planet. In article <4391@well.UUCP> jfoust@well.UUCP (John Foust) writes: >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. > Good Grief! Three Sculpt animations???!! How do I talk to this guy? >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. > Oh, good. That's a powerful piece of knowledge that should be (but isn't) in the manual. Or is it? >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. Actually, I don't consider this a problem. The animator simply decides how "big" everything is going to be at the outset, and scales everything accordingly. This arbitrary scaling works great for VideoScape (uses floating point), but I don't think works with Sculpt (which I hear uses fixed point). The reason the outside radius on my unicycle wheel is 40 is because that's what size fit best on my piece of graph paper. The only time scale becomes a problem is when someone else wants to use your object in their scene. Then they have to know the size of your object, and re-scale it. (Yes, I know you said this.) >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? > I'll bet he used the unfilled border option. I'll go stare at the file. >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. [ ... ] Now *this* I didn't know. I consider this a bug. I'll talk to Allen about it. >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. [ ... ] Yes, I noticed this behavior. Intersecting solids are done right. The behavior of VideoScape's polygon rendering has bit me. The floor in The Dream Comes Alive is composed of some 350 polygons. This is to prevent the software from screwing up the drawing of the unicycle. Allen since told me a neat little trick, which I used in The Dream Goes Berserk. It's inelegant, but it works. >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. > Tell me about it. A couple of planes in the unicycle's seat I happen to know are non-planar. I had no choice but to do it this way, due to lack of a solid modelling package. >This business of specifying the outward normal of the polygon takes a lot >of mental energy, too. [ ... ] Not to mention the fact that, if you get it wrong, things come out looking weird. >Aegis should not have sold VideoScape for $199 without a >user interface for making objects. Agreed. D3D (a/k/a ROT) was not a viable excuse for a modeller. >They have announced an object editor >destined to ship in four or five months, priced at $149. GAAAKK! That's a bit overpriced.... >Meanwhile, I'll >try to sell InterChange to everyone else who owns VideoScape. You've got at least one sale right here. >Some example VideoScape objects list the same point several times. [ ... ] This bugs me, too. The new modeling program will collapse redundant points. The main contributor to this is OCT. EGG is also guilty of it. >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. > Can I get your tools? Do they come with InterChange? They sound very useful.... >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. [ ... ] Big, isn't it? :-) >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? [ ... ] Not at all. Unlike Sculpt, we don't have edge smoothing. I wanted a cylinder to look like a cylinder no matter where I was looking at it from. I'm rather proud of the fact that I spent a lot of time on the little details of the cycle. Yes, it takes a long time to render; but I think the results are worth the time. No matter what angle you look at the cycle from, it looks good. By contrast, Allen Hastings took my unicycle, reduced the number of points and polygons in it, and used the result in the Car Demo. I can see the difference. So call me weird. >Did you notice the colors are fully IBM compatible? [ ... ] Yes. I wasn't impressed. Oh well..... >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. [ ... ] I found the color limitation very strange, too. But Allen has pulled all kinds of trick just so that he doesn't have to wait so long for a frame to be rendered. Which is perfectly within his right, I suppose. >Speaking of ports, Bill Volk has ported the ANIM of "The dream goes >berserk" to the Mac II. > Now that *is* criminal. >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. > All right, I'll admit my mind works a bit differently from everyone else's. But do please believe me when I say that, no matter how implausible it may sound, I find VideoScape easier to use than Sculpt. I do promise to play with Sculpt more, though.... Phew! Got longer than I wanted. Anyway, I think Sculpt is a great rendering package, and if I ever get comfortable with it, I'll do some stuff with it. Right now, all that I feel comfortable with it VideoScape (or, as the marketroids at BbB like to call it, Vege-Scape). I can make it do what I want. I'm having trouble getting Sculpt to do what I want. But I'm working on it..... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
adh@well.UUCP (Allen D. Hastings) (11/14/87)
This posting is a response to a message by John Foust in which he
explains some of the difficulties he had writing a conversion program for
VideoScape 3D and Sculpt 3D object description files. While he brought up
several good points, he also made several misleading statements about
VideoScape 3D.
For example, he complains that non-planar polygons are allowed by
VideoScape. Many polygons with more than three vertices are bound to be
slightly nonplanar to some extent, simply because their coordinates are
not specified with infinite precision. If perfect planarity is desired,
one can always construct objects out of only triangles. The fact that
VideoScape allows up to 250 vertices per polygon simply gives additional
flexibility and convenience to the object designer. (It is also important
to note that VideoScape allows less than three vertices per polygon for
creating lines and points. To make a starfield in Sculpt 3D, each star
would have to be represented by tiny triangle!)
>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.
While it is true that "one unit" in the coordinate system of any 3D
program can be interpreted as any actual distance, in VideoScape the
convention is that one unit corresponds to one metric meter (a convenient
unit for floating point representations of common objects). This means that
objects such as those included with the program and on future library disks
can all be used together in the same scenes without having to worry about
rescaling any of them.
>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?
Actually, in that case the blue window is drawn first and then a black
outline polygon is drawn around the window ("outline only" is one of the
rendering modes for a polygon). Both of these are examples of surface
details, which are a useful feature of VideoScape and allow it to avoid the
confusion that Sculpt 3D suffers when one polygon is inside another.
>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.
This statement is obviously false. If it were true, then when the
camera panned around a scene, polygons would be disappearing along one edge
as their centers went off the screen (which clearly does not happen).
VideoScape "culls" polygons (what John meant by the term "clips") only
when all of their vertices are behind the camera, or when they are "back
faces" and point away from the camera. The latter condition allows one
to paint each side of the same polygon with a different color (a unique
ability among Amiga 3D programs as far as I know).
> ...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.)
A scene rendered by VideoScape will look nicer (and still be drawn much
faster) than a scene rendered by Sculpt 3D's painting mode when there are
lots of colors in the scene, because VideoScape can use dithering to create
more subtle shading than exists in Sculpt's computed pallette (this is
especially true when Extra Halfbrite mode is used in VideoScape 1.10).
Also, knowing the pallette in advance allows the use of IFF foreground and
background paintings (another unique feature among 3D programs so far).
>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.
None of the Amiga 3D programs have done too well in this regard, and the
problem is not a lack of objects, but a shortage of people who want to give
out their creations. However, there are lots of user-created objects out
there (some of the ones I've seen are incredibly complex, and I don't just
mean Leo's), and it's only a matter of time before they are available in
greater abundance. I have several hundred VideoScape objects now, many of
which I plan to distribute on a library disk (disks?) shortly.
> ...Allen Hastings stopped creating objects on graph paper
>months ago when his friend Stuart Ferguson wrote this object editing
>program.
I'm afraid that is completely untrue. I have found very efficient ways
of creating complex objects quickly using the techniques explained in the
VideoScape manual. To make the Psycho-like haunted house in Halloween 3D,
for example, I simply traced a few basic parts from a book (like a wall
with a window, a roof section, etc.) and then put them all together like
toy building blocks with the OCT utility, resulting in a complex object with
very little work. In fact, if one uses see-through graph paper, it is
easier and more accurate to trace the outline of an object from a diagram
in a book than it is to "eyeball" it with the mouse (and there are no
jaggies on the paper). I should point out, however, that Stuart's graphic
object editor, Modeler 3D, is simple to use and quite powerful, and I'm sure
I'll use it a lot when it's completed.
> ...The selection of colors is completely arbitrary, unless
>you consider that it may be ported to the IBM...
Port VideoScape to the IBM? That's heresy for an Amiga fanatic like
me! Actually, the color codes follow a very logical system in binary:
the one's digit represents blue, the two's digit represents green, the
four's digit represents red, and the eight's digit represents intensity.
More significant bits are used to select various modes such as dull,
shiny, luminous, etc. VideoScape 1.10 also renders semi-transparent
polygons and various "special effect" polygons for things like spotlight
beams or atmospheric shadows. Colors can be mixed to get 121 different
choices (not counting the different rendering modes), and the pallette can
be set by the user to any of the Amiga's 4096 colors.
I hope this message clears things up a bit. Since serious Amiga
graphics nuts should have both Sculpt 3D and VideoScape, I wish John luck
with his object translation program. Sorry if you had trouble writing it,
but nobody said it was going to be easy!
- Allen Hastingsjfoust@well.UUCP (John Foust) (11/15/87)
I must comment on something I said in this message. I said: > 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 This is not true. I got this description from someone who uses VideoScape a lot, but in retrospect they had it confused. I hadn't tested it myself before I posted. I apologize for the error, and clarify: While "centroid" implies a point that is the average of all coordinate triplets, VideoScape instead uses the center of the bounding box of the object, that is, the center of the max and min of all points in the object. This might be more properly called the center of extent. It does render polygons if their center of extent is off-screen. (This should have been obvious to me.) VideoScape uses the distance of the center of extent as the determiner of the "depth" of the polygon when drawing the scene. Farther polygons are drawn first, layering the image. A correct example of a failure of this rendering technique is an object on a tabletop. In a view with the center of the table between the object and the camera, the object may disappear because the tabletop will be drawn after the object, thus obscuring it. How do you get around this? Break the up the tabletop into several polygons, instead of one big polygon.
harald@ccicpg.UUCP ( Harald Milne) (11/16/87)
In article <4443@well.UUCP>, adh@well.UUCP (Allen D. Hastings) writes: > >To me, the ultimate proof that most people have trouble with VideoScape is > >the dearth of user-created objects. > None of the Amiga 3D programs have done too well in this regard, and the > problem is not a lack of objects, but a shortage of people who want to give > out their creations. I can understand that. Considering how much time it takes to do this. Just for an exercise, I created the old Enterprise main hull, and it wasn't fun. But it wasn't that hard to do in Videoscape3d. We really need more tools. > I have several hundred VideoScape objects now, many of > which I plan to distribute on a library disk (disks?) shortly. Boy, would I like to see this. The whole game is objects! Not to mention Sclupt3d's triplane objects! Objects! I wanna to play too! > I hope this message clears things up a bit. It sure does! Care to divulge any other secrets! > Since serious Amiga graphics nuts should have both Sculpt 3D and VideoScape I have both. And I'm nuts! More, more! > - Allen Hastings -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
jfoust@well.UUCP (11/20/87)
> slightly nonplanar to some extent, simply because their coordinates are > not specified with infinite precision. If perfect planarity is > desired, one can always construct objects out of only triangles. In some of the objects on the VideoScape disk, the non-coplanarity is as much as 20 percent. Hey, it works, even though it doesn't seem academically elegant. > Actually, in that case the blue window is drawn first and then a black > outline polygon is drawn around the window ("outline only" is one of > the rendering modes for a polygon). Both of these are examples of I misinterpreted the VideoScape file, this was my mistake. In Sculpt, edges and points are not rendered at all. Only triangles are rendered. Sculpt edges and points have no color characteristics. I do not translate outline polygons to Sculpt form. > A scene rendered by VideoScape will look nicer (and still be drawn much > faster) than a scene rendered by Sculpt 3D's painting mode when there > are lots of colors in the scene, because VideoScape can use dithering > to create more subtle shading than exists in Sculpt's computed pallette Do you mean to say "lots of colors" equals "eleven fixed colors, plus fixed shades of those colors"? My point was that Sculpt does choose a new palette for the picture, which looks much nicer than a fixed palette. An example of the benefits of a flexible palette are obvious when you move around a simple object, like a cube. In VideoScape, the shades of the rotating sides go "clunk, clunk, clunk" when making the transition from light to dark, because of the limits of dithered coloring. To be fair, this is true of any any non-HAM rendering scheme, so this isn't a particular criticism of VideoScape. To me, the best situation would be both a fixed but user-settable palette and dithering to get shades. (Changing palettes between frames leads to complications in compressing the resulting animation files.) Also, it no one has explored the use of dither patterns with two colors, instead of one color and black. They used to squeeze dozens of extra colors from the Apple ][ by placing different colored pixels next to each other. In Amiga interlace, it works quite well, according to some experiments I've done. > beams or atmospheric shadows. Colors can be mixed to get 121 different > choices (not counting the different rendering modes), and the pallette > can be set by the user to any of the Amiga's 4096 colors. Ah, good. > None of the Amiga 3D programs have done too well in this regard, and > the problem is not a lack of objects, but a shortage of people who want > to give out their creations. However, there are lots of user-created > objects out there (some of the ones I've seen are incredibly complex, I am sure many people keep their objects to themselves, just like programmers do with programs they create. Programmers are enough like artists that I would expect the proportions to be the same. I've been looking for objects like mad, and found very few. I've found few animations, too. My point is, most users/buyers of VideoScape find graph paper, EGG and OCT to be very difficult to use to create objects. Certainly this is the reason Aegis plans to market Modeler 3D: VideoScape users have complained. > > ...Allen Hastings stopped creating objects on graph paper > >months ago when his friend Stuart Ferguson wrote this object editing > >program. > > I'm afraid that is completely untrue. I have found very efficient You had once told me you'd been using Stuart's program for some time prior to his showing at BADGE and Aegis, and I incorrectly assumed it was preferable to graph paper. > This posting is a response to a message by John Foust in which he > explains some of the difficulties he had writing a conversion program > for VideoScape 3D and Sculpt 3D object description files. > with his object translation program. Sorry if you had trouble writing > it, but nobody said it was going to be easy! Bringing any commercial product to market is never easy, otherwise everyone would do it, and do it well. More precisely, I had trouble understanding implementation and design choices in both VideoScape and Sculpt. Nowhere did I complain about writing *my* program. :-)
adh@well.UUCP (11/21/87)
In article <5299@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: > > Boy, would I like to see this. The whole game is objects! Not to >mention Sclupt3d's triplane objects! Objects! I wanna to play too! > I'm glad to see how enthusiastic you are about 3D on the Amiga! I'm curious though about what triplane object you are referring to. If you mean the Red Baron's 1917 Fokker Dr1, that is actually a VideoScape 3D object. I created it last May by tracing top and side view drawings from a library book, and then I stuck an ellipsoidal pilot's head (with goggles, leather cap, and grim expression) in the cockpit. If someone has made a triplane object for Sculpt 3D, I would like to see it. By the way, I wrote a utility to convert Sculpt 3D objects into VideoScape files that works nicely. I'm thinking of freely distributing it if anyone is interested... - Allen Hastings
harald@ccicpg.UUCP ( Harald Milne) (11/23/87)
In article <4504@well.UUCP>, adh@well (Allen Hastings) writes: > In article <5299@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: > > Boy, would I like to see this. The whole game is objects! Not to > >mention Sclupt3d's triplane objects! Objects! I wanna to play too! > > > I'm glad to see how enthusiastic you are about 3D on the Amiga! > I'm curious though about what triplane object you are referring to. I got an update for Sculpt3d that had an image of two british triplanes. They look very nice! The planes even have the smear of propwash! Unfortunately, no object on the disk. For $30.00, you will recieve support of 68881 floating point. > If someone has made a triplane object for Sculpt 3D, I would like to > see it. By the way, I wrote a utility to convert Sculpt 3D objects into > VideoScape files that works nicely. I'm thinking of freely distributing > it if anyone is interested... I certainly would be interested. I am also interested in seeing a public domain library of objects. This would really add fuel to the fire! I love the stuff that Leo does, and everybody else for that matter. Not to mention "Infinite Loop". 8^) Great stuff! Keep up the good work! > > - Allen Hastings -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
adh@well.UUCP (Allen D. Hastings) (11/24/87)
In response to John Foust's latest comments on VideoScape: >Do you mean to say "lots of colors" equals "eleven fixed colors, plus fixed >shades of those colors"? My point was that Sculpt does choose a new >palette for the picture, which looks much nicer than a fixed palette. As I said in my previous posting, polygons in VideoScape 1.10 can be set to any of 121 colors (not counting the various surface types such as dull, shiny, luminous, transparent, etc.), and the palette used can be set by the user. Even in VideoScape 1.00, many colorful scenes (such as a sphere with blue, green, red, yellow, and white bands) will look better than in Sculpt 3d's paint mode because there are 56 shades available (achieved through dithering) as opposed to 32. >light to dark, because of the limits of dithered coloring. To be fair, >this is true of any any non-HAM rendering scheme, so this isn't a >particular criticism of VideoScape. Actually, VideoScape 3D 1.10 does support not only Extra Halfbrite mode, but also Hold and Modify mode, and can render a complex 4096 color scene with realistic specular highlights (from multiple variable intensity light sources) in well under a minute. This has been under wraps until now, but since John mentioned HAM I couldn't resist... >To me, the best situation would be both a fixed but user-settable palette >and dithering to get shades. This is what VideoScape 1.10 does (see earlier comments). >no one has explored the use of dither patterns with two colors, instead of >one color and black. They used to squeeze dozens of extra colors from the VideoScape has always used dither patterns with two colors, and never dithers with one color and black in version 1.00. In version 1.10, you can mix any of the basic colors this way. >You had once told me you'd been using Stuart's program for some time prior >to his showing at BADGE and Aegis, and I incorrectly assumed it was >preferable to graph paper. I didn't say that graph paper was preferable. I just said that tracing scale drawings from books is an efficient way of creating real-world objects and is more accurate than "eyeballing it" with the mouse (it was easy to enter the Lotus and the F15 this way, for example). I'm sure I will use Modeler 3D heavily once it is completed, as it is already the most powerful 3D object editor on the Amiga. It will make a great companion to VideoScape. However, Modeler 3D is not due out for a few months, and since some people like John are used to Sculpt 3D's user interface, I have written a program that allows the use of Sculpt 3D as an object editor for VideoScape. The program reads the object descriptions saved in Sculpt's ".scene" files and, taking into account color and texture information, converts them into "3DG1" files for direct use in VideoScape. The program also can produce the new "3DB1" binary format files used by VideoScape 1.10 for high speed loading and compact storage. I plan to upgrade the program to handle objects created by other packages such as Forms in Flight. The program will be included with VideoScape 1.10 and is freely distributable, so look for the Foreign Object Translator (FOT) soon on a BBS near you... - Allen Hastings
adh@well.UUCP (Allen D. Hastings) (11/26/87)
I just wanted to make it clear that my Foreign Object Translator program
currently only converts Sculpt 3D objects into VideoScape objects, and does
not allow you to go the other way (you'll need John Foust's Interchange
program for that and also to handle object formats from other programs). I
originally wrote FOT so that I could use some of the Sculpt 3D objects to
test VideoScape 1.10, and so that the routines could be incorporated in
Modeler 3D (and also so I could use some of those neat geodesic spheres that
Sculpt makes).
By the way I think that the recent trend of sharing object databases
(like the Teapot and Space Shuttle) is great. I did a nice HAM animation of
the teapot as a test of VideoScape 1.10. For those interested, version 1.10
should be shipping in a few weeks (people who already have VideoScape will
probably get it first - it's a $10 or possibly free upgrade). I hope this
clears up any confusion...
- Allen Hastings