e-mail from Martin Hash


#1

I just got a really nice e-mail from Martin Hash talking about the crashes we keep discussing openly on CGTalk.

It makes a lot of sense. I just emailed him back asking if I can post it here in full.

I’ll give you the short version.

Most of the random crashes deal with the almost infinite number of variables on a system’s video card and video card drivers. Animation Master uses a “Standard” method of dealing with windows that most other applications don’t use. Because of that. . . Other applications don’t suffer from the same issues but also don’t allow you to open new modeling, action, pose windows all over the place as you work. (Something I find very usefull.) He suggests trying to keep up with the latest drivers and if there are still problems, start trying different working modes within Animation Master to find a solution that works best with your video card/driver combo.

You can find those settings in the “Options” “Global” tab under “Real-time Driver”.

I really appreciate Martin making an effort to reach out to us/me and I hope people find this information useful.


#2

How is this different from what he’s been saying since… oh, 1997?

How does it support that so many crashes happen with only one window open? Usually the chor. window. Could it be internal coordination of variables handled by AM is actually at fault (thus when all the variables come together in chor. we get crashes) and not how the video card handles them?

Probably it’s just both of these things…


#3

This sounds only like a “shot in the dark” possibility of why the app crashes.


#4

Billy;

Though you never requested any help concerning your A:M problems, I
thought I’d offer an olive branch and provide some myself.

A:M’s most fundamental troublespot is its reliance on hardware
accelerated graphics. Versions before V9.5 relied on software emulation
for OpenGL and Direct3D, but the advent of inexpensive hardware
accelerated videocards precipitated a customer clamor for support. In
the past, the OpenGL and Direct3D software emulation libraries were
supplied by Microsoft, a single vendor with immense saturation, so any
problems were well known and could be worked around. Hardware
acceleration, however, is the responsibility of the videocard vendor,
and therefore each implementation has its own set of problems, for every
model, and every version. Additionally, OpenGL and Direct3D are
entirely different implementations, so one may work while the other
fails. There are literally hundreds of drivers available, and they
change constantly. A:M cannot fall back on software emulation because
Microsoft has discontinued support except for the “debugging” version,
which is unacceptably slow.

A common complaint is that “other 3D programs work on my computer, why
doesn’t yours?” The simple answer is “overlapping windows”. Most other
3D apps are custom, split-screen interfaces where no windows, other than
dialogs, overlap. A:M is a standardized application (like “Word”) that
acts and operates in a consistent, industry-accepted manner. Many
videocards do not seem to be robust when multiple polygon engines are
operating simultaneously in overlapping windows. Assuredly, this will
improve with time, as does all technology.

This is not an excuse for all A:M related errors. There is an easy way
to tell “driver” problems and “applications” faults: does the
Application error dialog appear when the software crashes? The one that
says, “Master.exe has caused a fault
” If not, you are probably
experiencing a system level error rather than an A:M error. Another way
to tell is if the fault is repeatable. Random crashing back to the
Desktop is indicative of system level errors, but if it is repeatable
then the programmers at Hash can usually do something about it. Below
are some other tests you can make:

  1. Turn on “Wireframe” display, rather than “Shaded”.
  2. Turn off “Show Decals” for the “Shaded” option on the “Render” tab.
  3. Close all unessential windows.
  4. Change to Direct3D support.
  5. Try the “Ref” Direct3D driver.
    If any of these things prevents the faults or reduces the frequency, the
    problem probably lies in the videocard driver. Try updating your
    videocard driver from the manufacturer’s website. Most people rarely
    experience videocard induced faults, but no matter the kind of error,
    the Product Support team at Hash wants to know when you are having
    difficulties.

Sincerely,

Martin Hash


#5

It also supports what a lot of us have been saying over the years. I know when I switched out my ATI card back to Nvidia, my crashes went down a huge amount. Maya was also a lot more stable as well. Don’t mean to say ATI sucks as this was a year or so back and I’ve heard that current ATI drivers are much better then what they have been in the past. Heck, I’ve even heard that a lot of the customer service folks at ATI aren’t nearly as big a bunch of pricks as they were a few years back.

Not that I think this gives Hash a total pass on crashes, but it’s nice to see Martin reaching out. Besides f all the crashes went away, waht would Dearmad do with all that pent up rage :wink:


#6

