On Tuesday, November 27, 2012, Carsten Haitzler wrote:

> On Mon, 26 Nov 2012 12:47:16 -0200 Bruno Dilly 
> <[email protected]<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?




>
> > 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)    [email protected] <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
> [email protected] <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to