Last night I tried over and over to render a scene I'd set up. But Firefly kept crashing after a few buckets. Oddly enough it crashed after around 5 buckets of precalculating indirect light, then, when I OK'ed the "Firefly has stopeed working" message box, it actually RENDERED those buckets - and crashed again. And yes, a new instance of Firefly.exe popped up in the taskmanager while it happened. So Firefly restarted itself, only to die again.

Now today I decided to track down the problem. I could render the scene just fine in draft mode, but the moment I turned the settings up to include indirect light, it crashed.

So I thought I'd see WHAT made it crash. And apparently it is the wall of the scene I used. I loaded the room in question - 3-D-C's Simple room - and PLEASE I'm not saying bad things about that product, I love it - but for some reason It won't render with indirect light. And I can't figure out WHY?!
I tried loading four walls, a ceiling and a floor, thus making a closed box. Put one point light inside as well as the camera, and rendered.

Crash.

So now I made a room of 6 Poser boxes, properly scaled to simulate walls, ceiling and floor. Put one point light and the camera inside my closed room. And rendered. 

No crash.

In other words it IS something about the wall props that Firefly with indirect light doesn't like.

I looked, and the walls-that-won't-render are seemingly ONE large polygon (the foot panels are more but the walls themselves looks to be made of one) - usually that is how I would make a plain wall for Poser myself, if I were to make a scene, since I like to save polys where they're not needed. 

But is this a general problem? Does Poser 8's firefly have problems calculating IDL / rendering very large polygons?

Might be a general problem.  I tried this scene, which I've used in P7 several times with variations.  Two point lights, one infinite.  (Probably should delete the infinite for IDL because it's too bright this way.)

The rendering went without any problems, took about 30 minutes. 
Then, the program crashed as I was closing.
("Poser executable has encountered an error and must close.")

Hi TG, First, I like the way you go about troubleshooting the problem--good technique!
 
--just wondering,  the product may have been corrupted during the download process.  Have you tried downloading it again?   Jan

I tried the same scene with the same props.
The first time I rendered, I got a ffrender crash as well but it kept rendering the entire scene. This was with IDL off. Each render after that rendered fine (without crash) - even with IDL on.
If I save the scene and restart Poser, the same thing will happen - 1 ffrender crash and after that no more crashes
I could be that it is one of the materials which is choking ffrender.
 

What are the shader configurations for the walls?  Could a setting be off with one of the nodes?  I do have the d/l but haven't cracked it open yet. 

Report it. A lot of us have had the same things.

Poser "hangs" during precalculation or during IDL renders.
But? ? ?
can be restarted by Crtl+Alt+Del.

I reportred it to SM, but please do so too. The more info they get, the  better.

Windows 7 gives a very early warning about a prog not responding. But in background, it is actually rendering (sometimes). I'v had the same.
"poser executable stops responding", wait a bit, hit Ctrl+Alt+Del, and Poser jumps forward by a couple of precalculated or rendered buckets.

I called it poser cycling, between running, and stopping, running, and stopping. Each time reactivated by Ctrl=Alt+Del.
overnight renderings? Forget it? Your PC and Poser want you next to them ;-)
Report it.

There does not seem to be anything special - standard texture maps with some of them a reflection node.
It could very well be that the OS (in my case windows 7) thinks ffrender has crashed while in fact it has not and when windows 7 detects that, it removes the message and the render continues.
Renderspeed or choking the processors is not really an issue here (I think). The whole render with IDL calculation takes about 45 seconds.

Thank's for posting this, I just started having it happen to me and will try to figure out what models are causing my issue and report them back here.

I was told by SM "It's My graphics card.. I even sent them a copy of My console log..

 Hm. Seems there IS something with that model then. What a shame. I'd still like to know exactly what it is so I can avoid making whatever the mistake is when I build my own scenes.

