Attached Link: http://www.renderosity.com/viewed.ez?galleryid=273205

Hi there, short question: how do you see whether Vue crashed or got caught in a dead-loop on a Windows system? Well, situation is this: I'm working on a new image (old WIP image is below the link). Changed textures and lighting, and wanted to render a highest-quality image overnight: 16 aa-subsamples, best quality. Well, I started the render, and it proceded well to about 4% (if slowly) and gave me an ETA of 4h. Went to bed, and this morning, it gave me an ETA of 130h, 6% completed . . . apparently, there was a deadlock. The application simply looped, but didn't really "crash". I could interrupt the render with ESC and no problems. So--is there any way to know when Vue deadlocked / crashed for sure? It would suck to interrupt a long render because I simply *think* Vue was looping . . . ta, -Sascha.rb P.S. the scene has about 100,000 polygons and 25 lights, and is rather light--about 30MB or so. -.rb

Addition: CPU usage was on 98%, this morning. Hence: deadlock, not crash. ta, -Sascha.rb

I don't think this was a geadlook. While Vue starts to render, it calculates real time to finish it. This time may change when Vue decovers lots of lights, reflecting material etc. Just render in stripes and assemble it in your paint program. Guitta

Sometimes when you render, you start with a remain time of 4-5 hours, but the render itself can take 100hours. This especially happens if you use heavy anti-aliasing. The image "render" fast, but the anti-aliasing spend a lot more time.

Well, yes--but the image didn't render, really, but stopped progressing at 6%. The only thing it updated was the render time accordingly to its progress. The first 4% were rendered in 5 minutes, but the next 2% (mark without anything special in that part of the screen) took 7 hours . . . My guess is that it encountered a loop of death, i.e. reflections that went too deep. Funnily, though, in the area of the screen that 2% took 7h, there was no reflection and no transparencies--they are further down in the image. (glass bottles, reflective floor). I should also add that the very same scene, with different textures and 4 lights less, rendered just fine in about 5h at same quality settings, the day before. ta, -Sascha.rb

It's not crashing man get used to it. If you want to render such a high setting set it up and walk away. there is another thread here just started that explaines the whole works and what to do about it. It's a thread about rendering big sizes. the first 4 % is the first and second pass the next pass goes from 4% to 25% or even a smaller step i can't remember then the last pass 25% to 100% then the antializing pass and that's going to be about 400 TIMES SLOWER than all previous passes so if it's taken 3 hours say so far the very last pass will take 15 more hours with the counter not updating appearing to be crashed when in fact it's hard at work. Group group and group some more. set it up so objects near each other are in a group. keep doing that forground bacground all the way across till everything is grouped. That will speed it up somewhat. !!!!!

Hi Pete, err . . . again: with the very same quality settings, but with 4 lights less (i.e. 21 lights instead of 25 lights), the image rendered perfectly fine in about 5h, two days ago. I don't see how 4 additional lights (120% increase in light sources) will result in 135h total rendering time (2700% increase in render time), especially considering we've already had 21 lights to begin with which took the abovementioned 5h to render. ;) I know very well how vue's percentage, time estimate, and render steps work. As mentioned before, the first pass took close to 5 minutes, but the second pass, rendering about 10 lines of no-transparency, no-reflection, no-softshadowed textures, didn't proceed further than 6%. I don't know whether these 10 lines took 7h or 5 minutes to render, as I was in bed by then already. My guess would be the later, and looping for close to 7h afterwards. It's not as if I weren't used to 12h+ renders at high quality settings. But, again: 130h? If almost the same scene took 5h, previously? Clearly something fishy here. Are we really talking 5 days rather than 5 hours, due to 4 additional, no-shadow lights? Oh, btw, only one light actually casts shadows to begin with, the rest are fill and bounce lights. Even if the additional lights would increase rendering time by 2700%, this still doesn't explain why already the second render pass took 7h for 2 additional percents--corresponding to about 10 scanlines--when a similar scene was fully rendered including FSAA in about 5h, before. But that's not really the point of this thread. We've got the other one for perfomance questions. :) This is a thread about how to diagnose lock ups or dead loops. The render I mentioned was only supposed to serve as an example, not as a problem to be solved--if it takes 100h to render that image, fine by me. :) But: I am still wondering how to GENERALLY diagnose loops of death if they occur. Will Vue crank CPU usage up to 100%, will it simply crash, will it interrupt a render automatically (as it should)? Error messages? Any idea? ta, -Sascha.rb

Hi everybody, My apologies. I have phrased my question, together with the example, rather unclearly, apparently. So I'll try again. :) My question, as intended, was: Generally speaking, how does one check whether Vue is a) running as supposed or b) looping / crashing? If a render takes much time, it's hard to see whether Vue is actually still rendering or already looping, simply because one scanline already needs many minutes to complete, i.e. until the display is updated. Hope it's clearer this way, without the example. ;) have fun, -Sascha.rb

