AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ::sob sob sob::

:( It looks like it was a really nice scene. What went wrong?

:((((( so much for vue 4's 40% faster render time!

Is that for the daz calendar Bloodsong? If so then maybe you could render smaller to get something to them before the deadline. Then work on getting a large render after the smaller one is submitted. Hopefully you can get it to work looks like an excellent image. Griggs

Sorry to hear that. Was it rendered in 'render to disk' mode ? If it is, did you disable the power saving settings on your system ? (screensaver, hard drive standby, etc...) I found they have a big impact on the result of the render. Also... I will say this again : don't do anything else with you machine while Vue is rendering :) Take a break, read a book, go for a walk... Now that I am rendering increasingly complex scenes, I never had that much time on my hands away from the computer. Vue can be a good therapy for computer addiction.

Sorry to hear that... Well, with me, Vue doesn't render to disk at all.... I have the upgrade... I'm writing to them and see what they say...

I would try render to screen - you can make it bigger than your screen if you want to - you will have to pan around at the end to find the save button - and you can see what is happening and if you see corruption like this you can stop the render and investigate. Also, if you are using Vue 4 then I think you must also have been using ultra to get a render time that long. Try broadcast - I cannot see any difference worth bothering about between that and ultra. It may very well be some other program interfering. When I got Vue 4 it would not render transparency properly. My vegetation leaves all had black surrounds where the transparency should be. After countless emails between myself and e-on help, lots of enquiries on this and other forums, I decided to turn off every program I had running in the background, virus checker, zip magic, firewall and so on, and then turn them on one by one to see if I could find a culprit. It turned out to be Keyboard Express. I have now switched to Typeitin which does much the same thing, and uninstalled Keyboard, and Vue 4 is perfectly happy. If you render on screen you can see if this corruption is happening, and conduct similar experiments. If it happens in every image you do, it may be that something like your virus program is conflicting. If it is just this one, then it may be this file is corrupt and the quickest solution would be to start again - infuriating when you have it just as you want it. Hope you sort it out.

oh man... :(

Bad luck, guy ! I'm rellay sorry for you... :-(

Yeah, what agiel and Caroluk said.... I will not trust rendering to screen. I've done it, and had it work, but I like seeing it happen, so I always render to screen. And I always disable all the power settings, but haven't had a problem with allowing the screen saver to run. I HAVE though, had problems when allowing the sleep or hibernate, or whatever settings to take control. I would think that rendering is a running task, but Windows doesn't seem to think so....

heyas; oh, the pic was much bigger than this, of course. (no it didnt take 30 hours to render 450x320! lol!) now the honeymoon is really over! after that, i went to patch render the blackened parts. as you may know, vue doesnt calculate the patch area based on the entire image area, but tries to blow up the patch to the entire image size. but that was okay, so i thought, if i select the entire band going across, i know what size to make it (3300... um, or was i doing 2200? i forget). but NOOOOOOOOOOOOOOOO! you cant render a patch to disk! why? i dont know! and of course, you CANT render to screen bigger than 1600x1200 even if you wanted to tempt fate and try it. so then i had to select half the strip and render to 1600xwhatever. all right. until i moved the dratted render area bit over to do the right half. then i get 'cant render to screen bigger than 1600blahblahblah.' i tell it to USE RENDER AREA. it is set to 1600xwhatever. it keeps telling me i cant render bigger than 1600, i keep telling it IM NOT TRYING TO! finally i hit okay, and whats it do? tries to render the whole smeggin picture. hellooooo? see this render area??? so i draw the smeggin render area again. no, it doesnt see the render area. it wants to render the whole image 1600x. and not even! it wants to shrink my image to 1500x something, dont know whats up with that, but it doesnt matter, its WRONG! so i try again, and geeze, you GOTTA draw the fool render area from the top left to the bottom right or else it doesnt exist. yeeesh. but at least i have the two top patches now. no clue if they fit, i know i'm going to have to resize them. tomorrow, i can probably get the bottom patches done. well, this is it, i am not rendering to disk any more. i'll do patches and sew 'em together if i have to, but this is ridiculous. why is it messed up? one or more of these reasons: 1: stopping/resuming render. i end up with render errors almost every time i do this when rendering to disk. 2: renaming the scene after each session (hawkd1/hawkd2). perhaps the blank parts are when it was named #2 and the regular parts are from when it was named #1. dunno. (mike: ignore what i told you in that other thread about this.) 3: running other stuff while rendering? now, mostly, i didnt. i cleaned my apartment while vue sat there doing its bit, for the most part. nearly went nuts with no computer, but i did it. two or three evening sessions, i was online while rendering. so i dunno. usually this doesnt bother vue. i suspect #1 most of all. i dont have any power-downing thingydoodles on my system. nor screen savers. i learned my lesson in ray dream! ;) render to disk sucks.

Bloodsong, I would seriously think about rendering to screen. You can set the dimensions to up to 1600x1200. Bigger than that I cannot go because that is the biggest screen resolution my graphics card will go, and it objects to using a bigger size than that on screen and insists on render to disc for anything bigger. But I rarely render that big anyway. But if you can render to screen you can see all the time what is going on. If you select a render area, and you have the full render size set to, say, 800x600, it will render that selected area only, but it will set it to 800 wide and adjust the depth to keep the proportions, so unless you use the whole width for a render patch, it is not going to be the right size to fit your original. Stopping and resuming rendering works fine with render to screen, but only if you save both the render and the vue file at the point where you stopped rendering. The vue file has info on where it has got to in the render. So if you only save the image and not the vue file, it does not know where to restart the render and gives you an error message. If you save the vue file and not the half finished render (which you cannot do with render to disk because the render is being saved as you go along) then it knows where to start but does not have an image to resume with. If you are getting errors with render to disk, it sounds as though you are not saving the vue file when you stop the render. Be careful when you stop it not to hit ESC twice so it says finished. You will not be able to resume unless you do the saving while it says Stopped. Changing the filename of a half finished render, or resuming under another name would be pretty fatal I would think. It expects to resume the same render that it left off. If you have a pressing need to change filenames, I would do it with Windows Explorer by copying the file to another folder and renaming that, leaving the original unchanged and in the folder where you saved it from the render option. If you are trying to do something else while rendering, usually it will be the something else that suffers, not Vue. Vue simply takes over the resources and leaves everything else to struggle. I hope some of this helps.

Bloodsong, you might want to send E-on's support a link to this thread. If it doesn't elicit some immediate assistance, it just might be helpful towards a future version.

heyas; yes, im going to email them, varian. well, i got the 4 patches rendered, finally. now i have to see if i can get them to fit together. tesign, i hope your rendering smaller at 300dpi trick works, because i used that on the fourth patch, but not on the others. hmmm, so if the lower right corner looks screwy, you can say you did that ;)

e-on musta heard i was coming, their site was down... ;) anyway...check out the pic, here. compare it to the top pic. hmmmm! okay, well, its obvious that rendering to disk, stopping, saving to a new file name, and then resuming doesnt work too hot. but, on the other hand, it worked better than i had thought before. yes, i was able to use the magic wand to grab the black rectangles in the top one and invert the selection to get the strips, and then paste them into the messed up parts of the other, all nice and seamlessly. wish i'd found that out before i spent all day rendering more patches. so, okay... i did that. my fault. except you gotta wonder why vue kept changing my image name each time. (yes, i found a hawkd1.bmp and a hawkd2.bmp). of course, since it insisted on changing my hawkd1.tif into hawkd1.tifbmp between renders, i can't be too surprised.

whoa...curiouser and curiouser!!

As Varian says, curiouser and curiouser. I just tried a render to disk as a bmp, only a little one since I did not want to be there all day, stopped it in the middle and resumed, and when finished it was fine. Bloodsong, you mentioned .tif. I have never tried that before, so I am just rendering that to disk while I write this message. I will tell you how it does in a minute. But rendering to disk does at least let me type almost normally in this message while the render is going on, so I may yet use render to disk more ofen, when I do not want to abandon the whole computer to Vue. I have pressed ESC twice in Netscape/Renderosity, and Vue is still happily rendering. I had to go back to Vue to hit ESC to see whether it still resumes properly after a pause when using tif. Well, the tif finished, it is a bigger file than the bmp, took over twice as long to render, Vue crashed when it got to 100% and only the bottom third is properly rendered. I stopped and restarted it at 30%, so I wonder if it renders from the bottom up when rendering to disc, and the tif gets corrupted by a restart? It did not attempt to rename mine to bmp, but I wonder if it resumes as bmp after a stop, and that is why the rest of the image is corrupted? This is all speculation, of course, but it does seem to me that bmp is the safest file type to use in a render, and use PSP or PS to make a tif copy if that is needed. I did another render to screen and saved that as a tif, and the result was fine and the filesize much smaller than the bmp, while the render to disc one was much bigger. I still cannot get ESC pressed with Netscape as the current application to stop Vue's render, so I don't know why that behaves impeccably for me when it is a bug for others. My guess is that there is a bug in the render to disk tif saving, and bmp is the safer option to use.

heyas; e-on just needs to clean up the render to disk mess, i think. tif is supposed to be smaller than bmp, which is why i use it. but yes, vue keeps trying to change it back to bmp, which is its default setting.

I agree there is something deeply wrong with tif saving to disc. It is the first time I have tried tif, because in everything I use bmp (to avoid compression), or jpg for posting to the web or gif for animations. I only use tif if I want to keep an alpha channel selection active, so I never even thought about using it with Vue. I get the impression that they tested the bmp saving, found that was ok and did not bother to test the other file types to destruction. It needs a patch for this I think.

good luck! and when it finally renders right, please post the image! it looks impressive so far... cheers, - tom

heyas; tom, they are rendered right. all i had to do was splice 'em together ;) and no peeking at this one til the daz calendar contest is over. well, i mean, you peeked at it already, but....