[Closed] Call anything cool recently added to MAX

Well I know that they will not have all the issues solved in my life time, then again, neither will every other piece of software ever written.

half time, and too one sided for the neutral interesting that you are extolling the virtures of OSD and it is very good but it brings us right back to my first request for the MCG graph of maintaining the specified normals when performing a mesh/poly subdivision. Tools are cool until they fail.

also it’s worth noting that having 90% of core max plugins running under paramblock version1 one means that for the last 15 years 90% of the example code in SDK is out of date by about 15 years. So any developer has to work out how to work out how to implement a plugin under the paramblock 2 with next to no examples and the worst sdk documentation on the planet.

this is one of my favourite pages they don’t even have the decency to say check out the MNNormalSpec page for actual descriptions of what the functions do

and the result of crap sdk examples,documentation and implementation, oh yeah badly implemented c# and python interfaces and endless threads on here and the autodesk help site about the wizard failures and how do i…

and of course any c# developer will run into the eh ? where the documentation of how do i do why is there no example of ? etc…

unfortunately at the moment I don’t get any option of what I have to work on

for my own part i think c++ is the way forward for most developers, the speeds you can achieve are just mind boggling compared any other approaches (see the speeds for the getElements thead) and improving the example set and documentation would go a long way to helping with that. IMO Oh c++ is too tough lets crowbar in c# and python has done themselves a disservice where they might spent there time better on improving the development environment and documentation.

Out of the box, in the current release, it will not preserve normals, nor any mesh data channel (edge visibility, vc, uvs,…), when using operators that change vert count. But its possible to write “smarter” mesh operators.

And yes, using C++ SDK, is a lot of guess work :P, shaders and texmaps are in constant mutation, with little to no good samples (its one of the parts I use most, AdvNoise was an adventure to write a few years ago). But maybe a new fresher SDK will also come in time.

how can it ? my point is 90% of the core plugins (and examples) are still implemented in a methodology that autodesk deemed out dated in about the time of max 4.

theres some really funny, “I’m not the first person to run into issuses” with implementing stuff in the sdk. Looks like even autodesk coders have found stuff that’s not working or they could work it out.And there should be absolutely no commented out code in the sdk samples. none! it’s either right or not included period.

yeah but they can look at the interface source code when they run into trouble, trial and error is all we get

Well, in 2016 there seems to be a bit of Qt (the render dialog with the A360 render fully QT, beside the “Caddies”). Well making pblock2 (forget pb1, it shoudn’t exist in the year 2015) UI wiring work with QT, will make them eat there own dog food, and possible a better system will emerge, or so I hope, if we ever see Qt in max.

I always thought, foolishly,it was for backwards compatibility but it turns out it’s not that much of a job to handle (see the geosphere) so I assume they all went on holiday for a couple of weeks

I also get the feeling that all of autodesk coders don’t like doing the boring stuff.