Quote - imho, that doesn't make sense to do.  i mean, if you're going to automate loading, why not allow selection of materials and props rather than relying on developers to add some specific naming convention?  that's not a very extensible answer.  what happens when there's a Yafaray exporter, or some new free renderer comes along that's better and needs completely different treatment? 

Seems that any render engine has some special things. No other engine I know of has a light that acts like a "skyglob" including a light for example.

Ok, we could assume any IBL should be replaced by a sunsky. But what if somebody is using a real skyglobe and addtionally IBL?

I don't talk about what can be examined from a Poser scene to standards used by any other engine. But I think material conversion for render-engine xyz is also not possible without doing something. Except render-engines do use the same material handling (rib, for example). This is the reason why bagginsbill thought of adding a standard-material handling for Lux as a Lux-extension (probably this has to be done for other renders, too).

The reason you talked about (a programer has to add something for other render engines) is why I mean it's best to write the code as abstract and "easy to read" as possible to make sure somebody is able to extend the code later (or to use it as a framework).

As far as I can see, to address the standard Poser user the material export is the most important part (some specialists may not need a complete conversion). Moreover, guessing what a nodeset inside a material may be good for is the hard part (skin or not for example, or x-nodes just to get a "realistic" reflection/glaseffect). Most of the tricks done to get a nice material in Poser aren't useful for other render engines. Discarding such nodes may not only speed up rendering but also may come out better.

I'm sure this part is true for any other render-engine but Firefly (the common part). So if it is possible to translate pure Poser materials to something like "Meta-Materials" (beside of the conversion to Lux matarials), the hardest work is done for any other render engine.

But all this has nothing to do with all the nice features a new render-engine may have and could be used by the user - if he had a "handle" (simply a special prop to fill the gap; with a name prefix to not disturb what is defined for another render-engine and not accidently rendered). 

This leads me to the need of having an editable list of "Prefixes to ignore" :)
Or to call a function with each name in question ...

My conclusion: If props/actors/ligths with a prefix are ignored, the material-exporter isn't involved anyway. All this objects could be disabled before the exporter touchs them (with automatic re-activation later). Materialnames are still untouched.

At the end: What I'm talking about is nothing you HAVE to use. But you CAN if you want. If it is properly ignored by parts who don't know to handle objects with the prefix in question.

---