Just wondering because it's been a month or so since the release and the issues that P6 is having are annoying. I think that instead of a content package, they really should have focused on that.

The memory bug is the only serious issue I've seen. and they need to issue another content pack that puts back the P5 stuff they took out.

Yeah, but he memory bug is HUGE. I lost half a dozen .pz3's and countless hours of work before I realized how to get around it. I'm not even close to the only person who's had a really hard time with P6. Message boards on multiple sites are rife with complaints about it.

Memory management is something which is pretty key in a piece of software and there's really no excuse for such a glaring bug, not in the 6th version of a program. They need this thing fixed...

Message edited on: 04/22/2005 22:05

I'm not even concentrating on P6 until they get some things straightened out. I will be leaving the pro pack on anyway for testing so I just use it and P5 for now. But like you, I wish they'd deal with it, not like they didn't know about it before they realeased it. Marque

I am arriving to the conclusion that the memory bug is not a bug, bugs happens, it is normal to happen, bugs are found and bugs are corrected. One month is much time to find a bug and correct it!, so the memory problem must be some structural problem, by some reason the program is consuming an absurd amount of memory, so the program must be reworked!

Well, there have been 2nd hand reports that CL's coders have found an issue that could be the foundation of the memory bug. Can't wait to find out if it might just be related to the OpenGL that others screamed for (memories of the pointer release failure and consequent CTD due to system memory filling up in Vue 5 tugging at the ol neurons). It could also just as easily be something in the new version of Firefly they are using, which would involve a 3rd party supplier in the fix most likely.

the dials seem not very responsive all the time, thats another thing ive experienced next to the memory bug..

Wow, this isn't very heartening news...

My P5 has started running out of memory, so I have just shifted to P6, as if I am going to have the same problems, might as well get the advantages of the new program.

A month isn't that long to trace, test, try again, test, get it tested by a larger group, try again, test.... If the problem is at all deep-seated it could be a while yet - better to get it fixed and make sure there are no knock-on effects before release rather than have to patch the patch, I'd say - unless of course P6 is your only version.

I've only gotten the memory bug once. I sent an email to the tech support people at CL with the file attached. I promptly recieved a very nice email back from them. It thanked me for sending all my information as they needed to know what types of images, what types of computers and what types of systems people were using in order to find the problem, fix the problem and test a patch.

I think CL should install a "Lab Cam" so we can watch them working (around the clock) and see just how things are progressing! ;)

There are a lot more problems in P6 than just the memory bug. The dial response problem referenced above, some remaining focus issues, the memory structure design error found by a partner at release time, features in the manual not enabled in the code, etc., etc. So if they are taking the time to try to address everything in one go, more power to them. Historically P4 took a couple of SR's, PP 3, P5 4 of (really 9 as there were 5 attempts at SR2 ;-) so it would be good if CL demonstrated that they could substantially fix a release in one pass. But the effort at the Content Update suggests otherwise of course. (By the time my P6-in-a-box arrived the CU was available, so I hate to imagine how bad it looked before the CU, 'cos it's still pretty bad.) And P6 still has all the bugs and slowness of P5, plus all the bugs and slow downs of PP and the bugs of P4 and ... As to 1 month being too long for the memory bug fix, that might be true if and only if the bug was a P6 development bug. There's a real possibility IMHO that it's no more than finally "hitting the wall" with the memory management bug that has affected all Poser versions with increasing seriousness. (Adding more resident code to an app which is already saddled with an out-dated memory structure.) Fixing that would be very tricky, especially - as indicated above - because CL has clearly little practice in fixing bugs in prior release :-O And did anyone else note a reference in that post about the memory structure design error by a development partner to CL, which said that CL should be able to fix easily because it is in "live code"? Which implies parts of Poser are "dead" code? Each development shop has its own coloquisms, but that sounds awfully like they do not have access to every piece of source code...

Well, there have been 2nd hand reports that CL's coders have found an issue that could be the foundation of the memory bug. Interesting. It'll be neat to find out precisely what is going on -- especially when it gets fixed.

