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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