I guess I should have listed my specs. Windows Vista, SP2 , 4GB ram. Intel dual core 2.40gHz. And Poser 8 SR1.

It's definitely not my graphics card, otherwise I wouldn't be able to render THE EXACT SAME SCENE just with that room swapped with the one I made out of 6 Poser boxes. And I can, it's rendering happily right now, and has finished once - I just didn't like one of the materials I'd used so I'm re-rendering it now. Slow but steady (there's some glass with a bump map here that takes forever to render)

Ockham, I'm not sure it's quite the same problem, although probably related. It's not Poser that crashes here, it's firefly.exe. I think if I wasn't rendering in a separate process, it would be Poser that crashed though.

It's also similar - but not equal - to the "not responding" thing. Sometimes, Poser whites out and looks like it has hung itself, only to continue if given time. This is a regular crash - I have no options than to click OK, after which firefly.exe disappears from the taskmanager list of running programs - only to appear a moment later and attempt to render the few buckets it has precalculated the IDL for. After which it promptly gives up and keels over again.

Strange thing is I was able to render it in draft, but as soon as the settings were cranked up top include raytracing - POOF! there it went again. Without raytracing (and thus IDL) it was fine. I tried that with the default settings otherwise I use the advanced ones in D3D's Render Firefly script.

I don't think it's a graphic card issue either. nVidia 260, quadcore Intell, 4 gigs ram, Vista 64 bit SP2, Poser 8 SR1. When I can get to poster later I'll try to isolate when models are doing it for me.

I am contemplating setting up a small experiment running similar scene renders varying the complexity and intensity of bump and displacement mapping.  I have noticed that IDL render time goes up significantly with the introduction of displacement maps in any given object.  If this is true, we may need to seriously consider how bump and displacement mapping is distributed within a scene.  Also, check the diffuse_value for all your objects and models.  A value of 100% will definitely cause major problems with IDL renders.  I have been scaling back that value to approximately 80%; I am considering using 90% for transmap hair.

 Hm. I've never really touched the diffuse value (other than setting it to 0 when I want something properly transparent and the like)

Has anybody done a python script yet that will turn it down to any given percentage on all materials in a scene? That would be neat.

Consequently, I haven't touched in on the scene that is rendering now. The walls are using some of Ajax' old Poser 5 tile shaders - they render lightning fast even with the bump and all. The only thing that is (still) taking a lot of time is my glass texture - I guess reflection, refraction + bump + IDL was a bad move. Still it's ALMOST done with that part of the pic now and I like how it looks, so I'm letting it finish this time :)

I hadn't noticed that displacement meant a lot in regards to render times, but I'll keep an eye on that. Has anyone tried with normal maps and how they affect render times with IDL?

TG:

What is the Normals Forward setting on the product? Is the wall figure one or two sided?

lmk

OK, I started removing items one by one from a copy of the offending scene rendering each time after each change with Firefly crashing every time until I was just down to Victoria 4 with nothing else and still crashing.

Hmmmm, could it be the textures I was using on V4? Switched to a different one and no crash of Firefly.

Load a new copy of the offending scene and switch out the texture on V4, render, no Firefly crash.

Problem is I can not remember what texture I was using. Poser novice, any way I can figure out what texture on V4 in the offending scene?

Since I still have the offending scene, if any experts want me to look at things, posting screenshots of stuff to help figure out what going wrong, be happy to help.

Later, guess I'll apply VSS to the offending scene since that replaces all the shader nodes and see if that renders without a Firefly crash.

My theory is some textures can cause Firefly crashes to some people.

Hmmm.  I do generate and use normal maps with many renders currently but I haven't tried comparing those with bump maps.  Something to put on my to-do list.

 Hm it MIGHT be a texture issue. I think I'll try to render those walls without any textures and see what happens. Will report back...

 AHA!

I found an oddity in this model! It's 99.9% related to the textures.

