Rodney

Here's that same GPT generated airplane with some minor tweaks (mostly to control point positions):

If you have GPT model the thing... you get what you get.

I was having GPT model shapes made out of tubes with varying degrees of success. For instance, this cartoon dogs head (here modified to connect the tubes and eyes added manually by me) The drawing of 'tubes' by me in an effort to have GPT shape and place tubes in 3D space. One thing GPT can do short of actually creating the models is help plan the model by creating the plan for modeling via an image. This assuming you don't want to draw it yourself. Then you can just model the thing yourself.

I really want to pursue lens-flare powered explosions but... haven't moved in that direction very far as of yet. Here's a quick proof of concept: (All the 'action' intensity animated directly in A:M just using a generated light grid) Added the project file. gridflareexplostions.prj

Shifting gears yet again I thought I'd explore a favorite although obscure feature of Animation:Master: Model's with lights and/or cameras inside. Initial success led to a simple light grid generator proof of concept where light color and intensity might be 'painted' onto a grid of lights.

For cases where the splines/patches follow what will be textured on the surface don't forget Patch Images. Ideally, we'd have dedicated images for the various types of patch image; diffuse, bump, specularity, relectivicty, transparency/cookie-cut, etc. but sometimes just using the same image for the various image types can produce interesting results:

Okay, what's going on here? In trying to model some curved splines and patches I had GPT create a treasure chest (not particularly successful). A treasure chest needs gold coins though right? So, had GPT made stacks of gold coins. Successful but time consuming to tweak and rerun with variations. So, what to do? Answer: Have GPT create a python program to create stacks of gold coins with easily adjusted settings. Many of the variables were informed by my failures to create good looking stacks of gold coins. For instance, if too close on top of each other the stacks look too much like long tall objects. Even though the coins have random shades of orange and yellow. So, need some distance between coins vertically. Perfect stacks horizontally don't look good either. So how about a 1 in 10 chance the coin will go in the same direction as the last coin placed? Etc., Etc. I started with GPT creating clusers of stacks with 1000 coins total. Not the best starting demo and we want the user to set all those numbers as well (min and max for stacking etc. too) Here's Take 1 results out of the python program that replicated the basic process GPT was using. Not bad. Save out a file with the settings for that (in case we want to recreate the same or similar set of coins (seed value allows us to get same results with random numbers) Try 1000 coins (the programs current max count) as these models are being generated immediately and... As each coin/object has it's own group we can grab any coin we want and adjust. Don't want to stack coins? Point to a different model, such as a sheet of paper. These processes are pretty good at plussing up the Duplication WIzard. Which reminds me. I didn't add an option for rotating each object as it is placed.

After having GPT extend the buildings, storefronts and street with cars another 10x wide I set up a few cameras and ran through the scene. The 'helicopter shot': storefront_helicoptershot.mp4

I'm trying to get GPT to place the Named Groups that contain smaller details and not collections of objects (almost always with the ALL prefix) at the bottom of the heirarchical listing we get all the colors assigned automatically to those shapes to appear. Currently GPT is inverting that listing which hides the color underneath groups that hide those colors. Here GPT generated a (one shot) city block with storefronts and cars out on the street in front of the stores: This looks much better than when everything of the same kind is all the same color because of that group color overwriting surfaces assigned to other groups.

The sports car drag/dropped into a default Chor and positioned. Added a tank as I thought the more mechanical angles of a tank might be easier for GPT to model. Keep in mind that I'm not supplying any reference material on what these objects should look like. GPT is doing the design work on its own.

GPT does struggle with more organize curved shapes but I chalk that up to me not giving it good examples to study. Here's a sports car (where again I had to flip most of the normals manually): I gave it a modified pipe.mdl from the A:M Library as a suggestion for the tires and that worked well. I should have had it assign surface colors to the groups as it opted to color everything red. Edit: Actually it did color parts of the car differently but the last group was incuded everything and was colored red so it overwrote all the other group colors.

I took a break from exploring that ModelManager and went back to see if GPT remembered how to build basic shapes into reasonably recognizable models and extract models from that master model based on Named Groups it created while generating those objects. Thee resulting master model and then the individual models extracted turned out pretty recognizable. I dropped those models into a new (empty) Chor and everything fell into place. (minor adjustments of positioning for asthetics in the referenced models) I did have to flip the majority of patch normals in all of the models manually as Find Normals in A:M didn't resolve that. I'm now trying to get GPT to figure out why so many normals are pointing the wrong way. I opened a few materials from A:M's Library and dropped those onto the individual models. Turned off the Chor's default lights and added two of my own. The result:

It seems GPT picked up on the problem and added a pass for older (Legacy) models without me asking for it. Model that didn't even appear before now appear as the initial passes gray silhouettes.

As much as I like the 3/4 view there is an appeal to the front only view: Older models have to be updated to appear in my modelmanager as I haven't added support for older models not in A:M's modern format. These are random models grabbed from the Free Models section of this forum. The '_26c' appended to the filename here stands for '2026 candidate' in a general review for modern compatibility.

In thinking about how we might parse large collections of models here might be a general plan: Modelmanager.py Main GUI Browses contact sheets Reads index/cache files Starts/stops background helper Opens model locations modelmanager_worker.py Background scanner/renderer Recursively finds .mdl files Generates previews Builds contact sheet pages Writes metadata The idea being to have the main program call the helper script to do the work behind the scenes. The user then is free to navigate through those contact sheets that are available with minimal delay. When done, a master html file can connect to all the contact sheets so that the user need not use the program to view the content unless they want to update the contact sheets and the content they contain. Added: Off to the side is a desire to have this process add the preview icons to the model files so that A:M itself can display what the models look like in A:M libraries. An issue with this for the Extras CD/DVD was that most models (and other A:M files) do not have preview icons so their default counterparts for that type of file are shown instead. This makes viewing those assets via libraries and other means less useful. On the down side, adding the preview icon to the resource does add additonal size to the file as that image data is embedded in the text of the file.