I "fourth" that motion. If anything, SP reminds me most of a "super-posette" in terms of prettiness as opposed to the more staturesque Victoria figures. The only thing I worry about is that, as a semi-freebie, she's going to get less support than the "premium" model. Bill

The same problem occurs with scaling the hands of all of the Poser figures. I don't know the cause, but I suspect it may be Poser's inability to handle very small or overlapping deformation regions. The "standard" solution is to re-scale the entire body by the required amount and then to scale up all of the (major) body parts to compensate. Bill

Actually your somewhat behind the times on this. I proposed it almost immediately after the launch of P5 and before the development of Studio was publically announced. The community reaction was, on the whole, lukewarm, which is why it hasn't been widely publicised since. Nevertheless, specifications have been made and reviewed and there is prototype code and work on serialisation has begun. Although while I've been tied up with other work recently the project is very much alive and is likely to go public sometime in the first half of next year under the Mozilla public license. The concept has evolved from a stand-alone "Poser-like" application into a general purpose scene description core library with all of the peripheral elements (user interfaces, im/exporters and renders) defined through the plugin modular interface. In conjunction with MPL this means it could also be considered as a royalty-free library replacement core for Poser, DAZ Studios and other existing applications as well as the core library for network rendering clients and format conversion utilities. Basic user interface and rendering interface modules are to be developed and included as part of the project, so that it will be usable as a stand-alone application, but its hoped that independent developers will contribute more sophisticated interface elements, e.g. open-gl support. If you want to go it alone, however, the best advice I can give is to start a project on sourceforge, which provides hosting, sharing and source control for open source applications. Bill

There was a similar bug found with the "apply to all" menu option (SR3), i.e. the image map nodes seem to be correct but no actual texture appears in any of the preview windows. Reselecting the texture from the pulldown menu of the texture selection dialog seems to fix this without necessitating a restart of Poser. Bill

Plus, the grass is a bit day-glow. Nevertheless, I love the subject matter, Anthony, it takes me back to when I was about eight or ten and UFO was by far and away the best thing on the box. Bill

Carolly says: *Don't leave. Every voice they manage to still, every person they chase out, only reinforces their claim of "unresponsiveness". * I don't know where you got the that anyone was attacking Stefan from, Carolly. He's a big boy and he's demonstrating that he's quite capable of acts of self-immolation without any external assistance. All that happened (and you should really make an effort to read these threads before you interject) was that Stefan went off on a pointless bug-disproval exercise and, in order to save him wasting any more of his time (and, of course as a matter of civic duty), I gave him a direct and simple test case in which he could witness the bug for himself without further dispute. Where I criticised him for demonstrating poor engineering techniques I was, admittedly, harsh, but nevertheless truthful. I most certainly didn't pour flammable liquid over him and I really don't think that even that criticism amounted to handing him the matches. Of course everyone makes mistakes and the occasional lapse but the guy must have been having a bad day... In an earlier post I did describe bug finding as one of the most thankless tasks in this community and subsequently Stefan managed to prove the point perfectly by, ungraciously, trying to excuse the bug with a criticism of the techniques of myself and the great majority of Poser users, backed by a statement regarding the "length of a piece of string" along with numerous contradictory quotes from the string trade (or something equally meaningless and irrelevant). Also, back on your quote, I don't know who "they" refers to, but I guess it a reference to "everyone who's not us", whoever "us" is. I am aware of "individuals" in this community, such as myself, who have put a great deal of time and effort into improving Poser through bug finding and identifying weaknesses, and if sometime we're critical it's because we need to be. We match it with constructive comment, accurate analysis and decisive opinions and, ultimately we've gained some small comfort in seeing our efforts reflected in both CL's and DAZ's future development plans. I'm also well aware of "individuals" who, as self appointed public relations representatives for CL, have been characterised by the inability to follow threads, knee-jerk reactions, rudeness, ineptitude and shortsightedness - the very sorts of people who try to turn technical and bug reporting threads into flame fests and factional recruiting grounds. By their voluntary association and the self-defeating negativity, these people have done a great deal harm to CL's public image and may have caused substantial harm to CL's business without ever providing any positive benefit for the company. Now it's enormously presumptous on your part to be creating your own minority clique and assuming the mantel of the "community", every bit as much as misguidedly believing that you are the sole "friends of Poser". Communities, of course, naturally tend to factionalise but responsible members should always strive to resist that tendency. However, if you do manage to form such a leper colony, please exclude me from any future member lists, as, I suspect, five minutes in your collective company would find me trying to saw off my own head rather than be exposed to anything more than you have to say between yourselves. I'm really much happier to remain one of "they", thank you very much. If your comment was intended as an invitation to Stefan, I'll let him decide whether to join the ranks of the bitter and ridiculed. I think his reputation (and his credibility in my eyes) has taken a battering, but its not unsalvagable. In fact I'm rather inclined to offer him some real hope to redeem himself. While Stefan has been searching his library for the definitive definition of string length I spent another ten minutes doing something constructive. Here's another exercise, Stefan: 1. Bring up the task manager, select "View::Select Columns::VM Size". 2. Launch Poser 5 SR3 into factory default state (i.e. 3 default lights and casual Don with hair). 3. Select Light 1 and set shadows to ray-tracing. 4. Select Lights 2 & 3 and disable shadows. 5. Select render settings and set to "Production Mode" and enable ray tracing. 6. Note the value of the "VM Size" for the Poser process in the task manager. 6. Render a movie using "Current Render Settings" across the default 30 frame range of the static scene (i.e with no animation). About 10 minutes. 7. After the end of the rendering note the "VM Size" of the Poser process. And, yes, its another memory leak, with not a shadowmap in sight (about 50MB in a 30 frame animation on my setup, maybe it would worth testing whether 3 ray-tracing light would give exactly the same results as the shadowmapping case). Just to save you some time, the answer to the first question that's inevitably going to pop into your mind is: "It's because you weren't looking and I was." Now, so far in this thread I'm the only person who's put any time or effort into really addressing the memory leak issue. As I stated earlier, however, I'm really no longer inclined to do this anymore, except as a diversion, and, if you re-read the previous posts (including your own Stefan), you'll understand why. So I'm not investigating these bugs anymore, and it's up to you whether you want follow Carolly into self-important oblivion or, instead, take up these problems, investigate further and demonstrate that you are capable of providing some real useful work that will actually help CL to improve the product. You don't, of course, have to do anything you don't want to, but the opportunity is there to achieve something positive in this thread and come away feeling good about it. Just don't expect anyone to thank you for it. Bill