First I assembled the room again, then I went to the material room to delete all the texture maps. And found something uncommon: ALL the props in the wcene included all textures. In other words, Left Wall ALSO included textures for ceiling, floor, curtains, silver, radiator ect.... likewise the floor contained textures for walls, panels, ceiling, curtains, silver. And all of them with the proper texture maps plugged in.

I think that is what made Poser throw a hissy fit. Once I removed all the textures, the thing rendered in record time.

Then I tried to add the textures again, and remove all the unused nodes on the props. But now it won't render again. Exact same thing happens. a few buckets of precalc then BOOM.

The textures are the culprits... I just don't understand WHY - unless it's the fact that all props have texture entries for something that rightfully should be on another prop - but I've had several odd textures on my own stuff (Hexagon loves to make those...) and never had this problem.

I can say pretty certainly that they ARE what makes Firefly crash though, because I finally tried replacing them with the same procedural textures I ended up using in my final pic - and the thing rendered without a hitch.

If I add so much as the foot panel texture - CRASH - keep it procedural: NO crash.

I'm going to investigate the paths and the textures next. It makes no sense that they should make Firefly crash, but there you are... they do!

 Hm. More about the textures...

Almost all the filenames here are with an underscore. I know that could pose a problem in Poser 8 prior to SR1... I wonder if that's the culprit more than anything else? I still don't understand why it would make Firefly crash and not for instance let Poser throw it's "texture not found" message instead - but the textures ARE found and all.. they just can't be rendered with indirect lighting.

I will try to make a few copies of the textures next, without underscores and see what happens...

EDIT

OK it seems like it is the underscores. Or the combination of underscores and spaces. Or the spaces... I renamed the offending textures so that "Back Wall_Farbe.jpg" became "BackWallFarbe.jpg" - and now... once again, the thing is rendering!

Can anyone reproduce this? I will file a bug report, but I'd prefer if someone else had the same problem as I had...

Were any of the extra texture node attached to anything ?

If not, Shift-clicking the "Remove Detached Nodes" Wacro button shuold do the necessary clean up.
(Orphaned nodes have caused trouble in the past, so this may be a regression)

They were. Everything was plugged into everything. So the ceiling texture was plugged into the walls and the floor as well. 

It is not the model itself or the textures. I had the same problem, but for some reason it is gone now.
I had a reproducable scenario where ffrrender would crash if you rendered the scene for the first time after starting Poser. After I ran the "collect all inventory to a folder" python script all problems with the scene disappeared. The new (collected) scene does not have the problem nor does the original scene.
I tried the scene on another machine and the ffrender crash did not happen there either.
Since the texture names remained the same and the nodes in the material room are the same it must be something else

During preview (and maybe draft rendering) not all textures are loaded - bump, displacement, normal and specular maps These are loaded when the rendering engine needs them. That is why you sometimes get a texture not found during a render and not when you load the object.
It could be that the texture loading mechanism during the renderfase is different and under certain conditions causes this error. But this is just speculation

 But that doesn't explain why the thing rendered perfectly as soon as I removed the underscores...

Hmm.. it certainly is odd. I can't render it with the original textures but once I rename them.. it works.

I've restarted and rebooted several times during this.

I will try the collect thingie and see if I can make mine work with it as well :) Not that it makes sense, but then Poser's quirks rarely do.

Quote - OK it seems like it is the underscores. Or the combination of underscores and spaces. Or the spaces... I renamed the offending textures so that "Back Wall_Farbe.jpg" became "BackWallFarbe.jpg" - and now... once again, the thing is rendering!

Quote - But that doesn't explain why the thing rendered perfectly as soon as I removed the underscores...

