3D Software for the Next Generation, Part I

[tedlchen]

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…

1. 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.

2. 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.

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.

4. 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).

5. 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.

Ted

[Rick_Stirling]

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.

[oomer]

>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?

Harvey

BTW, Ted was my C++ sensei

[MostlyToad]

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).

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.

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’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”

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).

… 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.

[Light]

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.

Cheers,
Light

[PaK]

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.

Simple…isn’t it

-R

[Jeff_Hanna]

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.

[Light]

Hey Jeff,

I agree completely. I think VS is a very mature IDE. Take a look at what some other folks did with Visual Studio shell:

Ruby

IronPython

Cheers,
Light

[tedlchen]

[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

[Light]

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.

Light