Estoy con vosotros. Lo que pienso yo es que quizá en Autodesk no quieren cambiar esas deficiencias porque la gente está acostumbrada a trabajar así, lo que me refiero es que puede que tengan miedo de rescribir todo el código por miedo a que los usuarios de max acostumbrados a cómo funciona dejen de usarlo.
Todos los que usamos max sabemos que tiene muchos fallos, es decir, sí, por ejemplo, pretendes hacer una simulación de dinámicas sabes que el dynamics de max es algo tan poco preciso que no conviene usarlo en caso de buscar realismo, entonces tienes que, acudir, en caso de una versión antigua de max, a un plugin externo llámese Reactor, una vez ven que Reactor es lo que usa la gente pues ala a meterlo en el lote.
En este caso, por poner un poco de limpieza y orden, me esforzaria por seguir mejorando el código que de Reactor y borraría por completo el código de las dinámicas de max.
Porque un editable Mesh y un Editable Poly? En este caso lo más lógico seria mantener el poly que es el que se actualiza y se esfuerzan por mejorar, y añadir las ventajas que pueda ofrecer el Mesh, pero en un código limpio.
Porque un MeshSmooth, un TurboSmooth y un Nurms subdivisión?
En vez de seguir metiendo plugins y seguir extendiendo un código tan mal organizado deberían mejorar cosas más obvias y problemáticas que influyen de manera drástica en el flujo de trabajo del usuario.