Man o Man Martian never ceases to amaze me. I cant believe the stuff that comes out of his mouth. Is he saying that they cant fix these problems because of video cards? I can open 10 windows in C4D and in shaded view and rendered in a few of them and not even a hiccup?

If Martian would spend as much time fixing the damn problems with AM as he does trying to moderate the mailing list and trying to get the moderators changed on CGTalk he would not have any problems.

Lets face it hash has been doing the same thing since version 4 and are still doing it. Instead of saying Ok we know there is a problem its hard to track down but we are working on it he is saying well the video cards are all different and its the cards fault.

You have to be kidding me right. Here is a pic of 9 or 10 windows open in C4D the big one in the center is rendered and they are all in shaded view and guess what NO CRASH!

Martian listen up! FIX THE DAMN PROBLEMS and you will be selling copies of AM so fast you wont be able to cut CD’s fast enough. Stop blaming everything else and the users and FIX THE CODE. Stop trying to moderate the CGTalk form and FIX THE PROBLEMS. Step up to the plate with some real effort and just do it. Tell the users we are working on FIXING THE PROBLEMS and will put out the next release when its done with real beta testers not newbie’s who don’t know the ins and outs, use people like Wegg and David Rodgers who know what they are doing and LISTEN TO THEM!!! How many years are you going to put out beta software over and over and fix one thing then break another.

What version is 10 on now H come on already you should be paying the users with all the testing they do because of your inability to FIX THE PROBLEMS. This is one more example of Martian NOT FIXING THE PROBLEMS and trying to blame everything else but the real problem. How can other programs like WINGS, C4D, TS work just fine with lots of windows open and not AM? I did not seen one comment in his email to wegg saying that they are working on the problem did I miss it?

MARTIAN! FIX THE DAMN PROBLEMS WHATEVER THEY ARE. Other programs do so can you. Gezz enough with the BS already.


#7

Now I’m just fed up with this. I have never heard a legitamate reason as to why the software is so fragile.


#8

Here is my analysis of Martins comments (for what it is worth)


A:M’s most fundamental troublespot is its reliance on hardware
accelerated graphics.

What about the fact that features often just don’t work?


Versions before V9.5 relied on software emulation
for OpenGL and Direct3D,

So earlier versions were stable were they?


the advent of inexpensive hardware
accelerated videocards precipitated a customer clamor for support.

A 3d tool company shouldn’t wait for costomers to request hardware support. It should innovate like Descreet are doing.


does the Application error dialog appear when the software crashes? The one that says, “Master.exe has caused a fault
” If not, you are probably experiencing a system level error rather than an A:M error.

I never get application errors so all the bugs and glitches that Hash fixes must be system errors. Amazing how they can fix my computer over the internet.


Here are some other tests you can make:

No, YOU do the tests. I want to animate.


#9

While I agree with Dfaris and John Keates - I still see this as a positive message. I want Hash to be as solid an App as any I use; I want all the features to “work”; I want it to be fast and capable of anything. These are things I think we all want or we wouldn’t be reading this.

I will pat Martin on the back for taking initiative to reach out and offer something up. The fires have stopped burning here and I see no reason why they could not have sat back and let the unsuspecting continue to purchase. His message is motivated by one of two things - either CG Talk has negatively impacted their sales and they want to “fix it” - or it is a genuine token of good faith on his part.

I only hope that whatever motivated him to send the message continues to do so…


#10

Honestly if I had to guess it’s because after seeing some of the work that Avalanche has been producing with his software he would love to see the Eggington crew back on board because that would mean even more mind blowing work using Animation Master. Pick up “Tak and the Power of Juju” when it comes out and you’ll see what I mean.

To be honest I thought AM had fallen behind and wasn’t sure if it was up to it. Avalanche’s work made me a believer just as the Eggington crew has in the past.


#11

[i]His message is motivated by one of two things - either CG Talk has negatively impacted their sales and they want to “fix it” - or it is a genuine token of good faith on his part./B]

Well. . .

Lets just say he isn’t too thrilled at the moment. He sees me as the pied piper trying my best to lead people away from Animation Master, sew seeds of malcontent and miss information and promote myself at every opportunity.

I do wish he could see that that isn’t the case but. . .

HEY! It doesn’t really matter!

The moderators of CGTalk have been good enough to back me up and are quite happy with the way our little AM area has turned out. I think we are growing as a forum and I hope we can continue to do so.

