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. Regards > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > 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
