On Mon, Dec 10, 2012 at 4:48 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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...
ok, option 3 is already implemented.
>
>> > > 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
--
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi
------------------------------------------------------------------------------
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
