Fri, Nov 8, 9:45 AM CST

Renderosity Forums / Vue



Welcome to the Vue Forum

Forum Moderators: wheatpenny, TheBryster

Vue F.A.Q (Last Updated: 2024 Oct 26 8:50 am)



Subject: Is there a max. file size Vue can save?


Muggle6 ( ) posted Mon, 05 January 2004 at 3:39 AM · edited Wed, 31 July 2024 at 7:44 AM

Hi there and a happy new year to everyone, I am currently working on a scene with a lot of imported Poser figures (about 8 so far)and the total size of the scene gets close to 150MB. Now, when I add on more figure (no matter which I swapped them already) there are two things happening: First while importing I get a message that the texture of the figure can not be found, although it is there and it would be perfectly loaded in a less crowded scene. Second when I save the whole scene it seems as if it would be done correctly but if I look on the file size it is just a few kB and of course the scene is corrupted. Any kind of advises on how to handle this? System: XP, 1GB RAM, 1,4Mhz AMD, 64MB MX400 and 100GB of free HDD Thanks in advance


gebe ( ) posted Mon, 05 January 2004 at 3:49 AM

This seems to be a memory problem. Vue needs at least 8 to 10 minutes (or even more) to save such a heavy scene on your machine. You may think that Vue has finished saving because nothing seems to happen, the slider at bottom is on its end since a while and then you interrupt the program. That's wrong. Wait, wait, wait until it has finished. You can see when a saving is finished, if you can move the slider in the world browser again.


Muggle6 ( ) posted Mon, 05 January 2004 at 3:53 AM

Well, I waited a for quite a while (had lunch) and also saw the progress bar going through on another occasion. It seems there is a "magical" barrier at about 150MB because when I saved the file earlier with 134MB everything was fine.


gebe ( ) posted Mon, 05 January 2004 at 3:59 AM

There is no barrier, except your memory:-)


Muggle6 ( ) posted Mon, 05 January 2004 at 4:03 AM

Okay, no it gets technical: During another occasion (I rendered the whole thing) I saw the following in the Task Manager: Used RAM about 250MB Used Swap about 1,7 GB I wondered why XP left so much RAM unused (as I said there are 1GB) but used the Swap instead. Is there a trick how I can make XP using the total RAM amount? I quit all other task which were not neccesary.


gebe ( ) posted Mon, 05 January 2004 at 4:06 AM

MightyPete, if he reads this, may be more helpful then I here.


wabe ( ) posted Mon, 05 January 2004 at 7:49 AM

My biggest file so far is around 640 MB, so 150 MB does not seem too problematic. In fact, the import thing sounds like a memory problem to me. And you said, that only 250 MB RAM are used really. So the main question is, why is not more RAM used. Because i am on a Mac, i cant answer this question, maybe the e-on support can. But nevertheless, some additional thoughts. You haven't said what Vue version you are using - or i haven't seen it. Would be important to update whatever version it is to the latest, if you haven't done that already. And maybe you can let us know what version it is. What you can try is, to import your Poser characters separatly to a small scene and save them as Vue objects. Then load those Vue objects into the big scene you are planning. Maybe that helps to solve the import problem. With Pro i sometimes have problems to save a scene when specific imported onjects are in. I have reported that but no answer yet. Seem that there are corrupt structures in some objects that can cause problems. So it can be interesting as well, what sort of objects are causing the problem. Another thought is, not to use "save" but "save as" and always save to a new file. I had sometimes problems with "save". I interpretated them as a sort of runtime error. That Vue got confused while renaming the existing file to xxx.bak and then writing the new version. Could be, because of a slow processor or other reasons. Like the OS does some other things the same time. I know that a lot of people here does that instead of "save" because of the problems "save" can make. ufff, that was long. Hope it helps a little, Walther

One day your ship comes in - but you're at the airport.


Sentinal ( ) posted Mon, 05 January 2004 at 7:50 AM