Oh well I use a program called Wintop I just check the processor usage.There is really no way to tell if it's stuck in a loop. you'd have to make calls right to the processor. check also that you don't got some damn stupid power saver thiny turned on cause your proccessor could be forced to idle and the drives going to sleep that could lock up Vue. I got mine set always on. I never turn my computer off ever and I just use a blank black screen saver. One thing to try is render the whole wad really small say 256 X 256 just to make sure everything is perfect before you attempt the bigger size. When Vue crashes the cpu power usage for that program drops to 0% then you know it's dead if it's up at 98% you know it's rendering. If it's less than 98% something else is sucking back cpu cycles (like say Vue reports 48%) find it and turn it off till the render is done. How I tell what's going on is I find the line on the screen where Vue is currently working then I place my cursor on it then later you can tell if it's done more more easily. Best is just no peeking till it's done. It will finnish. I've rendered 110 hour scenes. You just got to have patience. Make sure you got lots of free space on c drive so the ever expanding swap file will fit. Like lots of space, a few gigs free. That will kill you on a really long renders, the c drive filling completly killing vue in a out of memory error. You can just find that wintop program on a search on google.It's free of course. The antialasing pass is the worse cause it hardly updats at all then glow and glow antialasing it doesn't update any so it really starts to look like vue has crashed. Try to fix your scene, Group, man it will save you. I just rendered a scene with over 164 lights, easy. it worked no problem. I had everything grouped properly. I'm rendering a entire city here all the buildings are covered in a mirrored metal. there is street lights everywhere. I got 16 city blocks complete with street lights. Each block has got 20 street lights that work of course then there is other lights too light up the court yards. It's rendering man no problem. Group, it's the only way to get it done properly. The render will appear to stop at some points cause one building is reflecting on a different building causing a hall of mirrors effect. That will almost kill ya in Ultra setting cause it's set to 16 tries each photon or ray before it gives up. The sky will kill ya around the horizon Vue will creep around 40 to 60% complete because of this, every pass around the horizon will slow down around those areas. Volumetric skies will kill ya too if there too complex. Like to many cloud layers. Try also you may want to turn the fall off a bit more on the lights so it gives up faster on them and softness on lights could add days to a render. You got to watch settings you can't go overboard on anything. Looking at lights threw lights will kill ya. That was the problem with my street lights. I ended up moving them further appart to prevent it.

Hi Pete, excellent! I think you found it: "check also that you don't got some damn stupid power saver thiny turned on cause your proccessor could be forced to idle and the drives going to sleep that could lock up Vue. " I just reinstalled Windows couple of days ago, and haven't changed the power savings settings, yet. Duh. Small wonder it craps up. bangs head At least the problem with my latest render has been cleared, now. Thanks a lot. :) Also thanks for the Wintop hint, I'll check it out. The trick with the mouse should have been obvious, too . . . eh. Need more coffee, I suppose. I'm looking forward to your render, btw. Sounds exciting. Do you have a dedicated render machine for your 100h+ renders, or do you simply not need your computer for anything but Vue? ;) Again, thanks! ta, -Sascha.rb

Good I tried to post this message seems like Renderosity died just as I hit reply so I saved it: "There is also a bug in some versions of windows where it will be stuck in idle after suspend. Like it's in my Windows 98 SE version here, that's why I never turn it off. I've deleted power management completly from the registry to prevent it from ever turning on. Ya great it works ok maybe but when is the server machine it sucks, it's totally useless feature. It goes into suspend and all the other computers get dragged down with it. I'll pay the extra .05 cents of hydro it uses in a year to prevent it." I did use a dedicated machine to do the 110 hours render plus a few more really huge renders. I don't have that computer anymore I got to build a new one. Unfortunatly I probibly will not post my picture here. Ya notice I don't really post a lot of stuff here even though I'm rendering all the time. The problem is the size of the renders they're 2048 wide there too big to post here. I refuse to shink it. It will goof up the gallery if I post such a huge picture and also probibly goof up a few peoples computers. Then the size is one thing but with that and the limit of the size I got to compress it so much to make it fit here that it's really not worth it for me to post. I've been thinking about this just recently there on the web of course right now full size (although this city is not public viewing yet, a few more months I'm afraid before it becomes available for viewing even though it's finnished 100% ) If I can figure out how to post wrl files instead of jpg. I got to try it to see if it's allowed. Like see if it even works I can call the picture off the server from where they are stored without taking up bandwith or space here at renderosity. My pictures are huge there is over 2 gigs at least on the web of them. It would take weeks and weeks to see them all. The problem is to the size there even calling them off there present server they're about easy 4 or 5 megs each you really need highspeed to see them. There is no small ones there all bandwith pigs I'm afraid. The way it works, I just can't compress them. If I compress them you loose the effect so I can't. You've seen my work you just don't know it. Almost everyone has seen my work they just don't realize I made it.

Holy mother of God. That's some huge-sized images . . . are you doing print work with Vue? ta, -Sascha.rb

Attached Link: http://www.renderosity.com/messages.ez?ForumID=12368&Form.ShowMessage=984969

You might want to check this thread out. No I do commecial graphics art. Thank god too cause if this was to be printed it would be 8600 in size just to print it at 300 DPI. I'd never go for 300 dpi if my name was on it they would have to print it at 600 minimum, I'd die rendering it.

Short update: disabling all power saving settings solved the "133h-Bug" for me--image rendered just fine in about 7h. thanks again, -Sascha.rb