Rodney

I've sent my photos Mark! Thanks and my apologies for the delay. Roger, I'd take your photo for you but.... you may still be somewhere in the Midwest that isn't near to me.

Okay Matt, you've got me intrigued BUT... your link doesn't go anywhere for me and I don't see any other recent topic related to trees posted.

Yes, there are multiple ways to approach this the simplest way being just to rotate the instance 30 degrees and be done. For more automation (of turning of many trees) I'm sure a random expression could make sure every tree in a scene is turned slightly different that the others. A breakthrough in Modeling for me occurred when I saw other people Modeling in a Choreography. I was like.... whoaaaa... we can do that?!?! To keep file sizes low we would then just save the entire Project (or Chor... some people don't save Project files... only Choreographies.... but this is a tale for another time). If the desire were to be to have everything as one mesh (and not modular parts of a whole) then all we have to do is export to Model from the Chor.

Everything is generic (modified cubes) in this test but I wanted to get the patch count up higher for testing purposes. If I calculate correctly this Chor has the equivalent of 77,000** plus patches which are instanced from 1 original file (consisting of 6 buildings apiece that contains approx 11,000 patches). The Project file (with everything embedded in it) saves immediately. While I'd have to check, I believe the Project file also contains the individual story of one building that is duplicated three times in height (to get 4 sections/levels per building). If doing this again I'd probably make the windows of a type that could appear more detailed as well as give the tops of the buildings some type of detail. All of the buildings where turned 45 degrees via an action before being exported out into groups of six buildings. In the image you can see top center a building that is larger than the others. This was a quick test to resize an instance (not the original) via a Chor Action. To get differentiation in similar objects that have varying details... that's where Poses (pose sliders), Actions and such come in... but none of which are in this test. I know your setup is more detailed but am just going through the paces of testing to see what might be causing the specific issues you are dealing with. If you have tons of patches that will definitely take more time for A:M to process. If you have copy/pasted tons of patches that aren't optimized that will take additional time to process. In the image you can see top center a building that is larger than the others. This was a quick test to resize an instance (not the original) via a Chor Action. It can help to think of Modeling in similar way to Animation. We don't blast every bit of information into one frame but put what is needed where it is needed throughout. One of the benefits of computer animation is reusage where we don't have to recreate everything... every time... from scratch. We can just point to the resource and say, "(As a starting place) reference that." Edit: Nice example Nancy! I wish I'd thought of that. *Generic project is attached **According to A:M''s Info setting (RIght Click and select Info) the Chor contains just over 86,000 patches (remember though that only 11K of those are original patches). 81K plus.prj

I think we need to introduce you to the art of instancing. It's far easier (from the programs vantage point) to save a link to a resource than the resource itself copies many times. A question that might be asked is, out of those 800 or more decorative roof braces how many are exactly like each other? If the answer is 'They are all exactly like each other just put into different places' then you can drop that patch count tremendously just by referring each one back to the original. The the file only needs to save the original plus the 800 textual links (not sets of patches). I'm in the middle of a test (creating a cityscape of hundreds of buildings with hundreds of windows) to see how much it slows down my computer. At present A:M has ground to a halt while it's attempting to save the model. In a little while I'll try the same thing with referenced instances of original models. I guess what it boils down to is determining how many unique shapes you have in your setup and then optimizing your project from there. You mentioned 240 windows. I assume that is 240 of the same window duplicated over and over again. ...and of course, once you have the model rendering perfectly that'd be a good time to capture that render for use as a decal so you can place the resulting image back on a model with minimal patch density. In that way a 300,000 patch model can be whittled down to (easily?) less than 100... give or take areas where you may need close up detail.

