[Bf-cycles] New ideas list on developer.blender.org

Tue Apr 5 04:53:11 CEST 2016

“1. What about donation based feature requests?”

Worst. Idea. Ever.

Design is not something one votes on.

With respect,
TJS

On Mon, Apr 4, 2016, 4:49 PM John Tech <johnnytech at live.com> wrote:

> Hi,
>
> What do you think?
>
> 1. What about donation based feature requests?
> A: You post a feature request, it requires a donation just to post it. The
> advantage is it guarantees someone with authority to add it to the TODO
> list will actually look at it.(Perhaps if it is KILLED with "Denied",
> person should get a refund, or wait before accepting fund.)
> B. Everyone, and/or perhaps with higher-weight the $donors get to Upvote
> certain features etc.
> C. Everyone can DONATE more towards a specific feature which also is a way
> to Upvote that feature. If a feature reaches certain funding amount and/or
> upvotes it is then added to the official TODO list and developers assigned.
> D. Consider allowing NEW volunteer developers to start working for and get
> some sort of payment for good/acceptable work/patches, a kind of
> purse/bounty type system rewarding code contributions. Someone can see the
> "Donated" money on a particular feature and decide to work to implement it
> and send a pull request. Also, I expect that every feature request would
> keep a percent of the money donated for the foundation/Core developers etc
> and not entire amount is paid to external/volunteer as the bounty$ for a
> feature request etc.
>
> I myself would be willing to donate to a system whereby my own needs/wants
> have a much higher chance of being addressed versus just blindly giving to
> someone who may implement requests from their other buddies instead on my
> nickel etc. There is an aversion in open source against "some" financially
> guided development it seems, and I think its unwarranted. There should be
> some 'regulation' by some "Core/leadership" but at the same time there
> should be some "free-market" dynamics allowed also.
>
> Some things that interest me would be support for both AMD and ATI GPU
> rendering on the same computer to render even one frame, and ability to use
> both OpenCL on one card and CUDA on another for example, likely you'd use
> CUDA on Nvidia and OpenCL on ATI. Especially for complex scenes it would be
> nice to be able to in addition use network rendering to easily (without
> time consuming non-crossplatform hacks) render even one frame across
> multiple hybrid-GPU (each PC with both Nvidia/AMD/ATI gpus) computers on
> the network. This could perhaps be done based on Tiling or instead based on
> "seeding" methods or perhaps "render passes" so that different PCs and/or
> different GPUs render different "passes", z-depth etc...and hand in hand
> with all this would be:
>
> Adaptive AI(Artificial Intelligence/Machine Learning) Rendering (AAIR)
>
> The Rendering system would learn the best way to partition rendering
> across its available renderfarm and by subsequent renders it would
> auto-optimize itself using perhaps a Hybrid-CPU+GPU method to render even
> on a per frame basis and/or animation frames.
> Initially one would perhaps 'help' the algorithms by constraining them to
> the partitioning scheme you choose such as splitting render-passes or
> seeding or disabling one-frame support and letting it learn based on
> simpler previous frames rendering times and optimizing the future frames by
> giving it to the CPUs if warranted. As the AI/MachineLearning becomes
> smarter (longer code :() it could then be allowed more autonomy and such
> constraints would only be optional. I guess a "start" in this direction
> would be supporting HYBRID CPU+GPU rendering.
>
> The other "BIG"/"HUGE" thing I would say which could become a very
> "profitable" yet open source initiative would be some sort of realtime
> PHYSICS/GAME engine that could compete in a sense with the rage of Amazon's
> Lumberyard/Crytek-Engine, SourceFilmMaker/Source2-Engine, Unity, Cocos2d-x,
> etc. This should probably be something that an external team very familiar
> with BLENDER3D may attempt, as it seems to me that Blender3D's original
> realtime Blender Engine is a dead project more or less, please correct me
> if I'm wrong. The licensing of an engine should be similar to Cycles,
> Apache 2, or MIT like Cocos2d-x, definitely not GPL.
>
> In this day and age of the Microsoft Kinect, everyone wants to create
> their own realtime "movies" and I think realtime engines are the future and
> we will see more and more flexible movies produced in this manner. We
> already have decent "Pre-Viz" in various open source packages, the missing
> ingredient is well integrated Physics forces etc and easy rigging and
> control to create ones own RPG universe. Create the good quality
> realtime-Previz and the Physics and I think the rest of the game logic will
> be the easy part with many contributors.
>
> Anyway, I realize the engine stuff is off-topic here but I thought perhaps
> the thoughts may give some of the developers here some ideas etc, I know
> sometimes its hard to have time to contemplate the bigger picture when
> you're too busy coding.
> Best wishes!
> ----- Original Message -----
> From: "Lukas Stockner" <lukas.stockner at freenet.de>
> To: "Discussion list to assist Cycles render engine developers" <
> bf-cycles at blender.org>
> Sent: Monday, April 4, 2016 10:25:49 AM
> Subject: Re: [Bf-cycles] New ideas list on developer.blender.org
>
> Hi,
>
> [1] is already close to what I meant, but both ([2] even more so) are
> already specific plans about what will be added.
> What I mean is more like a general "Hey, we could add this at some
> point" (like the Ideas and ToDo in the Wiki) - while [1] is planning for
> what is supposed to be added to 2.8x and [2] is only for stuff that is
> already WIP.
> Of course, it would probably need moderation since lists like these are
> bound to attract feature requests from users...
>
> Am 04.04.2016 um 19:18 schrieb Sergey Sharybin:
> > Hi,
> >
> > There is already task for this i think [1].
> >
> > Additionally, thanks to Brecht, we now have tasks nicely organized in
> > workboard [2], so think it makes sense to avoid uber-task and have
> > individual tasks per official feature we're gonna to work and have those
> > tasks listed under "Features and Plans" workboard.
> >
> > However, it's still quite technical and it's still nice to work on a
> > more higher-level roadmap which would be more clear for users.
> >
> > [1] https://developer.blender.org/T46258
> > [2] https://developer.blender.org/project/view/26/
> >
> > On Mon, Apr 4, 2016 at 7:10 PM, Lukas Stockner
> > <lukas.stockner at freenet.de <mailto:lukas.stockner at freenet.de>> wrote:
> >
> >     Hi everybody!
> >
> >     Since creating a Cycles roadmap came up once again, I'd like to
> suggest
> >     creating an up-to-date ideas list as a first step.
> >
> >     There is a ToDo-list on the Wiki (under
> >     https://wiki.blender.org/index.php/Dev:Source/Render/Cycles), but it
> >     seems to be quite outdated and unmaintained currently.
> >
> >     Therefore, my suggestion is to create a "Cycles Ideas" task on
> >     developer.blender.org <http://developer.blender.org> where ideas can
> >     be added by developers. Once
> >     something gets implemented, the corresponding task/revision/commit
> can
> >     then be linked from there. Also, it gives a quick overview on
> possible
> >     and reasonable changes which is a good basis for creating a roadmap
> (and
> >     also could serve as a kind of Cycles-specific Quick Hacks list for
> new
> >     devs by marking some ideas as "easy")
> >
> >     So, what do you guys think about it?
> >
> >     Best regards,
> >     Lukas
> >
> >
> >     _______________________________________________
> >     Bf-cycles mailing list
> >     Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> >     https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160405/3dfb5281/attachment.htm 