Plug-Ins

You need Microsoft VC++ at least version 4.0. We use the MS cross compiler to make the Mac version, but since they discontinued it, we will port your plugin to the Mac, but we need the source code.

-Ken Baer, Hash Inc.

Go into the folder "After Effects/Plug-Ins/standard/format" and look for one that says "targa"-something. Drag it out and put it someplace else. Then copy the similar file from Photoshop's folder into the above folder. I "believe" we can thank Mike Caputo for this....

-Steve Sappington

Right Steve, Select:

Adobe AfterEffects>Plugins>Standard>Input/Output>Targa(AE)

and replace it with a copy of

Adobe PhotoShop>Plugins>Standard>File Formats>Targa

Tommy DAQ

It isn't closed!!!!!!!!!!!!!!!!

The format of the files are there for anyone to read and write to. My own attempt consists of about 2.5 K lines of perl code. Here's the inital comments of my perl module ...

# A module that will read and load Hash Inc.'s MH3D version V files, # and build up Perl in-memory objects representing all MH3D objects, # and write them back to a file. # # Currently this includes: # splines, control points, segments, groups, materials, links, # shortcuts. # Linked files are treated as read-only. # # All will be realised eventually. Until implemented, a section # is just read into an array, not an actual structure. # This module does not attempt to create or manipulate these objects # (other than reading and writing). Other modules will deal with the # attributes and structures relevant to various objects. # # This module should be maintained so that it reads in the latest # MH3D file. Where incompatible changes occur, there will be no # attempt to handle earlier versions of files. Presumably Hash Inc. # will handle this, so just do what they suggest. Any version V # MH3D executable should be able to read in all past version V files, # so just read in and save out your file, then try this module. # # To support this module, please get the latest version available at: # ??????? # and e-mail me at pricecg@netlink.co.nz any problems you encounter. # # The two subroutines to call are: # readV5file(file handle), # writeV5file(file handle). # # Chris Price # pricecg@netlink.co.nz # # copyright (c) 1997 Christopher G. Price # # In-memory Objects # # Eventually all will be realised. # # Note that refs are pointers to the object not IDs. # Pointers enable complex manipulation of objects. # As well, Perl offers a decent array mechanism compared to C. # # A %xyz is a hash array (or an associated array, not necessarily # an Hash Inc. array) that has keyed values. In Perl structures are # not predefined, you define what you create. # # %modelList # key model name # value [0] anon hash array # key attribute name # value [0] attribute name # [1] value # [2] order read in # [1] array of shortcut refs (materials) # [2] array of Spline refs # [3] array of top level segment refs # [4] array of group refs # Both segment and group keys are made unique # amongst models by appending the key with the # model name. # [5] reference to anon array of pose section lines # (until we write to a structure) # [6] reference to anon array of icon section lines # [7] file name (full path). # If this is defined, then the model was read in # via a file link, and will be written out thus. # Maybe dirtyness will be implemented. # Currently linked files are read-only, so the # above is not yet implemented. # [8] reference to array of patch section lines read in # (We create patches from high-level objects, at the # same time the splines are created. Because there # may be patches read in, we do a check on the # existance of the involved CPs and not write any # invalid patches.) # [9] array of refs to anon array of decal section lines # (until we write to structures) # # %controlPointList # key control point ID # value # [0] control point ID (for CP referencing) # [1] array of 3 element x y z coordinates (anon array ref) # or a CP reference for attached CPs # [2] unique meaningless spline id reference # [3] hook value, if it is one # # Spline IDs. # # Prior to august 1997 (5.10??) the spline pieces had # numerous values (bit flags in a 28 bit field) in front # of coordinate CPs (type 0) as well as attached CPs (type 1). # # Now there are few numbers (few flags set), and attached # CPs have an id of 1. # # It looks like there are a few bit flags for the # spline piece sequence settings (peaked/smooth,). # # The current spline piece reading scheme does not attempt # to reset older v5 files to the newer system. # Further experimentation is required. # # $CPs = \%controlPointList # # %uniqueMH3DSplineIDList # key A numeric ID in front of many CPs . # value = key # # %splineList (Really spline pieces). # key my spline ID. # value [0] array of CP refs # [1] array of 2 element attached spline ref/CP ref # [2] my spline ID (for referenced splines) # [3] array of refs to anon six element array of # in/out Curves factors, mapping to each CP ref. # # $splines = \%splineList # # %groupList (dot is string append) # key "group name"."model name" (group name also in hash array) # value [0] anonymous hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # [1] array of CP refs (initially original CP ids that are surplanted) # [2] ??? array of spline refs ? calculated value # [3] array of shortcut refs (materials) # # $groups = \%groupList # # %segmentList # key "segment name"."model name" (segment name also in hash array) # value [0] anonymous hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # [1] parent segment reference # [2] array of children segment references # [3] array of non-skinned CP references # # $segments = \%segmentList; # # # %cameraList # key camera name # value [0] anon hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # # %lightList # key light name # value [0] anon hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # # For shortcut key uniqueness append owner's name # (group, model, etc), and shortcut type # to shortcut name. # %shortcutList # key "shortcut name"."owner name"."shortcut type" # value [0] anon hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # [1] array of references to various anon arrays # of shortcut section lines. # E.g., light chore actions. # [2] type

model, material, action, camera, light

# # # %materialList # key material name or generated attribute number # value [0] anon hash of various attributes # key attribute name # value [0] attribute value # [1] order read in # [1] Empty # (for material container) # if linked material, fully qualified file name # else expanded flag # [2] attribute type

