On Tue, 27 Nov 2012 08:52:14 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> On Tuesday, November 27, 2012, Carsten Haitzler wrote:
>
> > On Mon, 26 Nov 2012 12:47:16 -0200 Bruno Dilly
> > <bdi...@profusion.mobi<javascript:;>> said:
> >
> > > Hey folks,
> > >
> > > we're are now making ephysics API more stable, almost all the features
> > > intended to go in are already implemented, so we are moving to the
> > > next step:
> > > adding support to physics on Edje.
> > >
> > > There are many ways of doing this, so I'm sending a proposal with some
> > > possibilities so we could discuss before we start to implement it.
> > >
> > > Just to make it clearer. My proposal exposes a lot of ephysics,
> > > something very complete
> > > (for what I believe are valid use cases. Lot of things possible with
> > > ephysics API are not exposed),
> > > and that would require a lot of time to be completely done.
> > > So, it will be implemented gradually, covering the main use cases first.
> > >
> > > So initially would be possible to create a new world with a list of
> > > bodies, with most properties set using ephysics default. Later we
> > > would expose
> > > some more relevant properties. Implement programs / scripts. Then
> > > adding support to constraints, camera, etc etc...
> > >
> > > But would be good to define what would be the better, complete scenario.
> > >
> > > Thanks in advance,
> > >
> > > ======================================
> > >
> > > PROPOSAL: SUPPORT PHYSICS ON EDJE
> > >
> > > === CHOICES ===
> > > There are 3 main different ways to do it. The first one
> > > is described in details above, and has some alternatives explained.
> > > The other 2 can be understood with these details.
> > >
> > > 1) A single physics block that would be set per group, and all the
> > rendered
> > > objects to be manipulated would be other groups.
> > > 2) A single physics block that would be set per group, and all the
> > rendered
> > > objects to be manipulated would be other parts of this group.
> > > 3) A physics block to describe world, camera and constraints,
> > > that would be set per group. And extra physics blocks per part that
> > > should be associated to a body. Example:
> > > group {
> > > physics {
> > > world {
> > > ...
> > > }
> > > }
> > > parts {
> > > part {
> > > name: ..
> > > body_type: ...
> > > description {
> > > ...
> > > physics {
> > > // body props
> > > }
> > > }
> > > }
> > > }
> > > }
> >
> > option 3. definitely.
> >
> > > Regarding programs, there are three main choices:
> > > 1) Physics world, camera, constraints and bodies have states with these
> > > objects attributes. Using STATE_SET as already exists on Edje would be
> > the way
> > > to change it. Bodies can handle actions that should be set only via
> > > scripts, like apply_impulse, apply_force, set_velocity ...
> > > 2) No specific physics ACTIONs. Everything should be set via scripts.
> > > 3) Another types of ACTION would be declared, like PHYSICS_IMPULSE,
> > > PHYSICS_FORCE, etc. So it could be used without scripts.
> >
> > option 3. definitely. (i assume this ALSO allows the script stuff to work
> > too) :) (i'm loving your multi-choice thing here :)).
>
>
> I initially said to Bruno that given the nature and usage of Physics, very
> rarely you will end using fixed value for effects/force. Then those actions
> would be rarely used, being easily replaceable with embryo script blocks.
>
> Most common case is calculating the force based on hit point (pointer),
> drag objects, etc.
>
> So why not stick with option #2?
i disagree it wont be common. i can well envisage ephysics as a way of doing
complex animation easily. you click the button and it emits a "force" on a
dozen "particle" object that fade it and glow - land bounce around - like
sparks coming off the corner of the button. it's the same force each time...
> > > The main argument in using scripts is that hardly a user will want
> > > just to set a hardcoded property. Usually it will be based on body's
> > > and other parts current state, like using geometry or velocity, etc.
> > > So it would be required to get properties, do some calculation, set to
> > body.
> > >
> > > PROGRAMS chapter exemplify it.
> > >
> > > Initially I would go with choices 1) and 1), but I would like to see
> > > what you think about it.
> > >
> > >
> > > === OVERVIEW ===
> > > collections {
> > > ...
> > > group {
> > > ...
> > > parts {}
> > > physics {
> > > world {}
> > > camera {}
> > > bodies {
> > > body {}
> > > ...
> > > }
> > > constraints {
> > > constraint {}
> > > ...
> > > }
> > > }
> > > programs {}
> > > ...
> > > }
> > >
> > > === PHYSICS ===
> > > The "physics" block contains all the other blocks related to physics.
> > Blocks
> > > "world", "camera", "bodies" and "constraints" will be found inside it.
> > Physics
> > > only will be enabled if at least one "body" is listed on "bodies" block.
> > >
> > > It should be included in group's block, since a physics world won't be
> > shared
> > > between groups.
> > >
> > > === WORLD ===
> > > The "world" block can have one or more description blocks.
> > > It's required to simulate physics between bodies.
> > > Only one world can be declared per group.
> > >
> > > Each "description" block is used to set all attributes required to
> > configure a
> > > physics world.
> > >
> > > ...
> > > physics {
> > > world {
> > > name: "name";
> > > description {
> > > state: "description_name" INDEX;
> > > inherit: "another_description" INDEX;
> > > rel1 {
> > > ..
> > > }
> > > rel2 {
> > > ..
> > > }
> > > rate: 30;
> > > gravity: 0 294 0;
> > > running: 1;
> > > light {
> > > light: "part_name";
> > > all_bodies: 0;
> > > }
> > > simulation {
> > > fixed_time_step: 0.033;
> > > max_sub_steps: 3;
> > > }
> > > sleeping_time: 2.0;
> > > solver_iterations: 10;
> > > auto_delete {
> > > top: 1;
> > > bottom: 1;
> > > left: 1;
> > > right: 1;
> > > front: 0;
> > > back: 0;
> > > }
> > > stacking: 1;
> > > }
> > > }
> > > ...
> > > }
> > > ...
> > >
> > > ---
> > >
> > > name [world name]
> > > Define the name that refer to this world instance.
> > >
> > > state [a name for the d------------- Codito, ergo sum - "I code,
> > therefore I am" --------------
> > The Rasterman (Carsten Haitzler) ras...@rasterman.com <javascript:;>
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Monitor your physical, virtual and cloud infrastructure from a single
> > web console. Get in-depth insight into apps, servers, databases, vmware,
> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pricing starts from $795 for 25 servers or applications!
> > http://p.sf.net/sfu/zoho_dev2dev_nov
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
