Cycles and Eevee are two very different render engines with to very different target audiences ...... sort of. What I like best about Eevee is it gives me realtime feedback of Eevee or Cycles shaders (for those that are the same). For projects where Eevee works, it's awesome! Think of doing an animation at 1080p with high a quality "PBR" renderer at 2-3 seconds a frame - that's what Eevee can give you (view port rendering is almost instantaneous). However, so far it seems to fall short with very large complex scenes (and poorly made models with polygons that are parallel and very close together), where Cycles shines. My understanding is that Eevee is an OpenGL renderer (I could be wrong).

With respect to Poser, I doubt Eevee will ever come to Poser. I don't think it has the same liberal licensing that Cycles has.

Deecey posted at 1:48AM Thu, 27 June 2019 - #4354939

Is Blender going to completely shelve Cycles, or keep both Cycles and Eevee?

I think they're going to keep both, at least for the foreseeable future.

Laurie

Giana posted at 1:51AM Thu, 27 June 2019 - #4354936

i'm not a programmer either, but i'm curious...

people have voiced thoughts/concerns regarding current materials & nodes remaining compatible [or that's how i've read it]...

there have been a number of systems created by vendors to convert such things in the past. wouldn't something like that be a potential solution to such things, or am i missing something? <---- genuine question asked with no trace of snark, fyi - i'm not terribly techie either in case ya can't tell... heh

I too, am not a programmer but I know how to double click things and apply pre-made shaders to make nice renders. lol

IMHO they need to fully integrate Cycles and ditch SuperFly. But they need to have a bridge that can automatically convert SF materials to Cycles. From what I can understand, the gap between SF and full Cycles isn't too great so an included conversion script shouldn't be too painful. This way we get the latest version of Cycles with the denoiser and fancy pantsy stuff that's been asked for for a long time and that also opens up Poser to the Cycles paid and free pre-made nodes/materials that are available on the web.

Giana posted at 7:28AM Thu, 27 June 2019 - #4354936

i'm not a programmer either, but i'm curious...

people have voiced thoughts/concerns regarding current materials & nodes remaining compatible [or that's how i've read it]...

there have been a number of systems created by vendors to convert such things in the past. wouldn't something like that be a potential solution to such things, or am i missing something? <---- genuine question asked with no trace of snark, fyi - i'm not terribly techie either in case ya can't tell... heh

I'd don't know if this is being unfair to the Lux and Octane devs but from my experience of using Firefly shaders in other apps (eg Vue) its more like an artful translation than a conversion. Render engines have their own "languages" based on how they are implemented which can mean its not always straight forward to reproduce in another engine. For example Firefly's "highlight size" and "highlight intensity" parameters do not have a direct equivalent in a render engine that expects a PBR type distribution function.

IMHO they need to fully integrate Cycles and ditch SuperFly. But they >need to have a bridge that can automatically convert SF materials to >Cycles. From what I can understand, the gap between SF and full >Cycles isn't too great so an included conversion script shouldn't be too >painful.

EVEE is essentially a real time game engine renderer Much Like Unreal or Unity. It uses many "cheats" to get that kind of realtime performance just as the game engines Do

As with All engines conversion of materials is the challenge.

It is All a matter of scripting really Doing it for poser should be theoreticly be possible as both poser and Blender use Python.

We have had a Free DS to cycles scene converter called"MCJteleblend" for years that converts Daz scenes/materials to cycle nodes automaticly upon export and opens the scene in Bblender there was a poser version ,in the past ,but the creator seems to have stopped making it .

I use it for High quality stills all the time.

But isn't the compatibility question is to do with Firefly which most older content in Poser uses, discussing Superfly vs Cycles is just pushing the peas around the plate. If the DS conversion was from Delight to Cycles it be interesting to know how reliable the results were.

As for Blender Eevee, Cycles, and Poser.

Blenders main render engine is still Cycles and Poser has SuperFly a migrated sister of Cycles.

If migrated to Poser, EEVEE would replace the preview render engine.

The Blender team is still improving on Eevee before the final release, and more and more Cycle nodes are becoming available in the Eevee preview.

Eevee = Preview

Cycles = the full bore all out render engine.

Best regards, Tony