I know what you mean. I think we all like to see our efforts rendered. I trying to cure myself of that! There are some ways we can get a good look at what the render may spit out for us. Render Lock Mode (Shift Q) is the main one I use (although I'd like to try to cure myself of using it). It's the one that we need to hit the Escape key on to tell A:M we don't want to see that preview. If there is a specific part of the screen/render we need to see we can hit the Q key by itself and then drag our mouse (while pressing down the left mouse button) and that will preview render that selected area of the screen. This won't render to file, it's just for us to get a quick look at what the final render will look like. There are some other options as well but I don't use them often. I try my best to stick with the realtime view and just get a sense of what the final render will look like based on that. The more complicated the scene (lights, particles, etc.) the more the final render will diverge from that previs. One thing you can to also is just render one frame of a sequence before turning the renderer loose on the full sequence. \ Like I said, something is very wrong there. It'd be good to figure out what that is. I must assume here that by 'save' you don't mean 'render' as those are two very different things.

Gah! You just made me realize I still haven't given Mark my photo! Yikes. Sorry Mark. You are seriously out of control.

Something is definitely wrong there. At the most it should only take a minute or two to save a file. Normally it will only take a few seconds. Yes, Fuchur has got the right advice! HItting the Escape (Esc) key should bring you out of a render and back to life. Rendering should never lead to losing work and *if* you get in the habit of always saving *before* rendering you won't ever need to. At times I've thought about putting in a request to have A:M save prior to rendering but there are times when folks may not want to save over a current file and just want to see the rendering results. Still, it's a bad habit not to save before rendering. The ideal process (in my estimation) is to save with an incremental number or letter in the file name. As this is similar to rendering sequential images that would be part of the feature request too. A:M does have a Backup feature but it isn't triggered by new (final) renderings. That's be nice. Other than saving a lot of heartache losing files the other thing that is good about saving before rendering is that saving to file frees up more memory for the renderer to use as A:M doesn't have to worry about unsaved changes or memory caches. Examples of incremental filenames could include: MyfileName A 001.prj MyfileName B 001.prj MyfileName.B 002.prj MyfileName B 002a.prj How you name the file isn't as important as the fact that you've saved the file under a new name. In this way you can get back to a previous version of your file if and when you need to. An exception to this would be if you are saving your files to some place that automatically maintains a version. This is true of some cloud services. I haven't done it lately but in the past I use to number my files incrementally but letter my files in reverse alphabetically order. Example: ThisIsaVeryCoolToonRendering Z 000.png ThisisaVeryCoolToonRendering Y 000.png ThisisaVeryCoolToonRendering X 000.png The idea behind this was to give me a sense of moving toward finality/deadline because as my file approaches the letter A (after starting from Z) I know it had better be getting close to being done. At a glance then I could see that a filename appended with a letter 'M' was very likely good enough to call 'done'. Especially if there were a bunch of letters between N and Z and none between A and L. Of course, instead of the letter a few words about what changed in the setup/project would work even better. Example: Particle Sprite Fireworks Blue 50 particles per second v1.prj Hope that makes sense! At any rate. The advice is save often and save incrementally. Followed by the secondary advice, 'always save right before you render'.

H,264 is a going codec these days. I (just now) downloaded and used Handbrake to convert your AVI to that codec and then it even played in Quicktime. If you use Handbrake note that when I first tried to get it to see the AVI file it seemed like that format wasn't recognized. I used * to see it in the open dialogue and then it converted it fine. I haven't used the feature but it appears that Handbrake can monitor a folder and convert files that appear therein on the fly. It may just be wish fulfillment on my part but theoretically that'd mean that we'd render (in AVI) to a folder monitored by Handbrake and automagically get the converted (MP4) file. I see there is a command line version of Handbrake also and that could be automated via batch file. Bottom line: I know that short of using the 32bit version of A:M to render/convert to .MOV we don't have a lot of native options at this point but AVI isn't a particularly good online format. Don't forget that you can run 32bit A:M in 64bit Windows (Win 10 or otherwise).

While I could see the preview image with Quicktime only the sound would play. In the end I had to open the AVI with VideoLAN (VLC).

Interesting... In two days their new campaign has taken in more than the total amount for their entire Kickstarter... and they are over half way to their goal with 44 days remaining. I'd say that the press and initial interest from the Kickstarter jumpstarted the new campaign. Perhaps someone needs to start a 'Jumpstarter' site just to get the word out -before- folks launch a campaign? One oddity... Don and Gary appear to still be posting on the Kickstarter which makes me wonder about the rules o' the fundraising game. Do the folks at Kickstarter care? There are a lot of movng parts in any fundraising effort and while the initial fundraiser did get some decent coverage it did seem to have a few things working against it. One of which was that its final days fell smack dab in the middle of the Thanskgiving week where folks were busy with other things (to include saving their money for Black Friday sales?) At any rate, the jury is still out on whether the campaign will be successful but at the current rate of funding I'd say Don and Gary will hit their goal this time around.

Nice one John. Almost looks like a singing volcano.

My sympathies to you. But look at the bright side! At least you were good at algebra once! My daughters knew me well enough to bypass me where it came to math.

For those interested... Don and Gary halted their Kickstarter just prior to it failing to meet it's goal and moved the entire endeavor over to Indiegogo. Will they be more successful? Hard to say. They are currently at 20% of funding 6 hours in with 617 backers and 45 days to go. https://www.indiegogo.com/projects/dragon-s-lair-returns/x/9070129#/

It doesn't surprise me that info would have changed. It is proof positive that due to the rate of change/innovation in a digital environment as soon as documentation is written it is already outdated. While I often get information wrong... very likely more often than I get it right... one thing I try to do is look at trajectories. Often these trajectories have hints of what will work in short term only. This usually includes pricing and quantities as those are competitive vantage points that can change very quickly. This is not unlike when we use absolutes in are projections, "I will NEVER do THAT again." That's a bit like saying, "Wait a second and watch me make that mistake again." While I don't care for a lot of Adobe's approach it is clear they have gone all in regarding their commitment to subscription service. As such they keep trying to make it a more valuable service with every iteration. They won't get it right every time but odds are they'll get enough right to remain in business.

Concerning mesh alignments for use with Fuse the following is an example of what I mean by the software relying on UV settings rather than mesh/geometry:

Nicely done Matt. MMMMmmmmmmm,,,,, need pizza.

Nancy, As for getting meshing into Fuse, it appears that there is a Import Wizard that helps guide through the steps to create a Fuse Character. The resulting character is then modular and therefore can be customized via the standard Fuse sliders. Several companies seem to have embraced some technology used in Substance Painter. Fuse appears to use this approach with procedural texturing for it textures. Specifically, Fuse allow importing of Substance files (which I assume to be the same as that used by Substance Painter). Hmmm... procedural textures... I wonder what other programs use such things. Disclaimer: I cannot confirm or deny, the only link between Substance Painter and Fuse's substance texture files may be the word 'substance'. Update: I have confirmation that Adobe Fuse uses Allegorithmic Substance Painter textures.

Haven't had it long enough to investigate properly. I do see a bunch of cartoony charcters on Mixamo so those files are getting there somehow... perhaps directly into Mixamo bypassing Fuse altogether. As I see it Fuse is primarily a use of technology Adobe obtained when they purchased Mixamo (and whatever other companies are represented). This is a lot like any of us sitting around dreaming up things we can create with the tools we have available just with a whole lot more money being exchanged. .

The short answer appears to be 'yes'. While things could change I did read that subscribing to Adobe CC grants access to Mixamo although I can't imagine it's 'all-you-can-eat' that does appear to be an option because Adobe wants folks to contribute. Somewhere else there is a post that outlines their original plan athough who know to what extent that may have changed. It's been awhile but that other post scratched the surface on this. As long as the model is OBJ (or FBX?) the autorigger will work. Much of the connectivity has to do with new approaches to using UV data. This is similar in some ways to Marvelous Designers use of UV data to solve mesh connectivity. Disney has borrowed some of that same technology (UV driven meshes) of late and the way they appear to be doing it is interesting. It'd be a bit like us being able to lay down splines (or perhaps more appropriately stated... patches) in A:M's Decal Editor. The splines/patches would then appear textured in the modeling windows ready for final retopology. It's a bit over my head but there are some Disney tech documents that go into some detail. The short answer is 'yes' here too. We can deduce this if for no other reason that Adobe Fuse can be used as the middleman software to get any OBJ mesh through to Mixamo.

I think 'animating in Photoshop' is definitely a stretch where it comes to our understanding of the word animate. The video that outilnes the procedure basically allows animation in Photoshop but as a means to find an ideal frame from that sequence and then use that (still) frame in an image. That isn't to say the process won't be useful... heck, lots of talented A:M Users have made a name for themselves creating still imagery rather than animation. Regarding Flash: I missed the word on Flash. Hmmmm.... changing the name from Flash to Adobe Animate isn't quite pulling the plug... I'll have to look into that, learn what there is to learn and get myself up to date. I've used Flash for little projects here and there but never warmed up to the workflow. Added: I'd say that any time an application is rewritten from the ground up some major changes will have to take place. It sounds to me like that is exactly what is happening with Flash. From my limited view it appears that some of the fringe applications Adobe brought to market (Edge Animate, etc.) formed parts (modules) for bringing Flash to it's current stage; moving more fully into HTML5 etc. I'm sure a lot of plugin technology was/is incorporated as well. Of course, the major move Adobe has been making is toward being a content provider where they get money by being at the crossroad where the transaction of digital goods and services are made. In the end, this move of Flash to Animate CC may save the day for Robert's legacy assets, especially if Adobe were to free up some of the resources from earlier versions of the Flash software.

Oh yeah. Make full use of that time and any resources they supply there! Even if not of any particular use (to me) some of these things may be of use to someone else and so it's good to at least have some cursory understanding of what is there if ever needed.

According to the last blurb on the attached write-up everyone should be able to import designs of their own (made with A:M) into Fuse to further customize and outfit characters. The meshes created with Fuse aren't optimal for use with A:M but can provide a good starting point even if only for assisting with design. A plus is that the meshes consist of quads (unless sprecifically set to export tris). Commercial usage? According to Adobe: For more info check out the site: https://www.adobe.com/products/fuse.html

And here's a shot from the general UI. Adjusting the parameters (via sliders) will be very familiar to A:M Users. Note that when updating a setting it can take a few moments for the program to update the other features. For instance in this shot, after adding the hat it looked like the hair wasn't going to change but after a little while it reformed (mostly) under the hat. I did notice that when adjusting the teeth that wasn't always the case although perhaps I just didn't wait long enough for the change to sink in.

Same generic character after a few slider tweaks...