Im having a bit of a problem with final rendering. If a render in image with 1 or 2 figures, I have no problem rendering it, with the lighting etc. at 300 dpi and at a pixel size of around 3000 x 2500. However an image I just designed with 3 comples figures and a background and props locks my computer up. Even if a render it at 1000 x 500 pixels. It locks. I can use the poser 4 renderer, but it's nowhere near as good of a final render as the poser 5 firefly... any suggestions?

I have the same problem with the firefly render engine. I think it's a bug in the program. Have you tried to decreas the quality setting on pixel samples? Try to use draf setting and 3-6 pixel samples. It seems like the more complex the scene is more likely that poser will crash. I usualy render my images at 2500 x 1500 pixels. When using raytrace there is a higher risk that Poser will crash. Be sure to reset all the lights when you apply a new light preset or Poser will crash to. klapakling

you could try decreasing the "Maximum Texture Resolution". I once realized a scene with eleven V3 with textures, just by decreasing this settings.

Is there no patch for this problem? What do you suggest decreasing the maximum texture resolution to? Id rather not decrease the quality of the render, then again, I don't want it to crash either.

What do you suggest decreasing the maximum texture resolution to?

Another thing you can try, if you don't mind some extra work, is to make the texture files themselves smaller. I have the high-res texture set from DAZ for Michael 3, which is nice but a waste of resources if he's very far from the camera. I took all of the high-res textures, made copies of them, made the copies 25% the size of the originals, saved them with the letters "Hi" in the file name changed to "Lo", and made a copy of the Mat pose file with the new names in it, so that I use less memory with a lot of Mikes or with Mike standing far away.

Generally speaking, I think you'll get pretty good results if your texture files are no larger than about 125% of your rendered image size, even on a close up. So, if you're rendered image is going to be 1024 by 768, you don't really need a 4000x4000 texture map, as 1200x1200 one will probably work just as well.

Is there no patch for this problem?

Poser 5 is probably about as patched up as it's gonna get. My guess is some of these issues will probably be addressed in Poser 6, if and when such a critter gets released. The owners of Poser have had their ups and downs with the product, to be sure.

The problem is probably associated with memory resources, since both Poser and Firefly are memory-hogs.

A suggestion (as well as the above cited help):

If you are satisfied with your scene and don't intend to change any poses, try exporting all posable figures as .obj files (keeping the groups intact), and then re-creating your scene using them instead. (If you use any transparancy/reflection etc. you'll have to re-apply them in the materials room. That's why you need to keep the groupings.)

Since the size of a .obj file is vastly smaller than that of a fully-fledged character (just compare the size of a .cr2 file with the corresponding .obj file), this may help.

PS. I'm not sure this will work with P5 (ie "dynamic") hair.

Cheers,
Diolma

Message edited on: 08/26/2004 16:34

The problem is not only memory. I've learned to expect render lockups (my scenes are usually big and complicated), so I've learned to ALWAYS save before I render. When I watch resources using Task Manager, and the render engine freezes, I usually still have over 200 Mb of available memory. I don't know what happens, I have the impression Firefly enters an infinite loop. Processor usage is at maximum, but no memory transfers are done. Changing maximum texture resolution tends to help. Increasing minimum shading rate also helps (but don't go above 2, your render tends to get blocky). Weirdest of all, sometimes a scene won't render on my main machine, and it will render perfectly on my secondary machine, at exactly the same settings. The difference between my main machine and my secondary machine is the processor: I have a P4 2.8 on my main and an Athlon XP 2700 on my secondary.

I do have the same problems detailed by svdl on a rather strong sytem: 2Go of DDR-SDRAM (corsair TwinX LL)working in dual channel, PIV(C) 3Ghz, MB Asus P4C800E-Deluxe, SATA hard drives. I looked at the memory use, and renders may bug with 1.2 or even at 1.7 Go of Ram use... Consequently, it does not come from the amount of RAM. By the way, I noticed no improvement with my second Giga of RAM... If you also consider that so many of us, with very different system, experiment the same kind of problem, this is surely a problem with Poser itself. This means that there is nothing else to do but wait and wait again for a better product from Curious Labs, hoping that their 6th version won't be as "curious" as the 5th!

