[Bf-cycles] Cycles Submission guidelines / Extending the math node

[Brecht Van Lommel]

Personally I think it's ok to add rounded corners and more math
operations. These normally should not affect performance, generally my
experience is that it's the "biggest" node (using most registers
typically) is the one that limits performance. When this is not the
case we can usually work around it.

We just need to test if patches cause performance regressions, and we
have better infrastructure for that now. It helps if the patch author
can do that testing and fixing themselves.

Mainly my concern with adding new nodes (and features in general) is
code complexity, UI complexity and maintenance. I believe we should
aim to add the most important features first and not randomly add
features whenever someone is interested in implementing them, and end
up with a "lopsided" feature set. So for example for the OSL on SVM
case it's a difficult thing to do maintain from which relatively few
users would benefit, and I'd be inclined not to accept it so we can
focus on more important things. But rounded corners or more math
operations seem fine to me.


On Tue, May 2, 2017 at 10:55 PM, Ray Molenkamp <ray at lazydodo.com> wrote:
> All,
>
> As Sergey brought up in [1] there is a need some formal
> rules on what will be considered for inclusion into cycles
> and what will not.
>
> I took a few stabs [2] [3] at improving cycles, and ran
> into a wall of "urgh not procedural textures again, we don't
> want this" which sometimes is understandable (I admit the
> osl patch was kinda 'out there'), sometimes not as much,
> either way rejections are never fun and a waste of
> everybody’s time.
>
> I'm currently looking to extend the math node. I'd really
> like atan2,some more comparisons, and logic operations
> to be available, but I can easily think of 20+ more
> functions that can be useful to people.
>
> I have found some previous work [4] which doesn’t bode well
> for my planned changes, so before I start any work:
>
> Do I have *ANY* chance of this ever getting accepted?
>
> Also just to answer the most likely first response 'why not
> just use OSL?'
>
> Simple reason: it's too slow. SVM runs circles around it.
> I have a hexagon OSL shader (and an osl->nodegroup compiler)
> and a full screen scene with this shader renders withthe
> following render times:
>
> OSL with osl script : 05:05.98
> nodegroups SVM/CPU* : 01:33.71 (3.2x faster than osl)
> nodegroups SVM/GPU* : 00:37.62 (8.1x faster than osl)
>
> [*] Missing functions in SVM like floor/ceil emulated with several
> math nodes
>
> I'm willing to pay a small price for the flexibility OSL
> offers but a 3x-8x increase in render time seems a little
> excessive.
>
> --Ray
>
> [1] https://developer.blender.org/D2441#56790
> [2] https://developer.blender.org/D1745
> [3] https://developer.blender.org/D2441
> [4] https://developer.blender.org/T32566
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles