Quantcast
Channel: The 3ds Max Blog
Viewing all 73 articles
Browse latest View live

An Introduction to MAXScript

$
0
0

This is a MAXScript tutorial in the form of a MAXScript program that you can download and run. The program demonstrates a simple procedural animation of a walking stick-figure and an animated camera associated with the viewport. For more information on some of the concepts used in this script the following links will bring you to the relevant online MAXScript documentation:

Here is the source code of the program.

/*
MAXScript Tutorial
This script demonstrates creating a procedural animation using MaxScript. 
It generates a simple stick man from cylinders and a sphere, and animates 
him in a simple walk cycle.
Other concepts demonstrated include:
* Create simple primitives
* Link objects
* Create animation frames
* Set node transform properties in local coordinate space. 
* Use the sine function to achieve smooth back and forth motion
* Creating a camera with a target and rotating it
* Setting the active viewport, and associating it with a camera
*/
/* Clear the scene */
delete objects
/* Initialize variables to help define the objects */
armlength     = 15
leglength     = 15
armradius     = 2
legradius     = 2
/* Create Body Parts */
body        = cylinder radius:5 height:20 
leftarm     = cylinder radius:armradius height:armlength 
rightarm    = cylinder radius:armradius height:armlength 
leftleg     = cylinder radius:legradius height:leglength 
rightleg    = cylinder radius:legradius height:leglength 
head        = sphere radius:5 
/* Set the arm positions */
leftarm.pos.x     = -body.radius - armradius
rightarm.pos.x    = body.radius + armradius
leftarm.pos.z     = body.pos.z + body.height 
rightarm.pos.z    = body.pos.z + body.height 
/* Set the leg positions */
leftleg.pos.x     = leftarm.pos.x
leftleg.pos.y     = leftarm.pos.y
rightleg.pos.x    = rightarm.pos.x
rightleg.pos.y    = rightarm.pos.y
/* Rotate the arms and legs by 180 degrees so that they point downwards */
leftarm.rotation.x_rotation     = 180
rightarm.rotation.x_rotation    = 180
leftleg.rotation.x_rotation     = 180
rightleg.rotation.x_rotation    = 180
/* Set the head location */
head.pos.z         = body.pos.z + body.height + head.radius
/* Link the body parts to the body */
leftarm.parent  = body
rightarm.parent = body
leftleg.parent  = body
rightleg.parent = body
head.parent     = body
/* Move the body up so the legs are aligned to the x/y plane. */
body.pos.z = leglength
/*
Animate the body to move along the local Y axis a small amount per frame
The "animate on" context expression automatically creates 
key frames when animatable properties are modified
*/
animate on (
    for t = 0 to 100 by 5 do (
        /* 
	    The "at time" context expression gets/sets animatable properties at a specific time frame.
        */
        at time t (        
            /* Assure that transforms occur in the node's local coordinate system */
            in coordsys local (
                move body [0, -2.5, 0]
            )
        )
    )
)
/*
Rotate arms and legs
In order to get the movement to change direction smoothly I use a sine function: 
*/
animate on (    
    swingArc = 45  /* The number of degress each arm and leg swings */
    spd = 10       /* Controls the speed at which the swing occurs */
    for t = 0 to 100 by 5 do (
        at time t (
            leftarm.rotation.x_rotation  = sin (t * spd) * swingArc + 180
            rightarm.rotation.x_rotation = sin (t * spd + 180) * swingArc + 180
            leftleg.rotation.x_rotation  = sin (t * spd + 180) * swingArc + 180
            rightleg.rotation.x_rotation = sin (t * spd) * swingArc + 180
        )
    )
)
/* Create a free camera targeted to the body */
cam = freeCamera pos:[100, -100, 50]
cam.target = body
/* Set the lower-right viewport as the active viewport */
viewport.activeViewport = 4
/* Associated the active viewport with the camera */
viewport.setCamera cam
/* Animate the camera around the origin while moving up. */
animate on (
    for t = 0 to 100 do (
        at time t (
            /* Rotate about the z_axis at the origin 
            Uses the "about" context expression to set the pivot to perform rotations.
            */
            about [0, 0, 0] ( rotate cam 1 z_axis )            
            /* Move the camera upwards */
            move cam [0, 0, 1]
            /* Update the roll_angle controller of the camera so that we stay level with the x/y plane */
            cam.transform.controller.Roll_Angle.controller.value = 0
        )
    )
)

Cross Platform C# Game Development with MonoGame

$
0
0

I am (or rather was) a big fan of XNA, Microsoft's C# game development framework, and I had high hopes for it. I was particularly enthusiastic when Silverlight started supporting a subset of it. Unfortunately Microsoft has given no indication (as far as I am aware of) that they will be supporting XNA for Winows 8 Metro and Silverlight is apparently not being supported on Windows 8 metro. There have been a lot of speculation around the future of C#-based game development for Windows on various threads. For an interesting and informed discussion on the topic see this topic on gamedev.stackexchange.com.

When I first read the thread on GameDev several months ago I had skimmed past a post talking about an open-source project called MonoGame. Today I revisited the MonoGame web-site and I was impressed with the number of downloads, positive reviews, and the general momentum of the project.

Here is the MonoGame mission statement:

MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro.  PlayStation Mobile development is currently in progress.

Imagine writing applications and games for all of those platforms at once in C#? Wouldn't that be amazing! To be honest I'm generally very skeptical when it comes to the success of open-source projects, but this group seems to be doing everything right. I also like their approach of building upon mature open-source projects like OpenTK and SlimDX.

However, what reaslly sold me were the trailers for ARMED! from SickHead games. This awesome looking game has been ported to Windows 8 Metro and Windows 7 Phone using MonoGame. I'm curious about the success they will have porting to other platforms!

At least for now I've become optimistic and enthusiastic about the prospect of serious game development in C# once again.

[video]http://www.youtube.com/watch?v=T4bEWO4-I2A[/video]

Creating an Undoable Python Command for Maya

A very gentle introduction to MAXScript for Artists

$
0
0

