[Bf-committers] Eevee and BGE proposal.

Sergey Sharybin sergey.vfx at gmail.com
Wed Jul 19 23:05:24 CEST 2017 

Hi,

This is the whole point of dependency graph -- to bring your scene up to
date when something changed in most efficient way. This means, dependency
graph will whatever it can to:

- Make sure order of update is correct (which means object is not scheduled
for update for until everything it depends on is brought up[ to date).
Surely, it is possible to have dependency cycles, but such setups are
problematic no matter what you choose.
- Make sure objects which are not changed are not updated/invalidated.
- Only actually changed components of objects are re-evaluated. This means,
for example, if you animate location of some heavy duty object who's
modifier stack does not depend on location (for example, mesh with
subsurface on a high level) dependency graph will only re-evaluate position
of object (parenting + constraint stack), but will keep geometry itself
unchanged.
If modifier stack depends on object position, then you'll be doomed again
to re-evaluate the whole modifier stack no matter what approach you choose
here.

You can totally avoid all "dynamic" things in modifiers stack setup, and in
this case i don't think you can make BGE reasonably faster than viewport.
We are investing lots and lots of time and effort making sure viewport is
as fast as it possible could be for complex production scenes. On another
hand, if you need or want dynamic changes, toy can still have those by
simply adding things to your modifier stack.

I am also not convinced speed should be an ultimate goal for BGE. You would
never be able to compete in both performance and quality with any high
quality engine from top rated games anyway. If you need those two things,
you'll be using standalone engine anyway. For BGE it is more important to
keep it as seamless as possible with Blender itself. Surely, you'll
probably sacrifice some performance and/or quality, but on another hand
you'll have strong environment where you will never run into issues when
your scene looks differently inside and outside of game engine just because
some evaluation is done differently in both sides.

There are following benefits of moving BGE to Blender itself:

- It will require animation system upgrade to support actuators / logic
bricks. This is something interesting to investigate for artists use anyway.
- With the new dependency graph, we support much more complicated relations
between objects on a more granular level than it sued to be in old
dependency graph. This includes all crazy things like interleaving armature
update with IK solver to a targets on another object, includes more robust
drivers evaluation order and lots and lots of more fixes. Those setups
would need to be supported by BGE. Surely, you can re-implement it in
whatever system you choose, but such duplicated work is not efficient at
all.
- We are working on a copy-on-write, overrides at this moment. It would not
be efficient to re-implement them in BGE as well. Same applies to proxies,
and we are planing to support proxies of any datablock.
- it is considered to support node-based constraints and modifier stack. If
you still was duplicating work in BGE side, at the point we'll implement
those nodes you'll be effectively re-implementing full featured dependency
graph in BGE instead of just using the depsgraph which is used by core of
Blender!

Surely one might consider that those features will never be supported in
BGE, but then what's the point of having BGE in the first place? If those
features are planned to be supported in BGE i see zero reason to
re-implement systems we're having in Blender already.


On Wed, Jul 19, 2017 at 9:55 PM, tristan porteries <
republicthunderbolt9 at gmail.com> wrote:

> Hello,
>
> The last conversations were about data managing with the new depsgraph, i
> want to share some arguments:
>
> In the BGE the data are designed to be frequently updated (even an update
> per frame), the BGE modify less data than blender: polygons and vertices
> are not added to meshes, the material node trees don't change, textures
> don't change. At the end the majority of the data update affect values of
> existing data, no creation or deletion.
>
> Because of these notes, i don't think using the depsgraph will be a good
> advantage in the BGE without complexify the code and slow it a bit. Leaving
> all dynamic is more appropriate for a game engine in my opinion.
>
> Interactive mode will not be impossible in futur as it is a part outside
> the BGE as BGE is the shared part between blenderplayer and blender. The
> interactive mode can be something in blender (as editor) checking data and
> synchronize them to the BGE data.
>
> I hope i'm sufficiently obvious.
>
> Tristan.
>
> 2017-07-18 9:39 GMT+02:00 Dalai Felinto <dfelinto at gmail.com>:
>
> > Hi Tristan,
> >
> > I mean the update of the values since they can be animated. And the
> > update of the world probe when the animated nodetree is of a world
> > material.
> >
> > > "And a node list for your new system."
> >
> > If you are referring to [1], the UBO is created storing a pointer to
> > the original socket data. You won't get to use it without using the
> > Depsgraph (and its copy-on-write system). Or some clever
> > implementation in the BGE creating your own local version of the
> > nodetree.
> >
> > Anyways if you don't show up at 10am (in 20 minutes) we will be
> > expecting you at 11am at #blendercoders.
> >
> > [1] - https://developer.blender.org/rB2a489273d7e2354a9f1afc321286
> > 3ff4b463cf86
> >
> > Regards,
> > Dalai
> > --
> > blendernetwork.org/dalai-felinto
> > www.dalaifelinto.com
> >
> >
> > 2017-07-17 22:04 GMT+02:00 tristan porteries <republicthunderbolt9 at gmail.
> > com>:
> > > Hello Dalai,
> > >
> > > Sorry, i want to clarify your question: When you talk about material
> > > update, it's the update of node values or totally something else ? Also
> > the
> > > BGE will never modify the node tree of a material so we don't have to
> > > manage the material creation. At the end the only think we need
> currently
> > > for update is a GPUMaterial or GPUShader and a node list for your new
> > > system.
> > >
> > > About probes, we already developed in UPBGE planar and cube probes, i
> > hope
> > > we could adapt them. For the irradiance/grid probe i have to check
> > deeper.
> > >
> > > Tristan.
> > >
> > > 2017-07-17 18:43 GMT+02:00 Dalai Felinto <dfelinto at gmail.com>:
> > >
> > >> Hi Tristan,
> > >>
> > >> Can you elaborate on how do you plan handling updates for the Eevee
> > >> materials and probes?
> > >> Right now this all goes via the depsgraph.
> > >>
> > >> Perhaps we could talk Tuesday morning (10am or 11am CEST) on IRC with
> > >> Sergey to get this sorted out once and for all.
> > >>
> > >> Cheers,
> > >> Dalai
> > >> --
> > >> blendernetwork.org/dalai-felinto
> > >> www.dalaifelinto.com
> > >>
> > >>
> > >> 2017-07-14 15:29 GMT+02:00 tristan porteries
> > <republicthunderbolt9 at gmail.
> > >> com>:
> > >> > Hello Dalai,
> > >> >
> > >> > The proposal is to use Eevee in BGE, it looks simple but it requests
> > >> > refactors in the BGE sources.
> > >> >
> > >> > The usage of draw engine based on Eevee help to not interfere the
> > eevee
> > >> ->
> > >> > blender side, the idea of common API can be forgotten and replaced
> by
> > a
> > >> > little number of duplicated functions if it is too complicated in
> > futur.
> > >> >
> > >> > I think that the debate about interative mode is for an other
> > proposal,
> > >> > implementing eevee in BGE will not exclude the interactive mode,
> doing
> > >> the
> > >> > both in same time can be very messy.
> > >> >
> > >> > Tristan.
> > >> >
> > >> > 2017-07-11 15:37 GMT+02:00 Jacob Merrill <
> blueprintrandom1 at gmail.com
> > >:
> > >> >
> > >> >> Step 1 in such a scenario, is a realtime switch for rendering and
> > >> running
> > >> >> the game loop.
> > >> >>
> > >> >> What about getting evee running, and upgrading viewport with new
> > logic
> > >> >> system, and after evee is integrated, integrate same logic systems
> > into
> > >> >> BGE?
> > >> >>
> > >> >> Maybe Bullet3 or even pyBullet based?
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Jul 11, 2017 5:54 AM, "Dalai Felinto" <dfelinto at gmail.com>
> wrote:
> > >> >>
> > >> >> > Hi Tristan,
> > >> >> > Thanks for writing this. Sergey and I just finished looking at
> it.
> > >> >> >
> > >> >> > The proposal is missing a big picture. What is it trying to
> > achieve?
> > >> >> > It seems to simply try to bring Eevee materials into BGE, without
> > any
> > >> >> > extra benefit.
> > >> >> >
> > >> >> > If that’s the only goal of this project, I would at least expect
> > it to
> > >> >> > not interfere with the rest of Blender. For example, the idea of
> > >> >> > changing Eevee to accommodate to a common API seems not ideal.
> > >> >> >
> > >> >> > That said, we have an opportunity to do something bigger. Which
> > would
> > >> >> > be to integrate interactivity with the rest of Blender. That’s a
> > >> >> > bigger undertake for sure, but I was under the impression that
> this
> > >> >> > was the original idea for after 2.7. It’s not clear if this was
> > >> >> > considered, or why was it dismissed.
> > >> >> >
> > >> >> > Regards,
> > >> >> > Dalai and Sergey
> > >> >> > --
> > >> >> > blendernetwork.org/dalai-felinto
> > >> >> > www.dalaifelinto.com
> > >> >> >
> > >> >> >
> > >> >> > 2017-07-02 12:23 GMT+02:00 tristan porteries
> > >> <republicthunderbolt9 at gmail.
> > >> >> > com>:
> > >> >> > > Hello everyone,
> > >> >> > >
> > >> >> > > I invite the people working on Eevee and 2.8 (Campbell, Dalai,
> > >> Bastien,
> > >> >> > > Clement, Mike and few other) to look at the following proposal
> > for a
> > >> >> > merge
> > >> >> > > of Eevee into the BGE.
> > >> >> > >
> > >> >> > > https://docs.google.com/document/d/
> > 1dpC2zCVD54yCGwNZFu_WM82uUAGI_
> > >> >> > s5-GmlgMLOcfYY/edit?usp=sharing
> > >> >> > >
> > >> >> > > Feel free to comment on the document, also an experimental
> branch
> > >> named
> > >> >> > > ge_eevee is available on https://github.com/UPBGE/blender.
> > >> >> > >
> > >> >> > > Tristan.
> > >> >> > > _______________________________________________
> > >> >> > > Bf-committers mailing list
> > >> >> > > Bf-committers at blender.org
> > >> >> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >> >> > _______________________________________________
> > >> >> > Bf-committers mailing list
> > >> >> > Bf-committers at blender.org
> > >> >> > https://lists.blender.org/mailman/listinfo/bf-committers
> > >> >> >
> > >> >> _______________________________________________
> > >> >> Bf-committers mailing list
> > >> >> Bf-committers at blender.org
> > >> >> https://lists.blender.org/mailman/listinfo/bf-committers
> > >> >>
> > >> > _______________________________________________
> > >> > Bf-committers mailing list
> > >> > Bf-committers at blender.org
> > >> > https://lists.blender.org/mailman/listinfo/bf-committers
> > >> _______________________________________________
> > >> Bf-committers mailing list
> > >> Bf-committers at blender.org
> > >> https://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin

More information about the Bf-committers mailing list