10% price hike on 3dsmax/maya (UK)

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Display Modes
  03 March 2013
The problem Max and Maya and SI have is that they're mature enough to struggle for new features that justify the upgrade.

I can only speak for my own experience, but for the work I've been doing more of lately - motion graphics/broadcast/events animations older versions would have been pretty good.

Nitrous is marginally useful, but some of the free third party shaders (Xoliul?) look like they do a much better job of shadows and don't require that.

A good portion seem to be Autodesk breaking things (I don't know when viewport backgrounds panning got broken, but seems to have been flakey for a while)

Ditto vertex color map support in Nitrous, or texture map sizes in Nitrous, or Reactor or caddies.

There's only so many times you can fix what you broke, or bundle a plugin the user already has before they go hang on, what am I paying you for?
  03 March 2013
actually there is a LOT more room for new features and also improvement from old stuff.

if you just check out stuff that 3rd party people are creating.. is there no reason that AD actually can;t offer anything on pair with those with all those resources?
but now good hair solutions, fluid simulation solutions and to mention rendering solutions are all coming from 3rd party teams.

so I really think that there is a lot of room for new features and implementing old ones, not to go into details right now, but honestly it is financially better to provide as low as possible support to get most out of subscriptions with as little investment as possible and then let others to invest in R&D in forms of 3rd party addons that will need main programs anyway.

ok makes sense, but it does slow down main application development... I wouldn't be surprised if we start getting new viewport modes as 3rd party solutions and original viewport remains as something forgotten and never used... like software rendering from
main applications.

so again, there is a lot of room to work on main applications but AD choose another recipe: invest as little as possible get most money as possible and let 3rd party do new features and R&D. that wouldn't be so bad if they actually cut price for main software application which really is becoming only development platform and others are making tools for it...

Fabric Engine anyone??

Need some help with rendering an Redshift project?
  03 March 2013
Sure, there's always room for improvement, but it's whether users feel it's worth the hassle and cost of maintaining upgrades or just stick with a current version.

That they now want to charge 70% new seat for a single upgrade makes no financial sense for a lapsed user.

Autodesk make a terrible job of specialising - it's usually outdated (no progress on modifier stacks, the abominably slow blobmesh code, particle flow abandoned for a good few years)

Or they focus on 'how crap the last version was' - that doesn't really thrill me, it just demonstrates how bad the last version was.

I can only speak from my own experience, but there's very little in the base Max package that I'd miss if I went back 4 versions - I'm just not seeing much return on my subscription, which is why I let it lapse last year.
  03 March 2013
Originally Posted by fuss: I wouldn't be surprised if internally Autodesk already decided to close their Media and Entertainment branch and were now just trying to squeeze out as much money from their existing customers as possible over the course of the next few years before they finally axe it. Mind you, it's just pure conjecture on my part, but it might be worth considering if you heavily rely on their products.
That is precisely what they did with Combustion 2008...milked it for years with no updates, and kept selling a dead product. When all they do is add on a $160 modeling plugin (for Maya), and then charge $2800 to upgrade...that's pure greed right there.

Look at Max. There was already a free PhysX plugin for Max. All they did is interface technology NVidia had already developed (iRay, PhysX hard and soft body dynamics). Wow.

When they added Toxik to the Maya and Max toolsets, it initially looked like a good value. They basically killed Toxik and gave the dead result to customers...kind of like giving a family member that old pc (on it's last leg) for a Christmas present. They look at the new one you treated yourself too, and feel all warm inside because of your generosity.

Last edited by AbnRanger : 03 March 2013 at 04:27 PM.
  03 March 2013
Originally Posted by Steve Green: That they now want to charge 70% new seat for a single upgrade makes no financial sense for a lapsed user.

It's pretty much just extortion. It does nothing to benefit the user. It's purely designed to scare people away from letting their subscriptions lapse. Now that I had to let mine lapse for financial reasons AD would have to come out with some pretty extraordinary new features to convince me to pay that kind of money for an upgrade. I always thought subscription was worth the money, but these small incremental upgrades won't convince me to pay the penalty to get back on it. It's a bad policy driven purely by greed.
  03 March 2013

The first price hike a couple of years ago was akin to a stamp on the toe with no explanation. The next was a punch to the gut with some sweet talk to confuse our feelings, followed by threats to keep us from leaving. Now it's a sharp slap to the face to show who's the daddy. They might give us some gifts but most will be stuff we have little use for and quite likely broken. We know the relationship is only one way but leaving would take considerable time, effort and expense.

...or is that too dramatic?
  03 March 2013
Originally Posted by fuss: I wouldn't be surprised if internally Autodesk already decided to close their Media and Entertainment branch and were now just trying to squeeze out as much money from their existing customers as possible over the course of the next few years before they finally axe it. Mind you, it's just pure conjecture on my part, but it might be worth considering if you heavily rely on their products.

I know such speculations are no good to us users and ADSK m&e, but that's exactly what I'm fearing for some time too. Because that's a very repetitive business pattern you see all the time. (Look at: The conventional hard disk business)

Let's just hope that whatever happens, the products end being further developed by serious innovation driven software companies.
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein
  03 March 2013
[EDIT] .. already regret I posted.

Last edited by kees : 03 March 2013 at 07:19 PM.
  03 March 2013
Most people here are probably aware about why your job at ADSK as a dev is not easy. For those who aren't this can help http://area.autodesk.com/blogs/chri...rtechnical-debt

I don't believe it can be downplayed as dooms day fear spreading. Everybody is in the business of meeting others expectations. People communicate here and try to understand what it's about. It's normal for people to get upset when prices increase for a tool they rely on, especially when these apps are increasingly buggy etc.

Just like it was normal to get upset when combustion got discontinued, toxik became bundleware, smoke, max, maya became what they are today. They all are a mess of million lines of 20 year old code you have to wrestle with every day. It's sad because I believe you guys could pull out amazing things if your managers had the guts to consolidate apps and start out for the next big thing.

Edit: The thearea blogpost above I linked to cannot be accessed for some reason. Other blogposts seem to work fine. A temporary thing for sure.
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein

Last edited by mustique : 03 March 2013 at 11:05 PM.
  03 March 2013
Originally Posted by kees: [EDIT] .. already regret I posted.

too late, it arrived in my inbox!


youtube channel:-

"zero stones - zero crates"
  03 March 2013
The blogpost of Christopher Diggins cannot be accessed so I copy and pasted this interesting read from google chace below:

Manny Lehmanís Law
A well-known occurrence in software development is that as software evolves it structure deteriorates. This is called Manny Lehmanís law:
"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it." ó Meir Manny Lehman, 1980

The Technical Debt Metaphor
Ward Cunningham first used a metaphor of debt to describe how certain software development practices can accelerate the deterioration of software in an experience paper for OOPSLA 92:

"Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise." - Ward Cunningham, 1992

The Impact of Technical Debt
Since technical debt means an increase in overall system complexity this results in an increase in:
number of defects
defect complexity
defect fix time
cost to implement new feature
cost to address technical debt
The last point should drive home just how appropriate the debt analogy is, since like financial debt, technical debt will compound over time until it cripples development!

Kinds of Technical Debt
Generally speaking technical debt can be anything during the software development process that slows down a developerís productivity. For example a bug fix in one module may have unintended consequences in other modules because previous work caused a tight coupling between the two modules; or perhaps removing a feature takes far longer than expected because the code is scattered among multiple modules due to poor code cohesion.

Technical debt can be categorized in the following types:
Process Debt Ė Processes become more complex and inefficient over time. Examples include builds, automated tests, check-ins, reviews, bug logging, bug tracking, etc.
Code Hygiene Debt Ė Examples included duplicated code, dead code, inadequate documentation, monolithic classes, inconsistent style, and cryptic symbol names.
Architectural Debt Ė Examples include high coupling of components, poor cohesion, poorly understood modules and systems, redundant systems, and unused systems.
Knowledge Debt Ė As products grow in complexity and team members come and go knowledge that is not written down gets lost. It takes longer for developers to become familiar with the inner workings of different systems. This can lead to cases where existing features are re-implemented.

When Technical Debt approaches Bankruptcy
Some signs that your project is nearly bankrupt with technical debt:
Fixing bugs regularly causes regressions
It is hard for developers predict what the effect of making a change to code will have
There are many duplicated systems
Developers are demoralized and disengaged
Simple changes to the software take a long time to make
It takes a long time before new team member can contribute to the project in a meaningful way. Losing a single developer devastates the team and product development plans; this is a sign of extreme specialization mentioned by Ward Cunningham

Software Development Misconceptions
Many programmers have some misconceptions that poor sofrware development practices are necessary for rapid software development. It is common to hear among developers statements like:

I donít have time to document or test my code
I didnít write that module
It is easier for me to write a brand new module than upgrading the existing one
I donít understand that code so Iím not going to touch it
Cutting and pasting code is quicker
Shorter variable or function names saves me time typing
I donít have time to break up the long function into several smaller ones.
Iíll go back and improve/fix/document/test it later
It is the QA responsibility to find bugs in my code
Anyone can tell what Iím doing from reading the code
I donít care if someone understands it, it works.

These reasons and more are often used to justify a quick and dirty coding approach; however often what is quick in the short term only means quick to write and check-in. The total time it costs an organization to deal with the dirty code is often much longer than if the developer just followed good code.

Good software development practices can become nearly effortless with a bit of retraining. An intentional and good-faith effort has to be made to learn and to follow good coding guidelines for a period of time.

Mitigating Technical Debt
Technical debt is virtually impossible to avoid altogether, but there are several steps that a development team can take to minimize its introduction:
Agree and adhere to coding guidelines
Document the code and architecture
Always provide tests and samples for new features
Try to update and reuse existing systems, rather than introducing new similar system
If a new system has to be introduced that replicates functionality of an existing system, then the old system should be updated to use the new one
Conduct architecture reviews of proposed modules, features
Refuse to admit code into the code-base that violates the guidelines.
Use tools to detect violation of coding guidelines
NEVER cut and paste code: introduce a new function or class.

Reducing Technical Debt
The following are some ideas for how reducing technical debt
Delete code Ė The easiest way to refactor code is to remove it; find features that can be removed.
Address the biggest debt first Ė Areas of the software that impede developers the most should be addressed first.
Merge systems Ė If there are multiples systems doing similar things they should be merged into one.
Donít be afraid to break things - As Jeff Atwood says ďdonít be afraid to break things: paying off technical debt means refactoring code and taking risks. If refactoring is done properly it should be easier to identify and fix bugs, afterwards."

Last Words
Technical debt if left unaddressed will crush a project and the morale of the people working on it. Don't put your head in the sand regarding technical debt, confront it head on!
I'd love to hear your thoughts about this article and technical debt in general.
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein
  03 March 2013
or google's cache, who has the complete page:
may not be following this thread.
  03 March 2013
not long now my friends, the Autodesk 2014 line up is just a few days away.

Crossed fingers it's going to be a "hum dinger" of a reveal too!

youtube channel:-

"zero stones - zero crates"

Last edited by cresshead : 03 March 2013 at 01:09 PM.
  03 March 2013
Originally Posted by cresshead: not long now my friends, the Autodesk 2014 line up is just a few days away.

Crossed fingers it's going to be a "hum dinger" of a real too!
With Kees onboard, I actually expected to see a big release (including some of his previous plugins, which are no longer for sale, publicly...hint, hint), for Max. But then we are talking about Autodesk, here...and we are talking about a company that adds features at a snail's pace, and in small micro-bite sized increments.

So, ShaderFX in 2014, limited Crowd tool in Geppetto (helpful to only ArchViz folks) and some progress on Nitrous. Then SkinFX and further Nitrous dev. in 2015...eh?
  03 March 2013
Originally Posted by AbnRanger: With Kees onboard,

Sorry :( I am on the Maya team.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 06:05 AM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.