Embedded in one of the over 200 videos on the Autodesk 3ds Max learning channel on YouTube is a very practical introduction to MAXScript for people with no programming experience. At about 4 minutes into a video on using MassFX Amer shows how to use MAXScript to automate changing a property on over 300 objects. What is great about this is that Amer takes the time to explain everything that he is doing without assuming the audience is familiar with MAXScript.

What he shows introduces several basic concepts:

  • Using the MAXScript recorder to discover the necessary code how to change a desired property
  • What the "$" symbol means (currently selected object)
  • How to change a property of all objects in the currently selected set

Its a great example of how one line of MAXScript code can save an artist a lot of wear and tear on their wrist!

For convenience here is the video in its entirety.

[video]http://www.youtube.com/watch?v=nmdEMpblRqg[/video]

Maya 2013 Extension 2: .NET and more

$
0
0

A .NET API for Maya

Cyrille Fauvel from the Autodesk Developer Network gave the first public sneak peek of a .NET API for Maya back in December on his blog. I'm pleased to announce that it is now a reality for our subscription customers with the release of the Extension 2 Maya 2013 on the subscription site.

For fun here is a sample Hello World plug-in for Maya written in C#:

using System;
using Autodesk.Maya.Runtime;
using Autodesk.Maya.OpenMaya;
[assembly: MPxCommandClass(typeof(MayaNetPlugin.helloWorldCmd), "helloWorldCmd")]
[assembly: ExtensionPlugin(typeof(MayaNetPlugin.helloWorldPlugin), "Autodesk", "1.0", "Any")]
namespace MayaNetPlugin
{    public class helloWorldPlugin : IExtensionPlugin    {        bool IExtensionPlugin.InitializePlugin() { return true; }        bool IExtensionPlugin.UninitializePlugin() { return true;  }        String IExtensionPlugin.GetMayaDotNetSdkBuildVersion()  { return ""; }    }    public class helloWorldCmd : MPxCommand,IMPxCommand    {        public override void doIt(MArgList argl)        {            MGlobal.displayInfo("Hello World\n");        }    }
}

Of course it gets much more interesting than that since there is support for docking WPF windows in Maya, and for using LINQ. Here is an example of how LINQ can be used to query the dependency graph for all selected objects with a mesh:

var meshes = from p in new MSelectionList()
             where p.hasFn(MFn.Type.kMesh) 
             select new MFnMesh(p);

In the Maya devkit/dotnet folder though you can find over 60 sample .NET plug-ins ported from the C++ API. For more information on the Maya .NET API you should check out the documentation.

Also note that the Autodesk Developer Network has made a C# plug-in wizard available on the Maya developer center page.

SDK Documentation Improvements

There has also been a number of improvements to the SDK documentation:

For detailed information on the changes in the SDK and SDK documentation see the What's New in Extension 2 for Maya 2013 topic. There is also some information about other improvements to the Maya 2013 Extension 2 in the Maya user documentation.

SDK Documentation Translator Widget

Finally is a special treat for Maya users who don't speak English as a first language: the addition of a Microsoft Translation widget to the SDK documentation. This is a pilot project, that we first tried on Gameware customers and that we are now rolling to the larger audience of Maya SDK users.

I'd appreciate hearing your feedback regarding any or all of these improvements.

Creating a Procedural Tree in MAXScript

$
0
0

The following is a two-part MAXScript video tutorial produced by the Autodesk 3ds Max YouTube learning channel. This is a beginner level introduction to MAXScript that will show you how to create, move, scale, and rotate objects. You'll learn how to create animations, use the for loop, and create random variations.

[video]http://www.youtube.com/watch?v=ZoIY5lT6IV4[/video]

[video]http://www.youtube.com/watch?v=NxI-ru5yAa0[/video]

JSON Scene Description Language

$
0
0

Today I'm presenting the first public draft an informal specification for a 3D scene description language designed specifically for web-services called the JSON Scene Description Language. I've tried to come up with a specification that is similar in spirit to JSON: as simple as possible, extremely generic, and very useful.

I'd appreciate any feedback you can provide, thanks!

JSON Scene Description Language

Draft Version, February 14th, 2013
by Christopher Diggins, Autodesk

Summary

JSON Scene Description Language (JSDL) is a specification for transmitting descriptions of 3D scenes via web services.

Introduction

Traditional representations of 3D scenes are monolithic static file formats (for example FBX and COLLADA) which do not lend themselves well to transmission over a network or for consumption by light-weight clients such as web-browsers.

JSDL is a specification for describing a scene hierarchy and the various scene elements (assets) contained within it. JSDL is open-ended in that it does not specify how to represent scene elements themselves. JSDL is compatible with any format for representing geometry, texture maps, materials, animation, particle effects, etc.

An important advantage of JSDL is that it supports multiple representations of the same scene element. An example of how this can be useful would be if a web-service wanted to present a custom binary mesh formats to certain clients that can support it, but to present more generic represesentations to other clients.

Overview

JSDL consists of the following parts:

  • Scene record - A JSON record describing a scene. It contains a scene graph and an array of asset descriptors.
  • Scene graph - A JSON representation of a tree of scene nodes. Each node has a transform, and may refer to one or more child objects.
  • Asset descriptors - An asset descriptor is a JSON record that contains meta-information about an asset and an array of the representations available.
  • Assets - An asset is a constituent part of a scene. An asset can be any kind of data. Typical examples of assets in 3D scenes include geometry, texture maps, materials, cameras, particle effects, animation tracks, and more.
  • Asset representations - An asset can have one or more representations. Each asset representation type has an identifier similar to a MIME type.

Asset URL

An asset is identified using a URL of the form:

[<scene_url>/]<asset_id>[/<asset_representation_id>]

The scene URL component is optional, if it is omitted then the asset ID is assumed to belong to the current scene. The asset ID component identifies the scene element (the "resource"). The asset representation ID component is also optional; if it is omitted then the JSON asset descriptor record is returned.

Scene Object

The scene object is a JSON object that describes a scene hierarchy and contains a list of all assets descriptors.

scene : {
  id : string,
  roots : [node],
  camera : string,
  assets : object,
}

The identifier is a string that can only contain letters, digits, and the underscore character, and cannot start with a digit. The roots field contains the top level scene nodes (i.e. those with no parents). The camera field is an optional asset URL or identifier that indicates the default camera. The assets field is an a dictionary of asset descriptors. Each asset key is an asset identifier that consists of letters, numbers, the "_" character, or the "-" character.

