Sorry - what I meant was the C3 Image Editor texture having to be greater than the spritesheet size. Many times, I load the texture that was embedded in GLB into the image editor, and this becomes an issue since the texture tends to be lower res (pixel art etc.).
I usually pad or combine textures, but it would help if I didn't have to. Not a deal breaker in any way - just curious if this is a limitation you're planning to remove.
I love the stylized look of the per-face lighting - a couple of questions and suggestions:
-while the ultimate goal would be per-pixel lighting, please do keep this mode available in the future, for its stylized look - same, if you manage to get per-vertex lighting going (Gouraud-ish?)
-are you working on/considering decoupling texture size from the C3 spritesheet size? This limitation kind of goes against using glb as an all-encompassing format (mesh+texture) - as you still need to take an outside parameter (C3 spritesheet size) into account...
Hi. Great software - but I have a couple of questions:
-Is it possible to import an image sequence as an array or animation automatically? My sequence is named Test0000.png to Test 0050.png
-when importing an image using any IO node, if the path/filename has spaces, it will be correctly encapsulated in quotation marks and the image will be visible, but upon clicking on the folder icon near the path (in the node) and specifying the file again, the quotation marks will not be added, resulting in an "image not found" error. This seems like a bug?