The problen is not the model nor the textures. The problem is in Poser.rsr.
The file "poser.rsr" has inside a cache of all the textures names and path that you have used now, today, yesterday, last month, etc. If by some reason poser.rsr get corrupted very strange things happens and it also depends on the Windows incarnation that you have.
When you rename the texture removing the underscores this new name is not longer in poser.rsr cache and so Poser picks the new texture and caches it and all works fine. If you try to put again the old texture name Poser will look in the cache for this name, this entry is corrupted and then who knows what it does.
The solution is to replace Poser.rsr by a fresh one. If you have a backup copy of Poser or you can find this file in the Poser's installation disk you can use it. If not, I don't know what you can do.

 Except that Poser 8 doesn't seem to have a Poser.rsr.

I can find it for all my previous versions, but ... unless I'm mistaken (could be, it took my computer AGES to find the Poser.ini as well) I do not have a Poser.rsr

Can you guys with Poser 8 find the Poser.rsr or is it just me?

 The thing about the Poser.rsr made me curious.

Sorry, Kawecki, but what you say can't be true. I checked all my Poser.rsr's - and IF it was storing anything it would grow over time, but all my Poser.rsr's are 6.13mb in size. And the dates correspond to whenever that particular Poser version was installed.

And again, there is no Poser.rsr in Poser 8.

In Poser 8 there is no Poser.rsr, at least not in my installation.

There were mentions of problems with underscores pre-SR1, so it would look like the problems weren't all fixed.

Quote - Sorry, Kawecki, but what you say can't be true. I checked all my Poser.rsr's - and IF it was storing anything it would grow over time, but all my Poser.rsr's are 6.13mb in size. And the dates correspond to whenever that particular Poser version was installed.

You must look inside with an hex editor.
A cache normally has a fixed size, when something new get in something older goes out.
Poser.rsr is not only a cache, it stores all the names and resouces used by Poser and who knows what else.

I don't know about Poser 8, I haven't it, but all the stuff inside Poser.rsr including its cache must be stored somewhere, can be in other files or in Poser.exe itself.
The only way to know is looking inside Poser's system files with an hex editor.

I discovered the Poser.rsr problem when I tried to render a scene and Poser reported that have not enough memory. The scene was a simple scene, so I quited Poser and restart it and the problem was still there. I restart the computer and nothing was solved. I reduced the render dimensions and only was able to render a scene 400x400.
As the scene was so simple, few textures and not big, the only remaining explanation was that Poser got corrupted. As I always have a backup of the latest Poser folder, I replaced one by one Poser system files, there are few, and found that the guilty one was Poser.rsr.
This problem happened to me several times and solved each one overwriting Poser.rsr with a backup copy that this time I had inside a backup folder insided Poser folder.
The strange thing is that this problems I never had with Windows95 that used for long years, and with Windows 98. It only happened many times with Windows XP.

Here's what Poser 8 does:

Apply texture with name A (eg. wood.jpg) from folder B to any item. Poser will show A from folder B in preview. Good.
Render.
Firefly will load A from folder B and store it in its temp folder "PoserTextureCache" in exr format (eg. wood.exr). Firefly will render A from B.

Change the texture A from folder B to texture A from folder C. Poser will show A from folder C in preview. Good.
Render.
Firefly say "oh, see, that's great, I already have A, no need to load and convert it again!
Firefly will render A from B.

So, that's too be taken into account, when trying to find the source of this issue. So either delete the "PoserTextureCache" or restart Poser (that'll also delete it).

Oh, and try guessing what happens if you have two textures with the same filename? ;-)

Well, thats an old bug from the p4 days but there together with the obj file with the same name. When it was broken you had to delete it and poser  created a new one and the file loaded properly.

I checked my poser.rsr with a Hex editor and for sure, thats not a cache. At the end or the file there are some settings for Poser included.

 There is no Poser.rsr for Poser 8, and the .rsr file has never been used as a cache file.

Trekkiegrrl: I thought I had the same problem as you had, but it was (probably) a different one.
The "crash" message which I had was in fact a "program not responding" error. Once the program responds it will go away. It almost looks identical to the crash message - except that one does not go away. These messages seem to be a windows 7 problem which occurs when you load textures/objects/etc from a network drive and it takes too long.