• He works at Pixar * In which case I can only assume that such a simplistic "rule of thumb" has been taken wholly out of context, or was merely poorly thought out. Bill

• Mr. Jeremy Birn gives as a "rule oft humb" that at shadow map sizes of >= 1024 you should seriously consider ray traced shadows instead - and I think Mr. Birn has more experience than all of us together. * Technically, the resolution required in shadow mapping is directly proportional to the output resolution. Likewise for a scene of any given complexity the number of ray tracing intersection calculations is also directly proportional to output resolution. The only point where a switch should be considered is where one implementation begins to fail technically, specifically, in this case, if the shadow mapping size on disc or in memory forces a resource crisis, which typically manifests itself in the intervention of OS resource management services. However, this apparently isn't the case for Poser shadow-mapping, as all of the reports have been consistent with memory leak problems, i.e. performance is acceptable at the outset, but begins to deteriorate with progress. Now I'm not sure of Mr Birn's qualifactions, or the amount of experience he's had with Poser and Firefly's implentations (I'd guess none), but I expect he was referring to specific implementations, and if he was generalising, frankly he talking crap. And I'm sure some people at Pixar, who almost exclusively use shadow mapping techniques, and for whom render times equate directly to production costs would disagree with that as a general assertion. But I digress, as this has nothing to do with the subject. Poser 4 users had no choice but to use shadow mapping. It was all that was provided. Likewise Poser 5 users have little choice but to use ray tracing, not because its the only alternative, but because the shadow mapping is broken and apparently nobody at CL has managed to find 5 minutes to verify that the myriad complaints and problem reports were in fact based on observation, rather than being of mischevious purpose. Hence cue dissatisfied customers and poor company reputation. If the best defense, after the fact, that can be made is that "Some bloke who never used Poser but wrote a book said that you shouldn't be doing it that way anyway", then frankly nobody should be surprised that users like Tim sometimes get a bit hot under the collar. Bill

