On Mon, 10 Dec 2012 14:43:52 +1000 David Seikel <[email protected]> wrote:
> On Wed, 5 Dec 2012 12:38:26 +1000 David Seikel <[email protected]> > wrote: > > > On Wed, 5 Dec 2012 10:36:54 +0900 Cedric BAIL <[email protected]> > > wrote: > > > > > On Tue, Dec 4, 2012 at 10:37 PM, Bruno Dilly > > > <[email protected]> wrote: > > > > On Mon, Dec 3, 2012 at 11:39 PM, David Seikel > > > > <[email protected]> wrote: > > > >> On Sun, 2 Dec 2012 12:25:40 +1000 David Seikel > > > >> <[email protected]> wrote: > > > >>> On Sat, 1 Dec 2012 18:19:52 -0200 Bruno Dilly > > > >>> <[email protected]> wrote: > > > >>> > > > >>> > On Sat, Dec 1, 2012 at 3:41 AM, David Seikel > > > >>> > <[email protected]> wrote: > > > >>> > > On Wed, 28 Nov 2012 13:15:42 -0200 Bruno Dilly > > > >>> > > <[email protected]> wrote: > > > >>> > > > > > >>> > >> On Wed, Nov 28, 2012 at 11:30 AM, David Seikel > > > >>> > >> <[email protected]> wrote: > > > >>> > >> > On Wed, 28 Nov 2012 10:46:00 -0200 Bruno Dilly > > > >>> > >> > <[email protected]> wrote: > > > >>> > >> > > > > >>> > >> >> On Mon, Nov 26, 2012 at 10:59 PM, David Seikel > > > >>> > >> >> <[email protected]> wrote: > > > >>> > >> >> > On Mon, 26 Nov 2012 14:55:26 -0200 Bruno Dilly > > > >>> > >> >> > <[email protected]> wrote: > > > >>> > >> >> > > > > >>> > >> >> >> Hi David, > > > >>> > >> >> >> > > > >>> > >> >> >> On Mon, Nov 26, 2012 at 1:36 PM, David Seikel > > > >>> > >> >> >> <[email protected]> wrote: > > > >>> > >> >> >> > On Mon, 26 Nov 2012 12:47:16 -0200 Bruno Dilly > > > >>> > >> >> >> > <[email protected]> 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. <major snipage> > > > >>> > > 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. <This is the only bit Cedric wrote, in case my snippage and the novel length stuff messed up the attribution.> > > > 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. Well, this got bumped to Christmas, but I'm baaack. B-) First I refactored large parts of my test proggy. It was using Evas_GL and ELM GL, with lots of duplication. Elm GL has bit rotted, not in my project, but in ELM, even the ELM test no longer works. So I just got rid of that and went with pure Evas_GL. I'll go back to ELM GL objects when that's fixed. This refactoring also cleaned up which parts of the code are responsible for what. It's much cleaner now, not just a frankenstein copy and paste mess like it used to be. With a little light surgery on Irrlicht I managed to get it to use the OpenGL surface and context that Evas_GL created. That previously mentioned new Evas_GL function did not help, it's not returning what I thought it was returning. Irrlicht and Evas_GL are still not quite on the same page though, Irrlicht renders ... something ... and it moves to the same rhythm as it should, it's just all squished up strangely, and stuffed in one corner. Plus, I get strange artefacts when the ephysics objects move over ELM objects, but it's fine when they move over the Evas_GL object that Irrlicht is drawing to. The ephysics objects leave a short trail as they move across ELM objects. So progress has been made, but they are still not sharing everything properly. This little bit of light surgery is basically making the "let Irrlicht use OpenGL stuff someone else created" actually work, so when it's done, my patch is likely to get accepted upstream. I did investigate "make a new Irrlicht engine that uses Evas_GL as the backend". Irrlicht is designed to allow that sort of new backend creation. There are two problems with this - A) my investigations seem to point to a need to patch other bits, so not a clean "just add this file" change. B) the experience of others trying to use things like QT and wxWidgets means that such a thing is not likely to be added to the main source, but kept in their modules area, which wont work too well if other patches are needed from A). I'll stick with my current patch work for now, see how far I can get with it before trying the "make Evas_GL engine for Irrlicht" route. On the plus side, I suspect that most of the work involved in doing this engine would be to copy the OpenGL engine, then a global search and replace to get Irrlicht to use the Evas_GL OpenGL function pointers instead of direct OpenGL calls. I've come up with a name for this - EnLichtIrrnment. B-) -- 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
------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
