I keep reading reports about freezes and 24 hr renders in Poser 5. I've never had this problem (though Win XP was a great investment for me which has cured all the freezes I used to get - not just in Poser). I'm beginning to wonder whether at least some of the problems I read about may have their roots in a conflict twixt P5 lights and (some of) the old P4 lights? I'm familiar with render freezes when I load some old light sets, but I've got in the habit of deleting current lighting before loading a legacy set (which eliminates the problem). An alternative solution is to resave old light sets within Poser 5. I'm not sure how much of my experience may be peculiar to my system, but as a yardstick for others to test, here's an example of what I'm trying to explain. For this example I've been using the "DNA_Figure Spots" (altho this effect is attainable with many other legacy light sets). Start Poser 5 with the Document Preference launched to factory state (Casual Don with default P5 lights). Render... and not surprisingly the render takes seconds (I'm just rendering with Draft Firefly settings). Immediately load one of the DNA light sets (I've been using FS 003) and then try to render again. Poser always freezes for me. However, had I have loaded an alternative version of the very same light setting (which I've previously re-saved in P5) then this freeze is totally avoidable (and what's more, I'm thereafter able to load any of the original DNA light sets without encountering freezes). To further complicate matters... if I load P5 with the Document Preference set to Factory State (as above) and then immediately load the same legacy DNA light set which had just caused the freeze (but this time without having rendered with the P5 default lights first) then there is no problem? The render freeze only seems to occur if the image has previously been rendered with the default P5 lights. Not sure if this is a known issue which affects Poser 4 also... but yet another lighting complication arises if I load a basic set of default P5 lights in a poser scene which is currently lit with spotlights. The infinite lights seem to inherit the "point at" settings from the spotlights which they are replacing. I wonder if there are other aspects of lighting which may hamper the render process that also get inherited or are retained in memory until a light is deleted? If the above freeze is reproducible across platforms, then surely a solution for it could be easily attainable? All things considered, I'm going to continue to avoid cumulative light transitions preferring to delete all light settings before setting up a complex scene for render. I'd be very interested to hear whether a saving of lights, followed by their complete deletion and a subsequent re-loading of the saved light set helps to cure any of the serious render freezes which are reported?

the only freezes with poser 5 i ever had was when changing from one lightset to another.Since i use ockhams python script for deleting all lights before i use another light set , i had nomore freezes

same here.. but sometimes i forget to delete all lights.. and she crashes..

yep..be sure to try that, I also use the python script to delete all lights, if not, mine freezes up also

I've never rendered with the Poser5 default lights. When I started with Poser 5, I started with DNA lights. pastels, earthlights, that sort of thing. Had absolutely no problem. And relatively fast renders. I also had a very light runtime. My problem started as my runtime grew. I think I may have had one prob with lights that were parented to something-- the camera? Only prob I've ever had with lights. All the rest is texture loading and object finding with lights I have hitherto rendered without any freezing. This fix may solve the problem for people who were crashing with lights-- it does not solve the general render freeze. That, I think has to do with larger runtimes with perhaps, duplicates in more than one runtime -- as in Daz figures in each runtime and sets and textures in more than one runtime. Emily

I often crash when I add different lights. If I save first and reload it works fine. Very annoying if I forgot to save ~S~

I think you are on to the right track, caulbox! I've done some of the same experimenting with similar results. I think the problem also involves the naming (and internal naming) of lights which is not consistent from set to set. A possible conflict occurs when Poser inadvertently creates the same internal name for two different objects - even though the lights show up in Poser preview, they freeze at render time. It might also involve the shadowcam name and data that causes the conflict.

Thanks for your feedback, ronstuff. I wasn't sure whether the effect was reproducible until you commented. You're certainly correct in saying that the problem involves the naming of lights. In this DNA set, as I'm sure you've already discovered, a simple renaming of LiGHT1, LIGHT2, and LIGHT3 eliminates the freeze! Thanks for putting more light on this issue! I've been a bit slow in replying having spent much of today trying to gleam some understanding of the subtle differences in saved light sets. At the very least, I've now learnt how to get Poser to save a set of lights with the PointAtParam listed before the translate/rotate stuff or after it! I've also learnt that it doesn't make a jot of difference! What I was trying to do was to generate a freezeable light set from within Poser 5, but after many conjectures and no refutations, I've (at least for the moment) concluded that sometimes you can't see the wood for the trees! As a simple renaming cures this particular freeze, then I'm beginning to conclude "if it ain't broke, don't fix it". Maybe a very simple solution for widespread render problems in Poser 5 is indeed lurking somewhere!

caulbox, which DNa set are you having trouble with? I'd like to see if it causes trouble on my puter -- well, "like to" is probably the wrong phrase. I'm still trying to generate a dna freezeable light set. Emily

Emily- The strange thing is that it isn't particularly any light set (although I have had it happen with the RDNA soft pastels on more than one occasion). It seems that any lights that have custom named or foreign named lights (or shadowcams)can cause a freeze depending on what lightset was loaded BEFORE switching to the RDNA lights. The reverse is also true - for example I have my default lights named "key light", "back light", "fill light" etc. because I was a professional lighting designer for quite a while. This was fine in Poser 4, but with Poser 5 I started having trouble with ANYBODY's lights except mine! :-0 that is how I got on the track of suspecting the names, because in most cases that was the only difference between my default lights and several made by other people. By the way, once you get Poser 5 to accept ONE lightset from RDNA, it seems to accept them all thereafter, until you switch to somebody else's lights.

Ok, that explains why all the RDNA lights work for me-- but not why the Evodes lights work -- those were the first I switched to from Poser 5, and the Marfono lights work, and Blue Venus, Spanki's, TheUmbra etc and so on. Could it be that renaming ones lights is a dangerous thing to do in Poser? The only sets I haven't tried are the the sets form PoserStyle becuase they were getting consistent freezes in the the old Beta forum. The worst thing about the bugs in Poser, imo, is the randomness of their occurrence. Just started up after takingtime off to heal a sprained hand and it's as if I'd defrag'd my HD, just installed Poser 5-- no freezes and lightning fast Firefly renders. I know it won't last, I just don't know why it's working so well now. Emily

Emily, if you want to do a test try switching between an RDNA light set and a PoserStyle set, and then doing a render. Remember that the freeze does not happen the moment you switch the lights, it only happens when you render after making a switch. Try this a few times back and forth with a render in between and see if you can force the freeze. As I recall many of the PoserStyle light sets are named with European (French or German) names, and they will likely cause problems for people with English versions of Poser, if my theory is correct. As far as P5 in general, mine is behaving beautifully too! I have had it running constantly for 3 days of more at at time without the slightest hiccup (as long as I don't switch lights) -= and I really love the rendering quality now that I got my settings tweaked.

I almost always render when I switch lights-- unless the lightset is manifestly awful. I never render in draft though-- could that be a factor? When I started using P5 there was no reasonable difference between Draft and Production speed-- in fact some draft was slower and I could never tell anything from the results that I really wanted to know. I love Firefly too, I just wish it was consistent. I did everything to push it two days ago, even stored some new textures out of any Poser folder-- it found them immediately whereas I don't think I've ever been able to get it to find and render Yann hair. I might be able to test it tonight if I don't crumble under the heat, I'll let you know what happens. Emily

One comment I would add. It's just a gut feeling I have, rather than anything tested... but I don't think it's custom names per se which causes the problem - in fact it's the opposite in this instance. Renaming the lights serves to turn off LGHT1, LIGHT2 and LIGHT3 (which were already in Poser's memory) rather than replacing them with a new set. Ronstuff.. this may also explain why on some occaions your lights went against the grain an masse. I find it a very interesting discovery that simply renaming the lights eliminates the problem. The possibility of a conflict with the lights Poser has in memory and some subsequently loaded sets remains. It appears even more likely in view of such evidence.

Right, caulbox, but I'm still not convinced that it is JUST a naming problem - I think that sometimes renaming the lights actually prevents the problem and other times may contribute to it, but it is not the names themselves that cause the problem. I think in renaming a light we force poser to update the entire light parameter list which automatically fixes any potential problem that might be lurking until render time. In other words, the real problem is in the update process done by Poser when a light set is switched. Something is not translating properly here from one light set to the next when they have several common lights with different parameters. Here is an interesting test which I can get Poser 5 to freeze 100% of the time - see if you or Emily can try this: 1) Launch Poser 5 to the factory state with the default lights and Don in his whites. 2) Switch lights to the DNA Creed Lights 01 - (first one on the list "Bark at the moon) and render the scene. 3) Switch lights to the DNA Pastels (first one on the list - Pastel 001) - and try a render. On my system, it freezes 100% of the time even after a fresh reboot. The funny thing is that on the surface it looks like both DNA light sets use Light 1, Light 2, Light 3 etc for their names. The difference between them is that the DNA creed light has no Lights 2 or 3, but it has a Light 1, Light 4 and Light 5. The Pastel set uses Lights 1 thru 4 but has no Light 5. Also the lights in one set (with the same names in the other) must change from inf to spot or vice versa, and maybe this is what is causing the problem. Anyway, I'm still tracking it down.

Sorry if I didn't make myself clear. I'm in total agreement that it's the updating process rather than the names where the problem has it's roots. I found it very interesting to discover the effect of renaming purely because it goes a long way to prove that there's a problem which occurs only during light transitions. I also tend to agree that the problem seems relevant to a transition between infinite and spotlights. We must have thought a lot of similar things, cos the very light set I'd been playing with when I was attempting to discover more was the Creed Bark at the Moon light! Anyway it's 3.30 am in UK now, and I'm probably ready to try a few other light switches! I'll certainly test your ideas sometime tomorrow and I'll report my findings.

Just to confirm, I get the same freeze. Is there anyone who doesn't?

Thanks for the feedback, caulbox. Unfortunately I don't think too many people are still following this thread. Maybe we should post this test in a new thread and see if we get any additional feedback. I would also like to know if anyone can get the above test to render without a freeze.

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

To round of this thread, I was just about to post the following: Maybe you can post a simple Yes/No survey question. The results would indeed be interesting. My comments about there being a possible simple solution to this render problem are based on the reasoning that this effect may be a universal one. Forgive the pun, but if the spotlight can ne but on such a specific issue (rather than a myriad of possible sources within Poser) then the task of finding a solution is obviously grearly lessened. I wish you all the best in your attempts to locate the source of the problem.

I agree wholeheartedly! There are numerous bugs in P5 that are directly related to P5's updating of current settings (windows, dialogs, parameters etc.) when changes are made. There is no question in my mind that the update process in P5 is the source of MANY different problems, not just the lighting freeze.

I posted in the other thread as well. The lights are known to freeze P5. The easiest workaround is to use the python script in Free Stuff that knocks out all the lights but one before switching to a new light set. I have it as a permanent part of my python script set. It's wonderful!

Thanks Crescent, we already have this information. Please see my full reply in the other thread. Thanks again for your contribution.