If this has been handled before, please forgive the repeat and just direct me to the answer if you know where it is . . . .

Quandry: On this particular project I am using V5I as a "studio" with a few Poser characters and a few lights. This XP Pro machine has 2 gigs of ram, HT P4 3.2 GHz CPU, and about everything else you could ask for.

After a few spot renders, Vue tells me that I am running out of resources -- although various perf. monitors show that I still have 1.2 gigs of ram left and lots of HD space.

If I dump the history cache, it makes no difference. If I close Vue and restart with the same project, all is well again. 

What's going on here and is there anything I can do to improve the situation?

Thanks in advance.

Ok, yes this has been answered before, but no problem, I'll explain it to you.

The OOM ( out of memory) message comes because of the texture maps that Vue has to load in your RAM for your Poser figures. Poser relies on hi res textures for its figures. Check in your runtimes the size of the images, they generally are 2048x2048, if not higher.

It is not recommended to have more than 3 figures in a scene (I'm not talking about ecosystem figures, just "real" ones.)

A workaround would be to: load them in separate layers, and hide the layers you are not currently working on, and make several render passes and composite in a paint program.

Another workaround is to buy SkinVue2 at Cornucopia3D, it's a Python script that swaps Poser textures for procedural Vue materials, and doesn't need much resources, and looks very realsitic.

Or create yourself in a paint program  a lower resolution of  your Poser figure texture maps.

Thank you Bruno . . .

The message from V5I is about "resources" -- not memory specifically. At best, Vue is only using 200- 300 MB of the 2 GB ram that I have. At the time the message occurs I still have 1.2 GB of available RAM. I don't see how Vue could be literally "out of memory" . . . but apparently it thinks it is.

Thaks for the info about SkinVue -- I have read the revues and visited their site, but I have not tried it yet. How does it handle highly customized, hand painted Poser textures? For example, aged skin with many lines and wrinkles painted onto an M3 texture?

How can it keep those details when converting to a procedural texture?

Thanks for your feedback.

R. 

Vue says resources, but you have to read memory, and I know it doesn't always show in Windows task manager or your ram manager, but believe me, this is is the problem.

SkinVue2 has different ways to work, procedural materials that will not take into account any texture map, enhanced that will add procedurals to your texture maps, and in this case, your custom map will show, but resources will not be freed, or cell shaded, or cartoon style, that will not use your maps.

Most OOMs are openGL related, so one workaround I didn't mention earlier, is to switch to wireframe display, and see if it improves how Vue behaves.

Thank you Bruno,

I switched off hardware OGL and am using software GL. I also switched all windows to wireframe except the main preview.

That seems to help, but it's not a satisfactory solution.

I appreciate your previous suggestions, but I cannot reduce rez on textures -- I am doing Limited Edition signed Giclee prints, 22" X 28" at 300 DPI. That requires high resolution textures. And right now, the available textures for most objects barely cut it for that size output.  Though I create some of my own textures to appropriate scale, I mostly modify existing ones. I think that's what most of us try to do instead of having to re-invent the wheel each time, n'cest pa?

But I'll tell you, it's a bit disappointing. I've been a Vuer since the first version I have pretty much first-rate equipment. I really didn't expect such poor memory management from the latest version of Vue -- really -- not after all this time.

In this case, my document is only one Poser adult, a few props, some clothes and 4 cats. IMHO, that shouldn't present such a huge challenge to the Vue render engine. It's doubly annoying because I really do enjoy using Vue for landscape and as a rendering environment.

The point is, as I'm sure you know, being creative is tough enough -- I don't want to be forced to become a hyper-techie as well. I've been a power user since the PC was invented and that's always been enough. But these kind of problems are beyond what I can deal with in the day-to-day of things. And it would be no small task for me to "switch horses" at this point, so to speak.

So I have to ask out of my own ignorance, why is it that I can work 150 MB images in Photoshop with multiple layers and undos, and no memory problems -- but Vue can't handle a 50 MB file without slowing to a crawl?

Even Poser doesn't struggle with large files -- it just won't render beyond 4096px, plus it takes all night to do it, and IMO Firefly is not nearly as good a ray tracer as Vue.

Anyway, I will check into SkinVue with more attention to detail. Thanks for the suggestion. If it can help solve this problem without destroying custom textures, I'm on it tomorrow.

Thanks for all the help, Bruno.

Cheers,

R.
www.rainer.us

I must agree you're right about photoshop handling huge layers better than Vue handling texture maps. There has been so much grief about this problem with Vue that I'm confident next release will be better in this field. But for now, that's all we can do.

I'm surprised that your scnee creates such problems. At first I thought you had 4 human figures in the scene, but only 1 with 3 kitties shouldn't lead to this problem. Did you check "collapse identical materials" when importing your pz3?

Also, I think you get the OOM because you want to render at such a big resolution. In this case, Vue is not the culprit, it's not enough RAM. I've had this a few times, and Vue told me that it required more ram than I had to render my scene. I said render anyway, but got the OOM. Is this what happens with your scene?

If you have another computer around, even an older one, use Hypervue network rendering.

If not, try and render to disk instead of screen. This works better, since Vue doesn't need to show the computation on screen, it needs less resources.

Did you check "collapse identical materials" when importing your pz3?

Yes . . .

Also, I think you get the OOM because you want to render at such a big resolution.

No -- the current problem happens at small rez -- 550 X 700 px at 96 DPI. They are spot renders -- I do many of them for Work In Progress long before I render the big ones. And I always render the large images to disk.

• Bruno, the problem here is that after a few spot renders, Vue complains, gets slower and slower and eventually bogs down. If I then close Vue and restart it with the same image, all is well again for awhile.

If you have another computer around, even an older one, use Hypervue network rendering.

Yes, I have a few comparable systems with render cows on a small LAN connected via Firewire. If If I needed large WIP renders, I would use the network. However, render cows have been somewhat problematic since their introduction. I usually get the most trouble-free results by rendering final images to disk.

But as I said, the problem occurs on a modest image with small, partial WIP renders at low resolution.  The issue is the ability to work efficiently while developing a scene. Final renders are not the problem.

It seems like Vue uses memory once for the render, then marks it as "used" and next time takes a different chunk of RAM and marks that as 'used" and so forth, until Vue is convinced there is no memory left (even though physically there is still over 1.2 GB of RAM in the pool).

Hey Bruno, thanks for all the input.

R.

I rarely use the area render , it is way too slow for me, and maybe you should address this to tech support, because i don't think this has ever been talked about before, maybe noone uses it because of general slowliness, but maybe we should do something about it.

Hmm... this could be a memory fragmentation issue.

It could be, that after all your spot renders, although you have 1.2 gig of RAM left, it's not contiguous, but scattered around in tiny-weeny little pieces, with other, used, chunks in between.
So when Vue then requests a new (largish, contiguous) chunk, it can't be found. A symptom very similar to disk fragmentation, except that while fragmented files can be handled by the OS, most software can't deal with fragmented memory.

Or, of course, it might be something totally different....

Cheers,
Diolma

Thank you both for your thoughtful suggestions.

I think you're probably right, Diolma, it's most likely a memory fragmentation problem. After all, we've been dealing with that issue on PC's since the beginning, haven't we . . .

Maybe I'll pickup a ram de-fragger and run it periodically to see if that helps. Meantime, it's not that big of a deal to shut down the program occasionally and re-launch it. I just thought maybe there was a tweak I was not aware of that might help.

Cheers,

R.

I agree with Diolma. I would definitely close any other open programs and unused services.

You can also save memory by saving the Poser imports as VOB objects, and then re-importing the VOB objects as substitutes for the Poser objects.

rainfrey,

Some other big memory stealers are GI/GR, HDRI and soft shadows. You might want to check your settings for all of those as well. Adding multiple lights, with GI on and soft shadows usually gets a groan from my system.

best, Chipp

I have been having the same problem a lot. I can confirm that it's having large texture bitmaps that causes the problems. I've started editing all mine down to a maximum dimension of 2000 pixels and this helps enormously. Nothing else works, I can tell you that. Turning off OpenGL improves things a little, but it becomes impossible to see what you're doing because the wireframe image is so lousy.

A little experimentation will show that Vue leaches away memory AFTER EVERY OPERATION when large bitmaps are present. Doesn't matter whether you do spot renders or anything else. Every operation, including just moving the camera around, takes Vue a step nearer crashing. Real killers are moving a Poser figure from one layer to another, or cutting and pasting them.

The only solution is this - for your scene, work out how many operations you get from loading to crashing. It may be as few as twelve. Load your scene, do ten things, save, quit Vue, start again, repeat until you get to a final version. It is inexpressably tedious, but short of reducing bitmap size it's the only thing you can do.

Thank you all for your comments.

The situation described by Phantast is exactly what is happening here. And I have been doing just that, relaunching Vue after X operations.

Maybe Vue 6 will handle memory more efficiently . . . sigh.

R.

If it's a complete rewrite as promised, one can hope that it will. I can understand that a program may be heavily loaded and perform poorly when large bitmaps are present, but there's no excuse for losing memory after every operation. It's buggy programming, and I would like to see it fixed in Vue5, which is the software I paid for.

I've just had a bright idea which I've tested and it works, and it may make life a little less hard for rainfrey. For those cases where you absolutely must use large hi-res textures.

Let's assume you have a Poser character called "Anna" and her texture files are in texturesvicky3anna in the Poser runtime. Now, under that folder, create two more, called "large" and "small". Copy the big texture files (anna_body.jpg and anna_head.jpg) into annalarge.

Now - working with the copies of the files in the anna folder itself (which are the ones Poser references) - load them into Photoshop and reduce them to a maximum dimension less than 2000. In fact, you can make them as small as you like without any ill effect. Copy these small files to the "small" folder.

Go back to Vue and load your vue scene. It doesn't matter if you already imported the pz3 file, vue doesn't store the textures in the vue scene file. What is referenced in the scene is annaanna_body.jpg, which is now a tiny little file.

So you can now work with the scene to your heart's content, because there are no longer any big texture files loaded. Once you've finished, just before you hit the render button:

• save the file
• close vue
• drag the files from anna/large into anna (overwriting the small versions)
• start up vue and reload the scene
• render!

When vue starts up it reloads the texture files, which are now the big versions. Close vue once the render is complete. If you want to make changes to the scene, drag the small versions into the anna folder and repeat.

This is a bit of a trouble, but a lot less trouble than counting your camera moves. You only need one save and reload per render.

Good idea Phantast!

For those cases where you absolutely must use large hi-res textures.

If you read the top of this thread, you know that my final output is Giclee prints 22" X 28" at 300 DPI. However, I may also be doing some really huge blow ups of select image parts  . . . for example, using just a character's face to take up the entire sheet . . . so it takes pretty large textures to hold up under these conditions.

But it never occurred to me to create low-rez tex for WIP.  Great idea, thanks!

vue doesn't store the textures in the vue scene file.

FYI, Vue can store textures if asked to. It's a save option in V5I. Makes files easily portable and helps avoid problems with network rendering.

Thanks again.

R.

yeah as a tip what I do to preserve my projects is to save EVERYTHING in the project folder, poser character saved as vob, any special materials created for the scene etc.

because say you back it up to DVD (as you all should do!), and later, need to re-load the scene, if you haven't saved the texture maps as rainfrey notes, that can be bad, but also, it saves a LOT of hassles if you've saved any special items in the folder too, like Poser people etc.

as a note I'm often copying/saving Poser textures now as 1024 or 512 versions, and named as such in the Poser folders, such as say: M3skin_1024.jpg

:)

Two suggestions that help a lot in case of resources issues (if they are applicable to your situation).

• Turn off openGL preview

• Reduce the number of levels of Undo down to 2