Does anyone use Reality 4 for Poser?



  • @h-elwood-gilliland That walk reminds me of this:
    0_1547869517676_keep-on-truckin.jpg



  • @h-elwood-gilliland said in Does anyone use Reality 4 for Poser?:

    Today in the lab... (Something I did today to test some adjustments to the path feature)

    Something I've suggested before over the years. Poser should have pre-defined paths in it's library. They should have control points so you can change their shape and layout. and be scalable, at least along the x and y axis.



  • @h-elwood-gilliland this looks like preparation for stair ascent and descent. All that's missing is an animation layer to add a constant bend to the feet, and you could be descending a flight of stairs.
    0_1547876336583_Andy2 Back Flip_0001.gif



  • Having luxrender compatibility would be cool. It is IMHO better than superfly, marginally. But don't have it have it replace superfly. It takes too long for most people. And better support for dynamic hair would be needed. That's a big reason why I don't use luxrender more. Both posetolux and reality support it, but it's in such a matter that it's guaranteed to crash my computer. I don't have a top of the line machine, but it can't be that bad if I can render 40 people in other render engines.


  • Poser Ambassadors

    I have Reality 4. I like Lux' resume feature, allowing one to resume rendering if the halt condition was set too low.
    I also like the ability to spread a render over a network, with all available computers contributing samples to the render.
    I don't know how to manipulate materials for Lux as I can for Superfly, though, and that's a critical issue for me.

    I'd like to have those two features (resume render button, and networked rendering of a singleton) added to Superfly.


  • Poser Ambassadors

    I really don't think that Luxrender is the way to go for Poser. No need to add more features like that.



  • @ghostman said in Does anyone use Reality 4 for Poser?:

    I really don't think that Luxrender is the way to go for Poser. No need to add more features like that.

    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!



  • @amethystpendant said in Does anyone use Reality 4 for Poser?:

    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.


  • Poser Ambassadors

    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".

    Conclusion :
    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


  • Poser Ambassadors

    Oeps, forgot.

    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.



  • 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.



  • 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.


  • Poser Ambassadors

    @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.
    https://render.otoy.com/forum/viewtopic.php?f=7&t=66014



  • @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:
    nodeInput "Diffuse_Color"
    {
    name "Diffuse_Color"
    value 1 1 1
    parmR NO_PARM
    parmG NO_PARM
    parmB NO_PARM
    node "Blender"
    file NO_MAP
    }
    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.