So you are misunderstanding what I'm doing due to your admitted not reading what I wrote at the top of this thread. Please read before you argue then. :-P
I AM reading what you are writing, but it's obvious you are not talking about what I'm talking about. What you are saying implies primitive 3D, as you actually pointed out in the quoted bits below. I'm not doing primitive 3D, as I pointed out to begin with. On Sun, 12 Jan 2014 11:49:24 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote: > second life is nor hard core 3d. > it's primitive 3d. hard core 3d is very far from what you are doing. Second life has progressed from primitive 3D. When I go to great length to to explain how what I am doing is more Skyrim than Second Life from ten years ago, you could at least read it. B-) Specifically what I am doing is making SL type technology more hard core. As hardcore as Skyrim, that's why I mentioned Skyrim. I also want to make SL type technology more generic, and bust out of SL's walled garden. > hard core 3d has shaders on everything with those shaders being 100's > or 1000's of lines of GLSL, Yep SL has that. I've not actually counted the lines, but there's a big directory tree with hundreds of GLSL files, I suspect they come to thousands of lines easily. > often runtime generated GLSL from templates, Nope not got that, but I want to add something like it. Not hard to add though. It's just text manipulation before you pass the resulting GLSL to the compiler. Been there, done that. > that provide specular lighting, bump/height maps, with > multiple rendering passes for multiple shadow maps (self shadowing > too) with filtering, bloom filters for glow, Yep, SL has all of those. > and other camera effects, motion blur, Other camera effects yes, motion blur no. > physics simulation with water, clouds (volumetric rendering) Yep, SL has those. Well, no physics in the water, but there are water waves, plus reflection and refraction. Physics they got, SL uses Havok, OpenSim uses a home grown physics engine, but is in the middle of switching to Bullet. Water physics has been simulated via the built in SL scripting engine, I wrote one myself. > and insanely high resolution textures where > you're pushing a 1gb of texture memory far beyond its limits. SL has a limit of 1024x1024 on textures, a limit set many years ago. I want to increase that. They used to have a limit of 2048x2048, long ago, but they cut it down further for their own reasons. Apparently there's still some ancient content with the higher resolution hidden in their content servers that slipped past the cut off. They also have an artificial limit of half a GB of texture memory usage, again I'd like to remove that limit. In fact, I want to remove all of the SL imposed artificial limits. > if your engine is anything close to second life, your 3d is far from > hard core. if it's close to what i just described, then you are > impressive as you're in the ballpark of unreal, latest id tech > engines etc. which are massive undertakings. So yes, the current SL engine is close to what you describe. Pretty much the only thing missing is motion blur, but that's likely coz SL didn't think to add it. Likely it could be added relatively easily to the current SL engine. The entire first post on this thread was equating SL style virtual worlds with Skyrim, this is why, they are both hard core 3D. By your definition they are, and by my definition they are. I guess you have not looked at Second Life or OpenSim recently. Even if SL itself was not that hard core, it's my goal to make it even more hard core than it is. That's the entire point of all of this. B-) The SL engine is crap, hobbled by lack of imagination, the need to monetize every little thing, and a long history of bad development decisions. I want to replace it with a real engine that does all the extra hard core stuff that SL doesn't do, and does things more generically, and easily grows in directions SL either doesn't want to go, or that they didn't think of. And yes, a massive undertaking, which is what I have been saying all along. This is why I want to use some one else's open source engine, much less work for me. I just have to get this engine to cooperate with EFL in a way that EFL developers and the engine developers are mutually happy with. I want to push what ever changes I have to make to their engine upstream and hope they accept it. That's why I'm really reluctant to make massive changes to their source code. There's enough flexibility in their system that I might be able to, but I don't know yet. I also don't want major changes to EFL just to suit my whims. I'll have a look at your suggestions for changing the Irrlicht engine, and see if I can do that in a way that is acceptable by upstream. Before I do that though, I'm going to see if I can get my playground app to share the window with EFL and Irrlicht like it did last year with EFL 1.7. Coz that's all least a minimal change to Irrlicht that I know they'll accept, since it pretty much brings Linux inline with their existing Windows support. I'm not so sure the Irrlicht developers will accept your suggested EFL porting. Maintaining my own private fork of a major sub system is not an option, part of the reason I want a real 3D graphics engine written by others is so that they do all the hard work of updating it with new features and bug fixes. Keep in mind please that my major goal is itself a massive undertaking that might take me very many years. There are many big parts to this that I really would love to just become a systems integration problem for me instead of having to write those big parts from scratch. So yes, I'll fight to keep things at a systems integration level instead of a write or rewrite major systems level. Coz I'd like to get major parts of my goal up and at least limping along before the end of the decade. Hell, I want to get a basic "here's all the major parts working together" test thing running by the end of this year. In this case the major parts include EFL and Irrlicht. Last years EFL 1.7 + Irrlicht 1.8 based "they share a window" thing fitted my "all parts working together" sub goal. I'm jinda pissed it bit rotted, but that's life. Deeper integration involving sharing GL contexts is for the future, so I know I can go there when it comes time to tweak performance. Specifically your constant mentions of how much of a bitch it is to have multiple contexts makes me worry about that more, and makes me try to make sure I can do it, keeping in mind my future goals. I'm between a rock and a hard place here, trying to find wriggle room. There's a big lack of docs and examples for doing this sort of thing. Once I get it working, and it stays stable, I'll document it all, and push docs plus examples to our git. If after twenty years I'm happy with the bolted together frankenstein system I produce to suit my goal, then I'll take time to actually write an EFL based 3D graphics engine in C, I promise. 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
------------------------------------------------------------------------------ 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
