[Bf-committers] Embree library update to 3.8.0

[Stefan Werner]

Hello platform maintainers,

I updated the Embree version for `make deps` and install_deps.sh to 3.8.0.
Please update the binaries when you get a chance.

Currently, there is no code in Blender that requires this new version yet. Once 
updated binaries for all the platforms are available, I will check in features 
that require the newer Embree library (D6575).

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] SSE/AVX in cloth simulator

[Stefan Werner]

> On 19. Dec 2019, at 13:55, Mariusz Pluciński  
> wrote:
> 
> 2. I tried explicitly enabling auto vectorization in GCC, but it didn't
> change much. Is that normal? If not, which flags should be used?

Auto vectorization is hit and miss - it can help in straightforward cases, but 
compilers can’t always automatically find the best code paths. 

> 3. If there's no other way, I may be ready to try to rewrite critical parts
> of the simulator for SSE/AVX. In such case, could you give me a guideline
> on how to do it correctly (with ultimate merge into master in mind)?

The important parts IMHO are:
* leave the scalar part intact for non-x86 architectures such as ARM
* profile first, optimize second. Make sure that you understand what the 
bottleneck is before jumping the conclusions. SIMD helps when compute is the 
bottleneck, b it won’t do much if branch mispredictions or cache misses are the 
performance limiters.

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8x - support and core development goals

[Stefan Werner]

I have a bunch of patches in and outside the tracker that I’d like to prepare 
for inclusion, such as:

* OpenImageDenoise compositor node
* Adaptive Sampling for Cycles
* Tiled Texture Cache for Cycles
* Various sampling improvements for Cycles

I hope to also get a few half-finished features ready for prime time:
* light BVH (GSOC 2018)
* OpenVDB import

If time permits, I would also like to dive deeper into the volume rendering 
code in Cycles, there is lots of room for improvement in my opinion. Sparse 
voxel representations (another GSCO 2018 project that hasn’t gotten merged) and 
tracking based integrators look promising.

-Stefan

> On 26. Jul 2019, at 08:00, Dalai Felinto  wrote:
> 
> Dear developers,
> 
> Which areas would you like to focus on in the next few months? Which
> code improvements, performance, stability, new features in those areas
> would you work on first [1]?
> 
> Finally which bigger new features are you confident would make it in
> the 2.81 release, and which are the ones that might happen? These are
> particularly important so we can allocate more time for code review
> early in the release cycle and work together to assess their
> feasibility.
> 
> That should empower us to set priorities and keep our ongoing
> development on track. The original goal of a more strict 2-3 month
> release cycle is still on the table, and it is up to us to set dates
> the deliverables. As long as we are working in the right priorities,
> and strive for quality, which specific features land in 2.81 are
> secondary.
> 
> I'm away for Siggraph (28-1) so there is no need to rush to reply to this.
> 
> [1] - Please update the module page to reflect this -
> https://wiki.blender.org/wiki/Modules /
> https://developer.blender.org/T63725
> 
> Best regards,
> Dalai
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC mentors needed!

[Stefan Werner]

Hi Ton,

I’ll be happy to help out.

-Stefan

> On 19. Mar 2019, at 11:36, Ton Roosendaal  wrote:
> 
> Hi,
> 
> Anyone with past commits or contributions to Blender's source is welcome to 
> sign up as a mentor for the Google Summer of Code. Contact me (in person) if 
> you are interested.
> 
> Thanks,
> 
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> 
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Help to get started

[Stefan Werner]

Then there’s also the quick hack list:
https://developer.blender.org/tag/quick_hacks/

> On 25. Aug 2018, at 07:56, Stefan Werner  wrote:
> 
> Hello David,
> 
> have you seen this?
> https://wiki.blender.org/wiki/Developer_Intro/Advice#Pick_a_Project 
> <https://wiki.blender.org/wiki/Developer_Intro/Advice#Pick_a_Project>
> 
> I suggest picking a bug from the tracker:
> https://developer.blender.org/maniphest/project/2/type/Bug/ 
> <https://developer.blender.org/maniphest/project/2/type/Bug/>
> 
> -Stefan
> 
>> On 24. Aug 2018, at 07:08, David De Anda > <mailto:omarandst...@gmail.com>> wrote:
>> 
>> Hi everyone,
>> 
>> My name is David De Anda, I’m new here and I’m trying to get started 
>> developing blender, I had some experience in the past playing around with 
>> OpenGL with C++ and Objective C developing small game, but I don't really 
>> have too much experience with projects as big as this. So I was wondering if 
>> you could help me pointing out some first exercise that I could do to start 
>> understanding the code, I had read some of the documentation and already got 
>> the project compiled with cmake.
>> 
>> Thanks in advance.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org <mailto:Bf-committers@blender.org>
>> https://lists.blender.org/mailman/listinfo/bf-committers
> 

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Help to get started

