6 ms·
Here is a another infinite city written in a WebGL shader. https://www.shadertoy.com/view/XsBSRG https://www.shadertoy.com/view/XsBSRG All the calculations are
by etaioinshrdlu 9y ago
Here is a another infinite city written in a WebGL shader. https://www.shadertoy.com/view/XsBSRG https://www.shadertoy.com/view/XsBSRG
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.
- deleted 9y ago[deleted]
- hardwaresofton 9y agoThat's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me, had to change to chrome and then it seemed to be getting 8fps (at least that's what the readout on that page was). 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.
- gilbetron 9y agoWhile there might be something, modern games take a massive amount of data, and for a website, you'd have to load that before playing it. Plus it is difficult to monetize. Demos are fun and easy, full games take a lot of work. There are actually some cool web games already out there, but being in the browser isn't particularly interesting, in the end. Infinitown is just a set of objects repeated in different orientations/combinations. The shader-city is awesome though. Very clever :)
- hardwaresofton 9y agoIf you're OK with handling a whole bucket of naivete, I'm going to really heap it on: - 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.
- dkersten 9y ago> I must not understand enough of why/how the demos are so different 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.
- jheriko 9y agoyou could associate data with the distance field based renderer - e.g. objects at x,y,z locations... the bigger problem imo is that working with such a fancy renderer is a headache. want to render anything else in there? you'll need to do custom depth writes or sort things... want to insert a custom building? now you have to cut a fancy hole in things .. etc...
- gilbetron 9y agoOh, definitely the infinicity approach is much more malleable, which is why game engines basically work that way after years of "evolution". But the shader approach is more impressive as a fun demo. If you want to make a real game, you go with the infinicity approach!
- juliangoldsmith 9y ago>That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me 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.
- gilrain 9y agoIt works great in Firefox 58.0b6 at a solid 60 FPS.
- deleted 9y ago[deleted]
- BatFastard 9y agoIt's hard, much harder than creating a native client game. Many more access restrictions, javascript and flash were only two options in the past, and each had it problems. 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.
- hardwaresofton 9y agoI'm really interested to know what the large problesm you've been facing are. 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?
- BatFastard 9y agoSend me an email. Happy to talk to you about it. Just the garbage collection issues is enough to frustrate all but the most dedicated developers. I use pre-allocated object pools for just about everything that helps, but it's easy at 60 frames a second for one allocation to build up to thousands of objects quickly if you are not very careful.
- batmansmk 9y agoI thought about it before. You could distribute your own builds prior to Steam. Here is a sample of the value Steam brings to developers: monetizing, managing DLCs, getting online features, getting visibility on the storefront, running promos/discounts/marketing operations, getting analytics, reviews, achievements, distributing free keys to testers, getting some partner connections to deploy server code, running a community forum, managing beta programs with two different builds, supporting screenshots, banning at the Steam level abusive players... it takes a lot of features to provide a meaningful MMO experience; the rendering engine sounds like 10% of the effort ;).
- gjem97 9y ago> All the calculations are done on a per-pixel basis. 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?
- lerpa 9y agoIt's a pixel shader. It's widely used for everything involving 3D graphics these days, as most engines require you to implement one, even if it's a trivial one.
- tgb 9y agoParallax mapping shaders do this kind of computation in actual games. In the case where the entire scene is rendered this way, you might see it referred to as a "two-triangle" shader like at [1] (since there's only two 'triangles' in the usual sense to draw the scene), but I doubt that this is at all common. [1] http://www.iquilezles.org/www/material/nvscene2008/rwwtt.pdf http://www.iquilezles.org/www/material/nvscene2008/rwwtt.pdf
- jheriko 9y agoi've used this in practice for a number of full screen effects... e.g. if something is volumetric and you are inside of it, it makes more sense to draw two triangles than an elaborate mesh that completely bounds the player.
- AlphaSite 9y agoIve had it referred to as a full screen quad.
- cobalt 9y agoThat example (and many on shadertoy.com) is called raymarching