3 ms·

Show HN: Terminal-Rendered ASCII Shaders

anewhnaccount2 5y ago
It looks cool but a web demo + a bit more explanation could help.
- teaearlgraycold 5y ago
  Thanks - it uses NodeJS so a web demo isn't possible without some advanced hackery (Edit: or minor code changes). But a video might be nice. Edit: Here's a screen recording! https://youtu.be/4bbClPPAkQI https://youtu.be/4bbClPPAkQI
  - city41 5y ago
    This is really cool. I took a quick peak at the code and nothing jumped out as too node specific. Curious why you think a web version would be tricky?
    - teaearlgraycold 5y ago
      * It uses the fs module to hot reload load the shader file. That is something that can be patched over for web execution. * It uses the readline module to write characters to the terminal. That can also be patched. I could patch it but the intended use case is in the terminal so I'm not super motivated to make that change myself. Feel free to fork it, though.
riidom 5y ago
If such a renderer would be used for something "serious" (a game with simple 3D elements running in the terminal, for example) the display creates some pretty interesting constraints on the content creation side. In your video, from 0:33 to 0:38 roundabout, the object "dissolves" in some unreadable kind of blob. On its appearance, it feels like the object can be kinda identified, but after a bit of rotation it's gone. When it starts to grow later on, I at least have the illusion of being able to interpret what I see. Now, this is obviously to the low-res nature of the display, and on that front is not much to change (assuming it has to run in a text terminal). Except using braille fake-pixels maybe, but given the situation like it is with this renderer, what needs to be considered when creating 3D models? I'd think, you probably want as often (as in, from every angle) a clear silhouette, and probably one should keep the on-surface details low in number, not too small in size, and properly elevated/engraved. In other words, rendered conventionally with pixels, it would look hideous :)

It looks cool but a web demo + a bit more explanation could help.

teaearlgraycold 5y ago
Thanks - it uses NodeJS so a web demo isn't possible without some advanced hackery (Edit: or minor code changes). But a video might be nice. Edit: Here's a screen recording! https://youtu.be/4bbClPPAkQI https://youtu.be/4bbClPPAkQI
- city41 5y ago
  This is really cool. I took a quick peak at the code and nothing jumped out as too node specific. Curious why you think a web version would be tricky?
  - teaearlgraycold 5y ago
    * It uses the fs module to hot reload load the shader file. That is something that can be patched over for web execution. * It uses the readline module to write characters to the terminal. That can also be patched. I could patch it but the intended use case is in the terminal so I'm not super motivated to make that change myself. Feel free to fork it, though.

If such a renderer would be used for something "serious" (a game with simple 3D elements running in the terminal, for example) the display creates some pretty interesting constraints on the content creation side. In your video, from 0:33 to 0:38 roundabout, the object "dissolves" in some unreadable kind of blob. On its appearance, it feels like the object can be kinda identified, but after a bit of rotation it's gone. When it starts to grow later on, I at least have the illusion of being able to interpret what I see. Now, this is obviously to the low-res nature of the display, and on that front is not much to change (assuming it has to run in a text terminal). Except using braille fake-pixels maybe, but given the situation like it is with this renderer, what needs to be considered when creating 3D models? I'd think, you probably want as often (as in, from every angle) a clear silhouette, and probably one should keep the on-surface details low in number, not too small in size, and properly elevated/engraved. In other words, rendered conventionally with pixels, it would look hideous :)