If you have ANY complaints about what is said here. . . PLEASE contact me about it before you go e-mailing people at Hash Inc.

Spline on dudes.


#12

Here’s a question for you. Since both Steve and Martin have been so willing to point out where the interface issues are, and at least in Steve’s case admit that they are stumped as to what to do about some of them without help from the GPU manufacturers, (see the list archives) wouldn’t it be in our intrests to quit bitching about issues they have little control over, and contact the GPU makers with our problems?

I use a Radeon 8500le 128 card and there are definate issues with the drivers from ATI that have been released over the last 3 to 4 months. By careful testing I ended up with an older driver that has made AM 10.5 quite stable (interface wise) for me. Details on this have been posted to the Animaster list.

If you look at the change log for driver updates and what they address, you will find that many times the driver changes are there to solve an interface or display issue in a certain program (UnReal, Quake, Maya ect.) This happens because the users of the gpu as well as the software developers complain to the gpu makers about the issue(s) and a driver change is made to address it. This is the opposite of what happens with AM. Here the users with all their varients of graphics cards and installed drivers IMMEDIATLY assume that the programing team at Hash is at fault. Do you expect Hash to have every gpu and driver set up for testing? it’s not possible. Without OUR input these issues will NOT get solved.

Have ANY of you sent your driver issues in to the gpu maker? I highly doubt it, as if you had this wouldn’t even be an issue by now!

A little more input and a lot less bitching just might get the job done. As some of you seem have a lot invested in the “Trash Hash” world, I expect to get lots of red and yellow particle emmiters flying my way. Have fun…

BTW, Wegg it’s great to see you evidence a more posiitive light for what Martin et all are doing. I was very uncomfortable with the idea of purchusing products (as I have in the past) from someone who seemed to want to destroy the very product that he sells items for. :thumbsup:

Phil Leavens
http://www.clipsandscripts.com


#13

Originally posted by phil3d
[B]

If you look at the change log for driver updates and what they address, you will find that many times the driver changes are there to solve an interface or display issue in a certain program (UnReal, Quake, Maya ect.) This happens because the users of the gpu as well as the software developers complain to the gpu makers about the issue(s) and a driver change is made to address it. This is the opposite of what happens with AM. Here the users with all their varients of graphics cards and installed drivers IMMEDIATLY assume that the programing team at Hash is at fault. Do you expect Hash to have every gpu and driver set up for testing? it’s not possible. Without OUR input these issues will NOT get solved.

Have ANY of you sent your driver issues in to the gpu maker? I highly doubt it, as if you had this wouldn’t even be an issue by now!

[/B]

Back in the “old days” (1994, 1995, 1996 when I was the most active with A:M because I had more free time) users did complain to the video card makers…ATI was the most responsive back then. Number 9 (I think that was their name) wasn’t…they’re gone now. I guess from an earlier post from My Fault things changed with ATI’s support…seems that’s always the case when computer hardware/software companies get bigger. But new drivers did solve A:M problems back then. I would say that points at the video card drivers as a problem source. That’s why there’s always been the same advice of update your drivers.

I always read about big video card problems elsewhere in magazines and the net, so it’s not hard for me to accept that they could be a source of some of A:M’s problems. Some companies, like Avid, would tell you (and probably still do) that you could only use a certain card, just because of driver issues.

I’m using an old ATI Rage Fury Pro…and an older driver because the newest one screwed up my ATI software DVD player’s display…and it doesn’t give me the problems others have had with A:M…it’s a mature card and driver. But I’m also a slow poke so who knows. But video drivers are always a bomb waiting to blow IMHO.

The longer I can stick with my old hardware, the better. The new stuff is faster, but the quality control may not be there.

BTW, the Avalanche ad for TAK is great!


#14

If they can get such stable systems that they are willing to dismiss all customer complaints as their own fault, would they mind posting their system configs? It seems some people are more than willing to just bend over backwards for Hash just to get this great little program to work, so if the (Hash) aren’t having any problems it would sure help us out a lot.

Either that or AM crashes just as much on their comps and they just ignore that.


#15

I appreciate that Martin is actually communicating with us (well… through an intermediary, but it’s a start;)), but I don’t really think “crashes to the desktop” can always be blamed on the GPU. As others have already mentioned, many 3d apps which also use hw acceleration do not crash as often as A:M. The Maya PLE hasn’t crashed on me once. Neither has Wings3d or the C4D demo. Having said that, I maintain hope that Hash will do their best to fix these problems. In the meantime, I guess they have to make some excuses.