• Why do you need such large shadow maps? Do you render at 2k cinemascope resolution? * The vast majority of experienced Poser users would find that to be an astonishing assertion. It could be viewed as being a indication of a surprising lack of experience on your part in the medium (and a worrying one coming from an ex-Cl employee). Rather, I suspect, it was just a an ill considered reaction. A 1024 resolution could only be described as "modest" for most non-newbies. The importance of shadowmap resolution has long been noted in this forums and that resolution is, for most people, the minimum considered useful. Mindful of resources I do use lower resolution maps when I can get away with it, but common wisdom (since P4), puts ideal shadowmap resolution for high quality work at values of 4096 or more, values that are commonly used in final production by the best artists. If you ran a poll in this forum I think you would find a very, very small percentage of users make use of lower resolutions than that, and if you take a good look through any of the light sets you may have acquired you'll find the same. As someone who demonstrated some experience in rendering technologies, you should be fully aware that as a "rule of thumb" sampling algorithms achieve the best quality when the sampled input (in this case the shadowmap) has at least twice the resolution of the output. And this is the minimum. If you need to illuminate some extensive area (say a wall in perspective at an large angle to the camera plane) the shadowmap requirements will necessarily have to be increased to achieve foreground resolution. And, of course, any animators who are satisfied with constraining their works solely to what can be seen within a narrow spotlight beam really aren't making good use of the medium. As soon as any camera dolly panning or zooming are introduced, the resolution requirements can become much greater than that required for any single frame. As a fellow student of REYES and Renderman technologies I expect you to be aware of the perceived advantages of shadow mapping over ray-tracing, not least of which is the improved performance that has endeared the technology to the likes of Pixar. Despite this theoretical advantage, many P5 users early on migrated to raytraced shadows precisely because of the perception of poor performance of the shadow mapping in Firefly. This is leading me to wonder whether the memory leak has, right from the start, been responsible for nullifying the speed advantage of shadow mapping. Ultimately, however, this is nothing but a serious bug. Expecting people who upgrade to change their working production techniques or the quality of their work simply to accomodate a failure to address bug reports is a recipe precisely for the kind of product dissatisfaction (and community strife) that we have widely encountered. Making apologies, or even outright denials, and wasting effort concocting scenarios to disprove a widely reported problem, rather than spending the five minutes that I spent this morning confirming it (plus another 30 minutes or so revising the technique so that anyone could reproduce it) is a disservice to, not a favour for, CL (as well as being extremely poor engineering practice). Sometime ago I gave up spending my time investigating bugs in the program because of the general hostility (including knee-jerk denials) amongst some sections of this community to anyone reporting bugs. That and the continuous lack of response from CL. I suspect that others feel the same, and everyone, of course has suffered for this, not least CL. Bill

Stefan, It sounds like you're watching the "Mem Usage" column of the task manager. This can be deceptive as it really only reflects the RAM usage and leaked memory tends to migrate to the disk pages through disuse. I haven't looked at this in SR3 (as opposed to SR2.1) before today, but it does look like the leak still exists. Here's a method of reproducing it: 1. Bring up the task manager, select "View::Select Columns::VM Size". 2. Launch Poser 5 SR3 into factory default state (i.e. 3 default lights and casual Don with hair). 3. Select Light 1 and set the shadow map size to 1024* 4. Select render settings and set to "Production Mode* 5. Note the value of the "VM Size" for the Poser process in the task manager. 6. Render a movie using "Current Render Settings" across the default 30 frame range of the static scene (i.e with no animation). About 10 minutes. 7. After the end of the rendering note the "VM Size" of the Poser process. It will have risen by about 120-150 MB. Minimising the Poser window will free up RAM ("Mem Usage") but won't effect the leaked memory in VM. *The best I can tell is that the memory leak is associated with shadow mapping, hence the setting of production mode which enables this. The actual setting have been somewhat difficult to pin down, it could be that there are in fact several sources of leaks. Bill

A forum search would be useful, since this is an oft-recurring problem, and I think you should find at least one other occurence within the last week. Having said that I can't remember the exact cause, but IIRC it may have something to do with corrupted .rsr files in the RuntimeGeometries folders. Deleting all of these RSRs (but not those in the main Poser folder or the libraries folders) won't do you any harm. Bill

Is it possible that the tint is coming from your lights? The default lighting setup does give everything a peachy/yellowish tint. Bill

It's not against TOS, nor in any way offensive. It's not Maya Doll, its a photograph. It's not pierrecolat it's Bebop. The purpose is thread is either to stir up some obscure controversy or just to insult the intelligence of Poser users in general. Either way it's just tiresome, and best ignored. Bill

The best place to start is the magnets section of the Poser manual. Bill

I've been finding the same thing and it does seem to be a new bug, or at least one of which I've been previously unaware. One important thing is to make sure that all of the nodes in a texture are selected before trying to use the apply to all, otherwise unselected nodes will not be applied and, likely, connections broken. However, even then some 2D image nodes which apparently have the correct texture loaded still show up as blanks, even in their own preview window, after the apply to all option has been used. Reselecting the texture from the node's pull-down menu seems to fix this. Bill