At this point in time, our engine is too closely tied to the IMVU content format to be generally useful anyway...
I trust someone like Floh to make something more generally useful. :) On Thu, Apr 10, 2014 at 10:37 AM, Alon Zakai <[email protected]> wrote: > Any chance to open source it? ;) > > - Alon > > > > On Thu, Apr 10, 2014 at 8:10 AM, Chad Austin <[email protected]> wrote: > >> These are exactly the same goals behind IMVU's new engine. :) >> >> We care a lot more about hardware compatibility, great performance, and >> reduced battery usage than we care about great visuals. >> >> Sent from my iPhone >> >> On Apr 10, 2014, at 2:00 AM, Floh <[email protected]> wrote: >> >> Ok, couple of points that I have in mind: >> >> (1) Min-spec will have to be OpenGLES2 and WebGL (1), which is quite >> different from modern desktop GL or console graphics APIs. While GLES3 and >> WebGL2 will close the gap a bit, I think that it's still important to >> support GLES2 for a while. Of course I still want to be able to do the >> fancy desktop-level stuff, so I'm thinking about a material system and >> rendering pipeline which is flexible enough that one can switch between >> different renderers (like forward renderer for weak GPUs vs different kinds >> of deferred renderers) without having to rewrite all material shaders for >> instance (so the shader system will have to be modular, and separate >> between a renderer-backend-specific part and a material-specific-part - >> that's nothing really new of course). Such a flexible system will also make >> it easier to experiment with new rendering effects. >> >> (2) I want to keep the compiled client small at all cost (1..3 MByte >> compressed for real games at most), so it's important to have a build >> system which lets one pick-and-choose what features to use, and not >> compile-in unused features (for instance, N3 has a dynamic object system >> where objects can be created by a class-FourCC-code or string-class-name, >> it cannot know beforehand what objects will be instantiated at runtime, and >> thus must "cheat" the dead-code-elimination, and force code to be linked >> which may or may not be used at runtime. >> >> (3) IO system designed for "random-access" on-demand streaming through >> HTTP, I want to keep startup time as small as possible, besides keeping the >> client itself small, this also means not downloading big asset bundles >> upfront. Instead the engine must be able to stream all data on demand and >> be able to handle the case when the data is not yet available yet. >> >> (4) Different threading strategy: I formerly used threads for 2 use >> cases: to hide blocking (so a blocking operation would run in a thread), >> and to spread work over additional CPU cores. Oryol will require threads to >> hide a blocking operation, instead use completion-callbacks and/or >> completion-polling for asynchronous operations. To spread work to >> additional cores there will be a parallel-task system which can either work >> completely on the main-thread and do its work in little slices, or move the >> work over to a worker-thread, or use pthreads. >> >> (5) Mobile GL and WebGL (also NaCl) seem to have a much higher >> call-overhead into GL then a native desktop GL implementation: >> https://github.com/bkaradzic/bgfx#17-drawstress, this will have >> influence the rendering features that make sense for a WebGL/mobile engine. >> If something requires a massive amount of draw calls, it probably won't be >> implemented in Oryol. The dilemma ist that techniques to reduce GL calls >> are either only implemented in modern desktop GL, or in extensions which >> are often not available in GLES2, Angle and WebGL. >> >> That's all I can think of for now :) >> -Floh >> >> Am Mittwoch, 9. April 2014 23:06:14 UTC+2 schrieb Alon Zakai: >>> >>> I'm curious, what are the design considerations that make this >>> specifically targeted at web and mobile? That is, what is different here >>> than existing engines? >>> >>> - Alon >>> >>> >>> >>> On Wed, Apr 9, 2014 at 12:05 PM, Floh <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> just wanted to let you guys know that I started a new "weekend-engine" >>>> a couple months ago, mainly as a sort of experimentation testbed of what a >>>> small C++11 3D-engine mainly built for web and mobile could look like: >>>> https://github.com/floooh/oryol >>>> >>>> Progress will be slow since it's a spare-time project, but one thing >>>> that will be useful (IMHO) in the short term is a growing list of samples >>>> which demonstrate and test specific, isolated features: http://floooh. >>>> github.io/oryol/ >>>> >>>> I think these samples will be useful for reporting, testing and >>>> tracking regression bugs in various browsers in the future (I learned that >>>> this is a bit complicated with relatively big engine demos like the Nebula3 >>>> demos, because it's hard to create isolated test cases). >>>> >>>> Cheers, >>>> -Floh. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Chad Austin Technical Director, IMVU http://engineering.imvu.com <http://www.imvu.com/members/Chad/> http://chadaustin.me -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