BTW, wouldn’t it be neat if a Hash employee (or even Martin himself) actually became a member of CGTalk and talked with us directly on these forums?


#16

Originally posted by Goon

Either that or AM crashes just as much on their comps and they just ignore that.

Steve mentioned to me that he was able to teach 60+ hours of his A:M class with only a couple crashes. Perhaps if they diversified their system configs, they would get a better idea of what we’re going through.


#17

Last weekend, I ran UnrealEd 3.0 max’d on one monitor, and Windows Media Player max’d on the other, with short jaunts into PaintShop Pro (and even a few IE searches for info) for 2 sessions totaling almost 9 hours . Didn’t crash once. (I’ve heard on the A:M list in the past that if I had even run IE during a windows session, that I should re-boot before running A:M due to IE’s crappy garbage collection!?!?!?)

This weekend, I ran UnrealEd 3.0, MayaPLE 4.0, Windows Media Player, and PaintShop Pro (and, once again, I lit off IE a few times to look up info on Unreal dev) all at once for 2 sessions totaling almost 7 hours making static meshes for Unreal. Not a single crash. I even did some MEL scripting, troubleshooting my limited scripting abilities (being totally new to Maya) without a single crash despite many errors in my script caused by my tuuribul speelink :wink:

For both weekend sessions I had NortonAV (w/ auto scanning disabled) and Agnitum Outpost firewall running in the background.

I am totally new to UnrealEd & Maya, so I’m sure I did some bone head things that would have caused a crash in a less robust app (a certain 3D animation pkg comes to mind…not to mention the fact that UnrealEd doesn’t have the best rep when it comes to stability).

(Kevin: Can’t do that on a ATI Rage Fury Pro…it won’t run UnrealEd 3.0 due to DX requirements)

I can’t run A:M, by itself (no background tasks, unneeded services disabled), for more than 20-30 minutes without an abrupt introduction to my desktop. No chor, single modeling window (not maximized), model imported from Wings3D in A:M MDL format (only 320 patches), trying to do spline re-direction, and stitching a few new splines. I almost always get a crash if I try to stitch more than three CP’s in succession. First one will latch onto a dead-end spline, the second will attach to an existing spline, the 3rd or 4th will introduce me to the desktop. The model looks pretty good in the viewport @ 4 polys per patch, but @ 1 poly per patch, it looks like almost every patch is a shaded pyramid (tried “Refind normals” to no avail)…weird! :stuck_out_tongue:

The PWS window never remembers it’s position on the 2nd monitor…it alway starts out half on one monitor, half on the other. Deleting the last named object in the PWS tree (like the last bone listed) will often result in a bone named “Poses” and all the Poses gone. The PWS tree text gets corrupted so often, I seem to spend more time opening and closing the PWS to get the tree to refresh than I do modeling.

Only progressive render in a viewport works. Full render in a viewport results in either a lockup or colored lines that look like VHS static. Render to file looks OK…but, even with no materials/textures, it’s painfully slow.

I could go on…but why? I don’t need the hassle anymore, Mr. Hash (if you’re reading). 3D for me is just a hobby. Something that I enjoy in my spare time. I DON’T enjoy tip-toeing around the minefield that is A:M.

How long would woodworking be your hobby if the head of your hammer wouldn’t stay on the handle, your saw blade had no teeth, your nails were made of rubber, and all glue and paint took a month to dry?


#18

Originally posted by Hookflash but I don’t really think “crashes to the desktop” can always be blamed on the GPU. As others have already mentioned, many 3d apps which also use hw acceleration do not crash as often as A:M

From Martins statement;


A common complaint is that “other 3D programs work on my computer, why
doesn’t yours?” The simple answer is “overlapping windows”. Most other
3D apps are custom, split-screen interfaces where no windows, other than
dialogs, overlap. A:M is a standardized application (like “Word”) that
acts and operates in a consistent, industry-accepted manner. Many
videocards do not seem to be robust when multiple polygon engines are
operating simultaneously in overlapping windows. Assuredly, this will
improve with time, as does all technology.

Looks like Martin is being very straightforward about this. Perhaps the need to “trash Hash” has become more powerful then the actuality of the issues. In this entire thread I’ve encountered a total of two statements that might help folks dealing with these problems. One is in the full statement from Martin, and the other is in my previous post about my tests with ATI drivers and the issues that exist in the current versions.