Based on Poser 5 development, I'm guessing it should be pretty stable for most users in 9 months (SR3 or 4). The initial alpha testers were a select group who probably couldn't detect the same bugs that general users would find, and who obviously weren't motivated in the same way the paid beta testers are - to get their money's worth. But assuming the alpha testers did catch some serious bugs, it must have been a real nightmare for some of them, so my sombrero's off to them for their intestinal fortitude.

"Yeah, but he memory bug is HUGE. I lost half a dozen .pz3's and countless hours of work before I realized how to get around it." onimusha, what's your methind for dealing with this bug?

To all.... Take heart! Even Maya has run into memory bugs (and real show-stoppers at that.) I've seen many pro applications choke on the size textures Poser uses. For what it does, it's a good piece of software. (...but the memory bug is making it rather unuseful at the moment.)_

There are two ways to deal with it that I know of. You can either use save as, to save your work incrementally. That way, when you hit the bug, you'll only lose the work you did after the last time you did save as. You can also save frequently and then copy the file to another folder. More complicated, and it does virtually the same thing. The only difference is that you'll only have two files, the original and the copied file (assuming you keep copying over the files as you go).

You can add to the problem the fact that all versions of Windows manages very baddly memory and CDROM.

• An application runing use some amount of memory, when you exit the application the operational system must release all the memory used by the application, with Windows this not happens in all cases and sometimes the memory is not freed.
  This is the reason why you have the restart the computer after running for some time some applications.
• If you insert a bad CD (with risks, dirty, etc) the reaction of Windows can be, get frozen for some time or forever, virus messages, error messages (invalisd code, memory pointer invalid with the classic EAX=0FFFFFFF ESP= 0123456 EIP=.....), after some time a blue screen (this time informing that was an error reading the CD), open the CDROM player with nothing to play, widows explorer get frozen, etc.
  You can see that all kind of things can happen instead of simple opening a Message Box informing you that the CD cannot be read.

Message edited on: 04/23/2005 14:12

Dale B, you're refering to the mail I got from CL and posted here a few days ago, right? ;) (Quote) ---------------------------------------------------------- Yes the engineers have found a bug that could be the cause of the problem. It will be in the first service release which will be out shortly. For know what I can suggest is two things. First, save out in revisions, ie save out to a different file name each time. Second you can add the entire scene as a prop to you library pallete. That way if the file does get over written you can just load it out of the libary pallete. ----------------------------------------------------------

" A month isn't that long to trace, test, try again, test, get it tested by a larger group" Isn't it be tested by a larger group? aka "Paying Customers" :)

Some years ago I was working in a company, one product was ten year old, 50,000 units sold and one day came a report from the field that a product recently sold was not working properly. I looked into the code and easily found the bug. All the process of finding and fixing the bug took less than an hour. The question is how it was possible that in a ten years old products and 50,000 sold, this bug was never found before? The product in question was an elevator up to 32 floors and the bug happened above the 16th floor. The answer was very simple, within the 50,000 units sold no one has purchased an elevator with more than 16 floors until one day was sold one for 20 floors.........

Hmmm...then I must be trying to ride on the express elevator to the penthouse everyday... ;-)

You know what, that's still no excuse because if they're not testing P6 with multiple figures on systems with a lot of speed and RAM, then they're absolute morons. The bottom line is that they're lazy and trying to make as much money as they can by doing as little work as possible. After the fiasco that was P5, they really should have reworked the whole program from the ground up. Since they have a large customer base, and knew they had a certain amount of guaranteed sales for P6, they didn't bother. The corporate mentality is so indicative of how selfish human nature can be... Okay... done ranting now... :)

Let's see, people build their own computers now and there are an infinite number of mother boards, chip sets, video cards, memory, etc to deal with so it's not at all possible to test a piece of software on EVERY configuration available. Second, with the rate at which technology is changing and computers are becoming obsolete by the month and not by the week now.......you'd have to write an entire software product in less than a week and release it the second week to guarantee that it would not have some problem with some component of a computer. We all know this isn't going to happen. Think about this, how long did it take CL to write Poser 6. Let's say they worked on it for a year. Well, one year ago, 1 GB of RAM was thought to be top end......not 2 GB. By the time the product had hit the shelves, things had changed. It will happen every time. The result will be buggier software from now own.