[Stefan Werner]

Hello David,

have you seen this?
https://wiki.blender.org/wiki/Developer_Intro/Advice#Pick_a_Project 


I suggest picking a bug from the tracker:
https://developer.blender.org/maniphest/project/2/type/Bug/ 


-Stefan

> On 24. Aug 2018, at 07:08, David De Anda  wrote:
> 
> Hi everyone,
> 
> My name is David De Anda, I’m new here and I’m trying to get started 
> developing blender, I had some experience in the past playing around with 
> OpenGL with C++ and Objective C developing small game, but I don't really 
> have too much experience with projects as big as this. So I was wondering if 
> you could help me pointing out some first exercise that I could do to start 
> understanding the code, I had read some of the documentation and already got 
> the project compiled with cmake.
> 
> Thanks in advance.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Library updates for Blender 2.8

[Stefan Werner]

While not directly applicable to Blender, would it be any trouble to include 
oiiotool.exe in the Windows binaries? There was just someone asking for 
binaries on the oiio mailing list:
http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html
 


-Stefan

> On 23. Jul 2018, at 21:53, Ray Molenkamp  wrote:
> 
> There's quite a few libraries we build for the various platforms
> (57 by the last count) and it's not always clear who the module
> owner is and who is supposed to ask for newer versions of certain
> libs. 
> 
> I took a quick survey of the versions we use and the latest versions
> available. (based on build_files\build_environment\cmake\versions.cmake)
> 
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0=true
> 
> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )
> 
> There are several libs with known CVE's, personally I would prefer
> to upgrade those to the latest versions (most seem low risk upgrades)
> but for everything else I really have no strong opinion.
> 
> Any module owner that wants edit rights, please poke me (email/irc) and
> I'll get you an editable link.
> 
> --Ray
> 
> 
> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
>> Hi all,
>> 
>> It's been a while since we updated libraries, and with the upgrade to
>> Visual Studio 2017 this has now become easier on Windows as well. Since the
>> platform maintainers have time now to do updates, let's try to get this in
>> motion.
>> 
>> Some of the latest library versions need C++11, I also propose we require
>> C++11 in master. This mostly involves removing the WITH_CXX1 option and
>> code cleanups for STL data types compatibility.
>> 
>> For libraries, these are the ones I know of. Let us know if any other
>> library updates are needed.
>> 
>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
>> https://developer.blender.org/D3398
>> https://developer.blender.org/D2915
>> 
>> * OpenVDB 5.1.0: so we can read files written by other applications that
>> have OpenVDB 5.x.
>> 
>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
>> bugfixes?)
>> 
>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, the
>> revision needed is not known (or doesn't exist) yet.
>> 
>> Thanks,
>> Brecht.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Apple deprecates OpenGL and OpenCL

[Stefan Werner]

> On 5. Jun 2018, at 11:01, Ton Roosendaal  wrote:
> I'm afraid a Metal port is going to be more than a couple of months... but 
> the benefit of open source has always been that you get surprising ports to 
> happen!

Odds are that someone, somewhere is using Blender to build their iOS games and 
has both the experience and the need to port Blender to Metal. I’m keeping my 
fingers crossed...

> My opinion: MacOS has not been a good choice for 3D artists for at least 5 
> years already. Artists didn't have choice of GPUs. Support for CUDA, OpenGL 
> and OpenCL was always behind. We never really had Cycles GPU render perform 
> good on a Mac system either.

Out of the three, CUDA was the one in best shape, because it didn’t rely on 
Apple.

> Looks like Apple is heading in a different direction with their OS. Probably 
> merging it with iOS…

We could port Blender to the iPad Pro, once we find out where tablets have 
their right mouse button. ;)
> 
> Meanwhile we can keep supporting it, but this support will then be for a 
> dying platform - like back then for SGI Irix, Sun Solaris and BeOS.

Hey! In contrast to macOS, there is at least active development for OpenGL on 
Haiku (= OpenBeOS)!

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Apple deprecates OpenGL and OpenCL

[Stefan Werner]

Apple is deprecating OpenGL and OpenCL and asks developers to use Metal instead.
Does anyone have a couple of months to spare to port Eevee and Cycles?

https://developer.apple.com/macos/whats-new/#deprecationofopenglandopencl

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Efficient generic data structures for Blender?

[Stefan Werner]