Now if any of you want to collaborate on DEALING with these videocard/driver issues, I’ll be glad to help. Since thats not likely I can get some laughs at the onslought of anti-Hash, screw_you phil_3d_you_don’t_know_nutin’about nutin’ posts that are sure to follow.
Have fun.

BTW notice that I never claimed that AM is perfect, I’ve sent more then my share of tested, repeatable crash reports to Steve, and have spent a fair bit of time on the phone with him in the past sorting out issues, both software and hardware wise.

Phillip Leavens
http://www.clipsandscripts.com


#19

phil3d:

  1. I missed that part about the overlapping windows. It’s good to hear that Hash is trying to improve the technology. I earnestly hope they succeed. I think we all want the same thing here.

  2. Could you possibly use a more condescending tone? Trivializing all the posts in this thread (except yours and Martin’s, of coarse) and then anticipating your own martyrdom is a little over-the-top.


#20

This is great! Many thanks to Martin for (indirectly) speaking up here. I’d like to make a few comments myself … and assume that Martin will read them.

A common complaint is that “other 3D programs work on my computer, why doesn’t yours?” The simple answer is “overlapping windows”.

Well, shoot… I like A:M’s interface. I would hate to see it different. But if that’s what it will take to improve stability… will you give it a try, please, Mr. Hash? Yes, I know - it would mean ripping up the underlying MS framework and writing something else.

Many videocards do not seem to be robust when multiple polygon engines are operating simultaneously in overlapping windows. Assuredly, this will improve with time, as does all technology.

Great! I’m a current customer and I can afford an upgrade. Wake me when the party starts. (Surely the video card manufacturers will work with you on this one?)

…Another way to tell is if the fault is repeatable. Random crashing back to the Desktop is indicative of system level errors, but if it is repeatable then the programmers at Hash can usually do something about it.

I’m going to repeat what some other people on this forum have already suggested: add an activity logging tool, some sort of debugging mode that can be turned on, that will record what I was doing when the crash happened, and (like Windows XP) send a message to you with the details. It’s rarely possible for me to accurately recall even my last 5 clicks and mouse gestures; I’m in the zone, modeling or animating, not watching my hands. Try logging to disk every function invoked by the user before it is executed, and whatever else might be useful. Let us upload the log to you for analysis. Don’t forget to let the user see the log first. Some of us get touchy about programs “calling home.” :slight_smile:

Alternate (better, I think) suggestion: Ask for volunteers in the experienced user community to accept a “debugging build.” Keep tabs on each one’s Windows version, video card, the lot. Require submission of the files that were in use at the time of the crash for your furthur analysis. Give a deep discount (80%+) for this “debugging” version. This is like paying these particular people to debug. I would join that group.

1) Turn on “Wireframe” display, rather than “Shaded”.
2) Turn off “Show Decals” for the “Shaded” option on the “Render” tab.
3) Close all unessential windows.
4) Change to Direct3D support.
5) Try the “Ref” Direct3D driver.

1-3 have not helped me. I’ll have to check on 4. What’s a “Ref” driver?

Most people rarely experience videocard induced faults,

Um, so it’s not likely to be the driver? Eh? Hmmm…

but no matter the kind of error, the Product Support team at Hash wants to know when you are having difficulties.

Do you guys really want to hear from me? I’m still back at v9.5. It works, sometimes. Sometimes it just disappears without warning. It’s quite disconcerting.

Publish a hardware/motherboard/driver recommendation list, if it will help.

I will wait for signs of progress before upgrading again. If A:M crashed only when I used untested, exotic features, I wouldn’t mind… but it crashes when I’m modeling in wireframe mode, with no decals, no textures, no imports from other programs, and an otherwise empty project. It’s hard for me to make my dreams come true with this tool… and I can’t afford the extra time to solve the problems you are encountering in writing it… so it’s back to watch and wait.

Hang in there, Mr. Hash.

“Lettuce”

P.S. On another note, I’m having a blast with the Shockwave tutorials on the Hash website. Since I was already a user, I’m not learning much - a button here, a menu item there - but if I were starting out, these tutorials would be gold. And if I were a prospective customer, I’d be half sold, getting to see the product in action. Great job. :beer: I hope that Hash finishes the unposted ones - and posts at least double the number listed - and puts them on the CD, too, if they are not already there.