Rodney

I'm pretty sure Steph Greenberg used Toonz with A:M for his "The Physics of Cartoons". That was way... way... way back in the day. xhttps://www.youtube.com/watch?v=K_QAeicX-Rw

There are a lot of things to get sorted out but I already anticipate adding OpenToonz to my workflow. I need to get busy and put together some useful animation sequences in A:M that can demonstrate the benefits of using OpenToonz. In a way OpenToonz is a bit like Blender (but more user friendly), a bit like Fusion (but with a very useful Xsheet premise) and certainly compatible with imagery rendered out of A:M. If OpenToonz gets a bit more streamlined I can see it moving onto the Top 10 list of software I use and (potentially) replacing Fusion at the Number 2 spot. This is saying something (IMO) because Fusion is an impressive piece of software that I wouldn't want to give up. Rather than spam the forum with OpenToonz postings I've started adding some basic information and resources related to it on my blog. I have a vision for what might be done relative to matching A:M with OpenToonz but it's too early to tell whether any of that will pan out. The potential is certainly there.

Very interesting. xhttps://www.youtube.com/watch?v=7d59O6cfaM0 Kudos to the demo team at Microsoft research who thought of excellent ways to show off the potential while adding new 'features' all the way to the end of the video. I can think of several downsides to such technology but it's hard to deny the potential.

I've been brushing up on my Japanese language skills and see just how easy it is to lose what you don't use. Not that I was ever skilled at reading kanji! I can see why the companies involved felt the need to open source. There is much work to be done. I've noticed several names that make this project well worth watching. The interest in getting Toonz ramped up and where it needs to be (largely documentation and workflow related) is certainly there.

I haven't yet seen the official release announcement but went a'lookin' for the OpenToonz software and looks like I found it. Downloading now... For the brave and adventurous, here's the link: https://opentoonz.github.io/e/index.html The announcement is/was to be 26 March but that is in Japan so... should have already happened. And of course the big question: how to best integrate OpenToonz with A:M! The scanning interface alone with Xsheet should prove valuable.

That looks to me like a classic example of inverted normals. If you turn 'Display Normals' on (in Tools/Options) you'll be able to see if that is the case. If it is then use the Group Select tool to grab those patches and then Right Click and select 'Flip Normals'. In your case there are two indicators that inverted normals might be the cause. The first is the black discoloring. The second is that the models appears to be displaced in the wrong direction at those areas.

Nice sleuthing Robert! Maybe Steffen can implement a 'Find Problematics' filter to make finding those things easier.

While I didn't find what it was there is something animated/keyframed that appears to be making the change. The reason I believe this to be so is that if you delete all the keyframes from the end of the sequence the problem goes away. But then again so does everything else that was animated too! For tweaking/troubleshooting purposes this is why I would generally suggest that cyclic motion/animation be made in an Action and then dropped onto the Model's instance in the Choreography. Then it's a lot easier to ferret out where the problem is. And it's easier to change the animation in all instances because you've got only one place to edit it.

Looking forward to it! This is the part I'm interested in the most. I've often thought of doing such things but outside of the occasional test haven't done anything significant with that approach. The closest I came to success with those tests was with two characters (one imported into the other for the purposes of fighting each other. The jury is still out on how well that turned out.

Not sure how to get a DAE file into A:M? Howzabout import it as an OBJ via SW3D. Same trailer scaled -100% on X axis to make a mirror image to butt up against the trailer's open side. I'll have to check to see why most of the color on the trailers turned to white... probably the intensity of the sun.

I've got a few more random tests of various file formats and modifications. Here's one of a basic cabinet out of the SW3D library recolored and adapted in A:M.

Here's a quick recolor test of a car downloaded from http://tf3dm.com While fairly detailed the original car came into A:M with limited coloring, texturing and no transparency. A few tweaks in the Chor's shortcut to the Prop resulted in the bottom image rendered out of A:M. Not bad for someone that doesn't know what the heck he's doing. Someone that has a clue could achieve much better results. Point being is that surfaces are highly modifiable in A:M as Props. Top image is of what the car looked like upon import into A:M as a Prop. Note the transparent windows in the render on the bottom. That is the result of simply adjusting our standard surface transparency property.

