3 ms·
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 re
by jheriko 9y ago
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...
- 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!
- wyqydsyq 9y agoAs 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
- dkersten 9y agoI 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.