As far as I see, Softimage tools are sometimes design by programmers, for programmers. Like the UV packing spacing parameter. It has no use at all. It should be defined as it is in UVLayout, pixels, or similar, it must be understandable, and USABLE in production. Me as a game artist is interested in the minimum distance between UV islands, and not some abstract number that has no visual meaning to me.
And so on. I hope, that after the next release the new developer team will focus on fixing these issues. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eugen Sares Sent: Wednesday, April 10, 2013 9:21 AM To: softimage@listproc.autodesk.com Subject: Re: Softimage 2014 My point exactly, Sebastien. About that SDK cluster update thing in custom topo operators: I assume it's basically about tracking array indices carefully caused by the topology changes and shifting cluster indices accordingly. Array index magic, so to speak, with just basic math involved. A sort problem, in other words. Sounds like some good legwork, but nothing out of reach. Should something like this be in the way of everything good to come from 3rd parties in the modeling department? Am 10.04.2013 09:02, schrieb Sebastien Sterling: 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/3rd 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 3rd 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] 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 <mailto: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
