Hacker News Reader

Comment by etaioinshrdlu | Hacker News Reader

Here is a another infinite city written in a WebGL shader. 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.

View on HN

That'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.

While 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 :)

If 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.

Naivete is awesome when trying to not be it ;)

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.

Being browser-based, you wouldn't be waiting to download 100MB+ if it's correctly designed

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)

> 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.

you 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...

Oh, 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!

As the shaders are basically only good for post-processing whatever output you get from your renderer, you'd definitely need to use an infinicity-esque approach for everything interactive in a game, but you could still leverage shaders in conjunction with that for non-interactive stuff like weather effects, animals (birds flying around etc), pedestrian and vehicle traffic and so on

I suppose you could use the technique to render a backdrop (either by rendering to a texture or by rendering it first, although you’d end up with a lot of overdraw if not careful) and then use a traditional renderer for the foreground. Not sure if it would win you anything, but certainly possible.

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.

It'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.

I'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?

Send 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.

I 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 ;).

>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.

It works great in Firefox 58.0b6 at a solid 60 FPS.

> 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?

Parallax 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

i'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.

It'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.

That example (and many on shadertoy.com) is called raymarching

Ive had it referred to as a full screen quad.

Reply on news.ycombinator.com