> On 8. May 2018, at 13:32, Christian Hubert  
> wrote:
> 
> * Compared performance of std::map vs. .Net dictionaries : .Net is
> about 100x faster than std (the test populates the structure of 100
> integers ; 50ms for .Net vs. 5s for std, both in debug mode)

The numbers you get from a debug build or from running in a debugger are 
meaningless. For example, Microsoft’s CRT runtime injects lots of bounds and 
heap checking any time you run code in the Visual Studio debugger, which can be 
a dramatic slowdown even for the most optimised Release builds. Compilers and 
debuggers can have all kinds of performance-killing behaviour when debugging.

Also, synthetic tests aren’t giving too much information. Your benchmark tested 
insertion time, where one typically uses a std::map when one cares about fast 
lookups.

-Stefan

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2018 BVH8

[Stefan Werner]

> On 29. Jan 2018, at 21:10, Sergey Sharybin  wrote:
> 
>> 4. Extract BVH data from Embree and write GPU traversal code.
> 
> To my knowledge you can provide Embree a custom node/primitive builder
> functions, so not sure what exactly "extract" mean here?

You can, but not with full feature access. There’s no motion blur or OOBB (for 
hair)
when using the separate BVH builder. To make use of those (IMHO essential) 
features,
one needs to either use Embree’s own rtcIntersect calls for traversal or 
extract the
raw BVH data from it like in this sample code:
https://github.com/embree/embree/blob/master/tutorials/bvh_access/bvh_access.cpp

My current implementation is using rtcIntersect, so it’s not using Cycles’ BVH
traversal code at all. To get this to the GPU, we’ll need to port rtcIntersect
to the GPU and extract the necessary data structures from the opaque RTCScene
pointer in order to copy them to device memory.

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2018 BVH8

[Stefan Werner]

Hi Brecht, Anton,

to get Embree to be a full replacement of Cycles’ own BVH, there are still a 
number of tasks to be done. From the top of my head, here’s what’s missing from 
my current branch:

1. Update to Embree 3.0.0, of which a first beta was just released. This should 
allow us to build with an unpatched Embree.
2. If we decide that it’s needed, implement a solid line segment/cylinder 
primitive for Embree. Embree has flat (ribbon) line segments, flat curves and 
solid curves but not solid cylinders.
3. Reduce the amount of duplicated data. Ideally, Cycles keeps all the geometry 
data in its own buffers and Embree accesses it directly through pointers. That 
may require resolving race conditions in interactive rendering.
4. Extract BVH data from Embree and write GPU traversal code.
5. Find out if it’s possible in the latest Embree to do quaternion 
interpolation of motion transforms - the 2.x versions are still limited to 
linear straight interpolation. If this isn’t there, motion blur quality will 
degrade.

Once parity is reached, there are several features in Embree that could improve 
Cycles. Some of these may not work with the GPU:
6. Using Embree’s ray stream API for the CPU split kernel.
7. Embree’s built-in displacement.
8. Embree’s quad primitive.
9. Compare Embree’s subdivision implementation to Cycles’ and use it if it’s 
better. The on-demand cache could help reduce memory usage at the expense of 
performance.

Feel free to take over any of these tasks. I would be happy to work on them 
myself, but as it stands I can’t make any promises regarding a time line. The 
embree integration in its current state is sufficient for our current 
production needs. I don’t expect to have a lot of spare time for extra polish 
in the next few months.

The current state of my Embree integration is here:
https://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/cycles_embree
 


It does rely on a patched version of Embree which you can find in this branch:
https://github.com/skwerner/embree/tree/cycles_compatible

Don’t hesitate to ask if you have any questions about this.

-Stefan

> On 29. Jan 2018, at 18:58, Brecht Van Lommel  
> wrote:
> 
> Hi Anton,
> 
> We're planning to move to Embree, so improving our existing BVH builder and 
> traversal is not the best use of time.
> https://lists.blender.org/pipermail/bf-committers/2017-November/048936.html 
> 
> 
> However a lot of work is still needed to get the Embree integration stable, 
> and I imagine whatever the state will be this summer, there will be a lot 
> room for improvement. Finding optimizations in the integration, memory usage 
> reductions, etc. Some of the bigger topics would be:
> * Use Embree for building the GPU BVH, so we can remove our own builder.
> * For subdivision surfaces, implement more memory efficient grid primitive to 
> intersect directly.
> * Optimizations for tracing short rays on a single object for subsurface 
> scattering, bevel, curvature.
> 
> Stefan, do you have an idea about which tasks will be open still this summer?
> 
> Regards,
> Brecht.
> 
> On Sun, Jan 28, 2018 at 11:07 PM, Антон Гавриков  > wrote:
> Hello, I worked on this (https://developer.blender.org/D2875 
> ) project as a
> summer intern in Intel. I would like to know if there is any interest in
> working on this project in GSoC 2018. Or maybe there are any similar tasks
> to optimize Cycles for new architectures.
> 
> Regards,
> 
> Anton.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org 
> https://lists.blender.org/mailman/listinfo/bf-committers 
> 
> 

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cycles + Embree

