Page 5 of 10 FirstFirst ... 34567 ... LastLast
Results 81 to 100 of 183
  1. #81
    Member Ace Dragon's Avatar
    Join Date
    Feb 2006
    Location
    Wichita Kansas (USA)
    Posts
    28,235
    Originally Posted by PixelPete View Post
    Both these features are superuseful for creating gameart. Agreed 100% with what Romanji wrote.
    I personally can see the use for offline rendering as well (not every object bevels well depending on topology, especially after boolean operations). The shader would also work for bevels between objects using subsurf or micropoly displacement.

    Brecht also mentioned that optimization could perhaps be done from how the length of the rays traced would be known depending on the bevel width, so the final performance penalty may be significantly lower than what it is today.
    Sweet Dragon dreams, lovely Dragon kisses, gorgeous Dragon hugs. How sweet would life be to romp with Dragons, teasing you with their fire and you being in their games, perhaps they can even turn you into one as well.
    Adventures in Cycles; My official sketchbook



  2. #82
    Member Fatesailor's Avatar
    Join Date
    Jun 2003
    Location
    Greece
    Posts
    407
    DcVertice... my post was not a complaint. It was a criticism with quite constructive aim. It was a suggestion for improvement. It would be much better to have such a node much more fast -and better results producing- than the osl script. It would be good to have all the options the osl script has plus some more options too, as, for example, an option for applying the bevel in corners according their degrees. Why not? And, at least... why not sharing such ideas? : - )

    If I knew how to contact the developers directly I would show to them too the differences with the image I put here. It is nothing to be offended... it is just an exchange of thoughts aiming at improvement.



  3. #83
    Member
    Join Date
    Apr 2015
    Location
    Munich Germany
    Posts
    253
    Originally Posted by Ace Dragon View Post
    I personally can see the use for offline rendering as well (not every object bevels well depending on topology, especially after boolean operations). The shader would also work for bevels between objects using subsurf or micropoly displacement.

    Brecht also mentioned that optimization could perhaps be done from how the length of the rays traced would be known depending on the bevel width, so the final performance penalty may be significantly lower than what it is today.
    I see your point, however I believe that solutions like this , once they become better, easy to use and standard part of modeling will make the bevel shader become obsolete for offline rendering purposes, donīt you think? Correctly modeled bevels are definately the superior alternative to an approximation via any sort of shader when it comes to pretty renders.

    I read their discussion and am intrigued by the idea for an option to decide which edges get beveled by the shader based on sharpness properties. However even that -I find- would be somewhat of a waste of the devs time, again because of the same "auto-beveling tools" argument above.

    What we got in yesterdays build is working perfectly fine for a very specific gameart related workflow:
    -Create clean hard surface mesh through basic modeling techniques with use of boolean operations without ever having to worry about beveling and being able to live preview the bevel shaders results in cycles.
    -then bake the beveling from the shader onto the final low poly mesh and voila! Done! Perfect!
    As long as we are polymodeling this is likely going to be the fastest workflow imaginable for this kind of thing. Even if the auto-bevel tools become super sophisticated, fast and easy, it wonīt beat the "one-click-wonder"-nature of activating the bevel shader.

    It just would be a shame if something that is actually really useful and needed right now were cut or postponed because of considerations related to plans that might turn out to be or not to be a waste of time. :/



  4. #84
    Member cgstrive's Avatar
    Join Date
    Aug 2014
    Location
    Estonia
    Posts
    607
    One more test scene: http://cgstrive.com/blend/bazooka1.blend

    Issues identified:
    issues_identified.jpg

    Notes:
    a) Using yesterdays build.
    b) The data of base meshes is minimalistic and complex forms are derived by using modifiers (e.g screw, some booleans). As such black glitches are not issue of "corrupt" modeling, but should render correctly. (@DCVertice)

    Edit: I saw there was some discussion regarding *True* pointiness and AO. Would be really useful to detect cavities and sharp edges for edge wear, dust and all sort of texturing control that we see in modern texturing apps (SP, SD, Quixel). Perhaps developers could give it some thought.
    pointiness_ao.png

    Edit2(to avoid spam): If Curvature in general could be detected(even for LOWPOLY) and pre-Cached, a lot of these effects could potentially be derived from that(e.g Edge wear, dust in cavities, Bevel/Round corners?***): https://forum.unity3d.com/attachment...ipe-jpg.47313/
    Last edited by cgstrive; 22-Aug-17 at 04:46. Reason: Trying not to spam the thread



  5. #85
    Originally Posted by Fatesailor View Post
    DcVertice... my post was not a complaint. It was a criticism with quite constructive aim. It was a suggestion for improvement. It would be much better to have such a node much more fast -and better results producing- than the osl script. It would be good to have all the options the osl script has plus some more options too, as, for example, an option for applying the bevel in corners according their degrees. Why not? And, at least... why not sharing such ideas? : - )

    If I knew how to contact the developers directly I would show to them too the differences with the image I put here. It is nothing to be offended... it is just an exchange of thoughts aiming at improvement.
    I think that after years waiting this tool the first to tell is not it's worst than OSL. Also that it isn't true if you tried the shader five minutes to compare. I have made a lot of test and the result are always favorable to the bevel shader. For example, in speed in render in my last test the results was.

    23s for base render
    97s for bevel shader
    72s last bevel shader
    142s for OSL shader.

    And with GPU the render ends in 30% less time. THe same happens in all the test that I made. The OSL shaders needs double time or more to the same that bevel shader. And if we talk about bake the difference is bigger, from 10 seconds of bevel shader with 50 samples to 2 minutes in the OSL with 4 samples. Also

    - The shader works with intersect. You can see in our tests.
    - The dark contour is the normal behaviour in the OSL shader with same parameters.
    - OSL shader cannot do the concave parts correctly and create a incorrect normals and create a AO effect. Making dark lines. It doesn't happens in the bevel shader
    - OSL shader make incorrect normals, making clear edges in all edges and specially in the corners where the normal don't work correctly.



  6. #86
    @cgstrive
    I think that your mesh is corrupt in some way. Because I tried to collapse and redo that part with fill and blender crashed.

    The displacement temporaly you must add the bump to the normal.

    Brecht upload some fixed this night. But the actual windows build is broken in a lot of parts. I will try in OSX this afternoon
    Last edited by DcVertice; 22-Aug-17 at 03:55.



  7. #87
    Member Fatesailor's Avatar
    Join Date
    Jun 2003
    Location
    Greece
    Posts
    407
    DcVertice... be sure that I gave much more than five minutes to test the new bevel node. It is true that I did not use gpu but in cpu the results were much better with the osl (in rendering times too). But, anyway, I would like to see visual examples of your tests and your node settings (with the use of both the new node and the osl script)... argumenting by words only, in such matters, is usually vain. : - )



  8. #88
    Originally Posted by Fatesailor View Post
    DcVertice... be sure that I gave much more than five minutes to test the new bevel node. It is true that I did not use gpu but in cpu the results were much better with the osl (in rendering times too). But, anyway, I would like to see visual examples of your tests and your node settings (with the use of both the new node and the osl script)... argumenting by words only, in such matters, is usually vain. : - )
    THe node settings are simple, same radius visualy, same samples in a principled shader.

    Bad normals
    Edges.jpg

    Dark lines in intersect
    AO.jpg

    I'm not comparing with GPU and last bevel shader, that only needs 13 seconds to make the same render. 13 vs 28, the difference is obvious.



  9. #89
    Just to note something about the new Brecht's bevel shader - is it bevelling all edges, or does it have some limiting function?
    I think maybe big part of the performance hit could be the fact it's bevelling all edges?



  10. #90
    Originally Posted by pildanovak View Post
    Just to note something about the new Brecht's bevel shader - is it bevelling all edges, or does it have some limiting function?
    I think maybe big part of the performance hit could be the fact it's bevelling all edges?
    Affect all surface.



  11. #91
    Member cgstrive's Avatar
    Join Date
    Aug 2014
    Location
    Estonia
    Posts
    607
    Upon further thought about these errors.

    1) One of them seems to be caused by INVISIBLE object(used as boolean cutter) being taken into consideration when raytracing.
    bevel_update.png

    Also as seen in post #66 there's some weird horizontal Bevel line on his chest: https://blenderartists.org/forum/att...326642&thumb=1 - This can only be caused by Invisible object that I have in the scene (boolean cutter).

    If that is the case then Shader still works amazingly, but Objects that are invisible should be excluded when calculating/raytracing normal of the bevel.



    2) Very simple object with SCREW modifier causes such black render. Interestingly if I apply ROTATION only then it renders as expected. Seems related to obj transformations not being properly considered with.
    screw_issue.png

    PS. I know It's very early for most of these issues. My goal is to identify any problems and offer test scenes for everything to be as good as possible and waterproof.
    Last edited by cgstrive; 22-Aug-17 at 08:38.



  12. #92
    Member YAFU's Avatar
    Join Date
    Mar 2013
    Posts
    2,870
    When things depend on transformations, it is a pain for the user/artist (at least for me )
    Here Luca was able to correct that for Surface Deform modifier:
    https://blenderartists.org/forum/sho...=1#post3161208

    And according to him, it would also be possible to correct it in other modifiers. I am not sure if here it would be possible in this case to make the calculations taking into account object transformations.
    Last edited by YAFU; 22-Aug-17 at 09:32.
    Be patient, English is not my language.



  13. #93
    Originally Posted by cgstrive View Post
    Results posted are very impressive! Eager to try.

    I am attempting to make a fresh build with problematic result. Latest files pulled 3x, everything by instructions, vc12 64.

    BGE module enabled:
    Attachment 495588
    note: make full nobg - builds fine
    can't seem to repro with the latest version of the diff, brecht probably fixed it in the meantime.

    Originally Posted by cgstrive View Post
    Patch applied, with Cycles GPU fails:
    Attachment 495587

    Until this point I have been making builds every few days with "make release"(vc 12, 64) without a single issue. I am at my wits end. Can anyone knowledgeable please comment on this matter?
    both cuda 7.5 and 8 have this bug on sm_2x , nvcc just randomly fails, the only thing you can do is just rebuild and hope it goes through, sometimes takes me a few tries. Was hoping for a fix in cuda 9, but they just dropped sm_2x support and called it a day..



  14. #94
    With the last fix we have the bake and "panels" back.

    I could make windows builds, but the part of VS give me some problems and I don't know how to solve.
    Last edited by DcVertice; 22-Aug-17 at 12:14.



  15. #95
    Member
    Join Date
    Oct 2012
    Location
    UK, England
    Posts
    538
    Hey People, Ive done a windows build with the Bevel shader Mixed with a modfied version to current master of the old Lukas Micro jitter scramble and also just for extra the CPU adaptive sampling patch. Give it a go and see whats what, The scramble gives good speed ups for the Bevel shader too.

    No micro jitter Opencl GPU, Render samples 756: Bevel shader 128 samples:3 mins 29 secs
    Bevel_128samples.jpg

    micro jitter Opencl GPU, Render samples 756: Bevel shader 128 samples: 3 mins 02 secs
    Bevel_Microjitter_128samples.jpg

    Example file: BevelShaderTest1.blend

    Test Build Win x64 Bevel shader:
    https://mega.nz/#!05pXHDab!wTtFMbUuB...XmjeZmA-8IbP_E
    Last edited by 3DLuver; 22-Aug-17 at 15:44.



  16. #96
    Member cgstrive's Avatar
    Join Date
    Aug 2014
    Location
    Estonia
    Posts
    607
    Originally Posted by LazyDodo View Post
    can't seem to repro with the latest version of the diff, brecht probably fixed it in the meantime.
    Thank you for looking into it. I still get ISSUES with BGE, it must be something simple.


    Thank you for new build 3DLuver!

    The problem with BLACK geometry is FIXED:



    Only two remaining issues are:
    a) Objects marked invisible are used for bevel calculation causing a glitch (horizontal line on Benders chest, dark glitches on Bazooka)
    b) Optional: Stacking multiple bumps/displacements is needlessly hard and artistically error prone. Subjectively think that displace slot should stack implicitly or there should be NML combine blending mode (as in Substance). That is not related to Bevel shader though.


    bazooka_issues.png

    Scene file: http://cgstrive.com/blend/bazooka2.blend
    Last edited by cgstrive; 23-Aug-17 at 02:02.



  17. #97
    Just wanted to say, if you are reading this brecht, this is VERY appreciated. Thank you.
    Paul's Law: You can't fall off the floor.



  18. #98
    Member YAFU's Avatar
    Join Date
    Mar 2013
    Posts
    2,870
    @cgstrive, I'm not sure if Brecht is visiting this thread. Since a lot of users have already participated in the patch thread, I think you are one of the most indicated to comment there. I have seen how important you have been as a tester in other projects like Alembic project.
    https://developer.blender.org/D2803
    Be patient, English is not my language.



  19. #99
    Member cgstrive's Avatar
    Join Date
    Aug 2014
    Location
    Estonia
    Posts
    607
    Originally Posted by YAFU View Post
    @cgstrive, I'm not sure if Brecht is visiting this thread. Since a lot of users have already participated in the patch thread, I think you are one of the most indicated to comment there. I have seen how important you have been as a tester in other projects like Alembic project.
    https://developer.blender.org/D2803
    Thank You. You are most likely right, posted there.



  20. #100
    Member
    Join Date
    Jul 2016
    Location
    Poland
    Posts
    66
    This is looking really promising, thank you Brecht for the time and effort.

    I see that there is a Radius input in the Bevel node. Would it be possible to somehow get the Edge Crease Value of the mesh into a node, and use it to drive the Radius of the Bevel? Oh, the possibilities.
    env artist @ CDPR | artstation



Page 5 of 10 FirstFirst ... 34567 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •