ANSI characters & Texture Coloring

[acxz]

Hey @saccharineboi this is a pretty amazing project!!! I'm honestly surprised why its not more popular.

In the future I kind of want to use this library to build some cool things on top, but for now I'd like to ask some questions/request some features.

One pretty cool thing I was wondering if possible was the ability to specify different ANSI character sets. For example, it seems you are rendering full blocks, but since you are using the notcurses backend would it be possible to add more options, such as vhalf blocks, sextant blocks, or the wedge blocks? Maybe even using more of the true image protocols like sixel, kitty, etc. Ideally, I imagine this to just be an option that is sent to notcurses rendering. Of course the speed will be slower, the more symbols that have to be rendered but I'm not particularly concerned about that right now and in any case, those optimizations should be done inside of notcurses itself.

Another thing that would be pretty neat would be showing the colors from the input OBJ files! I think the colors are part of the texture in the OBJ/MTL files, and it seems that you do have textures listed as a known issue. Going through the examples, you already seem to be able to specify color. It'd be pretty nice to have color support if the OBJ file supports it!

The first use case I'd like to start with when using this project would be to create a simple OBJ viewer for arbitrary ANSI resolutions and using the colors from the OBJ file instead of using say lighting via raytracing from light sources.

Thanks so much by the way for creating something like this, its pretty slick!

[saccharineboi]

I was wondering if possible was the ability to specify different ANSI character sets

This is currently possible for 1x1, 2x1, 2x2, 3x2, and braille.

Maybe even using more of the true image protocols like sixel, kitty, etc

This isn't done, and even though the implementation is trivial, performance will most probably be atrocious. The culprit is of course the fragment shader. There are multiple ways around this: either use opencl or cuda to compute the fragment shaders in GPU (not possible in systems with no GPUs), run it on different thread (or threads; in any case, you introduce the new problem of synchronizing the "fragment compute" threads with the render thread. So far, I haven't given much thought to this).

it seems that you do have textures listed as a known issue

I'm currently working on the texturing functionality right now (including mipmapping, filtering, (bilinear, trilinear), wrapping). Not sure if adding anisotropic filtering is necessary, given the low resolutions in which cursedgl-based executabls are likely to run. I've already made stb_image.h part of cursedgl, so image loading is already here. One important thing missing is a custom memory allocator to minimize mallocs during texture and corresponding mipmap creation, which I'm planning to do after texturing is fully done.

The first use case I'd like to start with when using this project would be to create a simple OBJ viewer

Instead of focusing on OBJ, you could simply use assimp to load most 3D formats out there. I will add an assimp example in the future (after texture stuff is done). Assimp will also make it easier for you to read animation data (including skeletal animation data), just so you know.

After you clone the latest commit you should be able to invoke examples with command-line args. Here's an example from invoking ./first_person_demo -h

Usage: [OPTION]...
Options:
-h, --help print this help and exit
-v, --version print the version and exit
-k, --keep do not switch to alternate screen
-l, --log logging level: from -1 (silent) to 7 (manic)
-s, --suppress suppress banner
-b, --blitter 1x1 (default), 2x1, 2x2, 3x2, braille

Edit: log messages can be read via redirecting stderr: ./first_person_demo 2> log

[acxz]

Whoa, thanks for the update, getting a bit more excited for the texturing!

Assimp will also make it easier for you to read animation data (including skeletal animation data), just so you know.

Dude, this is dope!

performance will most probably be atrocious.

Oh, I bet. Most of the terminals that do implement theses fancy protocols are typically GPU accelerated however.

Thanks for adding the command line args. I think one character set that would be really useful would be the wedge glyphs from "Symbols for Legacy Computing", chafa uses this. The neat thing about this character set is all the diagonals and inclined blocks, which would be important to visualize the surface meshes and I think it would be the same computation as 3x2's. I wonder if notcurses has this character set, so that we can use it here as well.