Many additional options are available so a video tutorial may be in order... after some more exploration.

Okay... okay... as I was. It helps to go back and read Steffen's release notes! He said: The problem I was having was that I couldn't change the image/decal type *in the OBJ*. But we can change the Image type from Color to Cookie Cutter (as he stated) in the same location in a Chor or Action. Ah, sweet success. Thanks Steffen!

There are still some issues I'm trying to troubleshoot with OBJ objects where images placed on "cards" show the outline of the cards. This is very likely an oversight on the part of the model makers and could easily be remedied in the original program the OBJ was created in but trying to resolve the issue via MTL tweaking or exchanging of imagery isn't resolving the issue. An example of this is a downloaded model of Paris where everything rectangular renders appropriately but the trees... not so much. The white from the cards the images are applied to shows up. In the attached you can see that both trees and lamp posts exhibit the same problem. This wouldn't be much of a problem if dealing with only a few cards (easily replaced) but is a bit more difficult when dealing with hundreds/thousands or cards. At a guess I'd say there is likely a way to tweak the OBJ file so that all cards have transparent backgrounds but I'm not sure what that would be. It's easy enough to swap out the images on the cards by editing the image shortcut in the MTL file. (Disclaimer: This Paris OBJ isn't from the site/libraries mentioned above but is from another free models site)

The only difference I know of is that when purchasing for $299 your license to the current release (at the time of purchase) will never expire. When purchasing the standard subscription for $79 that will run for one year from point of activation. Both perpetual and annual releases are downloadable installers activated by a keycode issued by Hash. Both require contacting Hash Inc to transfer the license to any new system the program isn't initially installed on.

Most of these files have licenses of their own. Generally each one will have an accompanying license in the folder with the model. Some state any usage is fine but the originator must be attributed somewhere in the final product. One set of models states this: I see that 235 models donated by Scopia have a very liberal license: When using any model made by someone else it's important to consider the intent of their license. Specifically, if that license is meant to restrict usage which is usually not the case with most online shared objects. The creators want others to use those objects. A license in place to protect the originators of the files is hardly useless nor does it nullify obvious usage granted by said license. It's not like someone has to be able to carve their object out of a rendered scene in order for their rights to be intact so the words concerning incorporation into larger works must be addressing something else. A good rule of thumb would be to always consider finances gained by use of some else's models. Another way of looking at this would be to consider a project that incorporates dozen these objects in a single scene. Because the original objects are Props in A:M they can still be accessed in original form in that Project. This meets the strictest interpretation of the license. In cases where the object is only used as a temporary stand in for another object that will later replace that object the license is likewise intact as the file(s) are not being incorporated into the final product. An excellent example of this would be George Lucas and Steven Spielberg's usage of old film to layout their films. One could argue that some monetary compensation should flow toward the originator of those products but the legal end of the chain is more concerned with the final product. And here is where modification comes to play as it is the judicial system that must more often than not decide what is to be considered a derivative work and what constitutes a new product. So, 'useless'? Hardly. It is a bit unfortunately, an encouragement for folks to build everything from scratch even though their may be no requirement to do that as intended by the originating artist. But for those that plan to make cold hard cash with their endeavors the only way to make doubly sure you are adhering to all intents and every letter of the law is to use products which you either own outright or have paid for the appropriate usage rights. And don't forget to keep receipts of all licensing transactions! At any rate, this is the long way of saying that 'useless' might not be quite the appropriate terminology.

Well worth the watch but set aside some time as the interview runs approx. 1 hour and 45 minutes, including a fairly long intro outlining the 'Design by Hand' project headed up by Cooper Hewitt. Part 1 xhttps://www.youtube.com/watch?v=00hDSOCQy4s Part 2 xhttps://www.youtube.com/watch?v=VmUzwM89Fdw John Lasseter, twice fired from Disney Studios recounts the history of animation which culminates in him leading the Disney Studio into the current age of computer animation.

Glad to see you are still at it... and back!

Looking good. It appears the use of cardinal direction (straight forward and profile camera) fits well with your project's over all style but if possible I'd suggest moving the camera slightly to allow for some variation of movement. An alternative in cases where objects move in a straight line would be to have the camera drift ever so slightly. It has been said... although I certainly haven't vetted the idea fully... that straight on camera shots primarily lend themselves to comedy. (speaking of which, I just noticed Grandma is riding the cycle backward during the second half of the previous shot (the terraced houses). I know that is just a standin, Press on. press on!

Sweet Home 3d is primarily a home layout planner. As such it has a library of OBJ models that can be drag/dropped to the plan view (top view). The reason one must Export to OBJ (rather than save) is that is the only option to get a Model back out of the program. Although the terminology of the program will tag everything as 'furntiture' just about any OBJ file will work. No, these aren't editable models within SH3D except scaling and such. To edit the model you'd have to use a different program... and if you have such a program... you'd probably use that program to export/save to OBJ. The primary reason to use SH3D would be to access the libraries of models which have been placed into a proprietary format that is used by SH3D. The (minor) temptation is to use SH3D to organize all OBJ I want to use in A:M but I sense that might only be the case until I find a more versatile program. Most of the models I've used thus far import into A:M as editable models as well although much depends on how the model was built in the first place. If the model consists of polygon tris the results will be mostly unusable. Even if the model consists of quads it may be too dense. So, the primary usage of any OBJ remains as props in A:M. The main difference being that A:M can handle them a bit better than previously. I'm still exploring and some models don't maintain their color after import to A:M while others do. Again, I'd say a lot depends on how the model was created originally. In my world OBJ files are usually static props that don't do much other than translate, scale and rotate but even there that allows for some considerable world-building and if nothing else the models can serve as temporary proxy models until more articulate and appropiate models can take their place.

One OBJ import in particular really impressed me. It was a relatively simple window frame. I noted the windows themselves had just the right amount of transparency. Nice.

Kudos to Steffen for the recent improvements in OBJ texture importing in v18p. Thanks! And to make this something of a useful topic... here's something related to consider... There are a gazillion models out there on the internet to play with but I recently tested some of the Models donated to the Sweet Home 3D community. The process is pretty straightforward: download the library of models, open them in Sweet Home 3D, export as OBJ, import into A:M. The models page: http://www.sweethome3d.com/freeModels.jsp The program download: http://www.sweethome3d.com/download.jsp What is particular useful with the program is how you can use it to recolor/texture the OBJ so that it appears in A:M as you want it to be. Here's a random piece of 'furniture' ( a willow tree) from that library loaded quickly into A:M and rendered. Of specific interest is the transparency that allows detail in the leaves. Of additional interest is the second image that shows the modification of the trunk color in SW3D just prior to importing into A:M. I see I am going to have to revisit some older projects with OBJ files that weren't rendering correctly!

Perhaps the most anticipated aspect of this software's release (to me) is the xsheet capability.

Ok, Sorry for droning on here but I had to return to this one again. Here's a hybrid approach that I alluded to before. Namely that of using a single (separate) patch for each tile. An interesting aspect of this (as seen in the attached video) is that this example uses the multi-group method but also adds a single group that controls all the tiles of any given color. Of course, because each tile is a separate piece the selection could be anything... design your mosaic any way you want by grabbing patches and coloring (or decaling) them appropriately. Of course because the tiles are flat this produces the slight facets one might see in a pixelated image or polygonal model. An added benefit of this approach is that since the tiles are each separate from one another they can be animated, modied, exploded... and otherwise manipulated without effecting other tiles. SinglePatchTiles.mp4