Poser Pro 11 now uses a tweaked Blender Cycles engine
The Poser Pro team is using a forked version of Cycles in their latest release, and called it SuperFly. The reason for their fork is that some features are too Poser specific, but they will be contributing back other, more generally useful improvements.
Remember that Cycles uses the Apache License, making it compatible with commercial/closed source applications as well.
Michael Fleming writes:Poser Pro 11 human modeling software was released on November 17, 2015 and now uses Blender’s Cycles as the basis for it’s render engine! According to the developer’s site: “NEW! SuperFly – Physically Based Rendering. Built on Blender’s Cycles Render Engine, SuperFly brings the power of physically based shading and rendering to Poser. Accurately rendering light the way it behaves in the real world makes it easier to produce hyper-realistic renders.” The attached image is a still-shot from the developer’s promo video for the software at their website.
https://www.youtube.com/watch?v=b8KIIp8tYkU
finally some one got the potential of porting cycles into other softwares
There was also the Rhino integration that Nathan Letwory was working on, but I don’t know if that ever got finished or not:
http://www.blendernation.com/2015/01/29/rhinocycles-introduction-preview/
Is this a demonstration of the cycles liscence failure? Did I miss something they got free developement, the blender community got notta. Worse yet it seems they Dangle our failure to adapt PBR in front of us. I can understand wanting to support projects which enrich Blender. But are we so desperate to feel like blender is in a class with industrial software that it need not benefit anyone who’s epic work gave us Cycles.
1. The Cycles license isn’t a failure. It was designed to let Cycles be variously adopted and variously adapted. To this end, its license has succeeded. There was no bottom-line expectation that Cycles would see all of such returned to Blender.
But what it does do is increase the chances of Cycles seeing some novel developments that might perhaps see its way back to Blender. We haven’t seen returns to core Cycles yet. But then again, it hasn’t been adopted very widely yet.
Overall, it seems to me that the goal in sharing Cycles wasn’t to seek the benefit of Blender so much as to seek benefit of proving what the philosophy behind Cycles can variously achieve.
2. You say they got “free development,” but honestly, so has Blender. Blender has and still variously adapts existing developments such as OpenSubdiv, Ptex and OpenVDB. If anything, Blender could stand to adopt some more existing developments and open standards, such as full Alembic support (or perhaps even Instant Meshes in Sculpt Mode). Anyways, it was the developers’ free choice to generously share Cycles, basically no strings attached.
3. Nobody’s “dangling” anything in front of Blender community. This community has really got to grow a thicker skin. If incorporating a PBR pipelines is part of their own needs, that’s no insult to Blender. Their adapting Cycles to suit their needs isn’t an affront toward Blender users–it’s simply their own adapting the freely-available Cycles engine to their own needs. If you feel this highlights where Blender hasn’t been keeping up with industry standards and concepts, then that’s more you candidly pointing it out the issue, than any implicit shaming from SmithMicro Software.
Though, I’m not sure if you truly understand just what “PBR” is, exactly. Technically, Cycles in Blender is already “physically-based rendering.” What PBR as a concept really relates to is a newer pipeline for real-time rendering applications (most particularly, game development, but also real-time visualizations), based on what 3D animation (offline rendering) has already long known.
Basically, “PBR” is just a borrowing existing BRDF concepts from traditional ray-tracing render engines used in 3D animation, optimizing them with modification suited for real-time visuals, and allowing for workflows that work in a more consistent, universal, streamlined way (even though several methods of PBR are in use). Sometimes, “PBR” can be more marketing than anything (similar to the concept “cloud” technology, which has long existed).
4. I’m not quite sure how to read your last sentence, as it reads just a bit incoherent to me. But to what I think I comprehended there, I will say here again, what a company does with Apache-licensed Cycles engine shouldn’t be seen as some measure of what should be shared and heading to Blender’s Cycles.
Anything that a third-party adoptee of Apache-licensed Cycles should wish to share back to the original Blender Cycles would be nice, but I think it’s fair to not expect it from people. Companies like SmithMicro Software (Poser Pro) and Robert McNeel & Associates (Rhino3D) modify Cycles to complement their software–as the license gave leeway.
If Cycles developers are going to share something as no-strings-attached, the community has to accept that these companies have done nothing wrong or anything against Blender. It’s really disrespect to the developers when we variously whine about this.
5. Honestly, aside from some aesthetic UI changes and a few specializations, so far, I haven’t really seen them create anything new within Apache-licensed Cycles’ technology which doesn’t already exist in the Blender’s Cycles. For the most part, it’s just been news of how they’ve adopted Cycles towards their own use, and they still seem to rely on what core Cycles development releases.
Which, again, is totally fine. It doesn’t hurt Blender or its community any. This is no affront to “anyone whose epic work gave us Cycles.” It only helps promote the idea that true sharing makes no obligations, and promotes the developers as pioneers. In the end, it only helps Blender’s generous image, and really, if you talk to make users of Poser Pro, you’d know that many (if not most) of them use Blender to some degree anyways.
There is no failure for not having PBR. Just the other day I easily incorporated a metalness PBR workflow into Cycles by means of a custom shader. Poser possibly did the same.
Smith Micro are feeding back their code changes to the Cycles team to see if it’s useful in Blender. Charles Taylor (Poser product manager) is quite OK with sharing information about Superfly with the Cycles crew, because it is mutually beneficial.
I think it was a dumb idea to put Cycles under a non-copyleft licence. This means that proprietary companies can take from it without giving back. This kind of freeloader behaviour can suck the lifeblood out of an open-source project.
But then, why take my word for it: why not listen to HP CTO Martin Fink explain it http://lwn.net/Articles/660428/