Infinitown – A WebGL Experiment
demos.littleworkshop.fr
demos.littleworkshop.fr
All the calculations are done on a per-pixel basis, there are no polygons or other objects created. The city is a 3d scalar field with effectively an isosurface plotted.
The city is made infinite with a simple modulo operation in X-Y on the field.
Interesting to note in this technique there is no additional computational load associated with more visible objects, and there can be as many objects as pixels.
The Infinitown posted here was (pretty much) buttery smooth though, and relatively fast loading time (especially the second time with cache), and I bet the codebase is a lot easier on the eyes, though it's likely nowhere near as efficient as writing it all in the shader obviously.
Is the world just waiting for a no-dependency cross browser MMO/shooter/whatever 3D game to take the world by storm? Why worry about Steam when people can just go to a website, if the experience is good enough and the game is simple enough? I must not know enough about the industry/how hard it is to make a good game + how hard it is to make a truly good browser-only game.
Infinitown is just a set of objects repeated in different orientations/combinations. The shader-city is awesome though. Very clever :)
- the game monetization problem's always around (and always going to be around) -- is there a reason one wouldn't pay for a game in their browser but would pay for one on steam?
- Some of the greatest games of all time made do with so much less -- Isn't the resource problem just a matter of effort/ingenuity? Also isn't that problem bound to go away as time goes on? (though of course the "modern game" target will also move)
- I must not understand enough of why/how the demos are so different. Isn't shader city doing the exact same thing but insted drawing the visible pixels in space (and from a different viewpoint) rather than rendering the higher level polygons? I thought the key innovation/hard bit was the fact that it was inside a single shader.
The difference is that the shader city is a pure function of the inputs. For every value of 'time', it generates the colours for each pixel in the scene. Infinitown can maintain whatever state it likes in javascript.
If you want to make a real game, you go with the infinicity approach!
Could you also upload dynamic object data as VBO’s or uniform arrays or something and read that in your single-shader-renderer? Still likely not worthwhile, but a fun possibility perhaps.
I guess that’s not unlike what jheriko said above.
What does playing in the browser get you when you need to download 100MB+? You use the browser to get access to the standard features and DOM, if you ditch all that, add in a huge upfront download cost, then you might as well just install. There are plenty of cross-platform ways to do it these days. Additionally, browser games have an air (fair or not) about them of cheapness.
Then again, I'd be really happy if someone proved me wrong, and significant webgames became a thing. And it is a great exercise to analyze why webgames are bigger.
The infinite city is "just" tying a location to a randomly chosen and oriented set of objects. All the rest is standard scene graph rendering pipeline. The city shader does that for each "pixel" in the scene, and takes much less data to get a far cooler effect. Imagine coming up with an algorithm that picks a random lego object (a car, a police station, a boulder, etc) for each inch on your floor. That's infinicity. Now imagine picking a single lego piece based on your location and direction you are looking, and having that always match up even if you move, and when doing so, the resultant "legoscape" is a cool city. That's the city shader.
Sorta.
You'd download a 1-2mb core script bundle that then dynamically lazy-loads resources as required. For example, if Hearthstone were converted to a browser game, you would initially only load the base client, all the metadata and media (e.g. hero SFX, card data, effects, images) would be loaded on the fly as they are required, or pre-loaded at determined points (e.g. load all the data for both players' decks when beginning a match)
Could that be an issue with the new rendering engine? I'm on Waterfox 55.2.2, 64-bit, and it worked well for me.
I have been working on a browser based game for TOO long now, and garbage collection is a constant problem. Plus things just run a LOT slower than a native c++ client.
Also, if you're facing a problem with garbage collection, have you tried the emscripten/wasm approach? Using some garbage collected language and compiling it down to javascript? Or maybe even one that is functional to make garbage collection simpler?
Is there a term for this type of shader? Am I correct in assuming that this approach is primarily for demos, or is there a benefit to this approach for gaming or visualization?
[1] http://www.iquilezles.org/www/material/nvscene2008/rwwtt.pdf
Sadly they never seem to open source anything? It'd be nice to see how such polished stuff is organized
Our first web game, http://browserquest.mozilla.org, was actually open source: https://github.com/mozilla/Browserquest
There are more details on: http://www.cs.cornell.edu/courses/cs4620/2017sp/
There is some car detection code but it's far from perfect and collisions happen from time to time.
Edit: Oh, this did the trick: https://askubuntu.com/questions/299345/how-to-enable-webgl-i...
The examples for this lib are also pretty cool:
(1) - After doing this: https://askubuntu.com/a/299346/81166
The prettiest so far is https://fenwick.pizza/rentaduck
I wonder why. Isn't google tag manager a tool to "click together" modules for people who cannot write html?
or would rather not?
Browser related? Here's my browser info for reference:
Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Yes, it did look like a bug to me because I didn't expect clouds to act like that in what I took to be a simulation of the real world.
To be fair, I did have a lot of tabs open in chrome already. Like about 30.
Edit - 47 to be exact.
I notice that the vehicles start and stop, whats the logic?
Is it doing collison testing?
Anyone seen any instances where it fails and vehicles collide?
Now, after a refresh it worked. But then again a refresh: grey screen. Refreshing with the screen open: It keeps working. But refreshing and then switching tabs quickly, and switching back: grey screen. (however very difficult to reproduce)
Logs only show this: unreachable code after return statement [Learn More]
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-a...
(note this will wipe out some settings)
Seems so.
But the rest of it is Three.JS. Thus were the assets created in Unity and someone copied the shader code to ensure that they render the same in ThreeJS as in Unity? I am a little confused.
Btw there is proprietary/coprighted unity shader code cut and pasted into this, someobe even copied the original comments from the unity shaders. For example search for "DecodeLightmapRGBM" in the below source code, which is from the demo - that code and others are copied:
https://gist.github.com/bhouston/1c3c6835ca9766571f07ad0126d...
Here is some unity source code to compare against: https://gist.github.com/nicloay/8d2ae254a77de58bb42b9009b4cf...