On Sat, 11 Jan 2014 19:07:06 +1000 David Seikel <[email protected]> said:
this is way too long. i just skimmed. i'm going to cut it down to the gl supporting bits of efl you need/want for ALL cases of gl rendering with efl - virtual worlds or not. it's not relevant. 1. use the preferred engine set. end of story. it isn't broken. it works. i have a 3d modelling from christophe app proving that it works. it works now. today. check it out. go google for "slime" on github. you have messed up somehow in an unknown way to me - but it WORKS. look at slime. (and nice work christophe!) 2. you didn't get my point. you really didn't. don't FORCE the opengl engine down peoples throats. your entire view is based on the erroneous assumption that the preferred engine doesn't work. they may not have working gl driver support. just PREFER it. let the end user decide if they like the framerate or not - if you prefer opengl_x11 then it is used IF available... and it falls back to software_x11 if not. at least it still works. the above #1 handles that gracefully for you without fiddling with core config. 3. elm_glview is just a convenience wrapper around evas_gl to make it easy to use and integrate. it's a good idea to use it if you want an easy life. 4. evas exposes an opengl-es2 api. any existing engine needs to be adapted to use this. that's pretty much the end of that. if the engine doesn't have a gles2 port.. it will need one. once it has one, then it is a simple matter of replacing all the gl calls as follows: glDrawArrays() -> api->glDrawArrays() glBindBuffer() -> api->glBindBuffer() you could make the port switchable with a macro: #ifdef EVASGL #define EG() my_evas_gl_api-> #else #define EG() #endif then fix up all the gl calls to be EG()glDrawArrays() EG()glBindBuffer() etc. doing the above allows evas to decide how to share context. it may allocate a separate context or share its own. either way as far as the evasgl api user is concerned.. they get their own private context to play with. if it does NOT do the above (use the api exposed by evas gl) then wrapping can't context switches can't work. all gl calls HAVE to go through the wrapped api to work right. this is because we can't REPLACE the internals of the gl driver which otherwise would be managing context and state all internally and we have zero access to that - especially with closed drivers. we'd end up writing a proxy gl library which conflicts with real gl symbol-wise (thus taking over and replacing normal gl calls) and i know i have no interest in maintaining a separate libGLwhatever.so that is an exact copy of gl and it's api's just to wrap it when we expose that wrapper without symbol complications via evas gl. 5. the engine will need to be adapted so the draw function is callable - eg by elm_glview. then it's easy to switch where rendering happens. evas offers a fast path to avoid buffer copies and make the gl view draw part of the evas rendering path directly. this would offer almost zero overhead vs doing it directly with egl/gles etc. to your backbuffer yourself, BUT gets you the bonus of having your 3d view as part of a larger scenegraph. combine 2 or 3 of them in a single window. overlay with evas objects or elm widgets for hud etc. all for free. this also implies the engine has to integrate to the efl mainloop etc. of course. 6. no not everyone has 3d drivers on their desktop - or not ones that can work with efl. the laptop next to me has an ancient intel chipset. it can't be used by efl at all. it doesn't do shaders (opengl2). it is one of my test boxes. no not everyone has drivers. i can point out a cyrix/via based netbook i ditched not long ago... no accel. can i point out all the recent efforts of people getting linux on the baytrail tablets/laptops? they can get it up.. without any gl accel. but accel simply isn't working for them. same situation as the arm soc angle. 7. i have no idea how you shared a gl context with efl with irrlicht and your playground, but if you didn't use evasgl/elmglview.. you were playing with "it's not meant to work and you just had it by luck". look at the elm test code for gl - the tests work. look at slime as above. it works. that's what you need to know. :) > I'm starting this fresh. Maybe if I specify what it is that I'm doing > in terms that any one can understand, we might actually get somewhere. > > I want to dedicate my life to making virtual world software great, so > I'm passionate about this subject. I'm also passionate about EFL, so I > want to use EFL for the infrastructure and the UI. So far Elementary > has not impressed me, but at least I'm still trying it out. > > There's lots of big parts to what I want to do, and I really don't want > to take a decade out from my main goal to write one of those big parts > from scratch each time. So integrating already written big parts is > important to me. I'm 53 this month, I'm not getting any younger, and I > want to finish this before I turn senile. I know, some of you think > it's too late, I'm already senile. B-) > > TL;DR - a modern 3D game lives and breaths by it's frame rate, and they > get their good frame rates by using hardware 3D acceleration. Modern > 3D game developers want access to the 3D hardware if it's available, > by default. They also want to use a 3D graphics engine written by some > one else. If they want to use EFL, they want that AND EFL UI goodness > overlayed on top. So it's important for these parts to cooperate and > perform well. How do we do that? > > > WHAT ARE VIRTUAL WORLDS - > > Virtual worlds are not a game, and not just 3D modelling software. > They are very game like in the basic technology though, and I have lots > of trouble trying to explain to people how they are not games. But > since this discussion is about the technology, and the lack of actual > game mechanics is not important at this level, I'll just bite the > bullet. Lets discuss making a game. Coz lets face it, if we can get > this all sorted out, 3D game makers might start using EFL. > > Second Life (SL) is a popular virtual world, but it sucks in so many > ways and is a walled garden. It's the basis of what I'm trying to do > though. I'm trying to make it not suck, and not be a walled garden. > There is a lot they got right in their concepts though, one reason why > it's popular. I want to use the open source SL viewer, and the open > source SL server clone (OpenSim) as "it already works" structure that I > will rip great chunks out of and replace with sane code. That way I'll > always have something that works while I take many years to make it not > suck. > > Skyrim is a popular open world / sandbox RPG game. It consists of a > huge 3D world (size of a modern large city, filled with all the > minutia you would expect to find in a city and country side), with > wonderful 3D graphics, really large draw distance, and GUI elements on > top of that. The player is free to wander anywhere in this huge 3D > world at any time. Hopefully most people here have played this or > similar games, or know about this sort of game. Big, open, 3D, world. > Rendered in real time, but with some stuff pre rendered. > > Virtual worlds are very similar, except there's no actual game system > on top of it. Also, in virtual worlds multiple people can connect over > the network to the same world, and interact. People can build their own > stuff in world, in fact a lot of the time the entire world is user > created. People can script the world. It's all one huge world filled > with all the sorts of crap the real world is filled with. Landscape, > trees, people, animals, monsters, buildings, sky, moving clouds, water, > waves, stars, sun, moon, pots, pans, plates, cutlery, vehicles, weapons, > jewellery, clothes, etc. Oh and hair, OMFG hair, the hair on one > person can be a huge resource sucking hog, let alone a crowd of > people. Then there is me and my beard. All fully textured. There > is particle effects, materials, transparency, and all that other usual > 3D rendering fanciness. All of this is rendered to the screen as 3D. > In real time, no pre rendering. Across the Internet. > > On top of these beautiful, rendered in real time, big complex 3D worlds > is some sort of user interface. I want to use EFL for this UI. > Actually I want to script the UI with Lua. A also want to script the > world with Lua. I want my users to be able to script UI and world with > Lua in the same script. I want to convert the horrid SL XML UI crap to > Edje Lua, preferably automatically, but these last things are for > later, and not part of this discussion. > > Sooooo, let's talk about writing Skyrim in EFL, since I think more > people will understand that than understand virtual worlds. Hell, most > people that use virtual worlds don't understand them. People > understand games. The tech challenges are the same. Let's pretend the > Skyrim developers fell in love with EFL and want to write Skyrim 2 with > EFL. How do they do that? How do we help them? > > > PERFORMANCE - > > This is the big sticking point in the previous discussions. Skyrim is > a 3D game. Rendering the 3D world fast is VERY VERY IMPORTANT. Yes, > software fallback for rendering for UI is acceptable, but not for the 3D > world. For the 3D world rendering it is of utmost importance that if > the user has 3D rendering hardware, that it gets used by default. Ask > any gamer, half the time they'll talk about their hundreds of FPS that > they get on their gaming rig, and how they tweaked things to get it > higher. Never mind that the human eye only operates at less than a > hundred "frames" per second. Though in the end, if the game can render > at hundreds of frames per second, that means it's spending less time > rendering, and can have more time for other things. > > Raster - this isn't bringing up a SOC where the graphics drivers are > not written yet and 5 FPS is OK for now. The drivers exist already on > peoples desktops. This isn't a 3D modeller where showing simple things > slowly is OK. This is not a ten year old game where 10 FPS is good. > This is NONE of those things where software rendering is any sort of > solution. I know you are fighting for those things, this is NOT that > fight. Please drop that fight in this discussion and think about this > real problem - modern big 3D games on desktops. > > Every modern 3D game tries to use 3D rendering hardware. Almost all of > them just flat out refuse to run if they don't find any. Try telling a > modern 3D game writer or player that software rendering is good enough, > and you WILL get laughed at. Software rendering is not an option, > forget about it. Sure it works OK for the UI, but a 3D game that shows > just the UI is unusable, it's the rendered 3D scene behind the UI > that's important. On the other hand, a 3D game that has the UI in a > separate window is also not good, especially when the game is > fullscreen and there are no external windows. 3D scene and UI need to > be combined. > > (As an aside, yes I do intend to have software rendering as a fallback > option for those cases where the user has no 3D rendering hardware. > It's a fallback, not the main aim. In such cases the user expects > their crappy ten year old student laptop to perform slowly anyway. But > for people with real 3D hardware, it should be used by default. People > expect their thousands of dollars high end gaming rig to perform fast. > People in the middle expect performance in the middle, not software > performance by default.) > > > Let me be perfectly blunt - CAN'T DO 3D GAMING WITHOUT 3D HARDWARE > SUPPORT. It's just entirely pointless, and a waste of time. Any > arguments to the contrary will be ignored. That's not what this is > about. > > > UI - > > I want to use EFL as the UI. I'm still not convinced yet about using > Elementary, but I am trying it out. I could use raw Evas, as I have > done in previous stuff I have written. EFL these days uses GL of > various sorts deep within it's guts, even if it's just software > rendered GL. Eventually I want to use Edje Lua, but Edje Lua is my > problem to solve anyway. > > (I did a lot of the current Edje Lua implementation, driven by my need > for it in an older project that is finished now. I intend to drive > further Edje Lua work with this Skyr.. er I mean virtual world project. > That's why I already have experiments for doing world scripting using > EFL and Lua.) > > For the Skyrim 2 game there will be UI elements rendered on top of the > 3D scene. There will be "windows" of some sort rendered on top of the > 3D scene. So the high performance 3D rendering system and the UI > rendering system have to cooperate to render to the same surface. > > Raster - you mentioned a couple of times that having multiple GL > contexts is a slow resource hog, so sharing one makes a LOT of sense. > Especially since performance is important. > > (Also I intend my system to have windows internal to the main 3D window, > and to allow those windows to be "torn off" and used as first class > windows in what ever window manager the user is running. So some sort > of internal window manager running in the 3D scene is also part of my > goals. I know we have one, but I've not looked at it yet. No idea if > it can work with Elm. This is not important for now.) > > > 3D GRAPHICS ENGINES - > > Writing a full blown 3D graphics engine that is suitable for modern > big 3D games like Skyrim is a very big and hard job. That's why there > are not very many of them already. There's about as many full blown 3D > graphics engines as there are UI toolkits like EFL. We all know how > hard it was to write EFL, and how many years it took our team to do so. > But such things are needed, and most modern 3D games use them. In fact > most modern 3D games use one that was written by someone else - Unity, > Unreal, OGRE, Irrlicht, etc. Coz it's too hard to write your own. > > Writing a big complex 3D Skyrim type game, or virtual world system, is > hard and complex enough by itself. I'm only one man, I'm not gonna > write my own 3D graphics engine as part of EFL. I doubt if any one > else wants to either. I don't think we want a full blown 3D graphics > engine inside EFL. Though I would love a proper full blown 3D graphics > engine that is based on EFL and suitable for big 3D games, but that's > just a pipe dream. Hell, I'd be happy with one written in C, but C++ > seems to be the language of choice for the people that write them. > > So getting EFL to live with third party 3D graphics engines will be > needed for Skyrim, and for virtual worlds, and 3D games in general. > Performance needs to be good. Performance needs to be great. > > These third party 3D graphics engines often allow various backends, > OpenGL, DirectX; and some work on various OSes, Linux (if you are > lucky), Mac (sometimes), and Windows (crap, but it's what "most" people > use). I want to support Linux, Mac, and Windows. Eventually I'll add > Android. I just spent too much money an genuine Apple hardware > specifically so I can do virtual world development (and EFL porting) > for Mac OS X. Maybe I'll support iPhone in future to, but I have to > get over my last Apple spend first. lol > > OpenGL actually works good on all those operating systems, so I really > don't mind sticking just with OpenGL, in fact that's my plan. It > works, it's everywhere, anything else is just Yet Another Distraction > in my life goal. > > I looked at open source 3d graphics libraries, I specifically looked > for one that was good on low resource and ancient hardware. OGRE > didn't fit my requirements. Irrlicht did. I was particularly > impressed with the Irrlicht software renderer. > > Raster - See? I can live with software renderers, but there's a place > for such things, and it's not the main aim here. > > No doubt people will want to use OGRE, or Unity, or any of the other 3D > graphics engines that are popular. They will have the same issues. > > > WHAT I'M TRYING - > > I have a playground app where I'm trying to get EFL GUI and Irrlicht to > play together nicely. So my previous experiment managed to get EFL 1.7 > and Irrlicht to share a GL context and render to the same window. This > was working fine, and I started to implement more of the basic code for > the 3D world. This playground app is also where I'm trying out Elm, to > see if it will work for me. So far, I'm not impressed, and really > annoyed at the excess screen space used, but that's another topic for > another place. Yes, it's a theme issue, me writing a them is Yet > Another Distraction. > > With EFL 1.8 this playground app stopped working. A bunch of things > stopped working, and I've spent a lot of the last week trying to get > them to work again. > > I'm trying both Evas_GL and Elm_glview, with #if around those parts. > Trying to see which one works best for my goals. Both Evas_GL and > Elm_glview bit rotted. That last thread of mine went over that, it > wasn't the lack of osmesa, get over that. I've fixed my Elm_glview > usage, but that's a hack to select X11 OpenGL (not "prefer", that only > works if the user selected OpenGL in elementary_config, which is a > silly thing to ask game users to do). Cedric said he'll work on that > part of Elm to make it better. I'm prepared to wait for his fixes. > This is just a playground to see if I can get everything to play nicely. > > Given the previously mentioned need to share GL context, there's two > ways to go about it. EFL creates the context and shares with Irrlicht, > or Irrlicht creates the context and shares with EFL. Irrlicht had > Windows code to use a GL context created elsewhere, EFL 1.7 may have, > it was not well documented enough for me to figure out, and the guts of > EFL GL code is a twisty little maze. Irrlicht was not happy sharing > out it's created context in my first experiment. Evas_GL has API for > creating GL context, and I patched up Irrlicht so Linux could share > context like Windows can. This last is what worked, but obviously not > in the Elm_glview version. > > Yes, I'm aware that this is using multiple contexts rather than sharing > a context. One step at a time, but still want to get to the point > where the EFL context is shared. > > Right now in my playground app and latest EFL git I have Elm_glview > working showing rotating gears. Evas_GL isn't working now, but now > that Raster fixed up the Evas_GL example to work, I can refer to that > to get Evas_GL version working again. It was pointless referring to a > broken example. Once I have done that I'll see if I can get the > Irrlicht integration working again. That might just work anyway once > Evas_GL works again. > > > GETTING THERE - > > As mentioned above, this playground app creates a new GL context, but > there's still the EFL context buried somewhere, and Raster mentioned a > couple of times that having multiple contexts is a bitch for > performance. So, how do we deal with that? > > "Just use software rendering" that I was constantly hit over the head > with yesterday is not an option. Serious 3D game developers will just > walk away, for the reasons I detailed above. Certainly you can't do > Skyrim that way. Virtual worlds can use software rendering as a > fallback, but it's still important to use actual 3D hardware by default > if it exists. With no jumping through hoops for users or developers. > > Use multiple GL contexts? While this worked in EFL 1.7, and I might be > able to get it to work in EFL 1.8, it's likely to be a performance > bottleneck if what Raster says is true. Frame rates are gold for 3D > games, this sort of lower performance will be a deal breaker for > developers, coz it's gonna be a deal breaker for game players. All > that extra memory usage from multiple contexts that Raster mentioned is > also a problem for me. I want my result to still work on resource > constrained devices, just like EFL. > > Share the EFL context with others? This seems to be controversial > enough that people keep trying to side track me with this "use software > rendering" and "make your game players install software rendering so > their hardware rendering works" nonsense. Bottom line, if this can't > be done serious 3D game people wont take EFL seriously, and that's a > big shame considering what EFL can do for 2D game people. EFL now > insists on using GL, but wont share. > > Raster - in an earlier thread where you detailed the issues with using > multiple GL contexts, we discussed sharing. You implied it could be > done. Even though this is where you went through the problems of > multiple contexts, and I thought that's one of the things we were > talking about, perhaps your half of the conversation meant "multiple GL > contexts is a bitch, and Evas_GL only supports using multiple contexts" > but you really did not mean "multiple GL contexts is a bitch, and > EVAS_GL supports sharing it's one gl context with apps". > > > SOOO, PRETTY PLEASE WITH SUGAR ON TOP - > > Can we have some support in EFL for the sorts of 3D game developers > that write stuff like Skyrim, or pretty much any modern big 3D game, > or even virtual worlds? I'm happy to do the grunt work to make EFL > examples and write EFL docs, that's exactly what I'm doing now. But > the deeper support is needed in EFL, and I'm not sure it's there yet. > It certainly is not stable in the experiments I've been trying. > > If this sort of support is there already, then how is it done? What > am I missing? > > > /me goes back to trying to get Evas_GL in my app working again with EFL > 1.8, then the Irrlicht integration. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