So in effect - I use the same props as you did and I do not have the problem with it. So I do not think the props or textures itself are the one causing the problem.
If you load the props in an empty scene and - without changing them - render, do you then have the problem you described? And if you render with IDL on?

The full path to the not working and the working textures would also be interesting. 

Quote - I have been scaling back that value to approximately 80%; I am considering using 90% for transmap hair.

it's not a singular issue.  it depends entirely on how diffuse your material is.  most people act like diffuse is 1 until it's 0 for mirrors.  but think about that; it's got to be a continuum.  specularity is a fake for reflecting light sources, so think of specularity and reflection as complementary and both as inverse to diffuse amount.  hair should be less diffuse because it's shiny.  unless you want very, very coarse hair, that's less shiny than skin.  and skin is generally less shiny than your matte painted walls.  but it does matter how glossy the paint is, or if you're rendering terra cotta plantholders or shiny plastic appliances.  one script to control diffuse amount isn't realistic at all, and one of the best ways to make something look really bad is to have your specular amount and diffuse amount about equal.  if they're both high, you're basically saying it emits light, which is why it messes up with GI/IDL.

Quote - Trekkiegrrl: I thought I had the same problem as you had, but it was (probably) a different one.
The "crash" message which I had was in fact a "program not responding" error. Once the program responds it will go away. It almost looks identical to the crash message - except that one does not go away. These messages seem to be a windows 7 problem which occurs when you load textures/objects/etc from a network drive and it takes too long.

So in effect - I use the same props as you did and I do not have the problem with it. So I do not think the props or textures itself are the one causing the problem.
If you load the props in an empty scene and - without changing them - render, do you then have the problem you described? And if you render with IDL on?

Ah so it was a "similar but not same" problem.

If I load the props into an empty scene and render with IDL, it crashes. Every single time. If I remove all textures and render with IDL, it renders fine. If I add my renamed textures, it renders fine.

What puzzles me is why I can't render with those textures and others can. Makes no sense, especially not when I can as soon as all spaces and underscores are gone from the file names. I don't think it's because the path is too long or anything. 

The path to the textures, both original and renamed (I placed them in the same folder) is:
K:progrrammerSmith MicroPoser 8ContentRuntimetextures3dc

and yes the progrrammer is correct. I made a typo when making the folder, but of course Poser doesn't care as long as things are where it expects them to be.

I'm crazy, I cannot find it too!

Poser 8 initial release had bugs when a path name component was equal to a prefix of another path name component. For example, a runtime called "Poser 8" and another runtime called "Poser 8 Content", or a subfolder called "3dc" and another  subfolder called "3dc freestuff".

Perhaps some form of this problem still exists. Perhaps you have other texture or subfolder names which form a prefix from or to one of these troublesome textures.

TrekkieGrrl: If it does not crash without IDL and crash with IDL - where is everything located in the scene (so I can create exactly the same one).
You have one point light. What is its location and what are the properties (color, falloff, shading rate,etc). And what are your render settings for the scene? And which camera do you use and its postion.

I tried several render settings and point light postions, but it renders fine with IDL

 

After firefly starts rendering: Is the problematic texture in the "PoserRenderCache" folder and is it the same as the nonproblematic? 

 BB - there MAY be a similar named folder, but not in th Poser 8 content/runtime at least. Perhaps in one of my other, older runtimes, I haven't checked yet :)

The thing is, the renamed textures are placed in the same folder as the ones causing problems...

wimvdb - loaded four walls, cieling and floor (right wall blank) with their default textures.

Parameters for the point light:

Light 1 0 Dist Start Spline 0.0000 61

Light 1 0 Dist End Spline 0.0000 67

Light 1 0 shadowStrength Spline 1.0000 41

Light 1 0 depthMapSize Spline 256.0000 40

Light 1 0 xrot Spline -55.8034 1