Also, Poser does have Cycles, albeit a slightly watered down version of it. And Richard 60, to answer your question, I had figures, like Dawn, come out black using Superfly, so I don't get your question. I made changes to the nodes and textures and got the render. It's not like Superfly did it for me.

EClark1894 posted at 8:03PM Thu, 27 June 2019 - #4354958

Also, Poser does have Cycles, albeit a slightly watered down version of it. And Richard 60, to answer your question, I had figures, like Dawn, come out black using Superfly, so I don't get your question. I made changes to the nodes and textures and got the render. It's not like Superfly did it for me.

But for the most part, SuperFly is compatible with existing textures. Compared to 3rd party renderers like Lux and Octane where you have to change most materials. Which is how I can image pure Cycles would be if it were used instead.

I was a Lux render guy for a while. When Poser made a song and dance about introducing Superfly, I was like so what - already have a PBR render engine. However it was a pain to set things up in Reality and the results were hit and miss. It soon became apparent how easy it was to render in Superfly because the Poser guys had done a great job in changing the Firefly shaders to Superfly. The default for me is Superfly and I haven't used the Firefly engine in years. I was using the CPU for rendering because the graphics card wasn't supported. I bought a basic 1060 graphics card for my old computer and I am happy with the GPU rendering.

Now I know that some of you love to tinker, but I think the vast majority just want to render a reasonable picture as easily as possible. That means automating the boring stuff as much as possible.

1. We don't want to spend time messing with shader trees.
2. We don't want to spend time in the fitting room. Transfer of clothes from one figure to another should be automatic.
3. We don't want to spend time creating morphs to get attractive characters. We expect someone else to have sorted that out, and I will go further to say that trying to create expressions from face chips is going to get tiresome really fast. Turn that expression dial, 3 seconds - render.

What Poser needs to be good at is 'posing'. The ability to quickly set up scenes and move characters. And for the future, lets dream. I want to put a character next to a seat and say "sit". Character sits and interacts with object and bottom compresses automatically. "hold cup". Fingers do not intersect handle. "smile" The program takes into account the skull, teeth and muscle structure of that particular model. Although this is a dream at the moment, we know that this is going to be a reality at some time in the not too distant future. If we are going to have cars that not only can navigate the city without human intervention but also recognise a human talking into a cell phone as a dangerous object, all this is possible. I can dream.

The thing with Superfly is that it can read previous Poser material nodes - with very few limitations. You can use nodes you're used to, nodes that do some things there are no specific Cycles nodes for, etc. And if you load old props, you don't really need to remake every material for Superfly - it'll treat diffuse color/textures as a DiffuseBSDF, Specular color as GlossyBSDF etc.

Ditching Superfly to go full Cycles means breaking a LOT of previous content, AND forcing everyone to use a Cycles Root node to use it.

A rather simple to implement way to go forward would be:

• Full implementation of Cycles and the Principled BSDF as default material room setup. (Replacing the FireFly and SuperFly root node)
• Full implementation of Eevee to replace the current preview mode.

However ; and please stay constructive here.

We can not allow a company to become a slave of another company's technology.

• We don't want Poser/Renderosity/Bondware to depend on DAZ for figure technology.

• We also don't want Poser/Renderosity/Bondware to depend on Blender.org for rendering technology.

If you make yourself "depend" on an external company's technology? "They" will always have it first, and you are always running behind playing catch-up.

And the reaction will be the same as always : Why pay for something we can get for free.

On the issue of future figures. => If you want figures to behave like humans, you need a human muscle geometry to make movements and muscle mass changes "believable". => Orion and Venus seem to go in the right direction.

Looks like still same Renderosity forum, always bickering or rather war between the DS users and Poser...

If this acquisition Renderosity of Poser SW is for good or bad, we will see, hopefully it will be for good

Thanks, Jura

tonyvilters posted at 9:11AM Thu, 27 June 2019 - #4354970

We can not allow a company to become a slave of another company's technology.

• We don't want Poser/Renderosity/Bondware to depend on DAZ for figure technology.

• We also don't want Poser/Renderosity/Bondware to depend on Blender.org for rendering technology.

This.

Hi Dee, we have lots of different opinions on different issues, and I am very happy to see that we can also agree on some of the more important aspects of future development. Best regards, Tony

