Renderosity Forums / Poser - OFFICIAL
Welcome to the Poser - OFFICIAL Forum
Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Dec 28 2:24 pm)
Subject: I am thoroughly convinced... poser memory rant.
Why don't you try rendering in Vue 5? The latest release has a wide range of rendering techniques- standard, global ambience, global illumination, radiosity and HDRI (uses actual HDR files- not FAKE HDR lighting). I think Vue 5 can far exceed Poser 5's "FireFly"... It reads in Poser files and even P5 dynamic hair and cloth. The new materials editor can even duplicate Poser 5 materials (according to those who have looked at the Advanced Material Editor- which uses nodes and other Poser 5 like material controls). Best of all Vue 5 uses all your STATE of the ART graphics cards- like ATI and NVidia! Vue 5 will NOT work on Windows 98 (like Poser 5) and REQUIRES Win2K or XPpro- so THAT should tell you something right THERE! (No ANCIENT software "compatibility" needed). The new Vue 5 OpenGL is really great!
I paid just $149 for Vue 5, which is the upgrade price. For me the HUGE DIFFERENCE in features over Vue 4, and the far greater POWER of software OPTIMIZED for PROFESSIONAL type rendering of Poser scenes is WELL WORTH the price! ********************************************************** Lighting and Atmosphere Ultra-Realistic Volumetric Atmosphere Model 100 predefined atmospheres 70 predefined shapes of clouds, unlimited layers of clouds Volumetric clouds; volumetric lights (visible rays, with optional dust). Point light, Quadratic point light, Spotlight, Quadratic spotlight, Directional light Complete lens flare system with global/local settings. Light gels with realistic projection modes. Stars, rainbows and ice rings. Caustics in the shadows of transparent materials. Caustics realistically depend on the Index of Refraction. Adjustable light shadow density, negative lights. Soft shadows, blurred reflections and transparencies, depth of field. New! Shadow and volumetric light optimization for dramatic increase in rendering speed. New! Image based lighting New! HDRI New! Global Illumination New! EasyGI global illumination adjustment. New! Global Radiosity New! Adjustment of global light intensity
All Windows 32-bit operating systems applications are limited to 2GB. The 32-bit addressing will handle only 4GB, and 50% is assigned to the OS side of the application, and 50% to the part of the application the user sees. So 2GB is it. CL are clean on this one. CL's sins are a) using .6GB of "other Stuff", and b) getting so little value out of 1.4GB left. 2GB oughta be enough for any Poser scene really... But as Poser 2 or (whichever came to Windoze first) through 5 still seem to use the same memory model as they did in the original version (Windows 95 or was it 3.1?), and still loads everything into memory whether you want or use it or not... So only solution besides a simpler scene, is Poser 4 as it has less to load, both code and options. It seems to me that it should be trivial for CL to not load some features, but it cannot be, or they surely would have done so by now. (As well as fix some very basic Windows file dialog issues, lost textures bugs, etc.) But as they have avoided all such efforts for all versions and SRs for Poser 4, Poser Pro Pack and Poser 5, one might have to assume that they are unable to access that part of the code source for some reason or other...
I have to confirm Little Dragon's observation ... I use two hard drives for my virtual memory. The second one is older, and makes a distinctive sound when the page file is being written to. At a certain point during long P5 sessions, I can hear the second drive kicking in. I just hope memory allocation and release is improved in P6, and assume it will be since this has been a matter of complaint for a long time. Another workaround would be to save your scene when it's ready for render, reboot the comp, then open Poser and render before doing anything else. I find this helps after long P5 sessions or after having done several renders in a row. I'm a Vue enthusiast too, but I think it's important that we try to find solutions and workarounds within P5 when discussing its shortcomings in this forum. After all, as already indicated, many don't want another app or can't afford one. I truly do appreciate your positive enthusiasm, Veritas, but hopefully you can see why some would rather make the best of Poser than buy another app for its rendering advantages over Poser's. Especially since the advent of SR4, P5 really is an amazing app in spite of the glitches.
This is what Mason said (near the end of his rant): "Bottom line. I'm pretty much ready to jump ship as soon as a better package comes along." So actually, my SUGGESTION of Vue 5 was EXACTLY in line with what Mason was saying. He appears to be reaching the end of the road with what Poser 5 is capable of, for his POWER USER needs. Poser 4, Pro-Pack and P5 may be just fine for many people in this forum as they aren't doing really demanding POWER USER stuff... A lot of the problems, that are REPEATEDLY indicated in all these threads is that Poser CODE is OLD and for whatever reason, the people who have had custody of it for the past several years have only been able to make COSMETIC changes to it- nothing DEEP and SUBSTANTIAL... Vue 5 is a reasonable Low-Cost alternative to Poser (cheaper than nearly every other app in its range- Carrara, Cinema 4D, etc.) And Vue 5 is the CLOSEST thing to POSER that any software company has ever released- BUT- with full 32 bit OS POWER and making use of Graphics Card horsepower, etc.-- ALL the things MANY people in this forum have ranted about for YEARS on their Poser "WANT LIST"! Low Cost, nearly 100% Poser file compatibility, Modern 32 bit OS design, uses advanced graphics cards features, TONS of render options, plus realistic water, plants, etc., etc. So in ANSWER to Mason's lament---- Vue 5 IS the ANSWER! (If not- consider MAX or Lightwave, heh!)
I can relate to Mason's irritation. I wish Poser 5 would tell you when it needs more memory instead of just quitting in the middle of a render. And that 'cancel' button just adds to the frustration because what it really means is "control-alt-delete" because Poser ain't gonna stop working on the job for another half hour. And the exploding clothing magnets are a big headache too. But just recently, I did try to render a scene ( a highly populated scene with big textures)with the P4 renderer and it locked up. Then rendered the same scene with Firefly and have to say, Firefly handled it with no problems. I think it's because Firefly allows more render options. Like I could bring down texture from 4096 to 1024 and fine tune the anti-aliasing. Whereas in P4 renderer anti-alias is on or off and it must be using each texture's fullsize. I do have Vue 4 and would use it more but the dang camera goes flying off everytime I touch it. Vue 5 sounds good. Just wish the cameras moved like Poser cameras.
Attached Link: http://www.renderosity.com/messages.ez?ForumID=12368&Form.ShowMessage=1971059
BTW- HERE you can check out one of Vue 5's new Procedural Terrain effects- realistic ocean waves- created by math wizard Hellborn...
Veritas. Despite your probably thinking I'm out to get you, I'm not. Your suggestion of VUE as an alternative to poser is reasonable. However, you have been so thrilled with VUE that you are often forgetting this forum is about Poser, not Vue. And the manner in which your posts are made discredits Poser in a forum that is here to support it, not discredit it. That's what's under a lot of stuff. ANd it is this constant bashing of Poser in an unfriendly manner that has, to a good extent, made renderosity a place that's less pleasant than it once was. Support a software in the forum designed for it. Don't dis it.
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
Well, can I bash Poser 5 in favor of Poser 4 Pro? I still don't use it, even though I've had it since... it came out? whenever that was. The dynamics are cool, but added to the bad memory handling capabilities in P5 (bad threaded addressing calls?), interface that is NOT a improvement over P4, and the requirement to work at 1024x768 or greater screen res I usually don't bother. I also only have Vue 4 (until a lot of $$$ shows up), so P5 won't even work for what I do the most of. Back on the original topic however, try tweaking your virtual memory; set it to a fixed size of 1.5 times your system RAM. This will not only increase the efficiency of your swapping to HD, but will let you know when an application is going nuts as the operating system will prompt you when it needs more than is assigned (in a real operating system like win2k it will at least, and since WinXP is just a pretty interface on top of a dumbed-down Win2k, should work). Ideally you should set up your swap on a freshly defragged seperate drive.
lol -- absolutely -- interversion squabbles are wholly accepted, lol. as for the vm point -- I've noted elsewhere similar things to do on setting up VM, as laying back tells it correctly. It does not matter what the program is, windows will only allow it to have 2GB for itself. What a lot of programs do, however, is add into themselves their own method that works with it -- photoshop is a good example of this. They essentially make their own VM that is used, bypassing the windows system so that they can handle larger vm sizes -- sorta like doubling up the same thing. That's some pretty serious coding to do, however. Which is why not a lot of applications do it. There's additional considerations as well, but that's the core one.
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
So Veritas777 does Vue 5 handle all the material nodes from P5? I use a lot of material combining to optimize figures and memory use. I don't want to go back and reinvent things. Also, I would imagine I have to pose the whole scene in poser then bring it into vue5 and render? I need to crank out scenes fast and make adjustments as I go. Thanks for the heads up. I was seriously thinking of Vue but didn't know if it handled the special shader nodes of P5. Most other packages expect you to export your scene as a big obj then import it and you lose all your materials and have to reconstruct them. For one shots that's probably ok.
The grinding of my hard drive convinces me otherwise. Admittedly, I only have 512MB of RAM .... << That's probably poser 5 searching for textures on our hard drive. >>All Windows 32-bit operating systems applications are limited to 2GB. The 32-bit addressing will handle only 4GB, and 50% is assigned to the OS side of the application, and 50% to the part of the application the user sees. So 2GB is it. CL are clean on this one. CL's sins are a) using .6GB of "other Stuff", and b) getting so little value out of 1.4GB left. 2GB oughta be enough for any Poser scene really... But as Poser 2 or (whichever came to Windoze first) through 5 still seem to use the same memory model as they did in the original version (Windows 95 or was it 3.1?), and still loads everything into memory whether you want or use it or not... So only solution besides a simpler scene, is Poser 4 as it has less to load, both code and options. It seems to me that it should be trivial for CL to not load some features, but it cannot be, or they surely would have done so by now. (As well as fix some very basic Windows file dialog issues, lost textures bugs, etc.) But as they have avoided all such efforts for all versions and SRs for Poser 4, Poser Pro Pack and Poser 5, one might have to assume that they are unable to access that part of the code source for some reason or other... << Yes, and knowing a bit about rendering 3d objects, just adding up the expanded textures and geometry the scene doesn't appear to come close to 2 gigs in memory usage. Plus I reduce all my textures to 512x512 or 1024x1024 whenever possible. I've also used virtual ram before and in windows you can exceed more than 2 gig by simply creating another virtual memory buffer. MAX renders far more complicated scenes without hitting 2 gig memory walls.
The bottom line here is that poser content (character meshes and texure maps) are designed by people living in the the 21st century using 21st century computers. unfortunately poser at it core is a character"posing and rendering" program from the mid 1990's at best. this has not changed with P5 which we all know is just poser4 bogged down even further by leased third party addons that were somehow crowbarred into its out dated code. those of us who are fortunate enough to be able to export poser scenes intact to modern programs( I use cinema4DXL from MAXON) have long accepted that poser itself is just a low end gateway tool for getting a wide variety of diverse 3D Characters into other programs for serious rendering. this is not a put down of poser or CL but an undeniable fact. My only advice for people who use poser exclusivly is to learn to optimize your scenes as much a possible
I have seen some of Mason's work and it is amazing. The issue of just deleting characters, it is possible but how often do you tell an artist "We are out of blue so don't use blue in your landscapes." Curious Labs would be well advised to put out a memory fix, but I have a feeling that could mess up a lot of other stuff. As for Vue 5, I think it is a pain to go back and forth between applications a lot, particularly if both are memory/CPU intensive. I am very intersted in DS but do not like how the Magents of Wyrmmater will not work in it.
"I've also used virtual ram before and in windows you can exceed more than 2 gig by simply creating another virtual memory buffer. MAX renders far more complicated scenes without hitting 2 gig memory walls." No matter how many vm buffers you have, windows, itself, still doesn't allow and individual program running to use more than 2GB. It's not exceedable. Indeed, if you have more than 4GB or VM, the amount over that is wasted and unused. This applies to any windows system at present except the 64 bit server -- which can handle 8GB of VM per program if it is run on a 64-bit processor natively. 3DS Max creates it's own buffers, much like Photoshop does, and utilizes a compression algorithm for handling bitmap images and meshes when handng them off to the processor. Improvements can be made, certainly. You note starting off that Poser cannot exceed 2GB. This is true, and a few of us have noted why. Poser does indeed use VM. Up to 2GB as allowed by the operating system. "What also bugs me is the abhorent lack of error messages when locking up. " I agree, and I really like Poser. Despite some notes earlier otherwise, the only program easily available that allows you to do what Poser does is D|S. (You can't pose natively in Vue) A separate buffer creatd by the program that is used prior to the use of the windows system would help -- but it would also drive the space usage up a lot. Since Poser uses files in their uncompressed and flat state (and from your description above, you're actually using close to 650MB in just figures+cr2's, even with the optimizations) already, there's some risk there. "I am also thoroughly convinced that FireFly uses double the ram of P4 renderer by handing the models off to FF to render. These models are probaly duplicated when packaged and sent to the other renderer. " I have to agree with CL on this one myself -- if it did dupe the object in handling, you'd see a fourfold increase in memory handling at time of rendering, and there isn't one. This is what is killer about hardware assisted rendering, as it does sorta require a doubling of things since it's passed simultaneously in most cases to CPU and GPU. Poser does have limitations. It is still ultimately designed for only a few figures at a time, and the greater community for it has certainly made all sorts of hacks (MAT files use more RAM, incidentally, and for no good reason that I can find) that make it easier to use. Then again, we're not dealing with 5,000 rampaging orcs. Having done a scene with 60 of the little DAZ gremlins, an ichiro, a Koshini, and some really high poly bryce terrains, I definitely feel for you. Oh yeah, definitely. My suggestions are going to be get rid of the CR2's whenever possible (ie, just use the raw objects exported after posing), and check the materials for unpinned nodes (which add overhead). After that, it's going to depend on your render settings -- and I'd go into firefly, not P4, for it.
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
Luminaa, In the Firefly render options window, there's a box that allows you to control maximum texture resolutions during rendering. At default it's set at "4096". If you wanna render at 1024 x 1024 then you can set that box to "1024". I've been told that setting the texture resolution larger than your final render output (like 4096 when you're rendering 1024x1024) won't make much of a difference in render quality. That might be open to debate.
My experience with Firefly and lockups with multiple complex figures isn't memory-related at all. It's poly count, as near as I can tell. I've had FF lockup with the following items: M3, simple hair for same, Downtown, Hankster's Vankwish, Alligator coat for M3, Real Jeans for same, along with the boots that come with it. All of these combine to a very high poly count. When rendering in FF in default production mode it will lockup with only 2 or 300k RAM in use. I'm running on an HP Laptop 3ghz HT with 1gb ram. I tried some of CL's suggestions, reducing bucket size, reducing texture size, remove backfacing poly's, and other things, but it still locked up, no difference at all. If I remove any one of the major items, like M3 and his clothes, or the car, or the Downtown figure, it renders fine. I can even get rid of all of M3's clothing and hair and it will lockup. But the clothing and simple hair prop really don't have a significant poly count. CL has told me that increasing the texture size to something over 4096 could actually make things worse. But again, I have never had problems related to texture sizes. FYI the lockup always occurs at one of the "Adding Objects" phases of the render. I had a similar problem with 2 V3s with the Ult changining ponytail, one M3 with only one clothing item and no hair, and the Country Kitchen figures. The odd part there was, it locked up SOME of the time, and some of those lockups occurred in mid render. No, I don't think it's memory, I think it's poly count and some limitation in FF. Jeff
Look at areas where there is a high degree of Polygon density in close areas and in a large portion of the scene, especially where there is intersection.
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
sorry, my mind was elsewhere at the time. My experience has shown it's not so much poly count, as it is poly density. A close up render of a high concentration of polys in a single location will often cause firefly to simply stop. Hair files are fairly notorious for having exactly that. This is most prevalent in situations where the polys intersect one another, as well. (I discovered the situation while creating plants recently)
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
I haven't encountered that myself. In my scenario I could remove any one of the major objects and the scene would render fine. Which meant there was no problem with any of them individually. But the fact that Poser never even got close to using up RAM meant it had to be something else. I even got rid of all the lights except one, since I had seen other threads that seemed to point to the lights as an issue. I agree with an earlier post that this kind of error shoudl be caught by the program, if there is some limit that isn't obvious to the user, there should be an error message. I worked with CL tech support, and in their defense they were very helpful, but could not solve the problem, and we tended to go in circles somewhat. It never did get resolved. So My only option is to use P4 Renderer for such scenes, which means none of the P5 atmosphere effects could be used in it.
it's poor memory managment that causes lockups, and that is caused by using rad ( rapid application development )
instead of coding for functionality.
targeting the newest hardware rather than most common hardware.
the joys of programs that are 10 times larger than they need to be, the bloat caused by non used code inserted by drag and drop ide (integrated development environment)tools. ( Ms Developer Studio, Visual Basic, Visual C++ ... )
these tools are great for bottom line, bad for quality.
Sorry to be late to the party, but I only now came across this thread via a search on another topic. Here's what I found on the P5 memory limitations: Poser 5 does indeed have a 2GB limit, and as already pointed out, this is a common limitation on Windows apps since the OS reserves the top half of the address space. No fault there. However, it is possible to get into the third gigabyte if you do two things. First, the program must be linked with the LARGEADDRESSAWARE switch, and second, the target machine must have the 3GB switch set in the BOOT.INI file. This will cause only the top 1 GB to be reserved by the OS, leaving a 3GB address space for an individual process. My real-life job is for a software company (not to be named here) dealing the very large datasets. One of our customers ran into the 2GB limit a few years ago, so we set him up with a special version that used the 3GB linker switch. Now, it's not quite that easy, because it's easy to let some programming tricks prevent you from using that third gigabyte. For example, since you "know" that all your pointers will be less than the 2GB line, you could use that top bit as a flag for whether a 32-bit value were a pointer or some other 32-bit data structure like an ID or a collection of byte-sized opcodes. But then when those 3GB switches get thrown, suddenly you've got pointers with that high bit set. Alternately, some large apps do their own memory management, and they may have inadvertently put in their own 2GB limit. I believe Poser 5 (or the Firefly component) is depending on one of those tricks. Since it's possible to set that 3GB switch after-the-fact, I used a developer tool to tweak a copy of my poser executable to access the third GB. Everything ran fine with my usual mid-sized renders. Then I threw a test at it that I knew would get into the third GB. I watched the memory line carefully as it ran, and shortly after crossing into the third GB, the render crashed. Alas, it was not to be, so I tossed my modified Poser aside and made do with various scene tricks to keep my big renders going. (Note: this test was done on a Windows XP machine with 4GB of physical RAM. While that extra RAM doesn't help Poser any, it does make it feasible to run other programs during a big render.) I have not repeated this test on Poser 6, but I probably should. Now, interestingly enough, with Win64 coming down the pipe, I've heard rumours that there will be a mode where the LARGEADDRESSAWARE 32-bit apps will be able to access all but about the top 200MB of the address space, giving them 3.8GB to play with. Again that will be subject to the coding whims/tricks of the app developers. (Note: I haven't read this in any official Microsoft doc, so it might just be a rumour.) If true, then I would encourage all Poser/Vue/etc. developers reading this thread to review their codebases for anything that would prevent them from moving into the high address space, and start using the LARGEADDRESSAWARE linker switch. (From someone who's paid to know this sort of thing, and sometimes actually does.)
Privacy Notice
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
I am thoroughly convinced that Poser 5 with the latest patch cannot exceed 2 gigs even if you have virtual space on your hard drive. In fact I am thoroughly convinced P5 does not even use virtual ram. In scenes with 3 Vicky 3s (that are optimized will nearly all MTs removed) 2 Vicky 2s, 4 Mikes and about 20 articles of clothing I will get memory usage up to 1.4gigs and the scenes will lock every single time in p4 renderer (you can just forget about FF after adding more than 3 figures). Removing one or two figures (doesn't matter which ones) but just enough to reduce the memory usage to below 1.2 gigs, the scene will render. Now I'm guessing the real memory limit is 2 gigs and that other parts of poser simply eat up to this limit. I know XP has a 2 gig limit on ram. I am thoroughly convinced P5 has a hard memory limit of 2 gigs including any internal ram P5 uses that isn't reported which probably adds to 2 gig. Its not an issue of broken textures, bad figures etc since, in experiments, I can remove random figures until the memory is reduced enough, then the scenes render. What does this mean? It means P5 is useless to me for large renders, which, I'm sure people already know, but makes the package rather limited. What also bugs me is the abhorent lack of error messages when locking up. The package isn't truly locked up since it can detect a cancel button press (but won't actually cancel) and you can min and max the app. But, if the package reaches some memory limit and cannot allocate more ram or load another texture, it should say so and tell me what it couldn't load. It should at least assess the scene then tell me to hide/remove figures if need be. Why am I bitching about this? Because each lock up and restart is a huge time sink. I can easily spend a good half hour simply reloading a scene and since CS did NOT fix the duplicating magnet channel bug (as was promised), I have to go through and either zero all the duplicate channels or delete and reload the figures involved. I am currently dealing with one scene that I have spent 4 hours trying to get to render and I still have no final render. That's half a days work dealing with crap and not making material. This is unacceptable. This includes hiding half the figures, rendering to background etc. Again, unacceptable. At least issue a memory error. I am also thoroughly convinced that FireFly uses double the ram of P4 renderer by handing the models off to FF to render. These models are probaly duplicated when packaged and sent to the other renderer. CS denies this claiming they do not do this but the fact FF craps out at half the memory usage is a pretty good indicator. Bottom line. I'm pretty much ready to jump ship as soon as a better package comes along. My system is a dell 3ghz with xp with 2 megs of ram and dual drives set up for over 4 gigs of swap space a piece.