Does anyone use Reality 4 for Poser?
Miss B last edited by
And lose the last 2 years of learning cycles/superfly no way. Please listen to your users, we want better cycles not a totally new, probably badly implemented, render engine. If you want to modularise rather than embed cycles, great, but please, please, please don't drop superfly for lux!
I agree whole heartedly. It's taken a number of years for me to get used to working with SuperFly, and now that I'm comfortable with it, I don't want to lose it.
Here is my contribution to this very useful tread.
How many cars do you need?
Because you can only drive with one at the time so better choose a proven render engine and increase its performance.
Bring SuperFly up to full cycles specs, (including AMD support) , include the Principled BSDF, and their new hair shader and make it work on a much improved hair room.
For the hair room?
We absolutely need a symmetry function, scissors, and better styling tools.. (and a work around for bug 35615...….) (extra prop, obj file split at ave, you know.)
More important however is to increase the quality of the current Poser Preview render engine so why not upgrade to Eevee at the same time and get a proper real time preview render engine that we know works best with Cycles.
We don't always need "more", but most would agree we need "better".
Bring SuperFly up to full Cycles specs, and replace the current preview render engine with Eevee.
The Population of the Universe will be thankful.
Best regards, Tony
We need something to render, so we need a new Poser family.
Husband, wife, 2 kids, some pets, Most current content and shader setups are dusty.
amethystpendant last edited by amethystpendant
Don't let this become a what do we want thread. It should be a we don;t want a new render engine, we want the one we have improved. The whole Lux idea needs quashing now, Cycles, proper Cycles implementation is what we need / want. Lets not get side tracked about path examples or anything else, the reason for this post was to see if we would accept Lux as a replacement for Cycles / Superfly. We don't @h-elwood-gilliland, forget it.
fverbaas last edited by fverbaas
The question, as I read it, was not about dumping Superfly but aimed at looking how we can get rid of an implementation of a render engine that lags behind its origin more and more every day without copying in all the changes into the code now into Poser.
If we could seamlessly call the up-to-date version of Cycles the way we now call Firefly or Superfly that would release the dev team of running to keep up and free time for core developments.
I guess same would hold for specialist tasks on the incoming/processing side. I made MDBridge for Poser to get past the shortfalls of the de-facto legacy ClothRoom. (Yes I know the price issue. Thank you.) Since I made it MD moved on since quite swiftly, but the Bridge works just the same. It could be more smooth if the Poser API would work as documented and support FBX and Alembic formats.
I bring this forward to arrave at the question about feasibility of Python scripts spitting out data other renderers can read. I have not endeavoured in the direction of writing shaders. I have no clue about that, but I think the answer is the same as for the garment interfacing exercise I did: it all depends on the reliability and completeness of the API. In my project I lost most time with finding workarounds for failures. Cooperation is fine if API is clear, well defined and rock-stable.
@h-elwood-gilliland No, but I did experiment with the Octane renderengine plugin for Poser.
And results from that are insanely impressive!
A final render in 10 minutes without grain! And I render with a GTX 1070, not very new card nor the best.
A free version will be released in Q1 if I understood it correctly.
richard60 last edited by
@h-elwood-gilliland To start I have not used any other render engine except what's built into Poser. Given that if you were to make the interface between Poser and an external standalone Render Engine a snap to bring in whichever Renderer we wish to use that would be great. Doing a quick check of render engines most seem to have a standalone version. The three that stand out to me at this time (since they are free and open) would be Cycles, Lux and the AMD render-pro.
The only issue that I can see is converting the Material Room interface to adapt to the different renderers. However given the structure of a Node in Poser it should be no problem as each input appears to be in a fixed format of:
value 1 1 1
Although to be fair I don't know what the structure is that each of the other render engines requires. Given that they are math engines the structure should be fairly fixed so setting up a two way lookup conversion table should be problem. Although if more of the render engines start to use Open Shading Langange it maynot be that big an issue.
If you could also add in the User Node that allows for Python Coding of a Node that would be icing on the cake as it would allow the user to create whatever math they need without be stuck to a predefined list.