Light 1 0 yrot Spline -215.7560 2

Light 1 0 zrot Spline 2.5440 3

Light 1 0 scale Spline 1.0000 10

Light 1 0 KdRed Spline 0.9792 23

Light 1 0 KdGreen Spline 1.0000 24

Light 1 0 KdBlue Spline 0.9917 25

Light 1 0 KdIntensity Spline 0.7665 29

Light 1 0 xtran Spline 0.0242 4

Light 1 0 ytran Spline 1.1043 5

Light 1 0 ztran Spline 0.0668 6

Light 1 0 Preview_Light_0_R Linear 0.9792 102

Light 1 0 Preview_Light_0_G Linear 1.0000 102

Light 1 0 Preview_Light_0_B Linear 0.9917 102

Light 1 0 Preview_Light_1 Linear 0.7665 102

Light 1 0 lampFlaps_Light_0_R Linear 0.9792 102

Light 1 0 lampFlaps_Light_0_G Linear 1.0000 102

Light 1 0 lampFlaps_Light_0_B Linear 0.9917 102

Light 1 0 lampFlaps_Light_1 Linear 0.7665 102

Light 1 0 lampBase_Light_0_R Linear 0.9792 102

Light 1 0 lampBase_Light_0_G Linear 1.0000 102

Light 1 0 lampBase_Light_0_B Linear 0.9917 102

Light 1 0 lampBase_Light_1 Linear 0.7665 102

Off to work now. I'll try to keep in touch tonight, but I won't have Poser available until I get home again.
 

I now use the same light and props (I assume you have the fall-off set to inverse square otherwise you get too much light). Everything works fine. Only thing which may be different is the IDL and other render settings.

I checked the texture references and they all seem to be fine too, so - unless you happen to have textures in the P8 library with the same name, which is unlikely give the german names - that should be ok too.

Let me know the render settings

Sorry I never answered last night. Was too tired when I got home and too busy before work today. But here we are again...

Actually I hadn't touched the falloff on the light. I keep forgetting that option
I tried once more, with the light set to Inverse Square, and it still crashed. I think took my saved scene with the renamed textures and tried that. Didn't like the effect of the inverse square though, it was all blotchy on the walls - so I tried with inverse linear which looks ok, but I didn't think the original was too bright.

Here's the render settings:

And here's the crash messages and how long it's able to get. There are two instances of the Firefly has crashed thing because it calculates IDL. Crashes. Restarts. Renders the buckets it has precalculated, and crashes again:

And finally the render as it looks with the textures renamed. As you can see, there's nothing obviously out of the ordinary...

Oh and the render finishes fine even after the crash (without having restarted Poser in the meantime, so the offending textures are still loaded in the cache. As long as they're not actively used, they don't seem to matter...)

Here are the textures currently loaded, after the render finished. Antonia's textures are loaded because I had used her previously. The result is the same with or without her textures loaded. Just making that clear.

I tried exactly the same settings as you had and  everything renders fine without crashes. My result is virtually the same (only the reflection seems slightly less). If I look at my texture cache it seems as if all the textures are loaded twice but the second set does not exist (I have seen this type of thing ever since I discovered the texture cache). If you point at one of the two, the right texture is selected automatically and will work. But all that does not help with discovering why ffrender crashes on your system.with these set of textures. One more question. After you made the collecting script and created a new scenefile. Did you try to restart poser and loaded the new scene directly? The new scene file has all new references in it to the new location. Does that render OK? Unfortunately all obj files are encapsulated in the new pz3 otherwise you could have send it to me. If that collected scene does not work, it must be something specific to your machine or to the poser configuration.

Regarding the brightness: If you increase the irradiance cache the whole scene gets much brighter. I had it set much higher.
Regarding the blotches with the inverse square falloff:Move the point light away from the ceiling. If it is too close you get the blotches. If it is 15-30 cm lower most of the blotches are gone and increasing the quality a bit gets rid of most of the others.