I've had exactly the same problem recently. I found that as soon as Vue wouldn't import properly (the textures couldn't be found as you said) then Vue wouldn't save the scene without it being corrupt, as far as I can remember the file size of any attempted save was 7kb. I'm with Gebe on the reason, memory. As to the solution ? One thing though, are you following the advice of others here and organising your scene into different layers? I've found that helps. Hope this is of some use, though I fear not :(


Muggle6 ( ) posted Mon, 05 January 2004 at 8:38 AM

I have the document organised in layers, but that helps only during the work since not so many objects have to be diplayed/handled. Good thing to do if you have such big files. However, I do not think that it will have any influence on saving the document, since all information (including all layers whether activ or not) will be saved. Correct me, if I am mistaken. Sentinal, what config do you have and could you observe if it happened only above a certain file size?


Muggle6 ( ) posted Mon, 05 January 2004 at 8:55 AM

Walther, thanks for your endurance. I really appreciate your long reply. You are right I forgot the version: it's 4.12. I tried your trick with converting the figs to .vob first and then importing them, same result. So I have to keep on looking for other solutions...


MixedNut ( ) posted Mon, 05 January 2004 at 9:21 AM

Attached Link: http://www.memtest86.com/

Have you noticed any weird behaviour in other applications? If so, you may have a bad memory block. It happened to me a few months ago - seemingly random crashes drove me up the wall with frustration! I tried running memtest and voil- bad DIMM. I now do it almost regularly - unfortunately it doesn't help me with Vue Pros lockups, but that's another story..


wabe ( ) posted Mon, 05 January 2004 at 10:15 AM

You know that 4.12 is not the last version? It is 4.2. Maybe you try to update? Is another option.

One day your ship comes in - but you're at the airport.


MightyPete ( ) posted Mon, 05 January 2004 at 1:22 PM

"MightyPete, if he reads this, may be more helpful then I here. " Hmm somebody call? Hmm saving large files. The biggest sucessfull save I've done is about 1.5 gig. Yup you read it right. How do I do it? Turn off render preview on save. Forget that render, name your scene well so you can tell what it's about instead. Vue will present you with a blank picture, black even so it's important. Never save using the same file name and if you want to know why do a search here for posts by me about numbering saves. When you finally render the picture full after you save that image save the scene again as a new named file and vue will set the just rendered picture as a thumb in the browser. At this time you can delete all working files. Give it time and saving huge files is problimatic at best so watch out, Save often. Do a bit of work then save do a bit more then save like that keep a flow going so if a goofup happens your only one step away from getting to where you where. Assembeling such huge scenes in the first place how I do it. I use multible files and then I save the entire scene as objects all grouped properly togeather is a single massive group. Then I make a new scene and import those huge meshes place and save. When I got them all like I want then I do the final pre save just incase save render then save again for last time ready to burn to cd.. Then I delete all the working files and reboot. I usually don't start to render the grand daddy right away, I do it on a fresh reboot right after I turn all the crud off like ICQ or anything else that could cause problems. Virus scanners, things like that. I turn off everything. Walk away from that computer till it's done. Now if this does not help you have something else wrong so we will have to try different things to figure out how to fix it. Make sure your running 4.2 Oh and impossible textures can also cause this like glowing liquids. You start a hall of mirror effect and it kills Vue trying to figure out the preview render. Keep textures simple. If there 4 layers deep you got to look at them and try to get it so there at most 2 layers deep. Like combining textures. If you need four layers to get a effect try to figure out how you can simplify 2 of the textures so they are only one texture and do that with the other set also. Then take those two textures and combine them into one. You can kill any computer with too many texture layers


MightyPete ( ) posted Mon, 05 January 2004 at 1:48 PM

Oh one more thing hidden layers. You cannot have a 1.5 gig file display in vue so forget it. You hae to put things on hidden layers. Import poser figure. Place it. Pose it what ever get it final. Group it. Drag group to a hidden layer. Save file And so on and so on. Now if the textures is getting you down the problem there is Vue does a sort on import of textures for the texture browser. That's a problem in Vue as this file gets huge. I find Vue will die faster with a large number of textures than any other reason combined. Try to simplify your textures as much as possible to get the total textures used count down.I've probibly rendered stuff with 1000's of different textures but it's pain and takes planning, hidden layers, no open gl, grouping, and seperate VOB objects imported to a new scene. It's sounds like your running into the dreaded too many files open at once problem that is in all Microcrud products. You have to hack the OS to increase the number but even then it's not enough. I got mine here set for 65535 files open at once the max, but I'm not sure about how to hack it in XP. I'll see if I can find info for ya. Chances are it's right now some silly 2000 or less. Why is my question?


Sentinal ( ) posted Mon, 05 January 2004 at 5:24 PM

Muggle6: I'm running a 1.7ghz 1gb machine with XP Pro. I was going to say that although I don't know at what level of file size the problem manifests itself, it's always large, however after reading MP's stuff about textures I can say it always fails after Vue fails to load a texture. (This is both 4.12 and Pro) Whilst I'm thinking about it now I reckon MP's on to a winner as the objects and polygons are never huge and compared to others in this thread the file sizes are modest (150mb) but the textures can be large and many of them. (7 x 4000x4000) and thats just the body textures without heads, eyes, clothes etc etc. I will investigate over the next few days.


MightyPete ( ) posted Mon, 05 January 2004 at 6:32 PM

Can't find anything about the max files open on a XP machine but what I did find if it's correct it very low like a bug low. 256? Like stupid low. Lower than win 95 Now that may not be right but there is programs out there right now and that's the max files open at once on XP. Your problem is probibly textures. Too many, too big ones. If that's the size of poser textures well that's the problem. Think 4000 X 4000 X 32bit is like 512 meg right there. Aren't swap files great? Hey BTW this is not the only program on XP that has this bug There is much more of them. It's XP Now I also read about XP computers dying faster with 1 gig of ram than with 512 meg of ram. Rendering BTW Things to try. See if there is anyway to turn off previews in textures. Other things. Try saving the textures on poser objects as Vue textures so it does not convert them on import. This probibly will not work, worth a try. The thing that I noticed with textures is that vue does this sort to put same textures as one preview in the texture browser and that takes a really long time with lots of textures. That comparing sorting kills it. Find and get a memory defrag utillity. I've posted many links here in the past to such programs. ie: MemTurbo like programs) There usually free. They will force a spool to disk way faster than windoz will and can stop random crashes like that by saving to the swap and defraging the memory in one quick second. I use that all the time with my computer and that maybe why I have such good luck with it. It's usually the only program that I do leave running while rendering and working in Vue. Big textures like that you'll have to really take your time. Find out how and set your swap file to some bigger number like 1/2 gig min. Remember there is also free ones that do the same thing but you can at least try this one for free. http://www.memturbo.com/ Oh and do you have like one big partion? Like over 100 gig c drive? That could also be a problem right there. It's not a 64 bit machine yet.


MightyPete ( ) posted Mon, 05 January 2004 at 6:58 PM

Attached Link: http://www.memturbo.com/thoeryofoperation.htm

You have to read this then you'll see why I use it all the time. Actually it's the only program I have that runs all the time. Oh and yes I use this program right here. It's the one I use. Yes I know there is free versions available. Some of those work very well too I've tried some but since I already own this one it's not much use to me now.


Sentinal ( ) posted Mon, 05 January 2004 at 7:04 PM

Cheers MP, good stuff. One thing I like though is the fact that Vue doesn't crash, like not at all. It won't save but it don't fall over either. :/ As to XP, I must admit that the damn things stable. This machine I'm on now has been up since nov 11 and not so much as a wimper, after the rest of MS's OS's this, for me, is a revelation. Like I said before, I'll have a play over the next day or so.


MightyPete ( ) posted Mon, 05 January 2004 at 7:26 PM

Attached Link: http://www.informationweek.com/story/IWK20011204S0009

The only XP I've tried I've been fixen for other people. Hmmm too much stuff running IMHO. Turn off the eye candy it's not a toy it's bread and butter. Turn off skuz working in the background. I've posted this link here before and using it have got not to bad results on XP. A google search for "XP Performance tweaks" shows up even more. http://www.google.com/search?hl=en&ie=UTF-8&as_qdr=all&q=+%22XP+Performance+tweaks%22&spell=1


Muggle6 ( ) posted Tue, 06 January 2004 at 12:11 AM

Hey MP, I feel honored about so many and so long postings. A million thanks!!! I tried this tips so far and if worked so far that I could import two more figures (I did not try more yet). That's what I did: - putting objects to hidden layers (helped increasing preview speed after all) - used less detailed textures on objects further away (stupid me was using the aforementionend 4000x4000 on most of the figures) -"Walk away from that computer till it's done." (Had a nice lunch in the meantime... ;-) These are my future plans to get rid off the problem: - updating to 4.2 - I found a nice break line where I can devide the scene actually in two sepearate scenes, render them seperately (with the same lighting conditions of course) and then put them together in Photoshop. This way I can use two files. - trying also to use your tutorial about rendering just parts of the scene to increase speed. Maybe you have some more suggestions. Thanks again!


MightyPete ( ) posted Tue, 06 January 2004 at 12:51 AM

All of those sugestions will keep you going for awile. Thing is you just have to be patent, It's the biggest killer right there. When your working on big files you got to take 5 or it will never work. Think of what the computer is trying to do and it might seem like it's taking forever but a few years ago it would be impossible period. We are still on the limit of what the machines can do. There always saying there is no need for faster computers cause not one game out right now can take advantage of all the puter power we got now. It's this rendering that kills them, We are about 20 Ghtz two slow and about 32 bits short to do what we are trying to do right now. Thing is it can be done with planing and using ideas from above to make it work. People look at the art here and say hey I want to do that but they don't understand all the complexity of doing huge renders. It's the learning curve and it's not in the book. These ideas I've developed over years to make it work. Trial and error and even more error than you could ever imagine. I can safely say I can crash any computer no problem but the idea is not to do that even once. So I've developed this system over years of work that works actually quite well for me and now you have it to so apply them and just think when your waiting a minute for the screen to update that same problem might have took me months to work around. So you can almost get a speeding ticket using my ideas in your renders compared to my first tries and crashes. My whole idea of getting vue was to push the envelope and see what this program can do. This program can do way more and work on way more complex stuff than you could imagine. Other programs I got here that cost thousands would die no problem under the same load I put vue threw. Oh one more thing I turn off that instant preview, it's a little too small to be much good. If you need it you can click on it and it will update right then and there. To save time with layout stop test rendering at high render qualities.Use the first two setting to get a idea if your stuff is indeed sitting on the ground and not up in the air. It's a waste of time rendering high quality just to check placement. Also use render area lots for quick checks on different areas. Also when it becomes poly line madness I turn down the line detail a bit to help speed things up too but you get the same effect by using hidden layers. There is lots of posts here by me about grouping and other topics that will also help you speed things up even more. You're now one light year ahead of where I started way back when. Use it wisely.


TheJerry ( ) posted Tue, 06 January 2004 at 3:23 PM

A few other notes from my own experience. I have this exact issue, I find it really is texture indigestion. Vue has a memory leak/issue somewhere that's causing this. I've found that if I get the image imported, save the file immediately (if you can) before manipulating the image. Then close Vue and restart and reload and you can go on. Of course sometimes texture indigestion is so great that it can't go on. I've found then that scaling back on the texture size/type etc can help, as mentioned, but then once you get it loaded and saved. Restart. You are then set. It seems that if Vue loads the object natively from it's own format it has no problems, with whatever texture. I've been able to cram lots of extra poser objects in this way. Actually saying this, I might want to import objects independently and save them, and then load them natively. That should work, have to try. Anyway, the only other thing I didn't see mentioned and that you may not have been aware of. If your file is corrupted 17kb'd as I say. All is not lost. By default Vue makes a copy of the file every time you save. So you should always have a copy of like right before the last save. This file has the same name and a .bak extension. You can open like a normal vue file (you just have to use . in the Open File dialog filter. When things crunch, I make a copy of my bak file, the open the bak file and save as a .vue file.


MightyPete ( ) posted Tue, 06 January 2004 at 4:08 PM

If you use my idea of numbered saves, different file names every time there will be no *.bak file cause it's unessesary you already have all versions saved with different names. Saving same named files over top of existing files can kill the computer if you do it several times cause of the amount of data that needs to be minipulated on every save, Saves take way longer to make and fragmetation of the hard drive occurs more. Now I pretty sure that it's the texturer browser that's creating the problem cause I've noticed. Import object and load texture browser. Import a new object and watch texture brower. Notice you have lots of texture spots displayed with blan pictures near the end as Vue trieds to render all the pictures? After awile you'll notice that the available texture spots is less than when you first lookd at it cause Vue has realized that some of the textures are the same and has dropped on thumb of the duplicate. All this takes time. A way to speed it up might be just save the textures as Vue textures, Can't say I've ever tried that. I bet they load faster cause there is no converting them and the render of it has already been saved to disk. Whatever. I suggessed way back wen on the "What do you want to see in Vue 5 tread " a idea of some how limiting the texture browser to just a single new object and then tabs for each object and a tab for total textures where you could turn off say total if you dont need it. If it ever ends up in Vue 5 I'd be surprized cause like every one votes on the ideas and this is like a bug fix so nobody votes for it. So it got tossed from the list that went to E-on. So here we are with this problem of killing Vue with too many textures cause stupid winders can't handle multi treaded applications. Don't thing so? Do this test. Start up IE Start it up again and keep doing it till the computer crashes. How many times did you get it started before it crashed? 5 ? 6? 20? Got linux here and I can start up say Mozilla 100's 100's of times and it don't crash it could care less how many apps the same I get running. See it can handle multi treaded. Now think Vue and the texture browser and think ever one of those images is a new render that Vue has to make, usually it's making them all at the same time. Maybe 50 at once. Crash ! Vue? No Micronot...!


TheJerry ( ) posted Tue, 06 January 2004 at 5:47 PM

I use the numbered saves for every major change, basically branch points that I might want to go back to (but never do unless I find out I royally screwed up). Now, now, let's be fair to Bill G. I wanted to check to see if this problem happened on my iMac. So I put Vue on it today. Just fine and happy dandy. I can create new files just fine etc. OpenGL actually works!!! (My Billbox has a Matrox Parhelia...which Vue doesn't like....) Except when I go to open ANY file with with the Open command a hideous error appears saying literally "something bad happened" and "please save your scene as soon as possible" So my iMac running Panther (10.3) can't even open a file. That's worse than what my BillBox is doing. As for my linux box? Do you actually run Vue somehow miraculously on linux? I can do 3Delight there, I can do Blender...but I can't do poser and I can't do Vue and I can't do Bryce or Cinema4D. So stable or not, that's also a worse problem then my Billbox. There is a reason they call this 3D picture making busines an ART! It's all the random finagling you have to do to get a picture of any sort...


TheJerry ( ) posted Tue, 06 January 2004 at 6:00 PM

By the by... In answer to my own suggestion... This seems, so far, to be working, strangely well. To work around our problem, Muggle6, Start Vue. Create a new/blank scene. Import the poser pz3 or whatnot file normall. Save the scene for your own protection. Right click on the new object in the group/layer manager. Do Save Object. Name it whatever you want. Close Vue (to clear the memory leak/problem from importing) Restart Vue Load your real scene that you are working on. Do "Load Object" to natively load the .vob file you just saved. Save your main scene and continue normally. As a further test. I imported a couple poser figures into the same blank scene and then clicked on and saved each one individually. Then went and load each one. So far....this has worked great, and in fact is actually almost faster than importing the poser scene into the original main scene.


MightyPete ( ) posted Tue, 06 January 2004 at 7:05 PM

Unfortunatly not yet.


TheJerry ( ) posted Tue, 06 January 2004 at 8:42 PM

So, OK, more revisionism on my part. Stand alone import got me a couple more figures, but then bad saves crop up again. I think it's just magic. If you pester the Vue gods long enough they let you save your file with imports. Odd, of course, I can load these preimported vue pose objects quite a bit, and as long as I don't save the new file I'm doing OK. I can do full renders even. So it's fine with these textures, haven't been having the bad file error with these imports. Who knows. Magic magic magic.


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.