EZDome - a new Skydome/Environment Sphere from SnarlyGribbly



  • @ghostship So where does this end ghost? I create a commercial material that consists of a few basic nodes in well used configurations, so now nobody can share that information because I was the first to do it commercially? How few nodes would you still respect? As far as I'm concerned, the fact that this person was the first to sell a product using the nodes in a particular way BUT ADDING NO UNIQUE CONTENT TO IT does not give him/her legal or moral ownership over it. I appreciate that you could make a case that nodes were like music notes, or letters of the alphabet, and it's the configuration of these nodes that counts, but by that token, all I had to do was change the actual value in half a dozen of the nodes and nobody here would have had an ethical leg to stand on AND legally, it would have counted as a transformative work.


  • Poser Ambassadors

    Why are we talking about the Snow Machine and snow shaders anyway? Some people seem to derail threads for a pasttime ...



  • @Snarlygribbly Well, I didn't derail it on purpose. I just asked a simple question about one of your products in a thread where I knew you would most likely see it.



  • @eclark1849

    Poser 11: Layers and Render Queues. Check this youtube video by Renderosity.



  • @Snarlygribbly Having GPU rendering issues with shader setup in EZDome. See this thread:

    https://forum.smithmicro.com/topic/1070/what-is-missing-in-gpu-renders?page=1



  • just so it's hear: The materials interact strangely with GPU rendering. When I remove everything but the image plugged into amb the GPU render looks like the CPU render.

    0_1482983777711_Render CPU v GPU.jpg



  • Gain node seems to be broken or work very different in GPU (at least in this particular combination). Without Gain = HSV output to Ambient input
    0_1483001356794_ezdome test 2.png


  • Poser Ambassadors

    Guys, I'm following this thread and (and the other related one) with interest.
    My difficulty is that I have no access to GPU rendering on my antiquated system - I can only test CPU rendering.
    I work on the basis that GPU rendering should be similar, if not identical, to CPU results unless Poser gives a warning message in the log.
    So, this sounds to me like a bug in Poser that needs fixing.
    However, if there is a change to the shader that you can recommend which will work for both Firefly and Superfly and solve this problem then I'll happily make some experimental versions of EZDome incorporating it so that you can test it for me with your fancy GPUs :)



  • @Snarlygribbly I think it's a bug and needs to be reported to the Poser team but I will look into it a little further.



  • I would be curious to know if these differences are also present in Cycles with CPU versus GPU.

    I am not saying that they do, but if they do it may be a larger issue.



  • As far as I know, Cycles does not have Gain Node/mode of Math/Blend node. So the question is in what nodetree SF compile problematic nodetree. Like now we can't check - no information what to check. When I assign "cosher" SF/Cycles shaders to EzDome all is right. (Outer emission for all rays except Camera, holdout for camera, inverse for Inner.)



  • I looked into this again today after about a month of just using @bagginsbill Envirosphere for simplicity. It seems that one or more of the nodes used in the materials for EZDome is not recognizing the extra data from HDR images. The result is flat color all around just as if I used a JPG image plugged into the outer dome instead of an HDR. I checked this by plugging in the jpg versions that came with the hdr sets. Results were the same (rendered with GPU.) To be clear, this only happens when rendering with GPU and folks that only have CPU rendering capabilities should not worry.

    To get around this limitation I plug the HDR image directly into the ambient on the Poser root and the image renders out just fine with more contrast because of the HDR image.



  • @ghostship said in EZDome - a new Skydome/Environment Sphere from SnarlyGribbly:

    I looked into this again today after about a month of just using @bagginsbill Envirosphere for simplicity. It seems that one or more of the nodes used in the materials for EZDome is not recognizing the extra data from HDR images. The result is flat color all around just as if I used a JPG image plugged into the outer dome instead of an HDR. I checked this by plugging in the jpg versions that came with the hdr sets. Results were the same (rendered with GPU.) To be clear, this only happens when rendering with GPU and folks that only have CPU rendering capabilities should not worry.

    To get around this limitation I plug the HDR image directly into the ambient on the Poser root and the image renders out just fine with more contrast because of the HDR image.

    I've just started using EZdome, but is this the reason why I have to bump up my indoor lighting values and pixel samples to double what it was before I added the dome? I haven't tried using the cpu for SF rendering in a long time because my is horrible at it, but I could give it a try I guess and see what happens.


  • Poser Ambassadors

    Snarly and I don't have GPU so can't answer. It sounds like the Gain function was incorrectly built for SF in GPU.

    When Gain is set to .5, it's neutral like f(x) = x anyway, so unless you're actually trying to apply the gain value other than .5, you don't need it.

    Do what ghostship said, or rewire around that node and you can still keep using all the other features of the shader.



  • @bagginsbill Sure thing. If I rewire around the node, do I have to do that for both the inner and outter domes?



  • @johndoe641 I don't but if you use the EZDome Script on the dome again it re-sets all materials. I just mess with the outer ambiance setting and leave the inner dome unless it's too dark compared to the light I'm getting on the figure.


  • Poser Ambassadors

    Hi folks,

    As Bagginsbill has pointed out, I am unable to test on a GPU and have also had no luck in eliciting someone willing to work with me to fix this (although I am very grateful for the posts here highlighting issues with EZDome).

    So, I've decided to put EZDome in the public domain.
    The source code is available on the EZDome support webpage, here: [http://snarlygribbly.org/snarlyspace/ezdome.html](link url)

    Feel free to modify it to do whatever you want it to do :)
    It's now yours, not mine :)

    And if you do make a better version, I'd be happy to host it on the EZDome webpage.

    Have fun!
    Snarly



  • WOW, thanks @Snarlygribbly I love looking through your code, if only to snaffle some of your brilliant ideas! I too cannot use GPU for rendering so can't help with this specific issue

    Amanda


  • Poser Ambassadors

    @Snarlygribbly Thank you :)



  • Actual first time use of EZ Dome script. At this point I have no idea whether I've used it correctly or not. I have been impressed with what I've seen from others, so this was a bit of a let down.
    0_1488281114558_surf2.png