Scene Graph Node

A scene graph node:

node : {
  transform : [float],
  assets : [string],
  children : [node],
}

The transform is an optional four by four matrix indicating the nodes offset from the parent. The assets field is an array of asset URLs or asset identifiers. The children field contains an array of child nodes.

Asset Descriptor

The asset descriptor is a JSON record that identifies an asset and lists the avaialable representations.

asset : {
representations : [string], default : { type : string, value : object, } }

The representations field is an array of asset representation type identifiers. A default representation may be embedded in the asset descriptor record if it is a JSON object. The "default.type" field is the type identifier, and the "default.value" is the JSON object.

Asset Representation Type Identifier

The asset representation type identifier is similar in concept to a “mime-type”. It is a string that represents a particular type of data. The asset representation identifier should start with a letter, and can consist of letters, numbers, and the '.' character.

Appendix: Predefined Asset Representation Type Identifiers

JSDL does not require specific asset representations, or representation identifiers. The following are some recommended identifiers for common asset representation types:

The various threejs.X.json representations are defined as those formats that can be loaded by the Three.JS JSON loader.

Appendix: Example JSDL

The following is a JSDL file describing a scene with two instances of a square with a side of length 2.0. The second square is offset from the first square by [3, 4, 5].

The default representation of the square is a Three.JS compatible JSON format, the alternative formats are a Wavefront OBJ ASCII file format, and the Alembic binary format.

