On Wed, 5 Dec 2012 10:36:54 +0900 Cedric BAIL <cedric.b...@free.fr> wrote:
> 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. I like the sound of your second idea. Irrlicht is cross platform, and in this case that means it supports OpenGL, DirectX, and software rendering. Software rendering I think is a good idea for my major use cases (users with old shitty student or business laptops with crap or non existant 3D support). OpenGL is also good for my use cases, and is basically cross platform (works fine on Linux, Mac, and Windows). DirectX is Windows only, though I understand that Microsoft deliberately slowed down OpenGL on Windows to make DirectX faster, but that nowadays they are both basically the same. Personally I'd like to just go with OpenGL and software rendering, and not bother with DirectX. I could probably get away with that to start with. See how many people bitch that it's too slow an Windows. -- 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
