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> 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 3rd 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 
> 3rdparty 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] *On Behalf Of *Sebastien Sterling
> *Sent:* Tuesday, April 09, 2013 5:40 PM
> *To:* 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> 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>****
>
> They do modo for birds ?
>
> Le 08/04/2013 20:27, 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 <tekano....@gmail.com> ****
>
> *Sent:* Monday, April 08, 2013 3:35 PM****
>
> *To:* ron...@toonafish.nl ; 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> 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****
>
>  ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>

Reply via email to