[Stefan Werner]

Pushed one more branch, cycles_texture_cache this time. Again, work in progress 
that has been developed for Tangent Animation. CPU only, it’s using 
OpenImageIO’s TextureSys directly. Unfortunately, it comes with a certain 
performance hit that I’m hoping to reduce further or maybe even eliminate. In 
exchange, it allows for rendering a large number of large sized textures in a 
pre-defined modest memory footprint.

This, the Embree branch and the Cryptomatte branch are features that I would 
hope to eventually merge into master (2.8?) once they’re stable, feature 
complete and reviewed.

-Stefan

> On 27. Nov 2017, at 15:43, Stefan Werner <stew...@gmail.com> wrote:
> 
> Hi everyone,
> 
> I pushed a new branch to git.blender.org <http://git.blender.org/> yesterday, 
> cycles_embree. As the name says, this is an integration of the Embree 
> raytracing kernel into Cycles*. If you are interested in building it, you 
> will need version 2.16.1 or newer of Embree, built with EMBREE_RAY_MASK=ON. 
> To avoid self-shadowing with hair, a slightly patched version of Embree is 
> necessary which you can find here: 
> https://github.com/skwerner/embree/tree/cycles_compatible 
> <https://github.com/skwerner/embree/tree/cycles_compatible>
> 
> For now, this is a CPU only feature, and the real benefits from using Embree 
> come into play with scenes using deformation motion blur. Small or static 
> scenes don’t benefit much. Be aware that that not everything renders 100% 
> identical to regular Cycles when enabling Embree: Object motion blur in 
> Embree does not do arc interpolation but only straight linear motion. Curve 
> and line intersections use a different algorithm and therefore render to a 
> slightly different shape.
> 
> This branch is still a work in progress - the last few (hopefully just a few) 
> bugs are being ironed out, there are still some known instabilities and 
> memory being wasted. I’m in touch with the Embree authors to see if/when we 
> can use a version of Embree without Cycles specific patches and still get 
> identical results to plain Cycles. It should certainly be possible to use 
> Embree’s BVH data and traverse it in OpenCL and CUDA to get fast deformation 
> blur on GPUs too, but that is still a task I haven’t tackled yet at all 
> (volunteers are welcome).
> 
> -Stefan
> 
> * As announced in my BCONF17 talk: 
> https://www.youtube.com/watch?v=_2Ia4h8q3xs 
> <https://www.youtube.com/watch?v=_2Ia4h8q3xs>

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Cycles + Embree

[Stefan Werner]

Hi everyone,

I pushed a new branch to git.blender.org yesterday, cycles_embree. As the name 
says, this is an integration of the Embree raytracing kernel into Cycles*. If 
you are interested in building it, you will need version 2.16.1 or newer of 
Embree, built with EMBREE_RAY_MASK=ON. To avoid self-shadowing with hair, a 
slightly patched version of Embree is necessary which you can find here: 
https://github.com/skwerner/embree/tree/cycles_compatible

For now, this is a CPU only feature, and the real benefits from using Embree 
come into play with scenes using deformation motion blur. Small or static 
scenes don’t benefit much. Be aware that that not everything renders 100% 
identical to regular Cycles when enabling Embree: Object motion blur in Embree 
does not do arc interpolation but only straight linear motion. Curve and line 
intersections use a different algorithm and therefore render to a slightly 
different shape.

This branch is still a work in progress - the last few (hopefully just a few) 
bugs are being ironed out, there are still some known instabilities and memory 
being wasted. I’m in touch with the Embree authors to see if/when we can use a 
version of Embree without Cycles specific patches and still get identical 
results to plain Cycles. It should certainly be possible to use Embree’s BVH 
data and traverse it in OpenCL and CUDA to get fast deformation blur on GPUs 
too, but that is still a task I haven’t tackled yet at all (volunteers are 
welcome).

-Stefan

* As announced in my BCONF17 talk: https://www.youtube.com/watch?v=_2Ia4h8q3xs
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Cryptomatte branch

[Stefan Werner]

Hi,