I tried diolma's trick once. Didn't help, the render engine locked up at exactly the same stage as before. I did have more free memory though. Some additional info: my main machine has 1.5 Gb of dual channel DDR400 (Kingston), my secondary has 1 Gb of DDR333 (also Kingston). My secondary machine tends to be faster rendering Poser scenes, the only reason I can think of is the fact that it's got a 2x80 Gb ATA100 RAID 0 disk system, whereas my main machine has a single 160 Gb ATA133 disk.

ahem. And what are the virtual memory allocations on these systems? Note that windows has specific requirements (typically 108 to 340 MB) of active ram that it keeps more or less open whenever possible for services in use by the system. Note also that Poser does not wait for windows to adjust virtual memory allocations, so if there is not enough when a render starts, Poser will just merrily go about rendering into the same tiny spot in Virtual memory indefinitely.

Virtual memory settings: 3 G on my 1 G system, 4 G on my 1.5 G system. Hard settings, min and max are the same. Total use of virtual memory never even reaches half of the amount allocated on disk. I also defragment my disks on a weekly basis, the amount of free space on the Poser partitions is about 60 G (on both systems) and 15 G on the system partitions.

I'd be surprised if it ever reached half of what's alloted -- Windows doesn't let any program ever use more than 2GB total, no matter how hard it tries. I usually suggest more becuase that gives space for the overhead of windows and any other programs that might be running. In that case, look to the particulars of the textures involved AND the specific render settings in use. NOtably, the size of a jpg texture should be commensurate with the actual need for it as displayed, and this should be matched to a good degree by the maximum texture resolution and then sharpened by the shading rate -- both in render settings and on the various objects within the scene. The problem is associated with memory resources -- always has been. The problem is that we don't expect it to be because other programs use different methods for internal handling. It is outdated, but Poser 5 uses the same methodology used since Poser 3. That method is one of the simplest and least efficient ones when working with large files as the throughput on it is not incredibly high -- that's what ya get with legacy code that predates 2k and XP. The fact that they handle it better is a credit to the os designers. Now, that said, reduce by at least half and into a factor of 8 any textures over 2048 that will not be displayed at 2048 or greater image size (that is, a render where the are concerned is being rendered at the same effective size as the actual texture map). Beyond this point, it's sorta adding wasted overhead, as the shading rate parameters and shader settings can be used to effectively sharpen the resolution of the texturemap beyond that point -- a capability sorely lacking in poser 4. the only other issues I've encountered that can cause this are objects which are malformed within the limitations of the rendering engine to display them and driver interaction problems (which trend to manifest in other areas as well).

I take that back. There is one other thing that still occurrs and screws stuff up. The posertemp file. They appear at random locations (seemingly) within the poser folder and subfolders, and they tend to halt renders dead cold.

I noticed that posertemp problem too. When a render has crashed, I delete all .tmps and poserTemps, and restart Poser. Sometimes it helps, usually not. About the virtual memory, the amount used by Poser never reaches 2 Gb, for just the reason you mention. 1.8 G was about maximum (and that render finished fine). I meant that the virtual memory of all running processes added together never reached half of the available virtual memory, the systems never have to increase page file. Textures may be the main problem, scenes using mostly procedural shaders can be way more complex without crashing the render. Time to start up Photoshop and make some midres and lores textures for V3!

One thing I've noticed recently. I have a pretty old system, though the CPU is more than fast enough, and recently upgraded the graphics card because of DirectX driver problems. The old card was a good piece of kit when it was designed, 5 or 6 years ago, and even when I bought it. So Poser doesn't, apparently, use hardware acceleration, but somewhere between the extra graphics RAM and the new drivers, things have started to work better. It doesn't eliminate crashes, but can anything?