On Sun, 2 Dec 2012 12:25:40 +1000 David Seikel <onef...@gmail.com> wrote:
> On Sat, 1 Dec 2012 18:19:52 -0200 Bruno Dilly <bdi...@profusion.mobi> > wrote: > > > On Sat, Dec 1, 2012 at 3:41 AM, David Seikel <onef...@gmail.com> > > wrote: > > > On Wed, 28 Nov 2012 13:15:42 -0200 Bruno Dilly > > > <bdi...@profusion.mobi> wrote: > > > > > >> On Wed, Nov 28, 2012 at 11:30 AM, David Seikel > > >> <onef...@gmail.com> wrote: > > >> > On Wed, 28 Nov 2012 10:46:00 -0200 Bruno Dilly > > >> > <bdi...@profusion.mobi> wrote: > > >> > > > >> >> On Mon, Nov 26, 2012 at 10:59 PM, David Seikel > > >> >> <onef...@gmail.com> wrote: > > >> >> > On Mon, 26 Nov 2012 14:55:26 -0200 Bruno Dilly > > >> >> > <bdi...@profusion.mobi> wrote: > > >> >> > > > >> >> >> Hi David, > > >> >> >> > > >> >> >> On Mon, Nov 26, 2012 at 1:36 PM, David Seikel > > >> >> >> <onef...@gmail.com> wrote: > > >> >> >> > On Mon, 26 Nov 2012 12:47:16 -0200 Bruno Dilly > > >> >> >> > <bdi...@profusion.mobi> 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. > > >> > > >> oh, nice > > >> > > >> > > > >> >> 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. > > >> > > >> yeah, it would be a good name, indeed. > > >> > > >> > > > >> > 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. > > >> > > >> I'm using ubuntu 12.04 too, and it is working fine (I'm using > > >> bullet rev2537). Built with cmake, looks like autotools is not > > >> well maintained. > > > > > > I'm using the latest release of Bullet 2.81 rev2613. There were > > > warnings that using GLUT was obsolete, and that I should use > > > OpenGL instead, even though it detected both. You would think it > > > would just use OpenGL then. Told it to not use GLUT, and now > > > ephysics compiles and runs fine. I also installed OpenCL for it > > > to use, but I don't think that's why it failed last time. Yes, > > > built with cmake. > > > > > > Now it's the weekend, I'll squish together Elementary, ephysics, > > > Irrlicht, and other stuff to see what I can get. > > > > Oh, good news =) Just to keep you informed, since you seemed interested, here is the results of my weekends experiments. Adding ephysics and Irrlicht source code into my existing Elementary test bed worked out well, except for one major problem. Since that proggy had not been worked on for some time, it had bit rotted after changes to Elementary, so I had to fix that up first. Elementary itself had bit rotted, it grew a new bug, which I reported, and apparently discomfiter had already reported. Perhaps the recent naviframe changes fixed that now? I'll update SVN later and see. Then I cut and pasted stuff from the ephysics no gravity test, so there was something with ongoing activity to test with. That went smoothly. I changed it to reuse the existing main window, and to use the size of that window, not the hard coded sizes no gravity test had originally. The result is two ephysics objects slowly bouncing around on top of the Elementary widgets, and bouncing off each other, all in one window. Note, one of those Elementary widgets is an OpenGL widget for testing, since I knew I'd be adding 3D stuff to it eventually. Finally I grafted the Irrlicht hello world tutorial onto this proggy. It involves a loop animated woman and a bit of GUI that says "hello world". I removed the GUI bit, since the whole point of this is to use EFL as the GUI, leaving the mesh women. I split the hello world main() routine up into bits (init(), render(), shutdown()), got rid of the main(), and called the bits from the right places in my main C proggy. Irrlicht does not have a main loop, you are expected to write your own, so it fits in well with EFLs implicit main loop. I just added the render code from the examples main loop to the callback that renders the Elementary 3D widget. Irrlicht, like Bullet, is a C++ library, so their hello world proggy is C++. So now my proggy has a C and a C++ file. I left the Irrlicht stuff with it's own window. This worked well. Now for the major problem. Both EFL and Irrlicht are cross platform libraries that jealously guard their inner windows. So there was no easy method to get EFL and Irrlicht to both share the one window. I've not yet found a way to get to the raw windows pointers used by EFL, though Irrlicht does have a way to get that. I've not found any way to tell EFL "use this window I already made". Irrlicht has a way of using an externally created window, but the docs say it only supports MS Windows for now. I assume this means Linux and Mac support for that is planned. The main Irrlicht developer is a MS Windows developer, so Windows versions have a tendency to get implemented first. There are more Irrlicht developers now, and I think one of them at least tends to do Linux stuff first. What I would prefer is to have EFL manage the window, and have Irrlicht just use the EFL created one. So the end result is one program, two source files (C and C++), two windows (EFL and Irrlicht). One shared window is the goal, then I can see how to get all this stuff to interact with each other. With a Irrlicht based 3D world as the background, Elementary widgets over the top for the GUI, and ephysics to get them to bounce off each other. It's entirely possible that some in world objects could be ephysics objects at least part time, I'll see once I have it all interacting and get to the "actually make the thing useful" stage. I'm still investigating solutions for this shared window problem, but the weekend is over and I got a busy week to deal with now. Something for next weekend. My end goal, if I can get EFL and Irrlicht to play nice with each other, will be to integrate them. I suspect the best way would be similar to ephysics, write a C EFL wrapper around the C++ Irrlicht library. Irrlicht is very easy to use, cross platform, has a decent software renderer, and you can extend it for those things it can't do. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