ATTRIBUTE, NOISE, GRADIENT, # SPHERICAL, CHECKER, TURBULENCE

# or (for material container) MATERIAL.name # [3] first attribute reference # or (for material container) top attribute reference # [4] second attribute reference # or (for material container) selected flag # [5] third possible attribute reference (turbulence) # or (for material container) modified data/time # [6] icon reference # # Combinations on CD: A, NAA, CAA, CAAT, SAAT, NNAANAA, CANAA, # SNAANAAT, CCAACAA, SSAASAA

Here's a third party development plug-in strategy:

know your V5 file formats (reading and experimentation)
choose a language to develop in
create the reading and writing code (a language's in-memory structure <-> file format)
create an object interface for primitives
and more until a reasonable foundation has been established

I'm starting stage four, with a reasonably working read/writer in perl. This stage will go a lot smoother and much more rewarding than the juggery pokery involved in file format reading/writing. Perl is brilliant for that task and will be fine for object oriented development.

Basically the above provides "a lot you can do" with the file formats.

What is a real-plug-in development environment? I'm creating mine. What environment are the 3DMax plug-ins develop in?

Chris Price

This seems like a very debatable issue. I've got some random thoughts about it, but I don't think they add up to a definitive opinion:

There is a difference between messing with the file formats, making a scripting language, and making a plug-in architecture. Virtually all file formats can be messed with if enough information can be found about the format. This could theoretically lead to more translators (import COB's or anything, etc...). This could also lead to bigger things, like a particle system, but only through a sort of work around. You run a script or program on a file you already created in Animation Master, and it inserts the necessary information for whatever you wanted it to do. Limited in that it cannot interact with the program, and must be run outside the program. For adding some tricks and translations, great, but far from a true extensible option.

A scripting language, like Real's RPL, is also helpful, especially when, like in the case of Real, it has access to virtually all of the program. Now you can add features and new things, but to actually sell them (as you pointed out) is trickier. Though, not impossible, as Real does. Look at something like Corel Draw. When they added scripting to v6, it expanded the power of the program by far more than any other feature they added. Their intent was people would trade the scripts via the internet, etc. People do, but not quite to the extent I think Corel hoped.

Maybe a better example is POV. The modeling language itself is a scripting language much like C. This has allowed endless additions to the package, everything from lens flares to character animation. People trade the scripts all the time and no one tries to sell them (then again, it would be even tougher considering POV is free).

A plugin architecture is another thing, the ability to have a program that can interact with the main program in a direct way. And not a program written in a scripting language, but a real honest to goodness program. There are several really bad examples of this - Netscape and 3d Studio. The problem with 3d Studio is the cost - it is an expensive program that only does really powerful things with several big plugins, that are even more expensive. Paying $800 for a plugin is horrible when A:M itself is cheaper. Netscape is another bad example, because the program itself is not based on plugin architecture, it just uses plugins as a way to add functionality. One plug-in is not compatible with the other, there is not good standard set of plug-ins, etc. It is a mess, though it is cheap.

Better examples of plug-in architecture exist. Like Adobe Premiere. Not only can you add filters, like PhotoShop, but the system itself uses plug-ins for all but the basic program. Thus, if a vendor wants to add its own video capture module, or anything else, it can. Plus, Adobe themselves need only work with plugins. A bug in the time line module? No need to re-issue the whole program, just re-issue that module (plug-in). Easy.

In the end, the list of programs that have benefited from either scripting (whether macros or full languages) or plug-ins is longer then the list that have been hurt by them. For the best examples, look at other 3d programs. OK, we already know 3d Studio messed it up. But look at Lightwave. The package comes at a certain price with lots of features (just like A:M, but we all know which is the better buy). Some of these features are implemented through the plug-in architecture, some are standard features. 3d party developers can make commercially available plug-ins. And they are not all that expensive. Fiber Factory adds hair creation, Particle Storm advanced particles, etc. And the plug-ins don't all range up to $800 like 3DMAX. Now, you can buy Lightwave, and take it to the level you need. If you are only going to use it for flying logos, don't buy anything more. If you want to use to in place of pyrotechnics for your explosions, buy only Particle Storm. If you want to do full blown character animation, you might have to buy a lot. But if that is what you need, that is what you get. Plus, it does scripting (by Rexx, I believe) and you can make your own in-house plug-ins that you do not make commercially available.

This sort of power is the only way a professional animation house can really use a program. ILM might use a lot of Softimage, but they couldn't if it wasn't completely extensible with their own plug-ins and shaders.

I'm rambling here, let me pull it together. Think of a world where A:M was expandable through plug-ins. It already has a toon shader and volumetric lights. But what about particles? Hash has already said they are back burner. Same for dynamics. What about shaders - other than volumetric lights - like local fog? Or hair? Modeling options, like extrude on a path. All could be added by anyone at any time via the interface. If you don't need particles (as Hash says many people have responded they don't), don't get the plugin or spend the money. If hash wants to put particles into v6, they still can. Nothing stopping them. If the $200 price mark of MH3D seems too low for such additions, make Plug-ins only part of A:M. If you are a hobbyist and don't want to spend $800 on a plug-in, don't. But if you are a professional studio and think A:M would save you a lot of time and money if only it did volume shading of objects, then you could make your own volume shader or buy one. Total package price would still be half that of the next package that could do the same thing.

Basically, it expands both the creators and users options, which is (almost) always a good thing.

Sorry for the rambling, just my 2 cents in the end.

Plug-Ins

What's new...