Actually, if you =really= want to get into the nitty gritty, throw these into the mix as well... PCI-E. DDR-333 and 400 DDR-2 SATA BTX form factor X86-64 AMD's single channel Athlon 64, dual channel Athlon 64, Intel enabling the pseudo 64 bit junk (more accurately a 40 bit bus with multiplexer). USB 2 Nforce 3 and 4 chipsets Via K8T800 and 890 chipsets At least 2 generations of Geforce class video chipsets At least 2 generations of ATI's GPU offerings. Going from AGPx2 to AGPx8 to PCI-E16 And that is just off the top of my head.

My .02 about the whole situation: (climbs on soapbox) On one hand, I have some sympathy for CL; to write a program this complex from the ground up for what is basically a niche use has got to be cost prohibitive. Poser is not, and never will be, a mass market program the way a MS Office or even Adobe Photoshop is - and even those programs are only incrementally updated. I don't think it's fair to accuse the folks at CL of being greedy or lazy, I think in the large scheme of things they just don't have the amount of resources needed to make the program perfect. I went from version 4.03 to 6, and I was actually pretty shocked how seemingly little it had changed, until I got to know the program better and came to appreciate the new interface tweaks. I really like the program, and I don't want to even use version 4 anymore, which says something about the good parts of 6. On the other hand... The problems with Poser don't seem to with hardware compatiblity: across the range of system hardware the problems are the same. My three year old, assembled from spare parts Athlon XP 1800 will crap out in the same places my brand new Athlon 64 3200 will working with the same content. The problem seems to be that the rendering engine itself has some pretty large flaws that I find it hard to believe that CL didn't know about, especially since it seems 5 has the same sorts of problems. I think the problem then, is of what they focused on in the development of version 6. I would have rather that they made the "basic" functions of the program bullet-proof (like you know...being able to actually RENDER!) then spend development time and money putting a bunch of features of dubious quality or use in.

I don't think the hardware is the issue either - If there weren't people running Max with "old" machines with fewer issues, you could probably say it isn't CL's fault. There's a guy over at CGTalk that's building some incredible stuff on a machine with only 512MB of RAM. The fact is (as others have said), the core of Poser is rotten. They had memory management issues in P5, they're still there in P6. Maybe they're not lazy, or cheap, but they sure as heck are sloppy. Maybe they don't test with multiple figures because they know it won't work... After letting P6 out the door with that memory leak, I'd be surprised if they tested it themselves at all!

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=2174088

Scroll down to #15 on the attached link to a post by WeirdJuice. Not only does he provide a very clear and detailed description of the reason P6 has an even bigger memory problem than (even) P5, he also explains how 4 hours of work on his part appeared to improve things considerably.

But it's the sentence "The good news is that, as the morph loading and storage processing has been changed in P6, it can now be considered to be "live" code and it should therefore be open to further improvements" that expresses what I'd sensed back in the P5_SR2_beta discussions with the likes of Larry W: that some of the older code seems off limits, ie. inaccessible, to CL. If it were true it might explain for example, how a 2005 product which claims W2K or XP as a requirement, stills sports Win9x style file dialogs!

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=2174088

Scroll down to #15 on the attached link to a post by WeirdJuice. Not only does he provide a very clear and detailed description of the reason P6 has an even bigger memory problem than (even) P5, he also explains how 4 hours of work on his part appeared to improve things considerably.

But it's the sentence "The good news is that, as the morph loading and storage processing has been changed in P6, it can now be considered to be "live" code and it should therefore be open to further improvements" that expresses what I'd sensed back in the P5_SR2_beta discussions with the likes of Larry W: that some of the older code seems off limits, ie. inaccessible, to CL. If it were true it might explain for example, how a 2005 product which claims W2K or XP as a requirement, stills sports Win9x style file dialogs!

"how a 2005 product which claims W2K or XP as a requirement, stills sports Win9x style file dialogs!"

The difference in the Windows API from Windows 95 to Windows XP-SP2 is very little, the only new things that were added are some functions dealing with the internet, the rest is all the same! Poser5 runs under Windows 95 first edition without any problem, you only need to change wininet.dll (the version that works is from the first release of Windows 98).

Message edited on: 04/26/2005 15:18