[color=rgb(0,0,0)][font=Arial]
[background=transparent]With this second entry I find myself ecstatic over my own personal introduction to WebGL. This subject gives me the opportunity to invest myself in a new community and it stamps the beginning of a new journey. A journey that will no doubt last as long, if not longer than what I've experienced as a software engineer to date. The obstacles in front of me look familiar and there is a familiar taste to everything, I think this will be a long lasting friendship...[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]Beyond the Basics[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]I'm not ready to jump into an entry or article series that walks you through writing shaders, interpolation of colors, how we can properly create lights or any of that today. It's a tempting task to perform for sure, provide a community something "meaty" they can use to bootstrap something fun. The payoff here is really not great though because honestly, anything I can give you in a quick entry is already covered by MDN or some other person who has invested far more time here. If I'm giving you a series on JS then it's going to be meaningful, useable code because that's what I believe in distributing.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]That being said I've come to a point that I often do when learning a subject when I've poured over countless articles, tutorials and read the same API method doc. 10 times. I'm ready to apply to a problem, because that's where the bridge lies for this developer. After the past week or so the world of WebGL engines has opened up to me, and three candidates have made my short list for contributions so far:[/background]
[/font][/color].
[background=transparent]Three.js (threejs.org) - I'm very impressed with the code quality of this project, and there seems to be a good number of projects using the engine. I'm a fan of the underlying modular architecture, not just to say it uses AMD for dependency management, but the fact that we can swap sub-systems.[/background]
[background=transparent]BabylonJS ([/background]
[background=transparent]http://www.babylonjs.com/[/background]
[/color][background=transparent]) - I like the editor included here and the project has some very good examples demonstrating various shaders. The community seems very active and I can see many issues I could potentially sink my teeth into.[/background]
[background=transparent]PlayCanvas ([/background]
[background=transparent]https://playcanvas.com/[/background]
[/color][background=transparent]) - Seems to be a more popular commercial choice and includes a hosting service which makes it easier to get your game distributed and get ad content into your game. I'm more interested in contributions to graphics here, but it gave me an idea take away for data persistence through web sockets.[/background]
.
[color=rgb(0,0,0)][font=Arial]
[background=transparent]Otherwise I looked at other C++ engines to see if a port to WebGL was worthwhile and the short answer is no. It seems tools that can generate JS code from low level code make any sort of port a waste of time.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]A simple pattern[/background]
[/font][/color][color=rgb(0,0,0)][font=Arial]
[background=transparent]While a great deal of my time will be spent contributing to the projects mentioned above, it's important for me to have something that I can just "play with." Really what I mean by this is a simple project that I can build upon slowly over time. The underlying idea is surely not unique (as few are) and revenue is not even on the list of goals here. I'm looking to take what I know about web application architecture and apply it to what I'm learning about graphics rendering.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]Engineering is about solving problems to achieve a goal and the solutions we generate become repetitive until patterns emerge in the way things are "done." The persistence and sharing of data is a common problem with any domain which extends to those that could benefit from graphics rendering. This rendering is likely to be real time as persistence and distribution of data is essentially for the benefit of easily and quickly viewing that data.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]Real time rendering involves a great deal of assets in one way or another, and these define the virtual world that we are rendering and how it should present to a viewer. These assets are in fact persisted pieces of data that make their way from memory, to CPU to GPU. The benefit of storing this data on a central server has already been seen in many applications. The nature of an HTTP application, specifically one using persisted websockets seems to match this problem set.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]Concluding[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
[background=transparent]I will be honest this post was very much me getting myself on the level, and trying to set the tone for the future work I will be producing. While I plan to post a great deal on the inner workings of render pipeline and shaders, I'm also getting heavy with some JS and web technologies. I hope you have kept with me thus far and I promise next I write I will provide you with much more "juicy" details.[/background]
[/font][/color].
[color=rgb(0,0,0)][font=Arial]
