Page 6 of 8 FirstFirst ... 45678 LastLast
Results 101 to 120 of 156
  1. #101
    Member
    Join Date
    Aug 2010
    Location
    Adelaide, South Australia
    Posts
    2,667
    Originally Posted by LordOdin View Post
    Lukas Stockner has done it again.. What this feature does is it pretty much takes the dynamic BVH of the viewport and applies it to final renders. Making it so you dont have to synchronize the entire scene every frame.




    Sadly this feature is very hacky and wouldnt be accepted in to blender as it currently stands. But the potential is amazing!





    It all depends on the scene whether it is a 15x speed up or not... But it does stand that it would accelerate the BVH construction by a significant margin!

    as you said, it isnt in the right state to be accepted into blender. But. That being said, all the developers (lukas, brecht, sergey) do agree it is a useful feature, so whilst it may not be implemented in the short term, long term there is a very good chance it will.



  2. #102
    Member
    Join Date
    Oct 2012
    Location
    UK, England
    Posts
    488
    Originally Posted by Ace Dragon View Post
    The feature only works with Sobol (the UI is deceptive in this case since the scramble distance field does not get grayed out).
    Hey,

    That's wrong actually mate. Scramble does effect Correlated multi jitter as shown in this video, it's just not as obvious as with sobol.

    I actually get better results with CMJ and denoise, but if you put too low can cause the black box issue. But you hold much better highlights with CMJ in my test's than with sobol. When doing SSS test's it's easier to see how the scramble settings do change CMJ.




  3. #103
    While I am also happy about all the speedups and additions to Cycles, I want to as you all one thing.


    Please stop speaking about 10X or 15X speedups, when it's clear this is ONLY for certain cases. Like blender team telling cycles is 10X faster, while actually the motion blur became 10X less slow, or LordOdin showing a very complex static scene with low sampling, where the 15X re-render times just aren't true for practical cases. I am much more happy with a 10% speedup on benchmark scenes. This kind of rhetoric just makes this forum a unreliable source for 3d artists.



  4. #104
    Member lsscpp's Avatar
    Join Date
    May 2006
    Location
    Firenze
    Posts
    1,949
    Originally Posted by pildanovak View Post
    While I am also happy about all the speedups and additions to Cycles, I want to as you all one thing.


    Please stop speaking about 10X or 15X speedups, when it's clear this is ONLY for certain cases. Like blender team telling cycles is 10X faster, while actually the motion blur became 10X less slow, or LordOdin showing a very complex static scene with low sampling, where the 15X re-render times just aren't true for practical cases. I am much more happy with a 10% speedup on benchmark scenes. This kind of rhetoric just makes this forum a unreliable source for 3d artists.
    Well said!
    Everything's relative. Even saying "Everything's relative".



  5. #105
    All the speedup of cycles doesn't add up to diddly if you're saddled with an Intel Graphics card.



  6. #106
    Member DoubleZ_'s Avatar
    Join Date
    Mar 2013
    Location
    France
    Posts
    85
    Basically, it work the same way as using the Stereo 3D/Multiple view right ?
    Meaning Blender know it don't have to recalculate the BHV part since both views render the same 3D scene, right ?



  7. #107
    Member
    Join Date
    Mar 2016
    Location
    Vienna
    Posts
    12
    Adding to the BHV topic:
    one of the last things i miss in blender (compared to e.g. v-ray) is object based BHVs and the possibility to have proxy objects / files with pre-calculated acceleration structures. This way you can load high-res objects at runtime (trees etc.) and they don't even impact the BHV generation process. (Along with proper proxy display in viewports)

    This would be one of the last features missing (for me at least) when it comes to rendering massive environments.

    On the fly loading / unloading BHV proxys would be even more awesome.. Just to give a number - i once rendered a scene in VRay that was 60Gb in obj format (all unique geometry, no shared data), which translated to 6Gb in proxys - and it rendered without a problem on machines with 8gb.. even some slaves with 4gb could join in, as the proxys were spread quite wide, and the dynamic loading / unloading took care of not running out of memory..
    Last edited by Atair; 18-Apr-17 at 10:52.



  8. #108
    Member Ace Dragon's Avatar
    Join Date
    Feb 2006
    Location
    Wichita Kansas (USA)
    Posts
    27,792
    Originally Posted by pildanovak View Post
    While I am also happy about all the speedups and additions to Cycles, I want to as you all one thing.


    Please stop speaking about 10X or 15X speedups, when it's clear this is ONLY for certain cases. Like blender team telling cycles is 10X faster, while actually the motion blur became 10X less slow, or LordOdin showing a very complex static scene with low sampling, where the 15X re-render times just aren't true for practical cases. I am much more happy with a 10% speedup on benchmark scenes. This kind of rhetoric just makes this forum a unreliable source for 3d artists.
    Agree, I know that people are excited to see such enhancements coming to Cycles, but by no means does it give a greenlight to grossly exaggerate and ignore what these alleged mega-speedups actually do for what cases.

    The whole claim about blending noise especially, Lord Odin's video shows him increasing the time steps which gives the idea of it supposedly speeding things up significantly in the sampling department (despite the actual purpose being the creation of a far more efficient BHV for moving/deforming objects making use of motion blur).
    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



  9. #109
    Member
    Join Date
    Oct 2012
    Location
    UK, England
    Posts
    488
    Originally Posted by Atair View Post
    Adding to the BHV topic:
    one of the last things i miss in blender (compared to e.g. v-ray) is object based BHVs and the possibility to have proxy objects / files with pre-calculated acceleration structures. This way you can load high-res objects at runtime (trees etc.) and they don't even impact the BHV generation process. (Along with proper proxy display in viewports)

    This would be one of the last features missing (for me at least) when it comes to rendering massive environments.

    On the fly loading / unloading BHV proxys would be even more awesome.. Just to give a number - i once rendered a scene in VRay that was 60Gb in obj format (all unique geometry, no shared data), which translated to 6Gb in proxys - and it rendered without a problem on machines with 8gb.. even some slaves with 4gb could join in, as the proxys were spread quite wide, and the dynamic loading / unloading took care of not running out of memory..
    Yeah I asked the AMD Radeon Pro render guys as part of the Beta to add Per object BVH with i guess a similar proxy system (Not sure how vray does proxy's) that uses OpenVDB as already part of Blender, We then use it to generate Per object Distance fields with a user controllable resolution.

    Far Far faster to trace rays against distance fields for things like shadows, AO.

    Would also be much faster for dynamic BVH, Ive never understood as right now with GPU rendering why we don't use the CPU if doing nothing as a selectable option to evaluate future frames to mark objects as changed or current, If the object has changed then get the cpu to update the per object BVH before even getting to the next frame when your GPU is busy rendering the current frame. Then your next frame BVH is already created and ready to go.



  10. #110
    Originally Posted by unkerjay View Post
    All the speedup of cycles doesn't add up to diddly if you're saddled with an Intel Graphics card.
    If you are on CPU the render times will still be significantly faster :P



  11. #111
    Originally Posted by pildanovak View Post
    While I am also happy about all the speedups and additions to Cycles, I want to as you all one thing.


    Please stop speaking about 10X or 15X speedups, when it's clear this is ONLY for certain cases. Like blender team telling cycles is 10X faster, while actually the motion blur became 10X less slow, or LordOdin showing a very complex static scene with low sampling, where the 15X re-render times just aren't true for practical cases. I am much more happy with a 10% speedup on benchmark scenes. This kind of rhetoric just makes this forum a unreliable source for 3d artists.
    There is an improvement on non static scenes as well since you dont not have to synchronize from blender again. If 1 geometry object moves you will have to do another scene wide BVH rebuild but you will not have to apply all the modifiers sync all the textures or compute all the geometry tangents (Which happens to be the slowest part in a lot of our big production scenes)



  12. #112
    Originally Posted by 3DLuver View Post
    Hey,

    That's wrong actually mate. Scramble does effect Correlated multi jitter as shown in this video, it's just not as obvious as with sobol.

    I actually get better results with CMJ and denoise, but if you put too low can cause the black box issue. But you hold much better highlights with CMJ in my test's than with sobol. When doing SSS test's it's easier to see how the scramble settings do change CMJ.

    Im like 99% sure this should have 0 effect on CMJ Ill ask lukas and see what he has to say



  13. #113
    Member
    Join Date
    Oct 2012
    Location
    UK, England
    Posts
    488
    Originally Posted by LordOdin View Post
    Im like 99% sure this should have 0 effect on CMJ Ill ask lukas and see what he has to say
    The Scramble setting is separate from the blue noise dithered sobol (which i didn't even add with this test build as never found it any faster, Ill add it for testing purposes for people but even at low samples was no better than general scramble for sampler).

    Also times for me with Opencl on gpu are no different from sobol scrambled to CMJ sampled, Yet CMJ just seems to hold highlights better. Maybe it wasnt supposed to effect CMJ but as i showed it does and works. #GhostsInTheCode



  14. #114
    Originally Posted by 3DLuver View Post
    Would also be much faster for dynamic BVH, Ive never understood as right now with GPU rendering why we don't use the CPU if doing nothing as a selectable option to evaluate future frames to mark objects as changed or current, If the object has changed then get the cpu to update the per object BVH before even getting to the next frame when your GPU is busy rendering the current frame. Then your next frame BVH is already created and ready to go.
    As far as I know, there is (was?) no good way to tell if/when data is updated between frames. If I'm wrong about this, I'd like to see how.

    The previous approach used for caching the BVH (removed feature) was to just compute a hash of the data every time.



  15. #115
    Member
    Join Date
    Oct 2012
    Location
    UK, England
    Posts
    488
    Originally Posted by BeerBaron View Post
    As far as I know, there is (was?) no good way to tell if/when data is updated between frames. If I'm wrong about this, I'd like to see how.

    The previous approach used for caching the BVH (removed feature) was to just compute a hash of the data every time.
    Hey Baron,

    You could just start of in a simple approach manner. CG scene's are animated, you do the animation of position or pose, get the scene ready for what you want then you render, right.

    Well then for example with a per object bvh system you could mark objects as static or dynamic, If an object isnt doing vertex transform animation or bone etc but just changes position you could do a quick test of all objects in the scene by wrapping each per object bvh in a bounding box.

    Then it's very quick to do a bounding box check per object to compare world space position against previous frame bounding box position, things that never change position like most things in a scene don't need updates, animated bone objects can get set to dynamic permanently and re evaluate per object bvh every frame.

    As your only needing to update a few things every frame, that could be done while rendering current frame and evaluating the bounding positions of objects in the next frame before rendering it. Vertex would need some better tricks, but even the approach above would be quicker.



  16. #116
    Well then for example with a per object bvh system you could mark objects as static or dynamic, If an object isnt doing vertex transform animation or bone etc but just changes position you could do a quick test of all objects in the scene by wrapping each per object bvh in a bounding box.
    Having users mark objects static/dynamic would be a pretty bad workflow.

    On the other hand, robustly detecting whether an object should be static or dynamic is not possible (technically anything can happen between frames via script).

    I'm not saying it's impossible, but the fast solution (ignoring edge-cases) is not robust, the robust solution (looking at all the mesh data) is not fast, and the manual solution is tedious.

    By the way, Cycles does support per-object BVH to some degree, that's how instancing works.



  17. #117
    Member Mobiledeveloper's Avatar
    Join Date
    Dec 2016
    Location
    Poland
    Posts
    112
    If I understand the problem with BVH recalculation correctly then I think the easiest way to check if object move is to calculate the center point globally by adding translate x.y.z. of any object each rendering frame. When any vertex move then BVH should be calculated ??.

    public Point centroid() {
    double centroidX = 0, centroidY = 0, centroidZ = 0;
    for(Vec3D pt: points) {
    centroidX += pt.x;
    centroidY += pt.y;
    centroidZ += pt.z;
    }
    return new Vec3D(globalX +centroidX / points.size(), globalY +centroidY / points.size(), globalZ +centroidZ / points.size());
    }

    then the bhv will be calculated only for moving objects. I don't know how bhv is calculated, but center point calculation should be fast .
    Last edited by Mobiledeveloper; 19-Apr-17 at 10:37.
    I am learning English so sorry for any mistakes.
    my animations: https://www.youtube.com/channel/UCbV...Y9ExjzjaIprrAA
    my addon: https://blenderartists.org/forum/sho...-or-virtualdub



  18. #118
    Originally Posted by Mobiledeveloper View Post
    I think the easiest way to check if object move is to calculate the center point of any object each rendering frame. When any vertex move then bhv should be calculated ??.
    This method is not robust: Imagine a box rotated by 90 degrees. The centroid will not change.

    It's even simpler to just feed the vertex data into a suitable hash function, then comparing hashes. That's how it was done before, for BVH caching (a feature that has been removed).

    In either case, you have to look at all the vertex data, for every mesh, for every frame - which is not optimal. To be fair though, that overhead should be acceptable.



  19. #119
    Member Mobiledeveloper's Avatar
    Join Date
    Dec 2016
    Location
    Poland
    Posts
    112
    Originally Posted by BeerBaron View Post
    This method is not robust: Imagine a box rotated by 90 degrees. The centroid will not change.

    It's even simpler to just feed the vertex data into a suitable hash function, then comparing hashes. That's how it was done before, for BVH caching (a feature that has been removed).

    In either case, you have to look at all the vertex data, for every mesh, for every frame - which is not optimal. To be fair though, that overhead should be acceptable.
    You are right.

    Anyway, it could be great if the static scene could be calculated faster. For example, I have rendered simple camera animation around the sheep standing on the grass. The building BVH process and other synchronizations take almost 48 seconds while the whole frame time was approximately 1:30 (AO = 1 bounces. I don't know what blender is calculating beside BHV and how long takes each process but any algorithm that could trace objects movement will be faster than this useless calculation of BVH for the static objects :/.

    I hope the Blender will have such a functionality in the future. then rendering simple animations for youtube could be much faster .
    I am learning English so sorry for any mistakes.
    my animations: https://www.youtube.com/channel/UCbV...Y9ExjzjaIprrAA
    my addon: https://blenderartists.org/forum/sho...-or-virtualdub



  20. #120
    Member
    Join Date
    Sep 2012
    Posts
    2,372
    In such cases user marks can be extremely helpful... in a way, UE4 uses it for actor's shadow/light properties.



Page 6 of 8 FirstFirst ... 45678 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
  •