As discussed at BCon, I created and pushed a temp-cryptomatte branch on 
git.blender.org. Note that it is still a work in progress. It is known to not 
build on gcc/Linux, I'm looking at that. Some code formatting and clean up is 
also on my todo list.

Still, it should be usable for many an I hope I can get it ready for master and 
2.8 soon.

I hope to get Embree and texture caching branches ready next week.

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly meetings and communication channels

[Stefan Werner]

Hi,

answers are inlined:

> On 28. Aug 2017, at 14:27, Ton Roosendaal  wrote:
> 
> Proposal: alternate Monday meetings to be 10:00 and 18:00 Amsterdam time. 
> Drop the Sunday meetings.

I like the alternating time idea, that should allow people from more time zones 
to participate.
Picking a right day is hard though - weekdays are good paid contributors, 
weekends better for volunteers.

> 1) Forums: (discourse)
> https://internals.rust-lang.org/categories 
> 

Some kind of developer focussed forum is helpful, I would think. Right now, 
we’re abusing the bug tracker
as forum: https://developer.blender.org/T46258 

Discussions like this don’t work at all on IRC and not very well in mailing 
lists.

> 2) Weekly activity log
> https://this-week-in-rust.org/ 

Helpful, we should do that.

> 4) No mailing lists!
> https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html
> 
> Now I don't think we need to drop mailing lists, but the forums and activity 
> log sound great.
> Discourse also might help making our onboarding process better.

If we use a web based forum, please let’s pick one that works well on mobile 
devices
(including the ones that are not the latest and greatest) and sends server-side 
generated
static HTML. Responding to email on a smartphone is quick and easy and works 
even when
you have a terrible connection. “Modern” HTML pages sometimes require several MB
just to display essentially a couple of paragraphs of text.

For example, one of the forums I visit sometimes runs on nodeBB. Just the forum 
start page
comes in at 1.17MB. That’s ridiculous and I pretty much never read it on my 
phone. BA, even
with the features images, is only half as big, simple phpBB sites come in at 
300kB. Plain text
contents of these pages is just a few kB, the rest is mostly decoration and 
oh-so-useful features
nobody uses.

I know, we need to have fast connections to begin with (wouldn’t want to git 
clone over GPRS)
but I like to make my time on the road useful too. From here to BConf is 
roughly 7 hours on a train
that promises WIFI but doesn’t always deliver. Don’t want to let that time go 
to waste.

-Stefan
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2017 - Cycles Motion Blur Improvements

[Stefan Werner]

His paper could also be of interest:
http://gruenschloss.org/msbvh/msbvh.pdf

-Stefan

> On 02 Apr 2017, at 16:28, Sergey Sharybin  wrote:
> 
> Hi again, and sorry for the spam.
> 
> Totally forgot about one more moblur-related project: moblur support for
> volumetric data (smoke, fire, clouds, tornadoes..)
> 
> On Sun, Apr 2, 2017 at 4:20 PM, Sergey Sharybin 
> wrote:
> 
>> Hi,
>> 
>> 1. Guess the technique is called Sampled motion blur, combined with the
>> importance sample over the camera shutter time.
>> 2. I do not see how those algorithms are connected to motion blur and also
>> not clear which exact algorithm you're referring to. Is it a generic
>> quesiton or you see how this is applicable for motion blur?
>> 3. I'm not aware of algorithms which could improve motion blur in Cycles,
>> but there are lots of rather technical tricks you can do to reduce render
>> time and motion blur looking better:
>> 
>> - Some adaptive criteria for motion blur steps, so we don't do steps in
>> BVH for cases when something barely moves
>> - Use traverse-time interpolation of motion BVH nodes (or at least
>> investigate whether this gives and improvements)
>> - Support multi-step object motion blur
>> - Support curved/scale motion blur
>> 
>> On Sun, Apr 2, 2017 at 9:43 AM, Natalevich Mikhail >> wrote:
>> 
>>> Good morning.
>>> 
>>> Thanks to LetterRip for providing useful papers. I would lke to know more
>>> about Cycles motion blur to be able to work on it, so have a few
>>> questions:
>>> 
>>> 1. What algorithm is used in Cycles for motion blur now?
>>> 2. Is it good enough to use the algorithm decsribed in the paper (link on
>>> jcgt.org ) for the
>>> improvement of Blender?
>>> 3. Do you know even better algorithms? (I will, of course, examine this
>>> topic comprehensively later, but there's not enough time before the
>>> deadline)
>>> 
>>> Thank you in advance,
>>> Michael Natalevich
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> 
>> 
>> 
>> --
>> With best regards, Sergey Sharybin
> 
> 
> 
> -- 
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers