Heya, ex-bioware here. So does that make me the .5 in the Bioware-Volition face off?
Anyways, I believe Iām in the minority here in saying that I actually like 3dsmax and Maxscript. From a purely systems point of view - I like XSI better, but practically speaking MXS is easily more flexible for me. While Iām an avid C#'er too, the typelessness of MXS does mean thereās less glue code to do callbacks, pipeline branching, etc. That relaxation of dependencies also means I can swap components with minimal fuss. Doing the same in C# would require a boatload of interfaces.
But it is a double edge sword. I concur with JS that the lack of a debugger greatly hampers things, which is why at Bioware, we had a bunch of MXS code conventions to smooth over the rough patches. The conventions (especially loose hungarian) really do help in eeking out what was intended versus what you see.
As for the future of 3d software packagesā¦
How about something that can actually run from command line in a clean form? Better yet, build the core (file loaders, etc), as a library that we can link to. That way, if we want to incorporate MAX21 into our pipeline, we can automate a good deal of it by creating custom headless MAX21 programs.
Iād like to see XSIās Custom Display Host system become more prevalent. I did like the ability to customize viewport display in 3dsmax, but with the current set of engines, we need to bring more ācrapā into the display logic. The CDH would be a better alternative nowadays.
Iād still like to see a scripting language that isnāt .NET though. Or at least make it JScript.NET. C# has way too much baggage to be an effective scripting language.
Iād like to see the companies DROP support for grandfathered features. This is definately a double edge sword, and has probably kept packages like XSI from gaining more ground. That said, there are ways to minimize the impact of said changes (see Drupal4/5/6/7 transitions).
Iād like to see a more open community of modules. See Drupal again. The quality of the modules is hit-or-miss, but whatās important is that the Core (as Yunus puts it) is maintained to a much higher standard. The Drupal project is a pretty good example in how a good framework is structured, in that it deals with dependencies which are allowed in a controlled fashion. Modules that become vital and well stabilized sometimes get brought into the Core, but more likely theyāll just get promoted to a higher priority level when the next version ships. Everyone else is left to upgrade as they need.
One of the things that Iāve really enjoyed about the development of Silo is that they not only add features, but are not afraid to remove or combine features. Case in point woudl be the Cut Tool, which combined Cut and Slice and so behaves differently whether you click on an edge (cut), or across an object (slice).
Iād like to see apps shipping with a fully customisable XML based drag and drop UI. Iād like to be able to switch between simple and full UI at a keystroke.
Iād like to see a scripting language that is not cobbled together as the software is built - Maxscript feels so much like this and itās very infuriating. Iād like to see proper feedback in the scripting language when you perform operations in the app - the maxscript listener seems to have selective hearing. Copying and pasting from the listener wonāt always work - why on earth should the syntax be different?
Iād like to be able to embed my scripts and functions into the UI, and Iād like to be able to assign hotkeys to not only full scripts, but to each button on the UI of a script (the most recently ran script having focus).
ā¦and Iād like to have windows within a session, so rather than having two or three copies of Max open, itād behave like docs in Photoshop where I can copy and paste, drag and drop between them.
>3. Iād still like to see a scripting language that isnāt .NET though. Or at least make it >JScript.NET. C# has way too much baggage to be an effective scripting language.
Hey Ted,
That is a very interesting comment about too much baggage for scripting. Iām curious whether your definition of baggage is the same as mine. I recently took a break from my Python scripting to port over some scripts to C# that I need a bit more speed and while at first I marveled at how much less baggage there was compared to c++, I quickly got tired of all the extra lines of code I had write. Generally when Iām scripting/prototyping, I want to iterate as quickly as possible. Is this the baggage that you think takes away from its effectiveness for scripting?
[QUOTE=Rick Stirling;1562]One of the things that Iāve really enjoyed about the development of Silo is that they not only add features, but are not afraid to remove or combine features. Case in point woudl be the Cut Tool, which combined Cut and Slice and so behaves differently whether you click on an edge (cut), or across an object (slice).[/QUOTE]
Yes. I also use silo from time to time and love it. I really wish more programs wouldnāt be afraid that their users canāt adapt to changes.
[QUOTE=Rick Stirling;1562]Iād like to see apps shipping with a fully customisable XML based drag and drop UI. Iād like to be able to switch between simple and full UI at a keystroke.[/QUOTE]
Iāve been using Modo latelyā¦ If youāre interested in an extremely customizable program, you might want to check it outā¦ If you decide to, most people (including myself) hate the default camera rotation (it rolls, instead of just pitch and yaw). Figuring out how to turn it off isnāt as well documented as it should be imoā¦ To disable it do: (from the menus) System > Preferences > Display > Open GL > Uncheck āTrackball Rotationā
[QUOTE=Rick Stirling;1562]Iād like to be able to embed my scripts and functions into the UI, and Iād like to be able to assign hotkeys to not only full scripts, but to each button on the UI of a script (the most recently ran script having focus).[/QUOTE]
ā¦ Yeah seriouslyā¦ check out modoā¦ dig into itā¦ you can customize everything. Button/keyboard actions reference the actual command.
As much as I love the program and the direction Luxology is taking itā¦ itās also important you know the downfalls:
[ul]
[li]No real animation system yetā¦
[/li][li]They have hard edges, but only for subdivided surfaces. which is justā¦ weirdā¦
[/li][li]Sculpting is buggyā¦ creates open edges along uv seams. Can be used for details, but probably best to stick with zbrush/mudbox/silo for the meat of the sculpting.
[/li][/ul]
Right now It seems like it would be good for environment artā¦ especially with Seneca Menardās (id software) UV scripts. But once they get past the above issues I could see it being extremely powerful.
Some .NET languages are pretty relaxed IMO, which would make them more suitable to use as a scripting language with the added benefit of still being able to use the language you are comfortable with. Like someone might have done some Lisp programming before and now could extend the program without much problem.
How about LOLCode for starters? It is a .NET compatible language too.
I learned to use MELScript before MAXScript, and now Iām adjusting to working under Maxās hood.
My Godā¦what a mess.
There is just a lack of consistency at every level of MAXscript, and, nothing is intuitive. I have to say, I had my frustrations with Maya too. If I had to ask for something from the āultimateā solution, I would just ask for 2 things.
-A consistent paradigm. Is it too much to ask for Autodesk to be consistent with their implementations? Iād echo what Rick said about the listener but he said it perfectly. Issues like that piss me off. I dont want to relearn a new paradigm each time uncover a different part of Max
-fix broken commands, donāt patch them with new commands that do what the broken one was supposed to do in the first place. Both packages are guilty of this.
Volition only has eleven TAs signed up here? Weāre missing a few. Iāll have to work on that.
Iāve been having an email discussion with Ben, Steve, Ross, Chris E., etcā¦ about TA roundtables and panels for GDC next year. I just sent out an idea that we should be making a concerted effort to get the DCC app devs to attend our presentations and talks. I donāt think the DCC app devs realize the depth and breadth of the tools we are making with their built in scripting languages. ADSKās inability to provide a decent IDE for MXS, and to leave the debugger languishing in an unusable state for 4+ releases shows that they still think MXS is that language artists use to automate repetitive tasks. Until the devs understand what we do and the complexity of what we are making they wonāt know that we need to have these languages and dev environments improved.
I would like ADSK to either completely expose the interfaces to MXS so that a third party could build a proper IDE with forms layout, properly integrated debugging, source control, and a profiler (an idea Light and I have discussed before) or to integrate Python so that we could make use of any of the numerous Python IDEs/debuggers/profilers that are available. MXS is decent (not great), Boboās never ending work on the docs over the past 5-6 releases has been a godsend, but the whole thing is just brought down by the 1/2 finished debugger and the extremely basic editor.
[QUOTE=oomer;1570]>
That is a very interesting comment about too much baggage for scripting. Iām curious whether your definition of baggage is the same as mine. I recently took a break from my Python scripting to port over some scripts to C# that I need a bit more speed and while at first I marveled at how much less baggage there was compared to c++, I quickly got tired of all the extra lines of code I had write. Generally when Iām scripting/prototyping, I want to iterate as quickly as possible. Is this the baggage that you think takes away from its effectiveness for scripting?
[/QUOTE]
Yup, thatās the gist of it. Thereās that whole scoping issue which makes you have to wrap all your variables into something. While I donāt like globals or session variables, I do find them quite handy from a scripting command line. Take for instance the operation in pseudo-script
var a = $scene.$body01.$legL.rotation;
In C# would at least haveā¦
[highlight=c#]
class MyScript
{
public Execute( )
{
Rotation3 a = Scene.GetObject(ābody01ā).GetObject(ālegLā).Rotation;
ā¦
}
}
Interactively, since the pseudo-scripts tend to behave more like 'sessions' in a listener window, I can add subsequent commands as I think of them. In C#, I pretty much have to recompile the entire Execute function every time I add a new line. This gets pretty tiresome especially when I just want to inspect something.
Then there's also the whole issue of types.
```pseudo
var a = #( "my text", 20, 150 );
doSomething( a );
doSomething( #( "my other text", 50, 350 ) );
Versus the C# way of
[highlight=c#]
ArrayList a = new ArrayList();
a.Add( āmy textā );
a.Add( 20 );
a.Add( 150 );
doSomething( a );
ArrayList b = new ArrayList();
b.Add( āmy textā );
b.Add( 50 );
b.Add( 350 );
doSomething( b );
Don't get me wrong though. I still love C# and would like to see it used more in plugin development. However, a scripting language should be fast and easy to use with the minimum amount of overhead fuss. If this means global session variables and no type safety, then so be it.
Ted
Nice demonstration of contrast between these languages there, Ted. I too agree that the scripting language should do pretty much everything for you, so you are really left out to simply define your idea, at the cost of some performance.
Personally I love Maxscript for this. Yes, itās harder to develop without the proper dev tools, but if you really know what you are doing, then itās really hard to make any mistakes IMO. The expressiveness of the language makes it very intuitive I think, thanks to its inspiration from Lisp.
Functional programming is perfect for this case I think. Each of the se requires a different mindset to work, but thatās expected if you want to code to perfection, in different mediums exclusively.