Thanks for the tips about the light :)

I never made that collect scene script thing - I forgot about that. Will try that and see what happens.

I'm curious of your double textures. Which is your "real" Poser location? P:runtime I'd guess?

Also.. I deleted the cache files sometimes during all the things I've tried here. And this was after a restart of Poser (the working scene I had saved was saved with Antonia in it which is why her materials are loaded)'

But it doesn't explain why yours are loaded twice when it's apparently not a general thing - otherwise mine would be as well. And since we (as far as I can see) have Poser on an external disk... the setup is close to identical. So what is making mine crash :( Hm If only it was crashing no matter what the names of the testures were I would write it off as a Poser Quirk™ or something to do with my machine. But when they work as soon as they're renamed, all logic stops...

Now that you mention it I think I swapped the sphere map for real reflections on the floor. That's probably the reason why they're different.

Going to sound crazy, but I am on a Mac. After reading this thread guess what? A scene that rendered before without IDL crashed the render engine when I turned IDL on. Started taking the scene backwards by deleting items. Still crashed with or without IDL. Got to the point I was down to V4 in the same clothes exactly the way I rendered her earlier last night and still crashed. Was beginning to think reading this thread jinxed my computer!!!!

What I did that seems to have solved my problem was look in the poser prefs file and find the TEMP_PATH line which in my case was
TEMP_PATH /Users/grichter/Library/Caches/TemporaryItems/Poser/8.0

navigated to /Users/grichter/Library/Caches/TemporaryItems/ and deleted the Poser file.

All is good again (so far)

Might be a long shot under windows, but could be worth a try by deleting all your temp items (which includes your previous render caches also).

 Well I'll be ....

If I do the collect thingie first the scene renders...

Still doesn't make much sense to me, but at least I have a workaround now without having to manually swap all the textures with renamed ones..

I assumed the collect script would work. The only thing odd about the props is that every prop has all the textures of all the props referenced, but - of course - uses only the material zones which are present in the props. By writing the scene with the collect inventory it will rewrite all the references and now probably the way Poser wants it. In the "normal" scene file it keeps the old references.

About the double references: I have seen that once in a while since Poser 4 I believe. I have no idea why - it probably is a quirk in Poser. The second set does not exist on disk. It probably has something to do with the way Poser caches its textures and the order in which it finds things. It only happens with certain props.

There are other things in Poser which take longer to write a message about as to correct it. Some jpg files cannot be read by Poser (they seem to come mosly from the japanes freebies). If you convert them with an image editor they work. Once you know this, it is a matter of seconds.

Regarding the original problem: I am pretty sure if you save the props back to the library after you loaded them, they will work in the future without ffrender crash.
But it all does not explain why it crashes on your macine in the first place

 It's actually a good idea to save them back to the library. I agree that they'll most likely work then. And Poser is a quirky program, I have learned to live with that since Poser 4 L I just like to know WHY when I encounter something that isn't a known bug.

But I'll try saving the props back after the Collect script has been run on it. With a little luck it would work then :) Thanks for the idea!

I hadn't run into the thing with the japanese props (and I have a bunch of those) biut should it occur I now know the cure :) )

I t is totally crazy/insane/wierd..  these crashes are completely random..

My scene consists of:
1:   A backround image  (jpg)
2:   A Tree  (Poisen's Badlands 2)
3:   RDNA IC3  Ground Plane
4   Default Poser 8 lights with shadows off on 1 & 3..

I can render this scene several times and get no issue.  (2-4 mins.)
Then it will render :-
a:   With a background similar to the Pre-calculation for IDL..
b:  No background at all
C:   Poser 8 will crash

Why??

 Saving the props back after the collection script did the trick. They render now.

NoelCan... your problem is another "similar but not same" thing.

This is about a specific scene, NOT Poser in general.

But who knows.. perhaps the thing that allowed me to render this scene will help you, too? Try it.