I agree with your sentiments Matt, i feel the priority should be
placed solidly on making the code more accessible to 3rd party dev's,
at the end of the day it helps the package live, and Autodesk seem to
have adopted a trend of buying up 3rd party plugins anyway, looking at
CAT for max, NEX for maya, maya had a weekness in modeling, and while
it may have considerable ground to cover, at least the code is loose
enough to allow 3rd parties to fill in the gaps.
if this could be a unified goal it could benefit everyone.
On 10 April 2013 04:24, Matt Lind <ml...@carbinestudios.com
<mailto:ml...@carbinestudios.com>> wrote:
All of the above.
There are parts of the core that are archaic and need to be
updated. Other areas perfectly fine but need somebody to step in
and finish an implementation of an existing feature.
In my opinion, the biggest problem is politics of getting the
issues identified to be addressed. Many of those making the
decisions are not well tuned into the real problems as experienced
in the field and therefore trust a database of reports, or a
voting contest among users who will tend to vote for whatever the
trendy new thing is rather than the bigger picture of what makes
the software better overall. This puts the decision on the
product manager and the last few haven’t exactly been tuned to the
market, which further distorts the decision making process. To
further complicate matters, there are programs like media and
consulting which can pull a developer off a task to address a
client’s need. Clients throwing dollars at autodesk can skew the
application’s development path off course if their needs don’t
align with the rest of the user base.
When a bug is reported and others are able to chime in whether
it’s important or not, the items that often get the most votes
tend to be things that treat the symptoms instead of the problem.
This is partly because end users are primarily artists and do not
understand the technical aspects, and therefore will vote for what
they know which is often a subset of the issues on the table.
This skews voting to favor things which are familiar instead of
things which need to be addressed. The item that could really
deliver positive impact often gets ignored because only one person
in the lot understands it and can see the big picture.
When planning development of an application, you need to answer
questions such as who’s going to use the product, what should the
application do best, does it need to be more portable or more
performance friendly, how much manpower is available to develop
and maintain the product, etc… Many of the criteria are opposing,
which means somebody must make tough decisions, lay down
boundaries and choose which criteria deserve more weight. Those
early critical decisions can have a long lasting impact on the
product for the rest of its useful life. For example, Softimage
was designed to favor animation first. That implies geometry data
structures for modeling and other operations may have to be
designed to be lean and efficient instead of robust as the
overhead for maintaining complex geometry is considerable and
works against performance which is needed to maintain frame
rates. 3DSMax, on the other hand, chose a different approach
which favors plugin development. It encouraged 3^rd parties to
contribute by making an open SDK, but it came at the cost of a
decent animation toolset….which is partly why animation tool
development has been discontinued on the product. In short, no
application can do everything equally well. Some sacrifices need
to be made.
Anyway, the product known as Autodesk Softimage was designed in a
different era with vast resources available under Microsoft rule.
Today’s landscape pales in comparison which can make the product
more difficult to maintain as it can require resources that are no
longer available. That combined with the needs of the market
steering more towards modeling, rendering, and special FX make it
difficult to rework an animation minded software to those needs.
It can be done, but it has to be made a priority – which is the
whole problem as noted above. There’s also a lot more to maintain
today than there was 10 years ago. Changing direction gets more
difficult with each release from the increased inertia.
In my opinion, the next release should be spent improving the
modeling core, operator construction history capabilities and
management, openGL view performance (OpenGL, HQV, and standard
views), data management (handling large quantities of objects),
access to user interface so users/3^rd party developers can get
better information what’s going on within the application (events,
callbacks, mouse/keyboard feedback, communicating with external
apps, …), and better ability to customize the user interface
(access to modify existing views, make our own views, etc..). A
multithreaded UI and SDK wouldn’t hurt either.
Sure, there are very long laundry lists of other things that can
be done, but many of them are dependent on what I just advised.
Want a better 3^rd party renderer? The developer of that renderer
probably needs better access to the internal guts of Softimage to
do that for you, as well as better UI elements to present the
renderer’s features to you such as icons for manipulating lights
and camera features unique to that renderer, or creating nodes for
use in the rendertree, etc…
Matt
*From:*softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>
[mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>] *On Behalf Of
*Sebastien Sterling
*Sent:* Tuesday, April 09, 2013 5:40 PM
*To:* softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
*Subject:* Re: Softimage 2014
If these things are to hard to accomplish for third party people,
then what realistic chance is there that they will ever be
implemented ? is what i want to know, Autodesk don't exactly have
a good track record of treating there customers as a valid source
of input... is there some secret ballot where this stuff gets
decided ?
Also, is the problem that the SDK is just too archaic ? does it
need a complete rewrite ? or are aspects of the code unavailable
or illegal to be changed to/by scripters ? if so does Autodesk
have the ability to make the code available ?
On 9 April 2013 09:27, Eugen Sares <softim...@keyvis.at
<mailto:softim...@keyvis.at>> wrote:
Oil on my fire.
That cluster SDK restriction really really sucks. It is the reason
why there never were any good topology/modelling addons from 3rd
parties, which leads to stagantion if there aren't any new
"factory" modelling tools brought also.
In 3ds max or Maya, all kinds of plugins are available, completely
natural. Not so in Softimage.
The few ICE modelling tools like Cap are nice, but slow. Native
code is nice and fast.
Luc-Eric mentioned once, ICE was meant to be the "new SDK", that's
why this cluster update mechanism has been implemented for ICE
already.
Imho that's an excuse. ICE complements the SDK, it is NOT a
replacement!
Cluster updates should be supported by the SDK as well, even if it
is complicated, and thus somewhat of a challenge for a 3rd party dev.
Try us! Provide a good code example alongside, and we'll do fine.
Be wise and do it. Please.
Am 09.04.2013 09:08, schrieb Piotrek Marczak:
Just give us proper SDK and let community do the rest.
"
Softimage currently does not fully support custom topology
operators. The problem is that any cluster or cluster property
will not properly update when a topology operator adds or
removes points that belong to the cluster. In the worst case
Softimage may crash. Hence custom topology operators should
only be used in the more limited scenario of objects that do
not have any clusters. Once the geometry is ready it would be
possible to freeze the object to remove the custom topology
operators (but leave the result of their evaluation), then to
add the clusters and other operators.
"
??
2013/4/8 olivier jeannel <olivier.jean...@noos.fr
<mailto:olivier.jean...@noos.fr>>
They do modo for birds ?
Le 08/04/2013 20:27, pete...@skynet.be
<mailto:pete...@skynet.be> a écrit :
I’m pretty sure there’s neither gentlemen nor ladies on
this list.
as for Modo vs SI – a little bird tells me there’s more
important issues at stake than selection.
*From:*Rob Chapman <mailto:tekano....@gmail.com>
*Sent:*Monday, April 08, 2013 3:35 PM
*To:*ron...@toonafish.nl <mailto:ron...@toonafish.nl> ;
softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
*Subject:*Re: Softimage 2014
now now gentlemen, there are ladies present on the list too!
lets just say , when it comes to apps and selection
methods, leave the race courses for the race horses..!
:)
On 8 April 2013 15:32, Toonafish <ron...@toonafish.nl
<mailto:ron...@toonafish.nl>> wrote:
...but I prefer brunettes with bigger boobs. If you get
the idea J
That's prolly because bigger boobs aren't obstructed so
much, so they are much easier to select in shaded mode ;-)
- Ronald
