Re: [E-devel] PROPOSAL: Support physics on Edje

[David S. <on...@gm...>]

On Wed, 28 Nov 2012 10:46:00 -0200 Bruno Dilly <bd...@pr...>
wrote:

> On Mon, Nov 26, 2012 at 10:59 PM, David Seikel <on...@gm...>
> wrote:
> > On Mon, 26 Nov 2012 14:55:26 -0200 Bruno Dilly
> > <bd...@pr...> wrote:
> >
> >> Hi David,
> >>
> >> On Mon, Nov 26, 2012 at 1:36 PM, David Seikel <on...@gm...>
> >> wrote:
> >> > On Mon, 26 Nov 2012 12:47:16 -0200 Bruno Dilly
> >> > <bd...@pr...> wrote:
> >> >
> >> >> 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.
> >> >
> >> > I'm gonna take a step back and consider the big picture from my
> >> > own point of view before delving into the details.
> >> >
> >> > First the simple question - have you considered Edje Lua as well
> >> > as Embryo?  I'll be happy to write the Edje Lua bindings.
> >>
> >> I'm planning to work with Embryo because it's used by most of the
> >> scripts in our repository, and I always pick Embryo
> >> for private projects done here on Profusion, so I know it much
> >> better than Lua. But would be great to support physics on both.
> >
> > I'll add similar Edje Lua bindings after the Embryo bindings are
> > sorted out.
> >
> >> > Now the hard part.
> >> >
> >> > I'm heavily involved in SecondLife (SL) / OpenSim style online 3D
> >> > virtual worlds.  Think MMOG where the users can edit the world in
> >> > world in real time, and it's not really a game, more a generic
> >> > platform.
> >> >
> >> > I'm working on both client and server side software.  I REALLY
> >> > REALLY want to convert the existing crap client and server code
> >> > into something more sane based on EFL.  So obviously 3D graphics,
> >> > 3D physics, and scripting of the world are important to me.
> >> >
> >> > Bullet physics I think is the way to go, so I'm on the same page
> >> > here.
> >> >
> >> > I know you have considered 3D stuff, so again, kinda on the same
> >> > page here.  Though I wonder if ephysics is suitable for this sort
> >> > of work?
> >>
> >> EPhysics is focused on 2D games and GUI effects.
> >>
> >> Does it support 3 dimensions ?
> >>
> >> Yes, you can set velocities, impulses, forces in all three axis.
> >> The same for angular stuff. It will move in the 3d scene, deform
> >> in 3 dimensions, collide, etc.
> >>
> >> But... it was not focused on that, so some stuff that is really
> >> easy using ogre, for example,
> >> won't be on EPhysics. Using ogre you can add a new entity just
> >> loading a mesh.
> >
> > I've already been working with a library (libg3d, not to be confused
> > with g3d) for loading arbitrary meshes in dozens of formats,
> > locally or across the network. I'm not sure, but I think Ogre is
> > not so good at that, Irrlicht is a bit better, but libg3d is better
> > still.
> >
> >> Right now we don't support such thing. It's planned to be done in
> >> the future to create shapes.
> >>
> >> But things like applying textures will be harder yet, that's
> >> another thing to be improved
> >> to make ephysics useful for such scenarios. The way it is now, you
> >> would need to create an evas object for each face you would like to
> >> see rendered explicitly. It would
> >> be needed more improvements to set what points of a image texture
> >> would mapped by
> >> each face. And even the support to have evas objects per face is
> >> only implemented
> >> for primitive shapes.
> >
> > Ah, so no UV mapping yet.  Evas object per face means a cube has
> > six of them?  That gets a bit heavy for high poly count arbitrary
> > meshes.  I guess your primitive shapes are simple cubes and things,
> > not SL style proceducal primitives?
> 
> Evas map supports only four points.
> So we need an evas object per face.
> For meshes we create many proxies automatically and set to
> parts of the evas object associated to that using
> evas_map_point_image_uv_set
> 
> You are right about our primitive shapes.
> 
> >
> >> I will make a blog post (dedicated to you =) ) with current state
> >> of ephysics, and what
> >> should be expected until the end of this year. So it would
> >> be easier to see what's is easy to do with it right now, and it
> >> will be more accessible to other people too.
> >
> > I read and commented on that.
> >
> >> >
> >> > For graphics I have been looking at Ogre and Irrlicht.  Irrlict
> >> > has my preference at the moment, mostly coz it's relatively light
> >> > weight and has good support for old hardware, including a decent
> >> > software renderer.  People using unsuitable hardware for SL is a
> >> > common problem.  Typically lots of people use student / business
> >> > class laptops, not the sort of things that are designed for 3D
> >> > games. Irrlicht has it's own 2D GUI stuff, but obviously I'd be
> >> > ripping that out and using EFL.  Perhaps ephysics would be a
> >> > better choice for EFL based software?
> >>
> >> EPhysics has a glue for using Bullet with Evas that will do the job
> >> for most GUI effects
> >> you may want (2D games as well). But for 3D games and related most
> >> probably you'll
> >> be interested in one of this well established 3D engines. Ogre has
> >> OgreBullet to make
> >> it easier to develop stuff using Bullet Physics (not sure if this
> >> project is well maintained).
> >> I know people use to do merge Lua in the recipe as well.
> >
> > I'm guessing ephysics does not have fancy scene management stuff
> > for big scenes, or fancy things like particles, height maps, sky
> > boxes, clouds, etc?
> 
> No, nothing of these.
> 
> >
> >> I don't know much about Irrlicht.
> >
> > I'll likely experiment with it next weekend.
> >
> >> > So I guess my basic question is - would your ideas for ephysics
> >> > be suitable for online 3D virtual worlds, or is it limited to
> >> > simple, mostly 2D games?  Perhaps some combination of ephysics
> >> > and Irrlicht is the way I should go?
> >>
> >> Uhmm... lights can be another limitation. I'm not sure these
> >> engines provide ray tracing,
> >> but we don't. We are stuck to evas map light calculations. No light
> >> reflection, refraction.
> >> Since light don't diffuse when reflecting other surfaces makes the
> >> contrast of light / shadow
> >> a bit ugly for such cases. Bodies between the light source and
> >> others won't produce shadows
> >> as well.
> >
> > Proper raytracing is usually not used for real time stuff, but it's
> > starting to come.  SL needs water reflections and refraction, and
> > only recently got proper shadows.  Ogre does great water, not sure
> > about Irrlicht yet.
> >
> >> We just support a single camera right now, no zoom in / out
> >> support, rotation ,etc. I know
> >> blender support such things. It's doable, but it's not planned to
> >> be done for now.
> >
> > One of the good things about SL is it's camera controls.  I pride
> > myself in being expert with them, so this is very important to me.
> >
> >> I've never worked with any 3d engine, so not sure how far we are of
> >> the state of art of such
> >> frameworks, and what features you would need. If you will have
> >> time to work on EPhysics / Evas
> >> to support your needs, I'm here to help, but I'm not sure how far
> >> we could go to satisfy your needs
> >> and can be a bit frustrating for you if you have to migrate to
> >> Irrlicht after all.
> >>
> >> When you study a bit more about Ogre / Irrlicht and I show
> >> the current status of EPhysics we could evolve with this discussion
> >> and evaluate how far we could go.
> >>
> >> I can't see how EPhysics would help you using these graphical
> >> engines. If you are going to use Irrlicht or Ogre, I would say to
> >> forget about EPhysics.
> >
> > Well, my intention is to EFLize the SL stuff.  That includes
> > integrating some decent 3D graphics engine.  I'll look at things
> > like Irrlicht and the other stuff I'm looking at.  Might be a good
> > idea to merge them with ephysics.  I suspect Irrlicht and ephysics
> > could complement each other, no reason why the GUI can't have
> > physics as well as the complex 3D world it's on top of.  B-)
> 
> Yeah, you may be correct.
> We can try to elaborate more about what these libraries provide and
> that could be
> added to ephysics or evas.
> 
> But for the next weeks I'll be focused on Edje.

Fair enough.  Nothing is moving quickly for me anyway, so no hurry.

> When do you plan to start to EFLize the SL stuff ?

I started last December and January with the EFL based LSL script
engine.  That progressed quite fast, but got held up on the actual
interfacing to the existing OpenSim system.  The person that said they
where going to do that vanished.  OpenSim is C#, and I really was
looking forward to someone else handling that side of things.  I don't
like C# much.  lol

Guess I'll have to do the C# stuff myself.  Oh well.

Since then I've mostly been busy with paid work and other things.
Slowly but surely I'm getting back into SL stuff.  That's why I plan on
starting to work with Irrlicht next weekend, see if I can embed it into
an Elementary window.  Can't call it Errlicht, that name is already
taken for the Eiffel bindings for Irrlicht.

I did manage a prototype SL user / grid manager with a little animated
3D image in elementary though.  I think it bit rotted.

Also, I had ephysics and effb compiled on Ubuntu 10.04, but now that
I've upgraded to 12.04 it wont compile.  Mind you there seems to be
four basic ways to compile bullet, maybe I picked the wrong one?  I'll
have to try that again soon.  I'll aim for an elementary window with
Irrlicht 3D world and ephysics 2D GUI soon, even if it does not do
much.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.