On Wed, 5 Dec 2012 12:38:26 +1000 David Seikel <onef...@gmail.com> wrote:
> 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. This weekends progress report. I got Irrlicht to use the Elementary window. "Sharing" is not the right word here, they use the same window, but they don't play together well, so no actual sharing is going on. With Irrlicht software renderer, it flickers rapidly between EFL and Irrlicht, as both try to redraw the window ignoring the other, but at least renders right. Irrlicht OpenGL rendering has similar flickering, except there's lots of bitching from Irrlicht, and it's not rendering right, and even the Elementary GL test widget is not rendering right. Software rendering I should get it to render to a texture, then use that texture as a background. Unless there is some way to tell EFL to just render on top of what ever some other thing rendered into the window. I could not find anything, both just want to clear the window before their renders. No amount of fiddling with transparency helped that. OpenGL rendering is a matter of delving deep into the guts of both EFL and Irrlicht, to make sure they are on the same page. Likely this will mean changes to the deep internals of one or the other, or perhaps both. I wanted to see how far I can get with out this sort of deep surgery first. That's why I wasted much of the weekend not getting very far. lol Mostly I think the issue is the OpenGL context and surface. They should be sharing the one instance of each, but they are both written in an OOP "you don't need to know the implementation details, so that's carefully hidden" style. Problem is, I do indeed need to know these carefully hidden details. So I gotta do two lots of trawling through "hide the details" OOP goop to find what I'm looking for. Irrlicht has a method of saying "just use this context / surface I prepared earlier", the problem is that it's not documented on the OpenGL side what it actually needs, though the DirectX side is slightly better documented. In both EFL and Irrlicht, these things are void pointers, due to them needing to be different things at the hidden lower layers. So EFL's idea of the OpenGL context is not the same as Irrlichts idea. Simply passing one to the other did not work. And buggered if I know what either sides idea is, undocumented void pointers on both sides does not help. I hope I can get EFL and Irrlicht to cooperate with out too much deep surgery, that is my goal. I think just adding a function to Evas_GL that exposes some more internals in a way that Irrlicht is happy with should do the trick. I just gotta sort out what's actually going on deep in the guts of both so I can get them to agree on what is what. Next weekend - I'm going deep OOP goop diving. If I'm not back by Tuesday, send a search party. -- 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
