kvancamp@ardec.arpa (Ken Van Camp) (09/23/88)
I just got my announcement from Byte by Byte about the
Sculpt-4D upgrade. Trying to decide whether it is worth it to
upgrade, I have a few questions/comments:
(1) Sculpt-4D is apparently faster than Sculpt-3D at rendering and
refreshing the tri-view, but no estimates on how fast were given. Can
someone provide me with some sample ray tracing times comparing the
two programs for the same model? Or at least give a seat-of-the-pants
estimate?
(2) The new features alone do not seem worth the huge price increase
for me. (This is not a flame, just a personal lack of interest in
most of the new features.) What I was really waiting for was texture
mapping, which Eric Graham said he was working on a year ago. My gut
reaction is to wait for 3-Tuple, rather than spending the money on
Sculpt-4D right now. Fred Mitchell says he already has texture
mapping in 3-Tuple, and you can map any IFF file onto a surface. (Has
anybody seen this?)
(3) Upgrade prices are somewhat strange. You can buy Sculpt-4D for
$499.95. Or you can upgrade from Sculpt-3D for $345. (Sculpt-3D only
lists for $100, and you can buy it at the discount houses for about
$70, so go buy it quick and get $150 off the price!) Or you can
upgrade from both Sculpt-3D and Animate-3D for $195. (You can buy
Animate-3D for under $100 at discount, so buy it now and knock off
another $150!) Hmmm.
--Ken Van Camp
ARPANET: kvancamp@ARDEC.ARPA -or- kvancamp@AC4.PICA.MIL
BITNET: (use above through normal gateways)
USENET: uunet!ardec.arpa!kvancamp@UUNET.UU.NET
'Tis better to Shell than to shell out the dough.ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/24/88)
In article <4182@louie.udel.EDU> kvancamp@ardec.arpa (Ken Van Camp) writes: >(2) The new features alone do not seem worth the huge price increase >for me. (This is not a flame, just a personal lack of interest in >most of the new features.) What I was really waiting for was texture >mapping, which Eric Graham said he was working on a year ago. My gut >reaction is to wait for 3-Tuple, rather than spending the money on >Sculpt-4D right now. Fred Mitchell says he already has texture >mapping in 3-Tuple, and you can map any IFF file onto a surface. (Has >anybody seen this?) > Turbo Silver Pro FP-XT6/6000SUX (or whatever they're calling it these days :-) ) has texture mapping available right now. Actually getting the image mapped on the object is a wee bit convoluted (with Turbo Silver), but it's possible. Scott Peterson demoed Sculpt-4D for me in Chicago, and I was pleased. It addresses many of my primary complaints with Sculpt. Rick Unland also seems to like it a lot. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{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
kvancamp@ardec.arpa (Ken Van Camp) (10/12/88)
>I feel that ray tracing is too exotic a process >to be valuable to production on a small machine. Scanline renderers are MUCH >faster and produce virtually the same result. I hope you didn't mean that first statement as strongly as it came out sounding... there are many things that you just can't do with scanline rendering. Nonetheless, I agree that it has been under-utilized on the Amiga. And when it has been utilitized, it has been brain-damaged. Why can't these people do smoothing in scanline mode? It's a lot easier to implement than in ray-tracing mode... > I think they should also offer some kind ascii format of their objects. This >way someone could write a myriad of programs to manipulate te objects which >could supplement the main programs. What's that? You don't read IFF? Script files in Sculpt-3D **do** work, and you can generate the geometry with it (no thanks to the documentation). I had to play around with it quite a bit before I realized what the documentation was missing. The correct way to generate a face (and all its vertices and edges) is with a line like: (x1,y1,z1)-(x2,y2,z2)-(x3,y3,z3)-(x1,y1,z1) That's right, you have to repeat the first vertex! The documentation doesn't make this clear, but I finally figured out that you're just generating edges when you specify coordinate pairs, and then Sculpt-3D checks all the edges and constructs faces only when it finds three connected edges. This (and the fact that it checks every vertex to make sure it isn't a repeat) makes scripts **extremely** slow to load. As I recall, there were also a couple of obvious omissions in the script language -- I think there's no way to set the observer location or target, and maybe one or two others. Anyway, I've given up on the script files and have written some routines that generate the IFF scene files, and they're **much** easier to work with. Since my surface modeler reads ASCII files, and I wrote a program that converts my surface model files into Sculpt-3D scene files, in effect I have what you have asked for: a way of inputting Sculpt-3D data in an ASCII file. It's not finished (currently only writes geometry info), but if you want a copy anyway you can mail me a disk with return postage (P.O. Box 784, Stroudsburg PA 18360). (What's that? You've never heard of my surface modeler? That's because it's just a small feature in a larger, commercial product -- to be released "some time next year".) > What is 3-Tuple? Is it a complete system like Sculpt- Animate? Who is Fred >Mitchell? Has he said anything about reflection mapping? Yes, it is a complete system, written by Fred Mitchell, president of MitchellWare. It hasn't been released yet, but I spoke with Fred after last month's JAUG meeting and he said he had already implemented texture mapping. I'm not sure if reflection mapping is the same as texture mapping, but 3-Tuple sounds to me like a very powerful package. There was actually a "review" in last month's Amiga/World, but it was VERY deceptive and I wouldn't pay much attention to it. (Either Fred lies alot about features, or the copy Amiga/World got was really old, or the reviewer didn't have the slightest idea what he was talking about.) Instead, just use the address on the review to write to MitchellWare and ask for a brochure. It tells much more. --Ken Van Camp ARPANET: kvancamp@ARDEC.ARPA -or- kvancamp@AC4.PICA.MIL BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) USENET: uunet!ardec.arpa!kvancamp@UUNET.UU.NET 'Tis better to Shell, than to shell out the dough.
shf@well.UUCP (Stuart H. Ferguson) (10/14/88)
| >I feel that ray tracing is too exotic a process | >to be valuable to production on a small machine. Scanline renderers are MUCH | >faster and produce virtually the same result. | [ ... ] Nonetheless, I agree that it has been under-utilized on the | Amiga. And when it has been utilitized, it has been brain-damaged. Why | can't these people do smoothing in scanline mode? It's a lot easier to | implement than in ray-tracing mode... The writer obviously doesn't shop around. VideoScape 3D version 2.0, which has been available for five months, does scanline-like rendering (Z-buffering) with smoothing. It uses the Phong shading model and Phong interpolation to render diffuse and specular smoothly shaded objects in HAM mode. The results are quite good and blindingly fast compared to raytracing. Most VS 3D 2.0 ads in magazines have a picture of the Mask, a smoothly shaded face, and its "reflection" in a checkerboard floor, which was rendered in overscan HAM in about 4 minutes on a stock Amiga (no '020 or '881). Forms in Flight II also does scanline rendering with smoothing although it does not support HAM mode. | > I think they should also offer some kind ascii format of their objects. This | >way someone could write a myriad of programs to manipulate te objects which | >could supplement the main programs. | What's that? You don't read IFF? [ ... ] I beg to differ. Sculpt-3D's file format is not IFF, regardless of the fact that it's composed of FORMs and chunks and things. It is not an "Interchange File Format" because it's not documented and therefore cannot be used for data _interchange_. For the same reason, Sculpt's "movie" files are not ANIMs. For an ASCII format, VideoScape 3D's ASCII geometry format is well documented and can be used to create or manipulate objects. With the "Interchange" program, you can convert these files into Sculpt format. With some exceptions, like the limitations on the colors in VideoScape format or the limitations on polygons in Sculpt format, the two formats are reasonably compatable. | --Ken Van Camp Sorry for the possible commercial nature of this posting. Since I have some affiliation with VideoScape 3D, I naturally wish to see misinformation corrected. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@wso.Stanford.EDU)
kvancamp@ardec.arpa (Ken Van Camp) (10/17/88)
Stuart H. Ferguson writes: >The writer obviously doesn't shop around. VideoScape 3D version 2.0, Right - I spoke without thinking. I have not checked out the new versions of VideoScape and FIF. I needed more fiber in my diet, anyway (munch, munch :-). >I beg to differ. Sculpt-3D's file format is not IFF, regardless of the >fact that it's composed of FORMs and chunks and things. It is not an >"Interchange File Format" because it's not documented and therefore >cannot be used for data _interchange_. For the same reason, Sculpt's >"movie" files are not ANIMs. Well, I'm not going to stick foot in mouth again and get into an argument over IFF, but I'll just point out that the Sculpt-3D scene file format *is* documented. I have a copy of the file format and so do hundreds of other people who sent for Grahams's Ray Tracing Newsletters. I assume you are complaining because it was not officially registered with Commodore, in which case you are correct that it is not IFF. But it is documented (correctly), and Interchange and my own software have demonstrated that the format is reliably readable and writable. Meanwhile, Peter da Silva (I spelled it right!) writes: >Sculpt is not a good example of a ray-tracer. > >Why not? Simple... it has only one object: a triangle. If you want a ray tracer of the type you say Sculpt should be, check out C-Light. It is limited to a small set of primitive solids, such as you are suggesting. The results I have seen out of C-Light (based only on the 2 demo disks) are not nearly as impressive to me as Sculpt's results. Why? Because most real-world objects can simply not be broken down into cones, spheres, cylinders, cubes and derived solids. C-Light's pictures look boxy and unrealistic, as the original Juggler did. If you're going to write a solids modeler, you also have to include some kind of arbitrary polyhedron primitive to take care of things that just can't be rendered otherwise. And then to make it powerful enough to handle complex objects, you have to offer boolean operations to handle all the special cases. And in the end, your user interface is twice as complex (which doubles your code size, since let's face it user interface is 90% of the code anyway) and the results aren't any better. As you say, though, rendering times can be reduced dramatically for simple objects like the peacock. But the trend nowadays is toward greater realism in rendering -- what if somebody wanted to ray trace a real peacock? (See this month's issue of IEEE CG&A for some surprisingly realistic ray tracings of natural objects.) For many complex objects that require arbitrary polyhedra, rendering times would increase, not decrease. That's why I think Eric Graham went with triangles, and I think it was a valid tradeoff. OK, let the flames begin. --Ken Van Camp ARPANET: kvancamp@ARDEC.ARPA -or- kvancamp@AC4.PICA.MIL BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) USENET: uunet!ardec.arpa!kvancamp@UUNET.UU.NET "Tis better to Send than to Receive"
bcorrie@uvicctr.UUCP (Brian Corrie) (10/20/88)
My 2-bits on the subject..... Disclaimer - I know little about the details of either of these raytracers, so my comments are on ray tracing in general. In article <4919@louie.udel.EDU> kvancamp@ardec.arpa (Ken Van Camp) writes: Whole buncha stuff deleted about Image File Formats >Meanwhile, Peter da Silva (I spelled it right!) writes: > > >Sculpt is not a good example of a ray-tracer. > > > >Why not? Simple... it has only one object: a triangle. > >If you want a ray tracer of the type you say Sculpt should be, check >out C-Light. It is limited to a small set of primitive solids, such >as you are suggesting. The results I have seen out of C-Light (based >only on the 2 demo disks) are not nearly as impressive to me as >Sculpt's results. Why? Because most real-world objects can simply >not be broken down into cones, spheres, cylinders, cubes and derived >solids. C-Light's pictures look boxy and unrealistic, as the original >Juggler did. True enough. I don't know much about C-Light, but I assume it has polygons ( read triangles = 3 sided polygon ) so the same objects constructed in Sculpt can be constructed using C-Light ( unless my assumption is wrong ). >If you're going to write a solids modeler, you also have >to include some kind of arbitrary polyhedron primitive to take care of >things that just can't be rendered otherwise. And then to make it >powerful enough to handle complex objects, you have to offer boolean >operations to handle all the special cases. See above comment. Almost all ray tracers have a triangle of sorts as a primitive to build up complex objects. Of course Constructive Solid Geometry is nice, but it ain't a peice of cake. > And in the end, your user >interface is twice as complex (which doubles your code size, since >let's face it user interface is 90% of the code anyway) and the >results aren't any better. Interfaces are everything in a user application. > As you say, though, rendering times can be >reduced dramatically for simple objects like the peacock. But the >trend nowadays is toward greater realism in rendering -- what if >somebody wanted to ray trace a real peacock? (See this month's issue >of IEEE CG&A for some surprisingly realistic ray tracings of natural >objects.) For many complex objects that require arbitrary polyhedra, >rendering times would increase, not decrease. That's why I think Eric >Graham went with triangles, and I think it was a valid tradeoff. I think the main complaint Peter is trying to make is Why just triangles. Peter will correct me if I am wrong, I'm sure 8^). Since ray tracing is so CPU intensive, and gets nastier as more primitives are added, If I want a sphere in my scene, I would much prefer 1 sphere primitive to a whole bunch ( Thousands maybe ) of triangles that are an approximation. A sphere is the simplest object of all to intersesct a ray with, so to me using just triangles isn't justified. It is the same with quadric surfaces, bicubic patches etc. They need too many triangles to approximate them. Adding a few simple primitives like spheres, quadrics etc. doesn't increase the comlexity of the code that much, but look at the time savings invloved. On the other hand, I agree that a triangle primitive is necessary to build realistic scenes, but most ray tracers provide both. This allows the flexibility of using both the Sculpt method or the C-Light method to create complex scenes. Of course if C-Light does not provide a triangle or polygon primitive then I agree, it is not feasible to create images of current complexity with it. > >OK, let the flames begin. > See ma, no flames, just some thoughts...... > --Ken Van Camp -- Brian Corrie, University of Victoria, Victoria, B.C., Canada Under the most rigourously controlled conditions of pressure, temperature, volume, humidity and other variables, the organism will do as it damn well pleases. Don't worry, I know nothing of what I babble about.......