On Tue, Dec 4, 2012 at 10:37 PM, Bruno Dilly <bdi...@profusion.mobi> wrote: > On Mon, Dec 3, 2012 at 11:39 PM, David Seikel <onef...@gmail.com> wrote: >> 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. > > Yeah, I'm interested, indeed. > >> >> 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 > > Right, I suppose it would be the way to go. > >> 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. > > Thank you for the email, and good luck with the shared window issue. > I couldn't propose a solution for that. I would need to investigate it > better too.
For using OpenGL with an Evas canvas, there is two possibilities in my opinion. Either put the canvas in a texture and give it to the 3D engine, or use EvasGL API and make the 3D engine integrate inside Evas. It is possible to have a direct rendering path with EvasGL and so have a fastest possible path. -- Cedric BAIL ------------------------------------------------------------------------------ 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
