Forum unknown
· Videophile
#Animation Standard?
15 messages in this thread
Well I felt it was time to get on my soapbox and complain about the lack of
3D rendering and Animation standards for the Amiga. The only 3D rendering
program that I have at this time is Sculpt 3D, and I've been wanting to get a
Animation program, but don't think I will until some kind of standard is set
by the industry. I have the Director, but it will only animate frames created
with VideoScape 3D. So if I want to use animation in my Director scripts,
then I have to purchase VideoScape. But then if I want to create animations
with Sculpt 3D, then I have to get Animate 3D also. I haven't seen or heard
too much about Silver, but I imagine they use a different format also. Then
if I do purchase VideoScape, then I would also have to purchase Interchange,
so I could port my scene's between VideoScape and Sculpt. So the bottom line
is this:
IT REALLY SUCKS, and if the developer's at Aegis, Byte-by-Byte, Impulse, The
Right Answers Group, and elsewhere can't get together and create a standard,
then they are going to hurt the future of the Amiga and animation. I, for
one, will absolutely refuse to purchase a Animation package until some kind
of standard is set. So its going to hurt you until you get something going in
that direction. So, now I feel better in getting this off my chest, but I can
only hope that the developer's out there are listening.
John Gager
Woa, slow down John. Lets break down some of what you've said.
"I have the Director, but it will only animate frames created with VideoScape
3D. So if I want to use animation in my Director scripts, then I have to
purchase VideoSape."
The Director animates using a page flipping technique. That means that you
can create animations by displaying individual pictures, in succession.
There is a utility in The Director to break a Vscape ANIM file into pieces
for this page flipping. If you want to use animations created with Vscape
with the Director, then you obviously have to get Vscape. But you can create
animations using Dpaint or anything that creates pictures and use Director to
flip through them.
"But then if I want to create animations with Sculpt 3D, then I have to get
Animate 3D also."
Not true. Animate 3D is an environment that interfaces with Sculpt 3D to
allow you to create animations (successive pictures) easily. You can create
animations without it though. You can create the individual pictures using
Sculpt, and then page flip them using the Director, or the PD software from
Byte by Byte.
Yes, Silver uses a different method for creating it's animations. But, as
with Sculpt, you an save the pictures as individual IFF pictures, and animate
them using the Director, or use the Byte by Byte software to create the
required compression. But this would be absurd, since you would have Silver
already, which creates the required compression.
"Then if I do purchase VideoScape, then I would also have to purchase
Interchange, so I could port my scene's between VideoScape and Sculpt."
This has nothing to do with displaying the animations or pictures that these
products produce. Each program stores data that represents the objects you
create differently. But, for any given scene, or frame, each an produce an
IFF image. Now, if you want to be able to use objects you create with Vscape
in Sculpt and vice versa, then you need something like Interchange.
Now you are confusing two different issues in your message. You want a
standard format for the animations, and you also want a standard format for
Woa, slow down John. Lets break down some of what you've said.
"I have the Director, but it will only animate frames created with VideoScape
3D. So if I want to use animation in my Director scripts, then I have to
purchase VideoSape."
The Director animates using a page flipping technique. That means that you
can create animations by displaying individual pictures, in succession.
There is a utility in The Director to break a Vscape ANIM file into pieces
for this page flipping. If you want to use animations created with Vscape
with the Director, then you obviously have to get Vscape. But you can create
animations using Dpaint or anything that creates pictures and use Director to
flip through them.
"But then if I want to create animations with Sculpt 3D, then I have to get
Animate 3D also."
Not true. Animate 3D is an environment that interfaces with Sculpt 3D to
allow you to create animations (successive pictures) easily. You can create
animations without it though. You can create the individual pictures using
Sculpt, and then page flip them using the Director, or the PD software from
Byte by Byte.
Yes, Silver uses a different method for creating it's animations. But, as
with Sculpt, you an save the pictures as individual IFF pictures, and animate
them using the Director, or use the Byte by Byte software to create the
required compression. But this would be absurd, since you would have Silver
already, which creates the required compression.
"Then if I do purchase VideoScape, then I would also have to purchase
Interchange, so I could port my scene's between VideoScape and Sculpt."
This has nothing to do with displaying the animations or pictures that these
products produce. Each program stores data that represents the objects you
create differently. But, for any given scene, or frame, each an produce an
IFF image. Now, if you want to be able to use objects you create with Vscape
in Sculpt and vice versa, then you need something like Interchange.
Now you are confusing two different issues in your message. You want a
standard format for the animations, and you also want a standard format for
<Continued>
Now you are confusing two different issues in your message. You want a
standard format for animations, and you want a standard format for the
objects that these programs create. The first is valid, the second is not.
Standard for animations formats, this is the final compression that creates
one animation file from the individual frames, or pictures:
Here there should be a standard. I know of 4 different compressions used
by VideoScape, Sculpt 3D/Animate 3D, Silver, and Animators Apprentice. Each
one takes IFF pictures (frames) and uses a different technique to compress
them for animations. Here a standard would be good, but the only real
benefit for now, would be to have just one Player utility for all animations.
Your second point which is being confused with the first, is your desire for
a standard in object data. This is just undoable. Each program stores it's
data internally (the data that represents the 3D objects) differently. If
all used the same format, then all would have the same capabilities. This
would lend to moving objects from one program to another easily, without a
middleman. BUT, each program would virtually be identical….but as you have
seen, they are not. They differ in abilities vastly. To attempt to create a
standard in object data would be futile, unless of course, every program is
given the same ability as the rest. For instance, Vscape supports polygons
with N number of vertices, 1,2,…,N number of points per polygon. It is
also limited to a fixed 11 colors, supports no reflections, no transparency,
is not ray-traced, and not HAM. Sculpt only supports polygons of 3 vertices,
has transparency and reflections, is ray-traced and supports HAM. Silver
supports what Sculpt does, also supports true refraction of light through
glass, texture mapping, stencils, more flexible reflections and mirror
values, etc.
As you can see, each is geared towards different results. For each to have
compatible object formats would require putting limitations on the more
capable products. This type of standardization is not needed, nor desired.
<Continued>
Now you are confusing two different issues in your message. You want a
standard format for animations, and you want a standard format for the
objects that these programs create. The first is valid, the second is not.
Standard for animations formats, this is the final compression that creates
one animation file from the individual frames, or pictures:
Here there should be a standard. I know of 4 different compressions used
by VideoScape, Sculpt 3D/Animate 3D, Silver, and Animators Apprentice. Each
one takes IFF pictures (frames) and uses a different technique to compress
them for animations. Here a standard would be good, but the only real
benefit for now, would be to have just one Player utility for all animations.
Your second point which is being confused with the first, is your desire for
a standard in object data. This is just undoable. Each program stores it's
data internally (the data that represents the 3D objects) differently. If
all used the same format, then all would have the same capabilities. This
would lend to moving objects from one program to another easily, without a
middleman. BUT, each program would virtually be identical….but as you have
seen, they are not. They differ in abilities vastly. To attempt to create a
standard in object data would be futile, unless of course, every program is
given the same ability as the rest. For instance, Vscape supports polygons
with N number of vertices, 1,2,…,N number of points per polygon. It is
also limited to a fixed 11 colors, supports no reflections, no transparency,
is not ray-traced, and not HAM. Sculpt only supports polygons of 3 vertices,
has transparency and reflections, is ray-traced and supports HAM. Silver
supports what Sculpt does, also supports true refraction of light through
glass, texture mapping, stencils, more flexible reflections and mirror
values, etc.
As you can see, each is geared towards different results. For each to have
compatible object formats would require putting limitations on the more
capable products. This type of standardization is not needed, nor desired.
<Continued>
Please don't take my message(s) the wrong way. Many people may have the same
feelings you expressed. I just wanted to attempt to clarify the issue.
Note, to anyone else reading this message(s), I am not recommending one
program over the other. For the sake of emphasis I may have left out many
features supported by each program, in fact, I know I did.
Responses are welcomed.
John, I hope I made some sense. <grin> Sorry for the long winded messages,
but it couldn't have been answered in less space. 🙂
Regards, GreG
Silver 1.1 is unusable, as far as I'm concerned. It is prone to guruing with
very little urging. The user interface is poor beyond belief; it handles
memory very badly; some operations give you no indication that they have
occured at all, so maybe you did, and maybe you didn't. And since other ops
depend of you getting THOSE doen right, well, fooey. I hope that the new
Silver is better – but in the meantime, no way. I waited what felt to me like
a long time before looking into the various trace packages. Still in their
infancy, I guess. Back to DPaintII. <grin> –Ben–
Ben, Sorry, don't know what functions you are referring to when you say that
there is no indication if they occured or not. I'm not going to debate with
you. You are entitled to your opinions, as I am to mine. I will be the
first to admit that 1.1 was not very usable. But not for the reasons you
cited.
As I suggest to many people, take a look at the various packages available
and make your own decisions. If you want input on indiviual packages, I'd be
happy to help. As to whether Silver is usable or not, take a look at
CRYSTL.ARC in DL6. I composed that scene in less than five hours….which
includes creating the pictures that are mapped onto several of the objects.
Note however, it was created with Silver 2.0.
GreG
Um, the one that comes to mind immediately is the one after you bind a null
to a sphere… remember that problem? The next thing you do is to select
another action… so cursor turns blue for action one on (sorry, I've
forgotten the terms already) then you click on sphere and null (in opposite
order) then select action one again, cursor turns red again; now, you select
action two… bind? tie? transfer? I forget. Anyway, no indication of
anything to the user there. And I managed to guru the darn thing more than
1/2 the times I tried to use it. I *did* finally get it to work, after
calling impulse, and finding out that it cannot use the ram: device (Are you
listening, andy???) but must use a disk instead; and that it MUST have the
disk containing the iff image in the machine when it does the job… which is
unusual, to say the least, in the amiga – no requesters prompting you for the
correct disk, or anything like that. I did d/l crystal; it's beautiful.
–Ben–
Ben, the GROUPing function does tell you that is in operation. When seleted,
the cursor turns Blue. Then the objects to be grouped are selected in the
hierarchical order you want. That produces visible links from object to
object, as well as changing the objects color. When done, select GROUP again
to signify an end of the operation, and the cursor truns red again. Thinking
about it a bit, there are several actions which produce a minimal amount of
"it's done" messages. But so do other software packages.
Nonetheless, it's trivial now. Silver has been gutted and reworked. You
will be happy to hear that a message is printed in the title bar telling you
what mode you are in, as well as supplying other required info.
Also, you say it's unusual for it to REQUIRE that a picture is on a disk
while it's rendering. Not unusual at all IMHO. If I was using 10 pictures
for a scene I wouldn't want them loaded into memory all at once, just when
they are needed. BUT, it should tell you when it can't find a picture.
Regards, GreG
Ben, the GROUPing function does tell you that is in operation. When seleted,
the cursor turns Blue. Then the objects to be grouped are selected in the
hierarchical order you want. That produces visible links from object to
object, as well as changing the objects color. When done, select GROUP again
to signify an end of the operation, and the cursor truns red again. Thinking
about it a bit, there are several actions which produce a minimal amount of
"it's done" messages. But so do other software packages.
Nonetheless, it's trivial now. Silver has been gutted and reworked. You
will be happy to hear that a message is printed in the title bar telling you
what mode you are in, as well as supplying other required info.
Also, you say it's unusual for it to REQUIRE that a picture is on a disk
while it's rendering. Not unusual at all IMHO. If I was using 10 pictures
for a scene I wouldn't want them loaded into memory all at once, just when
they are needed. BUT, it should tell you when it can't find a picture.
Regards, GreG
Um, the one that comes to mind immediately is the one after you bind a null
to a sphere… remember that problem? The next thing you do is to select
another action… so cursor turns blue for action one on (sorry, I've
forgotten the terms already) then you click on sphere and null (in opposite
order) then select action one again, cursor turns red again; now, you select
action two… bind? tie? transfer? I forget. Anyway, no indication of
anything to the user there. And I managed to guru the darn thing more than
1/2 the times I tried to use it. I *did* finally get it to work, after
calling impulse, and finding out that it cannot use the ram: device (Are you
listening, andy???) but must use a disk instead; and that it MUST have the
disk containing the iff image in the machine when it does the job… which is
unusual, to say the least, in the amiga – no requesters prompting you for the
correct disk, or anything like that. I did d/l crystal; it's beautiful.
–Ben–
Ben, Sorry, don't know what functions you are referring to when you say that
there is no indication if they occured or not. I'm not going to debate with
you. You are entitled to your opinions, as I am to mine. I will be the
first to admit that 1.1 was not very usable. But not for the reasons you
cited.
As I suggest to many people, take a look at the various packages available
and make your own decisions. If you want input on indiviual packages, I'd be
happy to help. As to whether Silver is usable or not, take a look at
CRYSTL.ARC in DL6. I composed that scene in less than five hours….which
includes creating the pictures that are mapped onto several of the objects.
Note however, it was created with Silver 2.0.
GreG
Silver 1.1 is unusable, as far as I'm concerned. It is prone to guruing with
very little urging. The user interface is poor beyond belief; it handles
memory very badly; some operations give you no indication that they have
occured at all, so maybe you did, and maybe you didn't. And since other ops
depend of you getting THOSE doen right, well, fooey. I hope that the new
Silver is better – but in the meantime, no way. I waited what felt to me like
a long time before looking into the various trace packages. Still in their
infancy, I guess. Back to DPaintII. <grin> –Ben–
<Continued>
Please don't take my message(s) the wrong way. Many people may have the same
feelings you expressed. I just wanted to attempt to clarify the issue.
Note, to anyone else reading this message(s), I am not recommending one
program over the other. For the sake of emphasis I may have left out many
features supported by each program, in fact, I know I did.
Responses are welcomed.
John, I hope I made some sense. <grin> Sorry for the long winded messages,
but it couldn't have been answered in less space. 🙂
Regards, GreG