#3dsr4 modeler
22 messages in this thread
Bob/Jonus;
>>Recently we made a tough decision regarding 3D Studio Release 4. We decided
to drop the patch modeler from Release 4…<<
Is there any chance that once the patch modeler is adequate for
productions (assuming that it does become adequate) that it will be
offered as a freebee due to the promise of it in the first place.
Just asking <g>.
Your's is the most sane response request to this disappointing news.
If Adesk has it's senses about itself it would comply with this
request. Maybe with a few more weeks/months development it will have
a product that will meet standards. The best thing to do is to
modify the official statement. They should say, " we will make it
available to all those R4 registered via a free plugin when
released." This, I think, would stop all the whining about it"
Don't hold your breath. This sounds similar to the situation that
arose with the issue of Renderman compatability. Except that time ,
it was Yost Group, not a 3rd party developer, whose code failed to
meet Adesk quality control. RIB output died a quiet death hidden away
in a dark corner.
I suspect spline modeling will be addressed, by Yost group directly,
but not until R-5. You may have noticed Yost responding to several
spline modeler questions with "hey, . . . we're busy with R-5
developement" . This is probably for two reasons:
1. To distance themselves from the current spline modeler fiasco which
they had nothing to do with.
2. I'd guess that they are shooting for yet another record short
development cycle to get R-5 out even faster than R-4 to keep
everyone amazed and satisfied. I'll wager this will include new
modeling technology.
Even without the spline modeler, at only $250 for the upgrade, R-4 is
a tremendous value – you'd pay that much for just one IPAS plug-in —
and look at all the cool features they are offering.
Whiners — compare compare the 3DS upgrade to the withered remains of
Topas Pro, what do Topas users get for an upgrade this year ? A
paltry incremental improvement consisting of a bitmap GUI with
presets in Bevel, animation of the perspective match feature (way
cool, but it should have been animatable in the first place), and a
library of simple motions any idiot could create with five minutes
effort for each , plus some bug fixes and flic player tweaks. Granted
they only charge $25 bucks, but I'd be alot more satisfied paying $250
for some real technology.
<< that it will be offered as a freebee due to the promise of it in
the first place. >>
I don't think so. When there is any word regarding the future of the
patch modeller, be sure that you'll see it here.
HiYa Jonas,
I have to agree with ADESK's decision to drop the patch modeler at the last
minute. I have not seen R4, but from the decriptions I've read, I think that a
lot of folks here were thinking that the patch modeler was more than it really
was in the first place. That is, "spline modeling" is a very broad term of
which a Bezier Patch modeler using 2 templates is just a very small part. So
honestly, I don't feel that folks will be missing *that much* with the decision
to leave it out…especially if they have YG Disk # 6. Obviously, there must
have been some strong reasons to omit it, perhaps far in scope beyond *just*
the current state of development of the plug-in. They could have just delayed
or thrown it in, and dealt with the possible flack after-the-fact. I actually
have to respect them, in this case, for pulling the plug now….Seems like most
people would have paid $295 *just* for an IK plug-in *alone*, and thought it
was a pretty good deal at that. I can understand some people being upset,
though….strictly in principle.
BILL
Hi Bill,
<< I can understand some people being upset, though….strictly in principle.
>>
Yup.. I've been forwarding all of these threads to all involved..
jonas[adesk]
I'll hope for now that they take some of your suggestions from/descriptions of
other packages for the next rollout (spline-wise, at least :^).
John Stetzer
JWS
<< I'll hope for now that they take some of your suggestions from/descriptions
of other packages for the next rollout (spline-wise, at least :^). >>
R5 maybe ? <g> Changing 3DS over to spline-based modeling/editing/animation
surely is no easy task, if they intend to do that in any future version. There
are very few companies actually, that have really done this well. I personally
would rather see it done very well, or not at all….and continue to use the
present tools & plug-ins.
Regards,
BILL
Bill it looked ok to me.
As I said, I've never used it or even seen it. But if AD feels it's not right
enough to omit it, I respect that MUCH MORE than shipping it….and then making
excuses. The latter would be more offensive to me personally.
BILL
I think you could be right about this. we all want the best tools and some of
us can
get down right uptight [me]. My ideas and overviews have been voiced regarding
Ipazs and now it is time to get back to work and push the software even more.
Now if I can only fine that honey jar, and my tail….
hope you are doing well,
-Brandon
Very astute observations, Bill. It shows what a strong committment Autodesk
has to only delivering robust production solutions to their (our) customers. I
personally feel that it took a lot of guts to make the decision to shelve it.
Most companies I know would've patched something like that up and shipped it
anyway, to avoid the eventual complaints.
The IK package (along) is so deep that I'd be amazed if anyone exploited all
its potential within the first 6 months of using it. That, along with the
scripting language, completely alter the context of producing animations. (I
don't think that most folks have comprehended how much potential those two
modules hold yet.)
– G
<< Most companies I know would've patched something like that up and shipped it
anyway, to avoid the eventual complaints. >>
Yes, unfortunately most companies probably would have. I'm surprised, as I'm
not crazy about most big dominating companies. But I do respect "you can't have
it at all", as opposed to shipping it and making excuses after the fact. Even
worse, perhaps trying to convince one that *it is* OK. That's the path many
software companies have taken, and it's very offensive. I think they made the
right call, if they felt the s/w was not right in some way.
BILL
Right on.
– G
Gary –
>>Most companies I know would've patched
>>something like that up and shipped it
>>anyway, to avoid the eventual complaints.
I agree with the philosophy. I think it's great that Adesk/Yost stays true to
the concept that 3DS has to be reliable and solid for production animators like
myself.
>>The IK package (along) is so deep that
>>I'd be amazed if anyone exploited all its
>>potential within the first 6 months of using
>>it. That, along with the scripting language, completely
>>alter the context of producing animations.
I like hearing that. I'll certainly dig in on those areas specifically. I'm
getting R4 this coming week.
On a related issue, one of our fellow forum members wrote a thread on "Why I
won't upgrade." I wanted to mention a few of my concerns about the myriad 3DS
tools that have been broken out into IPAS routines and (sometimes) sold
separately:
Common usefulness of many of the IPAS routines – can't some of these be
incorporated into 3DS itself? Are all the features in Yost or non-Yost IPAS
routines forever banished from the feature list of 3DS? Who thinks that
optimize or glow is something only a few users want? I thought IPAS was more
for old-time movie IXPs and sun positioner PXPs than something like "TWIST".
Performance and bugs is my biggest beef: If it's not built into the core of
3DS then it can't take advantage of other new features of 3DS. For example,
Digimation's Bones IPAS can't work with the IK IPAS. This situation is going to
become worse as more of the core needs of 3DS users are subverted into
"add-ons".
Also, interactive bugs between various routines has got me to where I cringe at
using non-Yost IPAS routines in production work. For example, the Digimation
magic IPAS is great, but if you keyframe-move a MAGIC4 box around and try to
field render it, it won't move. And no matter what you do, Magic won't field
render, the particles stay in the same place on both fields. SPURT and
FIREWORKS work great in field mode, why doesn't MAGIC? According to Digimation
president David Avgikos, it's because no one at the Yost group is showing
developers examples of how this is done. But meanwhile, back at my animation
studio, I'm banging my head against the wall as I look at 2 days worth of
rendering that's useless (not due to non-fielding, but the inherent
box-doesn't-move-in-field-mode bug)! In the end, I have to test everything on
my own time and make a "IF-THEN" list to follow for production work. This is
extremely aggravating!
Cost is another factor. I don't mention it to complain, just to say that if it
costs more for Autodesk to just include certain of the most-useful IPAS
routines, than I'm willing to pay more. It will help greatly with the expected
competition from Lightwave and it's built-in features that are IPAS for 3DS
users.
Thanks for reading these thoughts, and thanks again for 3D Studio. Did I
mention that it's my full-time gig now?
Best regards,
Jim
Hi Jim,
<< According to Digimation president David Avgikos, it's because no one at the
Yost group is showing developers examples of how this is done. >>
.. field data can be found in the FieldInfo struct documented on pg. 38 of the
IPAS3 SDK. Also, the stars example that shipped with the IPAS3 SDK uses this
struct.
jonas[adesk]
>>.. field data can be found in the FieldInfo
>>struct documented on pg. 38 of the IPAS3
>>SDK. Also, the stars example that shipped
>>with the IPAS3 SDK uses this struct.
I don't have the SDK, but I'm going to call David and discuss this with him. I
don't mean to get in the middle of something I didn't take part in, but now
it's affecting my work and I want to know the truth.
Thanks,
Jim
As Jonas said, the field rendering structure is well-documented in the SDK.
Re your larger issues, as you know I can't comment on future development. That
said, it's amazing to me how little credit many of the folks here on the forum
give my group for being attentive to the needs of the future. Heck… we were
farsighted enough in 1988 to develop 3DS in the first place. The folks who
think that we're sitting on our laurels and not innovating for the future are
"as wrong as wrong can be".
– G
Gary:
>>As Jonas said, the field rendering
>>structure is well-documented in the SDK.
Ok, I'm going to go back and ask for a better reason from Digimation. I was
telling what I had been told… I don't have the R3 SDK.
>>Re your larger issues, as you know
>>I can't comment on future development.
Ok, ok, I'll be patient and follow along.
>>That said, it's amazing to me how little
>>credit many of the folks here on the
>>forum give my group for being attentive
>>to the needs of the future.
Well, it's easy for us to get jaded, I guess…
>>Heck… we were farsighted enough in 1988
>>to develop 3DS in the first place.
Indeed, I agree.
>>The folks who think that we're sitting on our
>>laurels and not innovating for the future
>>are "as wrong as wrong can be".
Very well, I'll look forward to 3DS' future with the rest of the world of 3DS
users. Thanks for your comments.
Jim
Are you any relation to Brett???
<< …it's amazing to me how little credit many of the folks here on the forum
give my group for being attentive to the needs of the future. >>
Me too.
Your insight is ALWAYS welcome here.
– G