Rodney

We saved some cake for you. It's a bit... mmmm..... actually it's still quite tasty..

My characters from 'Doodle Time' (Time Travelers) are hesitant to assist. They think I might actually place in this contest if no one else has entered. That was two of them in the car entry that I misplaced. So... no Doodle Time entry made the cut... and THEY are timetravelers. Go figure.

I'm sorry I've offended. Certainly not my intention.

I'm not quite sure whether to be happy or sad. Without an entry from you the rest of us stand a better chance of placing. But... without an entry from you... um... okay... color me sad. Hope you'll share the results as you finalize it. (Then I can be happy again)

I rarely have that problem (lack of words) It's hard to accept this and even harder to hear it said when we are experiencing problems but... more than 90% of the time it's the user, not the software. That's just the way it is. We are, more often than not, the source of our own problems. Having said that... quite often the software can help guide the user to a solution they would otherwise not see. But computers only do what we tell them to do. Some of that is coded in software while some of it is the user not understanding how to use that software. In the case of the mysteriously moving object, the movement is very likely directed by something you have set. With regard to the rotating sphere.... is it rotating in the model (less likely) or an Action or Choreography (more likely)? If in the Model window... does the model have any poses set up? Models can't change on their own as the data is static so if something is changing then we can look to a pose (relationship) or action. There are two types of Action, standalone and choreography. If in an Action or Chor then you've very likely but unintentionally animated the object. So we'd need to crack open the timeline and look at that aspect. As Robert suggests, seeing the project file would tell the tale. In the latter case of the ball straying off the path my first guess would be that you've placed your bone correctly from the front view but if looking from the side might not be placed at 0 on the Z axis. If not this then it could very well be a constraint that isn't set up correctly (this is actually more likely but it's easy to check for bone placement first) To know more about this we'd need to know more about how you set your object to follow the path. We have to guess what you are doing because we don't know. One of the best ways to resolve a problem is to record a video of the issue and share that.(such as Robert is doing that demonstrates how he sets up a project). There are many video capture software but currently (on the free side) I'm recommending Open Broadcast Software (LINK). Get the Studio version not the classic. On the paid side it's really hard to beat Camtasia (LINK). The video approach works best because it captures exact steps used in a process. This can not only resolve a problem but lead to suggestions that improve workflow and better usage of the software. The next best approach to solving a problem is to share an example of the problem in a project. This can either be the actual project itself or another setup specifically to demonstrate the problem. The latter is usually best in cases where, for one reason or another, the user can't share parts of the project. For instance, when they are working with someone else's files and don't have permission to share the files. The downside of sharing files is that care must be given to share all of the pertinent files. Since A:M doesn't automatically save files into a Project these can inadvertently be left out. Software can't always anticipate/guess what we want. These two methods (video capture and sharing of (embedded) project files is also the ideal way to submit bug reports for those rarer instances when the problem isn't on the part of the user but fully in the realm of the software. One of the reasons I rarely have frustrating problems with A:M (or any other software) is that my first thought is to never blame the software. Once I've ruled out user error (my own or someone elses) then I can better see the shortfalls of the software. And in most cases there is a reasonable workaround.

Welp... found that one! Now I remember why I set that entry aside and didn't dive into the last 10% polishing. I really wanted to get a 'bursting through your screen' effect but got off to a bad start on achieving that. The reason for misplacing the file? I cleaned off my desktop and pushed the files it into a temporary folder named "AMData". These two guys are related to the story with the (greenish) cat. They are time and space traveling.

And here is an old (random) horse doodle... I've doodled horses in several styles but this guy might make a good companion for my Myst'ry Rider because he's got a little realism to him but still cartoony. Probably would need ears... and a body.

Here's something of a reverse shot from the last. In re-rendering this last one I am reminded of why I lost interest in the project (other than that my daughter moved on to other things). I was struggling to get the colors and lighting I wanted and never quite got the look I was after. It seemed that if I adjusted the lighting... the color went off. If I adjusted the color (on the characters)... the lighting looked off. The real problem was surely that I didn't know what I wanted it to look like.

Speaking of characters... I ran across these two (Aiburouzu and Henry) that I hadn't seen since posting about them in this topic. Hehe.... obviously my daughter lost interest in them.

Here's another non-entry (way too old) but because it's a character it feels appropriate to post him. He was last seen (from a different angle) in one of the forum banners. (and yes, his eyes are floating well in front of his face... in the banner I don't think that could be seen but it did add a little extra color around the eyes due to the shadow of the eyes falling on his face)

Now this thing... it was part of an entry that I haven't yet located. For some reason it was a render of the vehicle only and missing are the passengers of the vehicle. I think I was using this rendering as a way to get at the alpha channel... more on that later. Edit: I can see by the surface below the car that I wasn't after the alpha channel here. Perhaps I was testing smoke/exhaust. I'll post the full render once I locate it.

I was in the process of submitting my entries for the mascot contest and due to my extreme disorganization I misplaced a few. One of these days I'll get my act together. At least I did manage to enter something which was my goal from the beginning. As I've been looking for my misplaced files I've ran across a few 3d doodles and figure I might as well use some of my findings to update my long abandoned WIP topic. If I've already posted these before and just forgotten... my apologies!!! First up is a really old doodle that wouldn't have been submitted for this contest because it's not a recent creation but I kind of like the general style that started to appear with him so will start with him. The Capn... (I think he's in shock because he just found out I don't have a clue as to where several of my contest entries are located. Either that or I just reminded him of the contest and... he forgot to submit an entry.) I'll post models/projects if anyone wants them...

Down to the wire as always... but I'm about to submit.

During today's 'Live Answer Time' session I went through a basic demo of the HAMR viewer (link in first post... or right click and Save As here). Note that this is an executable file (.exe) residing on the Hash Inc FTP so if you are wary of downloading and launching such you should download and scan the file before launching the program first to allay your fears). I'm bumping up this topic because the content covers a lot more info than I could go into during the LAT session. It also outlines the status of HAMR according to the guru behind it (Ken Chaffin) and suggests we shouldn't expect see any development of HAMR in the near future. Further development may be unlikely but I say good ideas always return and HAMR is there with the best of them so that encourages me. I have several specific goals in mind that have me circling the HAMR viewer but regardless of all that it is nice to know the HAMR Viewer still works well with Project, Models and Actions created in v18. As anyone with the interest in HAMR very likely has Animation:Master already up and running there isn't much of a reason to run HAMR Viewer outside of the novelty of it all. This is especially true as A:M can load and display what the viewer can with more bells and whistles. But I remain amazed with what the viewer can display. So close.... so very close to success. Artic Pigs and HAMR were ahead of their time way back in the day. It may be that someone (on a PC) without A:M might find the viewer useful for accessing Projects, Models and Actions so they can be pointed to it where there is a need. If only the HAMR viewer was a mobile app...

I finally got it to download, install and open. It took me three trips to your link but it works! The first time the message said something like, "This app is not compatible with your operating system" and the download link was grayed out and inactive. The second time I visited the page it allowed me to download but I couldn't tell where it downloaded to or how to activate the app This last time the page had an "Open" button where the download button was before and that worked. I haven't got far yet... died at level 2... but wanted you to know that I did get it going. I see that someone has taken it to level 15. You go 'CauseWecan'! Added: I like using the mouse to move more than the keyboard. Fun music too.

Ha! I agree. Nicely done indeed. I won't specify my favorite parts yet as that might spoil it for others. Some very nice effects works in there (and some of it reminded me of work by Stian... which is one of the highest compliments I can think to use where it comes to quality). You are on a roll with these.

There are a ton of new bells and whistles that have been added since v12 and you are correct in your estimate that the 64bit version is helping things run smoothly. The 32bit version maxes out on memory quickly whereas the 64bit won't. There is only one thing I can think of that would have me using the 32bit version (and I suppose there might be a few others too that I've forgotten... such as the odd third party plugin, etc.). Rendering out to .MOV (Quicktime) format requires the 32bit release because Apple doesn't support Quicktime for 64bit on the PC. Keep on keeping on! Looking forward to seeing your progress on your character.

I like the look of him.

According to my sources the last v12 release was v12.0v+ so v12d is very early in the release cycle. I *think* during that era there was also a 'stuff' file that contained important drivers, so if that exists you'll want to install that as well. Edit: I see a v12 stuff file in the 2005 directory so... operating on the assumption that you might have the v11.5 cd you might start with the last 2005 release... to include installing the v12 stuff file in that directory... then work your way up to the next release.... installing in a different directory so that you still have access your last 'confirmed-to-be-working' release. xftp://ftp.hash.com/pub/updates/windows/Am2005/ I note that you've said you've done this (installed from the AM2005 directory) so... that'd mean moving forward (as I see Robert has suggested). *IF* you installed from the 2005 folder but did not install the stuff file I would start again with 2005 and close that loop first.

As both v11 and v12 are over 10 years old we can expect some instability but... I've seen very little in the realm of what you are experiencing so don't have much to relate to in that area. If you are using both the trial for v18 and some earlier version I would definitely stop doing that. Pick one or the other and stick with that.

It's the difference between file formats. The v11 (or v12) file format can translate forward fairly well but not in the reverse because those earlier releases have no way to know the format was changed. This is why editing the text file appears to restore the data... because the editing of the text has translated the data back into its earlier formatting. Specifically changing the container code from [tag] to going forward and (in your case) to [tag]. A lot can be accomplished in the process of examining and editing a text file. But I don't think the term 'corrupted' quite applies in this case. I'd say the newer format moving backward into earlier releases than v13 (as Fuchur describes) is 'incompatible. Of course, to a user on the outside it basically produces the same result... a file that can't be readily accessed. To recap what Fuchur said, files prior to v13 are saved in a different format. So when you try to open a v18 file (presumably started in the current v18 trial) you are trying to open a file in v12 that is incompatible. When that incompatibility is resolved (via text editing) the file can be accessed. As an aside: moving files forward often works but can also result in incompatibilities because features that have been updated will often process data differently. So the more complex the project/file the more likely that the data won't behaving the same across versions. This is why productions often lock down on specific releases until the end of production with the exception of accessing features that are required but not available in the sanctioned release. A feature that changes mid production can produce vastly different results and lead to serious problems. I hear you. I live in that cyclical realm myself. And of course A:M doesn't represent the entire cost in question. We have to include the cost of (procuring and maintaining) the computer and operating system as well.

I had my suspicions... (I also figure folks tire of me saying... don't let $79 separate you from happiness) At least we know how the corruption came about.

It's rare that files get corrupted on saving so that is something well worth looking into... and doubly so if you are experiencing crashes.

Yes, there are ways we can simulate the various views in the Modeling window at the same time but I discounted those because those views won't persist as we add more splines and CPs. Of course they will persist if we keep updating our groups to include the new additions... so that could become part of the workflow. A similar way to simulate would be that of adding an image to a group. That allows us to capture the flow of patches (though the use of an arrow image) or adapt our mesh to some other use through other imagery. An example of that might be a dot, cirlce or rectangle in the middle of our image that lets us precisely know the center of our patches for positioning of other meshes. That'd be the equivalent of a rotoscope that conforms itself to the shape or our mesh but again the group would need to be updated in order to include any newly splined meshes.

Not long ago (and in accordance with PIXAR's plan) USD was released as open source. The potential is there although all the various bridges aren't. (i.e. not of much use to A:M Users as present) But that's not why I'm posting this. Of more interest to me personally would be the following statement from USD documentation: Hydra is PIXAR's realtime GPU renderer. (REF: http://on-demand.gputechconf.com/gtc/2015/presentation/S5327-Jeremy-Cowles.pdf) It standardizes on PIXAR's other developmental efforts such as Open Subdiv 3.0 and USD) And here is an in depth video running through PIXAR's realtime rendering process: http://on-demand.gputechconf.com/gtc/2016/video/S6454.html It's all entirely too deep a dive into the unknown for me but intriguing never-the-less. Concerning USD, it is similar to the Alembic format (which has proven to be popular) and said to be 'file format agnositc' which presumably makes it more accessible for plugin creation. For those with the interest in such things more information about USD can be found at: http://graphics.pixar.com/usd/docs/index.html