{
  "id" : "my_scene"
  "roots" : [  
    { 
      "assets" : ["Square"],
      "children" : 
      [
         "transform" : 
         [
            1, 0, 0, 3,
            0, 1, 0, 4,
            0, 0, 1, 5,
            0, 0, 0, 1
         ]
         "assets" : ["Square"],
      ],
    }
  ],
  "assets" : [
    "Square" : {
        "representations" : [
           "threejs.geometry.json", 
           "wavefront.obj", 
           "alembic"],
        "default" : { 
            "type" : "threejs.geometry.json",
            "value" : {
                "vertexes" : [
                    [-1, 1, 0],
                    [1, 1, 0],
                    [1, -1, 0],
                    [-1, -1, 0],
                ],
                "faces": [
                    [3, 2, 1],
                    [3, 1, 0],
                ]
            }
        }    
    }  
}

If this JSDL scene is hosted on a URL such as http://test.autodesk.com we would then be able expect the following URLs to exhibit specific behavior:

  • http://test.autodesk.com/my_scene - This would return the above JSON object.
  • http://test.autodesk.com/my_scene/Square – This would return the “assets.Square” JSON object.
  • http://test.autodesk.com/my_scene/Square/threejs.geometry.json – This would return the “assets.Square.default.value” JSON object.
  • http://test.autodesk.com/my_scene/Square/wavefront.obj - This would return an .obj text representation of the square object.
  • http://test.autodesk.com/my_scene/Square/alembic - This would return an alembic binary representation of the square object

Acknowledgements

A special thank you to Aaron Tarnow at Autodesk for reviewing this specification and his enthusiastic support. Thanks to Stephen Taylor, Robert Goulet, Andre Gauthier, Mark Davies, and Mathieu Mazerolle at Autodesk, Grayson Lang at Adobe, Paul Brunt of GLGE, and Rob Bateman of Away 3D. This specification would not be possible if they didn't generously share their knowledge and experience.

Christopher's Thoughts on Technical Debt

$
0
0

Manny Lehman’s Law

A well-known occurrence in software development is that as software evolves it structure deteriorates. This is called Manny Lehman’s law:

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it." — Meir Manny Lehman, 1980

The Technical Debt Metaphor

Ward Cunningham first used a metaphor of debt to describe how certain software development practices can accelerate the deterioration of software in an experience paper for OOPSLA 92:

"Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise." - Ward Cunningham, 1992

The Impact of Technical Debt

Since technical debt means an increase in overall system complexity this results in an increase in:

  • number of defects
  • defect complexity
  • defect fix time
  • cost to implement new feature
  • cost to address technical debt

The last point should drive home just how appropriate the debt analogy is, since like financial debt, technical debt will compound over time until it cripples development!

Kinds of Technical Debt

Generally speaking technical debt can be anything during the software development process that slows down a developer’s productivity. For example a bug fix in one module may have unintended consequences in other modules because previous work caused a tight coupling between the two modules; or perhaps removing a feature takes far longer than expected because the code is scattered among multiple modules due to poor code cohesion.

Technical debt can be categorized in the following types:

  • Process Debt– Processes become more complex and inefficient over time. Examples include builds, automated tests, check-ins, reviews, bug logging, bug tracking, etc.
  • Code Hygiene Debt– Examples included duplicated code, dead code, inadequate documentation, monolithic classes, inconsistent style, and cryptic symbol names.
  • Architectural Debt– Examples include high coupling of components, poor cohesion, poorly understood modules and systems, redundant systems, and unused systems.
  • Knowledge Debt– As products grow in complexity and team members come and go knowledge that is not written down gets lost. It takes longer for developers to become familiar with the inner workings of different systems. This can lead to cases where existing features are re-implemented.

When Technical Debt approaches Bankruptcy

Some signs that your project is nearly bankrupt with technical debt:

  • Fixing bugs regularly causes regressions
  • It is hard for developers predict what the effect of making a change to code will have
  • There are many duplicated systems
  • Developers are demoralized and disengaged
  • Simple changes to the software take a long time to make
  • It takes a long time before new team member can contribute to the project in a meaningful way
  • Losing a single developer devastates the team and product development plans; this is a sign of extreme specialization mentioned by Ward Cunningham

Software Development Misconceptions

Many programmers have some misconceptions that poor sofrware development practices are necessary for rapid software development. It is common to hear among developers statements like:

  • I don’t have time to document or test my code
  • I didn’t write that module
  • It is easier for me to write a brand new module than upgrading the existing one
  • I don’t understand that code so I’m not going to touch it
  • Cutting and pasting code is quicker
  • Shorter variable or function names saves me time typing
  • I don’t have time to break up the long function into several smaller ones.
  • I’ll go back and improve/fix/document/test it later
  • It is the QA responsibility to find bugs in my code
  • Anyone can tell what I’m doing from reading the code
  • I don’t care if someone understands it, it works.

These reasons and more are often used to justify a quick and dirty coding approach; however often what is quick in the short term only means quick to write and check-in. The total time it costs an organization to deal with the dirty code is often much longer than if the developer just followed good code.

Good software development practices can become nearly effortless with a bit of retraining. An intentional and good-faith effort has to be made to learn and to follow good coding guidelines for a period of time.

Mitigating Technical Debt

Technical debt is virtually impossible to avoid altogether, but there are several steps that a development team can take to minimize its introduction:

  1. Agree and adhere to coding guidelines
  2. Document the code and architecture
  3. Always provide tests and samples for new features
  4. Try to update and reuse existing systems, rather than introducing new similar system
  5. If a new system has to be introduced that replicates functionality of an existing system, then the old system should be updated to use the new one
  6. Conduct architecture reviews of proposed modules, features
  7. Refuse to admit code into the code-base that violates the guidelines.
  8. Use tools to detect violation of coding guidelines
  9. NEVER cut and paste code: introduce a new function or class.  

Reducing Technical Debt

The following are some ideas for how reducing technical debt

  • Delete code– The easiest way to refactor code is to remove it; find features that can be removed.
  • Address the biggest debt first– Areas of the software that impede developers the most should be addressed first.
  • Merge systems– If there are multiples systems doing similar things they should be merged into one.
  • Don’t be afraid to break things - As Jeff Atwood says“don’t be afraid to break things: paying off technical debt means refactoring code and taking risks. If refactoring is done properly it should be easier to identify and fix bugs, afterwards."

Last Words

Technical debt if left unaddressed will crush a project and the morale of the people working on it. Don't put your head in the sand regarding technical debt, confront it head on!

I'd love to hear your thoughts about this article and technical debt in general.


Embedding Qt Content in a 3ds Max Dockable Frame

$
0
0

The 3ds Max API provides a custom Windows control called a CUIFrame that allows a plug-in developer to create dockable content. As part of a recent investigation I decided to figure out how to embed a Qt C++ dialog CUIFrame in CUIcontent. I created a helper class called "DockableWindow" that can be used as follows:

DockableWindow* DoStuff()
{
    DockableWindow* dock = DockableWindow::Create(_T("My QT Demo"));
    HWND h = dock->GetHWND();
    dlg = new QWinWidget(h);
    Ui::Dialog().setupUi(dlg);
    dock->SetWidget(dlg);
    return dock;
}

Here is the implementation of the DockableWindow class.

class DockableWindow  
        : public CUIPosData, public CUIFrameMsgHandler 
    {
    HWND h;
    ICUIFrame* frame;
    QWidget* w;
    CUIPosData posData;
    DockableWindow(HWND hwndCuiFrame) 
            : h(hwndCuiFrame), w(NULL), frame(NULL) 
        {
        frame = ::GetICUIFrame(h);
        frame->InstallMsgHandler(this);
    }
    void ResizeFrameToContent() {
        RECT r = {0};
        if (w == NULL) return;
        GetWindowRect(h, &r);
        MoveWindow( h, r.left, r.top, w->width(), w->height(), TRUE );
    }
    void ResizeContentToFrame() {
        if (w == NULL) return;
        RECT r = {0};
        GetWindowRect(h, &r);
        int width = r.right - r.left;
        int height = r.bottom - r.top;
        w->resize(width, height);
    }
    virtual int GetWidth(int sizeType, int orient) { 
        switch (sizeType) {
        case CUI_MIN_SIZE: return 50;
        case CUI_MAX_SIZE: return 10000;
        }
        return w->width(); 
    }
    virtual int GetHeight(int sizeType, int orient) { 
        switch (sizeType) {
        case CUI_MIN_SIZE: return 50;
        case CUI_MAX_SIZE: return 10000;
        }
        return w->height(); 
    }
public:
    enum DockFlags {
        Top = 1 << 0,
        Bottom = 1 << 1,
        Left = 1 << 2,
        Right = 1 << 3,
        Horizontal = Left | Right,
        Vertical = Top | Bottom,
        All = Horizontal | Vertical,
    };
    virtual ~DockableWindow() {
        ::ReleaseICUIFrame(frame);
        delete w;
    }
    static DockableWindow* Create(MCHAR* name, DockFlags pos = All, DWORD initialPos = 0, 
        bool isDockedInitially = false, bool resizable = true, bool visible = true) {        
        HWND h = ::CreateCUIFrameWindow(
                    ::GetCOREInterface()->GetMAXHWnd(), name, 0, 0, 0, 0);
        if (!h) return NULL;
        DockableWindow* r = new DockableWindow(h);
        ICUIFrame* f = r->GetICUIFrame();
        DWORD flags = pos | CUI_FLOATABLE;
        if (resizable) flags |= CUI_SM_HANDLES;
        f->SetPosType(flags);
        if (isDockedInitially) r->Dock(initialPos);
        f->Hide(visible ? FALSE : TRUE);
        return r;
    }
    virtual int ProcessMessage (UINT message, WPARAM wParam, LPARAM lParam) {
        switch (message) {
        case CUI_POSDATA_MSG: {
                CUIPosData **cpd = (CUIPosData **)lParam;
                cpd[0] = this;
                return TRUE; 
            }
        case WM_SIZING: 
            ResizeContentToFrame();
            return FALSE;
        }
        return FALSE;
    }
    bool HasWidget() {
        return GetWidget() != NULL;
    }
    QWidget* GetWidget() {
        return w;
    }
    void SetWidget(QWidget* w) {
        delete(this->w);
        this->w = w;
        if (w == NULL) return;
        w->move(0, 0);
        ResizeFrameToContent();
        w->show();
    }
    void Dock(DWORD location) {
        if (location & Top) GetCUIFrameMgr()->DockCUIWindow(h, Top);
        else if (location & Bottom) GetCUIFrameMgr()->DockCUIWindow(h, Bottom);
        else if (location & Left) GetCUIFrameMgr()->DockCUIWindow(h, Left);
        else if (location & Right) GetCUIFrameMgr()->DockCUIWindow(h, Right);
    }
    void Float() {
        GetCUIFrameMgr()->FloatCUIWindow(h);
    }
    HWND GetHWND() {
        return h;
    }
    ICUIFrame* GetICUIFrame() {
        return frame;
    }
};

For more information see the QWinWidget Qt class and the following 3ds Max SDK classes:

Sell or Share your Plug-ins, Tutorials, or other Content for 3ds Max and Maya via the Autodesk Exchange

$
0
0

With the release of Maya 2014 and 3ds Max 2014 the Autodesk Exchange site makes it easier for plug-in, content, and tutorial developers to distribute and sell their content more easily to Autodesk customers.

Both Maya 2014 and 3ds Max 2013 have direct links to the exchange app store from within the product under the help menu. In Maya go to "Help > Exchange Apps" in the main menu. In 3ds Max go to "Help > Autodesk Product Information > Exchange Apps".

According to the Autodesk Exchange developer center "apps" aren't restricted to plug-ins, and can be anything a customer will find useful. For example:

  •     Plug-ins
  •     Standalone applications
  •     Training tutorials
  •     E-books
  •     Content

Note that at the current time there is no cost to sign-up and Autodesk is currently taking no commission, but may do so in the future. For more information on that see the Publisher FAQ.

If you have enough information and want to get started publishing your content for 3ds Max or Maya, you can go directly the following links:

Happy content publishing!

3ds Max SDK and MAXScript CHMs now available

3ds Max and Flash Working Together

$
0
0

You may be familiar with FarmVille 2: it is currently the second most popular app on FaceBook with over 40,000,000 estimated monthly users (as of the date of this posting). What you may not know is that FarmVille is built using the Flare3D engine and 3ds Max.

The following video talks about the role of 3ds Max in FarmVille 2:

[video]http://www.youtube.com/watch?v=8iBjwLHyag4[/video]

This next video talks about the role of Flare3D in FarmVille 2:

[video]http://www.youtube.com/watch?v=nnNKko2ELKQ[/video]

Flare3D is a 3D engine that leverages a relatively new Flash technology called Stage3D (previously known as Molehill) to deliver GPU accelerated 3D graphics called Stage 3D. You can try Flare3D and the 3ds Max exporter for free here. The following video demonstrates the Flare3D exporter for lightmaps:

[video]http://www.youtube.com/watch?v=IG5acCdnz00[/video]

A popular open-source 3D engine for Flash is Away3D. The following video is the Away3D Demo reel presented at GDC:

[video]http://vimeo.com/62962084[/video]

Zynga, the makers of FarmVille 2, use Away3D in another popular Facebook game called Café World. Away3D was also used to build interactive 3D web applications to promote the Renault Megane and the Nissan Juke.

[EDIT: Rob Bateman from Away3D suggest that people also check out the Nissan Juke 3D configurator as it better showcases Away3D functionality, but unfortunately for me it only works on Google Chrome.].

One use case of 3ds Max and Away3D that I found particularly interesting was this iPad app (built with Adobe AIR) for a condo project called the Clarence.

There is a tutorial on the Adobe website for step by step instruction on how to create an interactive 3D application for 3ds Max using Away3D. If you want you can also download an Away3D exporter project  Away3D file format (AWD) project on Google code.

3ds Max and Stage Automation

$
0
0

Stage automation is a growing industry that plays an important role in live entertainment events from music shows to Cirque du Soleil. What may come as a surprise is that thanks to a plug-in from Stage Technologies 3ds Max is playing an increasingly important role in designing, simulating, and visualizing automation for live events.

Stage Technologies is an Australian company specializing in live event automation, they sell a number products for managing and controlling numerous types of live event automations. Among their products is a 3ds Max plug-in called Sculptor Animation Toolkit. Sculptor toolkit turns 3ds Max into a tool for designing and preview automation and to receive feedback on what movements are impossible or dangerous. Once ready Sculptor Toolkit data can be sent directly from 3ds Max to the eChameleon automation software.

As an example Sculptor Toolkit can be used to define a trolley that travels along a track, add a revolving ring hanging from it, then add some winches below the revolving ring as linear axes; these winches might then act as pickups in a larger bridled system. Flight paths, either drawn or sourced from recorded joystick data can be imported and supplementary feedback is provided to the operator when refining these paths, ensuring the flown move will run safely.

The following video shows Sculptor Toolkit in action.

[video]http://www.youtube.com/watch?v=t3XW2Pq8LxQ[/video]

3ds Max and the Sculptor Toolkit have been used together to design and visualize live event productions from RadioHead to the Pan-American games opening ceremony to animating a giant robotic Gorilla for an upcoming musical about King Kong.

[video]http://vimeo.com/57498670[/video]

For more information on Sculptor Animation Toolkit see http://www.stagetech.com/press/sculptor-animation-toolkit.

Autodesk Exchange Apps Portathon is happening on September 13th.

$
0
0

The Autodesk Exchange store provides a broad range of Autodesk® approved extensions for users of several Autodesk products such as 3ds Max and Maya. If you are a developer of extensions for Autodesk products it is a great way to reach more potential users. For more information on publishing content to app-exchange see http://apps.exchange.autodesk.com/en/Publisher/Description.

To support and encourage developers to port existing scripts and plug-ins to the app-exchange, Autodesk is hosting a portathon, a 48 hour virtual web based coding event runs through September 13 and 14, 2013.This is a community event where you’ll have the opportunity to work closely with Autodesk engineers in real time and meet hundreds of other Autodesk software partners from around the world.  It is all designed to help you get your apps ready and published on Autodesk Exchange Apps.

There’s no cost to join the Portathon, but there is a reward.  For all new apps submitted to the Autodesk Exchange Apps store by midnight on September 14, 2013 and accepted for publication in the store by October 31, 2013, you will receive US$ 100 per app (for up to 5 apps – US$ 500 total).

Don't delay - join well over 100 developers in getting the help you may need to get your apps published. For details visit: http://autode.sk/15DjZpq

M&E Scripting and SDK Channel on YouTube

$
0
0

Recently the video learning team launched a new learning channel (http://www.youtube.com/user/ScriptingSDKHowTos/videos) dedicated to SDK and scripting users. Right now we have videos on FBX, Maya, MotionBuilder and ICE. I hear that they are working on some 3ds Max videos, so if you do any SDK/scripting development I suggest subscribing!

Here are a few samplers:

http://www.youtube.com/watch?v=CvRgN6m5XuU

http://www.youtube.com/watch?v=eXFGeZZbMzQ

http://www.youtube.com/watch?v=OgT1B69BqWg

http://www.youtube.com/watch?v=1PF-dBjsqOM

One of the great things about the video channels is that they are a great way to enter into a dialogue with our subject matter experts and make suggestions for future learning materials.


ADN DevDays Conference in Las Vegas at AU and a New 3ds Max SDK Blog

$
0
0

The Autodesk Developer Network (ADN) is going to be hosting another DevDays co-located at Autodesk University in Las Vegas on Monday December 2nd this year. I'll be there to talk about the new Python API in 3ds Max. For more information on attending you can see Cyrille Fauvel's blog or register directly here. In addition I will be available (along with ADN and other members of the engineering team) to answer your SDK questions and help you resolved technical problems during the ADN DevLab programming workshop on the second day.

The other piece of good news (which I apologize for being late to announce) is that Kevin Vandecar, 3ds Max developer consultant at ADN, has launched a new blog for 3ds Max SDK users called amusingly enough "GetCoreInterface". Hopefully this will make up for the lack of activity on my own blog. 


The 3ds Max Gunslinger and yes I read your Crash Error Reports (CER's)

$
0
0

This year we had our first ever "gunslinger" event for 3ds Max. This was an opportunity for members of the development team (developers, QA, design, and product manager) to meet a cross-section of 3ds Max users and discuss their ideas, questions, and concerns. We invited several prominent members of the 3ds Max community to meet with the 3ds Max team in the Montreal office for two and a half days. For some it was also an opportunity to meet with the new 3ds Max product manager Eddie Perlberg, though many customers already know him through his work as an application engineer, his blog, or via his classes at Autodesk University.

During the event we discussed the 3ds Max product development process (e.g. how we use the Scrum development methodology and the legal repercussions that prevent us from talking publicly about current or future feature development). Hopefully they better understood why we are sometimes vague about what we are doing, and why it seems to take long (from a  cutsomer perspective) to start on new features. We also spent a lot of time learning how they use the product, what their pain points are, and what they want to do more easily in the future.

One question a lot of them had was how we choose what we work on. What surprised me to learn was that many customers didn't realize how influential CER data is for us when fixing bugs and improving stability. A CER (Crash Error Report) is the data sent to 3ds Max when a crash occurs and a dialog pops-up asking if you want to send the data to 3ds Max. We have an official description of the CER workflow on Autodesk.com.

Autodesk receives hundreds of thousands of CER reports annually. This means that we can't follow-up on inidividual CER reports, and instead rely heavily on data-mining techniques. The data goes to a database and is auto-triaged based on the module and auto-linked to related crashes. When patterns emerge, CERs are grouped into defects which are tehen submitted by the QA team to the development team. So as a developer I often see CERs once there are a group in a certain module (e.g. function or DLL) and assigned to a defect, which is usually a long time after it is submitted. At that point I can end up reading hundreds of CER reports one by one trying to find patterns.

Many people realize that 3ds Max 2014 is a very stable release which is due in large part to us working from data provided to us from CER reports. This has helped us identify, prioritize, and fix problems. The most useful thing you can do is provide us with steps that can consistently reproduce the crash. A description of the problem and the worfklow can also help (one of our users keeps us entertained by describing his problems in Haiku). Yes, we do get some data on what you were doing, but the technology is far from perfect. However, even without anything else just clicking "send" with no data still helps us to identify the modules that need to be reviewed more carefully.

PyQt UI in 3ds Max 2014 Extension

$
0
0

Chances are you are reading this because you want to write some UI for 3ds Max using Python. Because 3ds Max is fundamentally a Win32 application there are some challenges to overcome:

  1. Make your PyQt window is a proper child windows of 3ds Max
  2. Make sure that Python doesn't collect your objects
  3. Making sure that accelerators are disabled when your Widget has the focus

Making PyQt Windows a Child of 3ds Max

Digia provides a Qt module for C++ called QtWinMigrate that was designed specifically to support mixing Qt with native Win32 UI. This works very well in C++ but unfortunately is not available by default in the PyQt or PySide packages. Luckily Blur studios wrapped make this package available in their binary PyQt distribution. If you need to build it from sources yourself the SIP sources can also be found online.

Once installed (note: I didn't install the Blur plug-ins. I have no idea how that could affect Python in the 3ds Max 2014 extension) you have to tell the 3ds Max Python engine where the PyQt module is. This can be done by updating the PYTHONPATH folder to point to the folder containing your Blur PyQt installation. For example I installed the Blur Qt into my regular Python installation folder, I set the PYTHONPATH user environment variable to "C:\Python27\Lib\site-packages".  If you already have the PYTHONPATH variable you can append it to the list of paths, separating it from the others using a semicolon. If 3ds Max is running you will have to restart it before this change can take effect.

A simple test to see if 3ds Max Python can find the PyQt is to write:
python.executeFile "demoPyVersionTool.py"

On my system the result is:

    3ds Max 2014 path environment variable c:\\program files\\autodesk\\3ds max 2014\\
    MaxPlus module False
    PyQt QT version 4.8.3
    PyQt module True
    PyQt version snapshot-4.9.5-9eb6aac99275
    PySide module False
    Python prefix C:\Program Files\Autodesk\3ds Max 2014\python
    Python version 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
    os module True
    sys module True
    #success
   

Once all of this is done you have to do a bit of extra work to get the 3ds Max HWND from the MaxPlus API because it is exposed as a SWIG object, and not a plain int. Here is a snippet of code that illustrates how to do this.

import MaxPlus, ctypes
from PyQt4 import QtGui, QtCore, QtWinMigrate
def getMaxHwnd():
    mem = long(MaxPlus.Win32.GetMAXHWnd())
    return ctypes.c_longlong.from_address(mem).value    
class MaxWidget(QtGui.QMainWindow):                
    def  __init__(self):
        self.parent = QtWinMigrate.QWinWidget(getMaxHwnd())
        QtGui.QMainWindow.__init__(self, self.parent)
 

Make sure that Python doesn't collect your objects

There is not much documentation on how to assure that Python doesn't collect your PyQt objects, and to be honest I don't know exactly what the best practice should be. The general principle is that Python needs to see at least one active reference to an object so that it doesn't collect it. For this purpose I use a class member variable to track custom high-level PyQt widgets that I create which I remove when the widget is closed.

class _Widgets(object):
    _instances = []    
class MaxWidget(QtGui.QMainWindow):                
    def  __init__(self):
        self.parent = QtWinMigrate.QWinWidget(getMaxHwnd())
        QtGui.QMainWindow.__init__(self, self.parent)        
        _Widgets._instances.append(self)
    def closeEvent(self, event):
        if self in _Widgets._instances:
            _Widgets._instances.remove(self)
 

Making sure that accelerators are disabled when your Widget has the focus

Another challenge with UI code in 3ds Max is that the main window of 3ds Max will interpret most key-presses as shortcut keys. When you have an edit field in a Python UI this can pose some obvious problems. Normally in regular 3ds Max UI programming we can use the DisableAccelerators API call to temporarily disable shortcut keys. The problem with PyQt is knowing exactly when to make this call.

Intuitively we may think that overriding the Qwidget.focusInEvent() would work, but when using PyQt with Win32, the event is not triggered automatically when switching from a non-PyQt managed window to a PyQt window. The best approach that I have been able to come up with is to install an event filter of the QApplication instance that previews all mouse clicks. If the QApplication exposed to Python sees a mouse click, then we assume that a PyQt window has gained focus and we can disable accelerators. It’s a bit hacky, and I'm sure the more experienced Python programmers out there can suggest an alternative, but this is the best I could find for now, at least until we can make improvements to the core.

Putting this together with the other techniques here is a complete code example

# To execute from MAXScript (if in your <maxroot>/scripts/python folder. 
# python.executeFile "auDemoPyQt.py"
import MaxPlus
import ctypes
from PyQt4 import QtGui, QtCore
# Requires PyQt4 binaries from Blur studios https://code.google.com/p/blur-dev/downloads/list
from PyQt4 import QtWinMigrate
# Get or create the application instance as needed
# This has to happen before any UI code is triggered 
app = QtGui.QApplication.instance()
if not app:
    app = QtGui.QApplication([])
def getMaxHwnd():
    ''' Get the HWND of 3ds Max as an int32 '''
    mem = long(MaxPlus.Win32.GetMAXHWnd())
    return ctypes.c_longlong.from_address(mem).value    
class _Widgets(object):
    ''' Used to store all widget instances and protect them from the garbage collector ''' 
    _instances = []    
class _FocusFilter(QtCore.QObject):
    ''' Used to filter events to properly manage focus in 3ds Max. This is a hack to deal with the fact 
        that mixing Qt and Win32 causes focus events to not get triggered as expected. '''   
    def eventFilter(self, obj, event):
        # We track any mouse clicks in any Qt tracked area. 
        if event.type() == QtCore.QEvent.MouseButtonPress:
            print "Mouse down", obj
        elif event.type() == 174: # QtCore.QEvent.NonClientAreaMouseButtonPress:
            print "Non-client button press", obj 
        else:
            return False
        MaxPlus.CUI.DisableAccelerators()
        return False
class MaxWidget(QtGui.QMainWindow):                
    # Note: this does not work automatically when switching focus from the rest of 3ds Max 
    # to the PyQt UI. This is why we have to install an event filter.  
    def focusInEvent(self, event):
        print "Focus gained on MaxWidget"
        MaxPlus.CUI.DisableAccelerators()        
    def  __init__(self):
        print "Creating MaxWidget"
        self.parent = QtWinMigrate.QWinWidget(getMaxHwnd())
        QtGui.QMainWindow.__init__(self, self.parent)        
        _Widgets._instances.append(self)
        # Install an event filter. Keep the pointer in this object so it isn't collected, and can be removed. 
        self.filter = _FocusFilter(self)
        app.installEventFilter(self.filter)
    def closeEvent(self, event):
        print "Closing MaxWidget"
        if self in _Widgets._instances:
            _Widgets._instances.remove(self)
        # Very important, otherwise the application event filter will stick around for 
        app.removeEventFilter(self.filter)       
class MyWidget(QtGui.QWidget): 
    def btnPressed(self):
        print "Button pressed"
        if self.parent():
            self.parent().setFocus()
    def  __init__(self):
        QtGui.QWidget.__init__(self)
        self.topLayout = QtGui.QGridLayout()
        self.nextLayout = QtGui.QGridLayout()
        self.textEdit = QtGui.QTextEdit()
        self.textEdit.setText("Hello world")
        self.btn = QtGui.QPushButton("Apply")
        self.btn.pressed.connect(self.btnPressed)
        self.nextLayout.addWidget(self.textEdit)
        self.nextLayout.addWidget(self.btn)
        self.topLayout.addLayout(self.nextLayout, 0, 0)
        self.setLayout(self.topLayout)
def main():
    main = MaxWidget()
    w = MyWidget()
    main.setCentralWidget(w)
    main.show()
if __name__ == '__main__':
    main()

Introducing Max Creation Graphs

$
0
0

Introducing Max Creation Graphs (MCG)

Now that 3ds Max 2016 has been officially announced I can finally come out of stealth mode and tell you why you haven't heard from me for over a year!

Eddie Perlberg had me locked me up in a basement along with Martin Coven and a team of talented developers and QA until we completed the #1 most request feature for 3ds Max.

The result of our effort is a new feature in 3ds Max 2016 called the Max Creation Graph editor (or MCG for short). This tool enables user to create modifiers, geometry, and utility plug-ins using a visual node-based workflow.

With MCG you can create a new plug-in for 3ds Max in minutes by simply wiring together parameter nodes, computation nodes, and output nodes. The resulting graph can then be saved in an XML file (.maxtool) or be packaged with any compounds (.maxcompound) it depends in a ZIP file (.mcg) which you can share easily with 3ds Max users.

https://www.youtube.com/watch?v=E2Pv2-zjHD4

Once an MCG tool is evaluated you will have one of the following:

  • New objects primitive in a the "Max Creation Graph" category in the creation panel
  • A new modifier in the modifier pull-down
  • A new MAXScript utility
  • A new MAXScript function

After evaluation two files are generated next to your .maxtool file

  • A MAXScript plugin wrapper (.ms)
  • A representation of the .NET function compiled from the graph (.txt)

MCG is not Softimage ICE

Despite the title of the original request on user feedback (which you might notice was first suggested by Martin Coven before we hired him, I'm sure he is glad to finally get his votes back) and the obvious similarities this is not an integration of Softimage ICE in 3ds Max. At the heart of MCG is a brand new visual programming language we developed on top of the .NET framework.

Some of you may also be familiar with another open-source visual language from Autodesk called Dynamo and see some similarities. Dynamo is very similar to MCG (it is easy to extend using .NET and supports some functional programming concepts) but at the core is an interpreter whereas MCG is compiled directly to .NET byte-code. This design choice made sense for Dynamo, because it was designed for parametric geometry construction, however the performance was not sufficient to enable us to create tools for 3ds Max users.

3ds Max users expect all parameters of geometry and modifiers to be able to be animated and to have the results updated in near real-time in the viewport (usually buildings don't dance, but they can in 3ds Max). Because of this requirement we had to develop a full compiler. I'll bore you with more details if you buy me a beer (or I accidentally start to blog while drinking).

A functional dataflow visual programming language

For the most part MCG is a traditional visual programming language. Nodes perform a transformation on data that flows through input connections and output the result to the output "value" connection.

One characteristic of MCG that is immediately apparent is the fact that there are "function" connection outputs. This enables computations to flow through a graph as data. In computer science we call these first-class functions.

When a node is connected from the "function" output, the entire left sub-graph is treated as a function, with unconnected inputs in the graph treated as function arguments. This is equivalent to the lambda abstraction operation. More on this in later tutorials.

In MCG we can not only pass functions as arguments to higher-order functions like "Map" or "Combine" we can also return functions from operators such as "Bind" which performs a partial application or "Compose" which performs function composition. We can also store functions in arrays. I'll go into more details on this in a future blog post. 

A few things to note about MCG: most data that flows through the graph (with a few exceptions such as "INode", "Cache", and "Random" objects) are immutable data structures. In other words MCG is nearly a pure functional programming language (like Haskell). An example of this is that when you send data into a "SetValue" node the array you get on the other side is a new array, and the original one remains unchanged. This was done so that multi-threaded evaluation (e.g. via "ParallelMap") could be done quickly and easily. I promise more information on multithreading in a later post.

The Future

We are a publicly traded company which implies certain legal obligations, so unfortunately I can never talk about the future as much as I would like. It always makes me a bit sad, because I spend a lot of time thinking about the future … more time than my boss would like. :-)

https://www.youtube.com/watch?v=tmudH_C97O4

At the very least I hope that I have proven to you that by going on to 3dsMaxFeedback.autodesk.com YOU are directly influencing the future. Yes, big requests might take four years to deliver on, and sometimes we can't tell you we are working on them (it is a very competitive business after all) but we are paying very close attention.

I never forget that without the support of our users there would be no 3ds Max, and I wouldn't have my dream job.

Sample MCG Tools

For some sample MCG tools made by our team see this blog postThere are also a number of 3rd party sample tools and videos posted on the MCG Facebook page.

On the Autodesk 3ds Max Learning Channel on YouTube you can find a tutorial series on Max Creation Graphs: 

https://www.youtube.com/watch?v=YBPVUvvMdD0&list=PLnKw1txyYzRl1IVsbSFwd-c9i9cz-rRJ1

For inspirstaion, here was the demo video made by Martin Coven: 

https://www.youtube.com/watch?v=3nsAlw_j4lQ

Acknowledgements

MCG would not have been possible without the hard work of a talented and passionate development team. The core team included Martin Coven as designer and instigator, myself as architect, along with Abdelhak Ouhlal, Attila Szabo, Clint Lewis, Rick Delesdernier, and Roman Woelker. Larry Minton and Tom Hudson also contributed at crucial points to help develop key functionality. Martin Ashton played an important role developing the initial prototype of MCG and I look forward to the tutorials he creates on his YouTube SDK and scripting learning channel.

Of course this is an effort that spanned the entire 3ds Max team. No feature is developed in isolation, it takes an entire team of people working together to deliver 3ds Max. The whole team has worked hard to create a release that I am truly proud of.

I personally want to thank Eddie Perlberg, Michael Russo, Kelcey Simpson, and Chris Young for believing that our team could deliver on such a bold and daring vision, and supporting us through the process.

I also want to thank all of the Beta members and 3dsMaxFeedback contributors for their invaluable feedback, support, and encouragement.

Final Words

For now I want to leave you with the same words that Eddie shared with me recently "This is just the beginning."

Max Creation Graph (MCG) Sample Pack for 3ds Max 2016

$
0
0

Now that 3ds Max 2016 is available for download I'm pleased to announce a set of 30 sample MCG tools and 80 new compounds that you can download, use, and learn from! 

https://www.youtube.com/watch?v=ckfdHlzisTY

In order to install the tools unzip the contents of MaxCreationGraph.zip and it into your Max Creation Group user folder. You can navigate directly to that folder by pasting
%userprofile%/Autodesk/3ds Max 2016/Max Creation Graph
into your Windows explorer. 

If you have any other compounds and tools installed, be sure to back them up first, in case some files in the zip package have the same name as existing files. When you restart 3ds Max you should see a number of new modifiers in the modifier pull-down. Each name of the new modifier starts with "A" (e.g. "APush"). There will also be a new category in the object creation panel called "Max Creation Graph" with several new tools. 

I have also created a sample test file that you can load once you unzip the tools and restart 3ds Max here: MCGSampleTestScene.zip

Your comments and questions are certainly appreciated, enjoy!

Viewing all 73 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>