Technically Apple has had their Metal API available for a while now but I kind of doubt they're using that for image processing.
80 karma · joined May 9, 2011
Technically Apple has had their Metal API available for a while now but I kind of doubt they're using that for image processing.
Yep. If you look at the "How?" and "Performance vs Quality" sections, you can see that you need to render the scene six times to get the surrounding environment, so all you would just need to do is make a shader for the projection[0]. (Rendering the scene six times is pretty common in graphics in order to generate light probes for dynamic lighting and global illumination.)
I suspect with a modern GPU implementation (Vulkan) and some other minor optimizations, this could run pretty easily in real-time.
I think, for now, a hybrid OOP/FP approach would be best. Right now, I'm prototyping a game engine in F# and C# to see if one could be viable. Incorporating FP has definitely simplified and allowed me to reason better about parts of code but I'm not sure if the tools and languages work well with each other enough yet.
Also see [0] for some thoughts about FP and game development.
[0] - https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
I think a lot of games featured in Humble Bundles used to be that way. A lot of games used to be (and some still are) initially only released on Windows with Mac/Linux ports released later.
And technically you could export the sprite sheet with however many frames you want (and be able to lower and increase the number easily) while still getting the exact same results as the Sprite Lamp solution. And of course artists could go in and manually make any changes they want.
It's interesting hearing the perspective of the artists. Thanks.
I could see this getting prohibitive when creating animations for example.
As for types of lights and colors, yes, I think that would all be possible.
But I can't help feeling that generating normal maps from full 3D models would be more robust overall.
For instance you could easily make things like a walking animation or calculate ambient occlusion (pretty standard 3ds max work.) Render it into a sprite sheet and you have the pipeline to dramatically reduce the amount of work artists would have to do.
I guess Sprite Lamp would be best geared toward indies/studios without 3D modelers and can't invest in the aforementioned tech.
This is cool nonetheless.
The solution is simple, just click the sign out button and Google signs out all accounts that are configured to "stay signed in." Alternatively, he could have cleared his cookies or waited for them to expire.
Some people have been saying this is because of bad UX on Google's part. Google is kind of in a catch-22 situation here. They want to upgrade how multiple users check their Gmail on one browser but no one wants to learn how use their new system (I got frustrated when they introduced their new UI to compose emails and had to show a tutorial on how to use it.)
It's kind of like the Android vs iOS debate. DirectX is like iOS in that there's one main feature set which runs on a lot of devices. Whereas OpenGL was pretty fragmented because of extensions.
The only fragmentation on DirectX that I remember is the vertex-texture fetch (which was only supported by NVIDIA cards) vs render to vertex buffer (only supported by ATI cards) features in DirectX 9.0c. After that, Microsoft really started emphasizing the notion of a standard feature set.
OpenGL moved away from all of that starting with OpenGL ES which is partly why it has became so popular.
[0] http://www.gamedev.net/page/resources/_/technical/game-progr...
Now-a-days it's pretty much standard to use two floating-point off screen textures to store, update, and draw the particles completely on the GPU. This way, you can get 1M+ particles easy.
Sure it's possible for one person to develop a successful social game. But how many of those people can develop two successful social games? 5? 10+? The only name that comes to my mind is Zynga.
I believe the precision/overflow issues can be mitigated using modern GPU hardware (the authors mention this in section 8.5.2 of the article.) Now-a-days it is pretty much standard to have floating-point render targets (especially with deferred rendering and light-pre pass renderers) so 16/32 bits per component should be adequate especially if you apply the tricks the authors present in the article. Not to mention that now we have DirectCompute/OpenCL/CUDA.
Though I don't really see people talking about SATs that much (I myself have never implemented them.) Maybe there is an underlying reason why people don't? Bandwidth maybe? I would imagine it would be pretty taxing on the system to recompute the SAT every frame.
An alternative would be to use Summed-area tables [1] where each texel contains the sum of all texels that are above and to the left of the current texel. This allows variable-width blurs to be computed in constant time, using only four texture samples (!).
And the concept of a variable-width blur is an approximation to a related concept in photography/optics called the "circle of confusion." [2] The circle of confusion, combined with bokeh sprites, are usually what AAA games are doing for depth of field [3].
See [4] for more details.
[1] http://http.developer.nvidia.com/GPUGems3/gpugems3_ch08.html
[2] http://en.wikipedia.org/wiki/Circle_of_confusion
"...helping students understand, analyze, critique, and review in an objective manner the scientific strengths and scientific weaknesses of existing scientific theories...."
Being able to openly and freely criticize scientific theories is at the core of how science works these days.
As for teachers using this law to teacher creationism, hopefully anybody from an objective perspective, with the aid of the scientific method and recent scientific findings, can come to the conclusion that the current definition of creationism is not possible.