"you decided to turn off the GPU rendering feature just to make Poser backward compatible with an archaic material room?"

I wish nerd would come back and clarify this issue. I feel like this hasn't actually been said, although it is plausible. We have not actually been told WHY the GPU is not supported. The group assumption is that they are avoiding some extra work motivated by backward compatibility, and the argument against it is drop the compatibility rather than the GPU support. I'm concerned about that but also about something else.

Some of the nodes implemented in Cycles/Blender are BETTER than the "equivalent" nodes we have in FireFly. I dont' want just the nodes from FireFly. I actually want the Cycles nodes for a lot of reasons. For example, the Poser Reflect node cannot be made to deal with anisotropic reflections at all and the specular Anisotropic node only deals with lights, not reflections. (And also doesn't work right) Conversely, the Cycles Anisotropic BSDF node does both CORRECTLY. I do not want compabiliity with the poser Reflect node. I want the Cycles Anisotropic BSDF node - period. In fact, add that back into Firefly, please.

I want to make clear that PBR is a new style of parameterization, not a new style of rendering. I've been doing "physically correct" rendering in Poser quite well since we got IDL, SSS, and Fresnel_Blend. But, we still have problems with light transmission, anisotropy, attenuation, and too many artifacts with IDL, so I'd like to see a new renderer that doesn't have those problems, and a node system capable of implementing ALL the physics. Almost all of the shaders I'm building in FireFly are trying to implement what the Cycles nodes do directly. I want the Cycles nodes - not the FireFly nodes!

I note also that Cycles is not a pure, unbiased renderer. It is also capable of non-photo-real shading (NPR), such as toon rendering. There are lots of examples of Cycles materials on the web showing how to build various NPR shaders with the Cycles nodes. Google for "cycles toon" - you'll see it isn't just about physics. So if you think we actually need FireFly for that, you're misled.

On the other hand, there are some great things about FireFly nodes - the ability to do arbitrary math is terrific. I don't want to lose that. The arbitrary math isn't motivated by lighting effects - it's motivated by procedural pattern generation. I can make so many patterns that don't exist as pre-built nodes simply because the FireFly nodes include all the basic math operations. Yes I understand many of you would never make a procedural fish scale pattern generator from + - * / on your own and you hate those nodes. Cool - don't use them.

So - I'm not sure I understand the value proposition of hiding all the Cycles nodes in favor of the FireFly node implementations. Nor have we actually heard that, but ... if that's what is happening, then I'd like to argue against that. If that is also the underlying cause of preventing the use of GPU mode, then I strongly argue against that. The Cycles node system has capabilities that I've long wanted, but have no way to get in FireFly and obviously now I never will. 

Backwards compatibility is good, and I would like to see, to the extent it can be done, a subset of the FireFly nodes work in SuperFly mode, even if that means CPU only. But don't throw out the baby with the bathwater - if GPU can be supported, and the user has only to rewrite some nodes into some other nodes (which I or SnarlyGribbly could probably automate) that allows quickly porting physically correct shaders from FireFly to SuperFly, I would prefer that. If FireFly nodes can't be supported at all and existing shaders need to be converted to Cycles nodes, in order to use Cycles as Cycles, and not as SuperFly, that's not so bad. Give us Cycles mode, where there is no backward compatibility, but we DO get the Cycles BSDF node system and we DO get GPU rendering.

I don't recall Nerd saying that they were gonna sacrifice GPU rendering for compatibility with the material room, but I have a lot of the same questions as you BB about the Cycles nodes, especially how they're gonna make Poser nodes that are geared toward faking now do faking AND physically based functions. I realize this is not every Poser node, but a lot of nodes I just don't see transferring over very well :). I would rather see two material rooms then to see them try to shoehorn making Cycles work into a system that really isn't compatible. Hopefully we'll see what's what soon :).

Laurie