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

Sergey Sharybin sergey.vfx at gmail.com
Tue Apr 5 23:56:23 CEST 2016 

Hi,

John, i don't see what exact issue you're trying to solve here. You are
proposing something, but don't outline problem itself and don't show how
the proposal will improve anything.

But it is to be stated that we don't have any issues discussing Cycles and
Blender with artists and looking forward having a feeback from them. We are
always open for constructive conversations within this topics. This is just
given and not gonna to change.


On Tue, Apr 5, 2016 at 11:04 PM, John Tech <johnnytech at live.com> wrote:

> Hi,
>
> Could you please elaborate on why you think that?
> Who said anything about "Design"?
>
> There are tons of features that would not have to require a "Re-Design" of
> the underlying structure of everything.
> There are tons of features that would probably be possible to implement as
> pretty much equivalent of "add-ons" through 'hooks' etc.
>
> Also I thought I made it precisely clear that Requesting/Submitting a
> feature request:
> A: Requires a Donation "without guarantee it is accepted". ie someone
> REVIEWS the feature request to "judge" if it is acceptable or not. In a
> sense you do this already, you just don't get any money sent along with the
> feature request. A small (disclosed) fee could be kept even if feature is
> completely Rejected/killed with vengeance :D
>
> From my perspective, my proposal was intending to find a way to integrate
> the needs of the "community" with the vision of the Core-Developers.
>
> It is my opinion that requiring some payment for posting requests would
> help keep requests down to the more worthy ones and would allow some of the
> Core-Developers to approve or reject it. If request is NOT rejected after
> being read by a Developer, then it can be allowed to garner more support
> from the "community" by allowing others to DONATE towards that specific
> request, upvoting it etc.
>
> The next step would be for the Core-Developers to take a look at the "Top"
> funded requests and they can decide which of them they would like to add to
> their official TODO list, or to ask for external volunteers to help develop
> it for a bounty/purse cash amount. An external developer could then
> implement the feature request as some add-on or part of Cycles and submit a
> pull request to be examined by Core-Devs and rejected or accepted etc. If
> accepted, would be paid from a portion/percentage of the funds that were
> raised from donations for that specific feature.
>
> So from my perspective such a system does not take away from the
> Core-Developers control over the overall vision and direction of a project,
> but it helps to make for a much more vibrant and excited "community" behind
> a project. I think that too many open source projects shoot themselves in
> the foot so to speak by alienating a lot of potential contributors and
> financial supporters due to mainly unfounded fears.
>
> ----- Original Message -----
> From: "Troy Sobotka" <troy.sobotka at gmail.com>
> To: "Discussion list to assist Cycles render engine developers" <
> bf-cycles at blender.org>
> Sent: Monday, April 4, 2016 7:53:11 PM
> Subject: Re: [Bf-cycles] New ideas list on developer.blender.org
>
> “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
> >
>
> _______________________________________________
> 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
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160405/8b60f118/attachment.htm

More information about the Bf-cycles mailing list