Call anything cool recently added to MAX


#31

Does that mean they are not aware of it and don’t know that it should be fixed?? Or again are you assuming that they can fix everything that you deem to be needed and fix it for you?

they are probably aware of it, but they won’t fix it in my life time anyway, but it cause issues for everyone in one way or another who has to develop in the sdk for max (or at least something that you have to be aware of) so not just for me, oh it’s all about me me me :slight_smile: And stuff like this predates the MD from hell by about a decade. Anyway footies on now so i’m off


#32

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.


#33

half time, and too one sided for the neutral :frowning: 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.


#34

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 :slight_smile:

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…


#35

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

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.


#36

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.


#37

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.


#38

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.


#39

at least we on an equal footing with autodesk developers. they use the same old c++ sdk :wink: (c#, python, MCG)


#40

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


#41

they can but probably don’t do it. fair play :slight_smile:


#42

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.


#43

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 :wink:

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


#44

this is something I bashed out (in wire frame) in the sdk (2 days) (I don’t do hard sell look at me promos :wink: ), “rewrite” of the conform world space modifier, using a kdtree on the targert mesh, blends normals, vertex colours and uv coords (with soft selection blending) runs 10 times quicker than the autodesk original (there’s absolutely no shared code btw) It will blend any mesh to another mesh seamlessly in real time.


#45

i need it for my old “Tree generator” written 10 years ago using only pure MXS. :slight_smile: (it was very smart toy but damn slow)


#46

should be able to post up a kdtree extension class on the mxs extension thread soon, reduces the ray casting time considerably.a purely mxs kdtree implementation is very slow in building the tree and so not really viable.


#47

how could i forget?!
the

Avguard DLX Extension

was the awesome addition since max 2008. it’s very useful with mxs, and great resource of learning max sdk since its source code was added to it.


#48

can’t be classed as “cool” as it doesn’t clone a teapot in a million and one different ways :wink:

though I should be careful with the jokes though, don’t want to be accused of being negative and told to f off to maya :slight_smile: never had it soo good


#49

but i have to say that to you, Klvnk, anyway…
you are the most negative against cloned teapots person i know. and it’s not just a skepticism, you really hate them. :slight_smile:


#50

I really really would like to get my hands on such a scene
Of course you can’t share those , but i guess you did manual testing too and not only some automated tests ? So you should know the area causing you troubles with >Max2009 versions ?
Thus you should be able to post a representative scene which shows the performance problem you see in all versions >Max 2009 ? I’m really curious about 3ds Max’s performance shortcomings ( and of course especially compared to Maya) , be it factual, historical, method related or plain mythical.

sorry spacefrog I missed your post being the last on the page. you’re right I can’t share them, as I said we don’t do them any more (game was canned) and we had to change the way we worked a bit. IIRC the scenes were approaching 1 million faces using a lot of directx shaders. 2011 was the worst by a long way.