hey, i'm still in P10, rendering with FF, but i figure if i honestly want Poser to move forward, which i do, change will have to happen. if it means that i would then have broken, but repairable content, or tools inside Poser to fix/update those breaks, then i'm okay with that since the larger picture really is about growth for Poser. or if i need to learn a new, or slightly newer, format, then so be it. since RO now owns Poser, i feel if semi-big to big changes happen, and if i need to learn new things, that the curve for that might only be sorta steep once simply because Poser won't be changing so many hands as frequently as it was... stability in ownership, with clear vision of future, will hopefully do a lot for Poser, even beyond the obvious...

i do understand that it is a greater concern for content creators though.

Deecey posted at 11:19AM Thu, 27 June 2019 - #4354939

Is Blender going to completely shelve Cycles, or keep both Cycles and Eevee?

From what I've read from comments on the forum related to the class I'm taking, Blender 2.8 is dropping the old, original Blender Render engine, and will have Cycles and EEVEE. This is probably why I'll probably still have version 2.79 installed, because I usually just do quick renders to see how my modeling is coming along. I don't "need" EEVEE, I just want to "play" with it to see what it's all about.

You do have to hand it to Smith Micro though, up until now they stuck by Poser the longest. ['95 - '98 Fractal Design] ['98 - '99 MetaCreations] ['99 - 2005 Curious Labs] [2005 - 2008 e-frontier] [2008 - 2019 Smith Micro]

I'm not willing to hand much of anything to Smith Micro. On the SuperFly/Cycles issue, on the DAZ side, Materials for 3Delight are pretty much incompatible with Iray and it does cause issues with some vendors there dropping support for 3Delight materials. Having both rendering engines being compatible material wise has its advantages.

On the other issue, of relying on another company, I think the industry really should move to some standards as an industry where applicable allowing everybody to share in the decisions and allowing objects to move between the programs better. Unless and until that happens though. yes, by depending on another company to lead in anything means you are vulnerable to sudden changes due to decisions they make that are beyond your control.

Sort of like Browsers, while they all operate differently, they are supposed to accept core standards of HTML, CSS3, and Javascript. Where they "embrace and extend" (and I'm looking straight at you Microsoft) it causes problems.

Afrodite-Ohki posted at 12:28PM Thu, 27 June 2019 - #4354969

The thing with Superfly is that it can read previous Poser material nodes - with very few limitations. You can use nodes you're used to, nodes that do some things there are no specific Cycles nodes for, etc. And if you load old props, you don't really need to remake every material for Superfly - it'll treat diffuse color/textures as a DiffuseBSDF, Specular color as GlossyBSDF etc.

Ditching Superfly to go full Cycles means breaking a LOT of previous content, AND forcing everyone to use a Cycles Root node to use it.

While it's true that a lot of content would have issues, I mentioned that there needs to be an auto-script that would convert certain materials to Cycles. If Reality was able to convert materials to Lux then it should be possible to have something like that for Cycles, just integrated within Poser with an easy to use one or two click operation.

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

If the DS conversion was from Delight to Cycles it be interesting to know how

reliable the results were.

@ironsoul I am not sure what you mean by"from Delight to cycles".

I dont Use IRay or 3Delight -technically because I never render from Daz studio however any image based materials are converted to cycles nodes referencing the

texture maps used in the DS Scene. Most Iray procedural shaders do not convert to cycles nodes properly (no surprise there)

Of course you can replace any Daz converted node with a principled shader as I

have done for the Clothing in the image I posted the Characters skin is an Old Mike 4 "Sole elite" set being used on the G2 Male.

Of course nodes will need adjusting in blender particularly the gloss nodes which are always much too shiny by default.

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Glitterati3D posted at 2:14PM Thu, 27 June 2019 - #4355005

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Hahah Ol' Elwood is a wonderful name for him. Now I picture a tired old Sheriff in a dust bowl of a town, sitting in front of the ol' jailhouse, on a laptop from 1997 typing replies to us on the SM forums sighing every time he reads a comment asking about adding new features.

Like I said, I would loooove to be proven wrong. Being able to render in SF with Turing would be a game changer for me and probably anyone else who wants to use SF but can't atm because they don't have Pascal or Maxwell.

Deecey posted at 3:25PM Thu, 27 June 2019 - #4354977

tonyvilters posted at 9:11AM Thu, 27 June 2019 - #4354970

We can not allow a company to become a slave of another company's technology.

• We don't want Poser/Renderosity/Bondware to depend on DAZ for figure technology.

• We also don't want Poser/Renderosity/Bondware to depend on Blender.org for rendering technology.

This.

They don't. Cycles is open source. Poser or who ever uses it can make whatever improvements they want., when they want. As far as I know, it wouldn't cost Poser a cent. Further, seems Poser is in good company. The following is from the Cycles website.

Cycles is an physically based production renderer developed by the Blender project. _ The source code is available under the Apache License v2, and can be integrated in open source and commercial software. Cycles is natively integrated in Blender, Poser, and Rhino. The Cycles4D plugin for Cinema4D and a plugin for 3ds Max are available as well. _

Glitterati3D posted at 3:41PM Thu, 27 June 2019 - #4355005

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Oh, I'm not blaming SM or anything - I'm just commenting that it was probably not technical difficulties that stopped them from improving Superfly.

Afrodite-Ohki posted at 3:43PM Thu, 27 June 2019 - #4355013

Glitterati3D posted at 3:41PM Thu, 27 June 2019 - #4355005

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Oh, I'm not blaming SM or anything - I'm just commenting that it was probably not technical difficulties that stopped them from improving Superfly.

I'm guessing it was time AND money. And telling me that there wasn't time to include all the nodes before release doesn't quite square with me either. If you were going to release All the nodes, then why not continue, finish and release it in an update? Here it is almost two years later, 4 or 5 updates and sold to Bondware, but no update on the nodes or Superfly. That tells me their work was over and done.

EClark1894 posted at 3:53PM Thu, 27 June 2019 - #4355015

Afrodite-Ohki posted at 3:43PM Thu, 27 June 2019 - #4355013

Glitterati3D posted at 3:41PM Thu, 27 June 2019 - #4355005

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Oh, I'm not blaming SM or anything - I'm just commenting that it was probably not technical difficulties that stopped them from improving Superfly.

I'm guessing it was time AND money. And telling me that there wasn't time to include all the nodes before release doesn't quite square with me either. If you were going to release All the nodes, then why not continue, finish and release it in an update? Here it is almost two years later, 4 or 5 updates and sold to Bondware, but no update on the nodes or Superfly. That tells me their work was over and done.

Except you left out that whole step where SM let all the programmers go who knew anything ABOUT Poser and Cycles and Superfly.

Glitterati3D posted at 3:59PM Thu, 27 June 2019 - #4355016

EClark1894 posted at 3:53PM Thu, 27 June 2019 - #4355015

Afrodite-Ohki posted at 3:43PM Thu, 27 June 2019 - #4355013

Glitterati3D posted at 3:41PM Thu, 27 June 2019 - #4355005

Afrodite-Ohki posted at 1:59PM Thu, 27 June 2019 - #4355003

What other choice is there? SM had over a year to get SF compatible with Turing, but nothing ever came out of it and as of now it makes SF a dead end and a major problem for anyone looking to upgrade their GPU from Pascal. You saw the threads that were starting to become common on the SM forums, every week there was a question of why someones new video card wasn't working for SF and the answer was always the same.

I don't know if SM was unwilling to add that functionality to SF or they simply couldn't due to SF's implementation, but I don't think SM would purposely not add in functionality that would extend Posers life cycle. So I'm assuming that it's technically not a feasible feat with what we have right now. Though I'd love to be proven wrong and have a new update for PP11 that gives us support for Turing cards because being forced to use old hardware that's become even more expensive than the newer hardware is pathetic.

I honestly can't say for sure what was going on behind the scenes, but from what I picked up in general conversation my guess would be that SM didn't implement that just because SM didn't implement much of anything into Poser in the last couple of years.

My guess is (and I am guessing, I have no insider information) that SM knew the sale was ongoing and they had no intention of devoting resources to Poser for anything. A sale like this does not happen overnight - no doubt it's been in the works for some time.

For some time, "Ol' Elwood" as I called him gave me the impression he was the only soul working on anything Poser.

Oh, I'm not blaming SM or anything - I'm just commenting that it was probably not technical difficulties that stopped them from improving Superfly.

I'm guessing it was time AND money. And telling me that there wasn't time to include all the nodes before release doesn't quite square with me either. If you were going to release All the nodes, then why not continue, finish and release it in an update? Here it is almost two years later, 4 or 5 updates and sold to Bondware, but no update on the nodes or Superfly. That tells me their work was over and done.

Except you left out that whole step where SM let all the programmers go who knew anything ABOUT Poser.

No, I said time AND money.

Glitterati3D posted at 2:02PM Thu, 27 June 2019 - #4355016

Except you left out that whole step where SM let all the programmers go who knew anything ABOUT Poser and Cycles and Superfly.

And that was November 2016, or almost three years ago.

EClark1894 posted at 10:29PM Thu, 27 June 2019 - #4355010

Deecey posted at 3:25PM Thu, 27 June 2019 - #4354977

tonyvilters posted at 9:11AM Thu, 27 June 2019 - #4354970

We can not allow a company to become a slave of another company's technology.

• We don't want Poser/Renderosity/Bondware to depend on DAZ for figure technology.

• We also don't want Poser/Renderosity/Bondware to depend on Blender.org for rendering technology.

This.

They don't. Cycles is open source. Poser or who ever uses it can make whatever improvements they want., when they want. As far as I know, it wouldn't cost Poser a cent. Further, seems Poser is in good company. The following is from the Cycles website.

Cycles is an physically based production renderer developed by the Blender project. _ The source code is available under the Apache License v2, and can be integrated in open source and commercial software. Cycles is natively integrated in Blender, Poser, and Rhino. The Cycles4D plugin for Cinema4D and a plugin for 3ds Max are available as well. _

There several render engines which can be used in Poser, AMD ProRender is one of them, it can be used like with Nvidia or AMD GPUs and can be used too with Intel or AMD CPUs

Its free, just Renderosity or Bondaware must speak with AMD regarding that

Same applies to any 3D SW is reliant on other render engines like 3DS Max or even DS

Cycles is nice but unless Renderosity or Bondaware implement full blown Cycles with AMD and OpenCL support then we as always have just poor version of Cycles

Then Turning support which is missing for few months and we are still waiting on this, I expected it will be pretty straightforward to implement but not

Thanks, Jura

Has DAZ incorporated cycles in DAZ Studio? Or did they implement their own version like Smith Micro. (I don't use or follow DS, so I've no idea.)

SatiraCapriccio posted at 7:07PM Thu, 27 June 2019 - #4355034

Has DAZ incorporated cycles in DAZ Studio? Or did they implement their own version like Smith Micro. (I don't use or follow DS, so I've no idea.)

DAZ Studio uses iRay

The Cycles integration in Poser was one mans job. One single man who had the tech and knowledge to do that.

He got laid of with the rest of the team in November 2016.

Of course Cycles was not updated in the SR's because the single guy with the knowledge to do so was fired.

Blender moved on with Cycles and Eevee and is on the verge of releasing 2.8, but who has the capabilities to bring it over?

This is a question only Rendersity/Bondware can find an answer for.

Right now, it is months too soon to even start speculating what the "next" render engine will look like.

Finding the right people for the job is the hardest part. Remember, the original team had the know-how, but we are 3 years down the road of the initial cut-offs.

The same goes for beta testers. Wait too long to appoint a "fresh beta tester team", and most of the internal knowledge will be forgotten too.

For all companies, during all take overs, the knowledge transfer is the single most important fact.

And, that became close to impossible, since the only team that "knew" the code is already gone 3 years.

They tried a team in Portugal, recovered and brought the app back home, and now it is sold.

3 Years are lost and gone.

The WORST case scenario would be to appoint "friends" to become programmers and appoint "friends" to become the new beta-testers.

Friends are to have a BBQ with.

If you want the job done as it should?

You find the tech guys, and they can NOT be vendors because they HAVE to stay NEUTRAL, and they can never be "friends", because they will find and report your errors, whether you like it or not.

Appoint "friends" or vendors as beta testers, and they will agree and accept everything you make, and you will not advance a single coding line, and never fix a bug.

All I can say is : I hope Rendersity/Bondware can "recover" the tech guys, preferable the original team members, or they are going to see dark times.

Poser is my hobby, Poser is my passion, has been for the past 25 years, and I really hope that they can recover.

Add my name to the list of folks flogging the AMD Pro Render engine.

Open source, and most importantly, GPU neutral.

Turning (Nvidia only - no AMD GPUs or Macs) is like Thunderbolt - a solution in search of a problem. It isn't just Poser that hasn't adopted it.

And Tony is dead on re: developers & beta testers....

ssgbryan posted at 7:54PM Thu, 27 June 2019 - #4355042

Add my name to the list of folks flogging the AMD Pro Render engine.

Open source, and most importantly, GPU neutral.

Cinema 4D uses AMD Pro Render.

Turning (Nvidia only - no AMD GPUs or Macs) is like Thunderbolt - a solution in search of a problem. It isn't just Poser that hasn't adopted it.

I've read some stuff about it but not much. What I did read was several different people suggesting that there is already another GPU card in the works and they would be hunting down 1080's in the meantime.

And Tony is dead on re: developers & beta testers....

Makes a wish.

tonyvilters posted at 8:20PM Thu, 27 June 2019 - #4355039

Appoint "friends" or vendors as beta testers, and they will agree and accept everything you make, and you will not advance a single coding line, and never fix a bug.

I beg to differ. Vendors are the most interested in making sure the bugs are fixed.

wolf359 posted at 6:02AM Fri, 28 June 2019 - #4355004

If the DS conversion was from Delight to Cycles it be interesting to know how

reliable the results were.

@ironsoul I am not sure what you mean by"from Delight to cycles".

I dont Use IRay or 3Delight -technically because I never render from Daz studio however any image based materials are converted to cycles nodes referencing the

texture maps used in the DS Scene. Most Iray procedural shaders do not convert to cycles nodes properly (no surprise there)

Of course you can replace any Daz converted node with a principled shader as I

have done for the Clothing in the image I posted the Characters skin is an Old Mike 4 "Sole elite" set being used on the G2 Male.

Of course nodes will need adjusting in blender particularly the gloss nodes which are always much too shiny by default.

Thanks Wolf, I was interested to understand if we had the same idea of how a conversion process works, we use a script or program to create the basics and then tweak to fix any issues. My concern about FF compatibility is that there are many users who have no interest in tweaking mats and whose criteria for a successful conversion is to load FF model in to SF press the render button and the result meets their expectation. I'm the same with cars, don't care how an engine works just want it to start and get me to and from work. SM did a great job with compatibility that almost but not quite worked, unfortunately the failure was with the eyes not being rendered correctly which is the first place people look so p11 SF got a bad rep for not working correctly IMO. To move forward I think we need an upgrade path that allows old FF content to still be used in poser reliably.

ironsoul posted at 4:28AM Fri, 28 June 2019 - #4355066

wolf359 posted at 6:02AM Fri, 28 June 2019 - #4355004.

To move forward I think we need an upgrade path that allows old FF content to still be used in poser reliably.

I actually would have no real issue with that since we technically have three renderers in Poser now. But implement a full Cycles now. With all the nodes, and Cycles shader development should expand. Right now you can only do so much, and places that make shaders for Cycles, don't bother with Poser's limited nodes. It would also help if Poser could read Blender nodes since they would do the same thing. But there's not much point if the nodes aren't in Poser.

I think, at some point we will all have to face up to the fact, that to carryon getting the latest and greatest features... Backwards compatibility is either going to suffer or have to be dropped.

I know that will not be the prefered for a lot of ppl.. But not much we can do about it. It can be mitigated by converting up old files - as we did with poser 4 files - but at some point even that will be dropped.

(example of this, try running 8bit or 16bit programs in Windows 7 (64bit) and Windows 10.. Not supported at all.)

EClark1894 posted at 12:07PM Fri, 28 June 2019 - #4355071

ironsoul posted at 4:28AM Fri, 28 June 2019 - #4355066

wolf359 posted at 6:02AM Fri, 28 June 2019 - #4355004.

To move forward I think we need an upgrade path that allows old FF content to still be used in poser reliably.

I actually would have no real issue with that since we technically have three renderers in Poser now. But implement a full Cycles now. With all the nodes, and Cycles shader development should expand. Right now you can only do so much, and places that make shaders for Cycles, don't bother with Poser's limited nodes. It would also help if Poser could read Blender nodes since they would do the same thing. But there's not much point if the nodes aren't in Poser.

Euh, 5 render engines Earl, there are 5 in Poser.

EClark1894 posted at 6:41AM Fri, 28 June 2019 - #4355071

ironsoul posted at 4:28AM Fri, 28 June 2019 - #4355066

wolf359 posted at 6:02AM Fri, 28 June 2019 - #4355004.

To move forward I think we need an upgrade path that allows old FF content to still be used in poser reliably.

I actually would have no real issue with that since we technically have three renderers in Poser now. But implement a full Cycles now. With all the nodes, and Cycles shader development should expand. Right now you can only do so much, and places that make shaders for Cycles, don't bother with Poser's limited nodes. It would also help if Poser could read Blender nodes since they would do the same thing. But there's not much point if the nodes aren't in Poser.

Wow, so yeah, now you want vendors to add yet another render engine to learn and support. I hope you're willing to pay the additional price for products to support all this work?

Vendors only have to learn how to use the PhysicalSurface Root node.

This root node "serves" all 5 internal render engines equally.

If I follow your argument that cost and prices go up by adding a render engine?

The logical result would be that If vendors learn how to use the PhysicalSurface Root properly? => Prices can go down. LOL.

Does Physical Surface root work with Firefly? I was under the impression that it only worked with Superfly.

(Also, if Superfly is dropped in favor of full Cycles like people are suggesting, wouldn't that mean that people would need to use the Cycles Root to be able to render something in Cycles?)

iRay being Nvidia iRay?

So, why cycles rather than iRay or another render engine? Is it because people know cycles because they use blender to model ... being free. Or is it because Poser developed Superfly based on cycles?

Personally, I can't wrap my head around Superfly, and I've never used blender. I can't get skin that isn't washed out with Superfly, and eyes? Yeah, forget it. They are washed out even more. I've set my materials up node by node based on products that have great looking Superfly skin ... and still I get garbage. Sad, isn't it?

I'd probably be happier if Bondware/Renderosity ditched Superfly for a render engine other than cycles. Though, that's not to say I'd be able to learn it any better than I've been able to learn Superfly. Hair room ... easy peasy to me. Dynamic clothing? Piece of cake. Superfly? Kryptonite!

Deecey posted at 6:20AM Fri, 28 June 2019 - #4355037

SatiraCapriccio posted at 7:07PM Thu, 27 June 2019 - #4355034

Has DAZ incorporated cycles in DAZ Studio? Or did they implement their own version like Smith Micro. (I don't use or follow DS, so I've no idea.)

DAZ Studio uses iRay

SatiraCapriccio posted at 8:04AM Fri, 28 June 2019 - #4355082

So, why cycles rather than iRay or another render engine?

Because DS is the one that uses iRay, Poser is the one that uses Cycles and DS is one program, Poser is another program entirely.

Please, we've gone through this one thousand times already.

Afrodite-Ohki posted at 2:05PM Fri, 28 June 2019 - #4355080

Does Physical Surface root work with Firefly? I was under the impression that it only worked with Superfly.

Yes, the PhysicalSurface Root node serves all internal render engines equally, but the content creator has to learn the proper workflow. Easy because the dotted lines will tell, you (as will the Message log that turns yellow/orange in the upper right hand corner next to the library button), what can and can not be done.

All root nodes have their limitations but the PhysicalRoot Node is easiest to learn and the most flexible one, and serves all internal render engines.

Well, I know this much.......I'm done purchasing products that have no material preview. This results in constant, unnecessary rendering just to SEE what it is you're loading onto the stage. Or the ridiculously slow Raytrace Preview open at all times.

here an example From left to right, Preview- FireFly - SuperFly

Because I have a fast CPU but a less performing GPU, the FireFly render is at production quality, and the SuperFly render is with more draft settings.

All material zones in the Construct, the figure, hair, and all clothing only use PhysicalSurface nodes. Preview - FireFly - SuperFly => The figures are simple "duplicated".