But wait for Armory + b2.8 get more mature first.
Will we be able to make 2D games too? How about a setting that allows us to lock a particular axis? It would also be better if Armory can render in orthographic mode for 2D. It would allow us to also use 3D objects with 2D Grease Pencil assets. But I am not sure if Grease Pencil is strong enough for making games with... (Grease Pencil is still awesome though.)
@AdityaSrivastava2819 Nothing says we can't. Armory is a 3D rendered(Through Iron) engine but Unity does it's 2D with the 3D renderer a bit like we would if we used Armory for 2D. The only question right now is do we add the features that Iron has in 2D with Armory or do we use the 3D renderer.
I really need this grease pencil support, hope it's soon...
continued from https://github.com/armory3d/armory/issues/1427,
@luboslenco I noticed in the grease branch you created, you moved code from iron to armory, so what should be done with the remaining code (Data.hx, SceneFormat.hx, Scene.hx, etc) that was in iron too?
Yes, moved it into single armory branch for a reference. For actual implementation I am thinking of triangulating grease pencil objects in the exporter itself and exporting as a mesh. That way there is no added complexity in the engine itself. Once that runs we could move on to handling animation frames.
triangulating grease pencil objects in the exporter itself and exporting as a mesh
Where should the triangulation be done exactly? .. I'm thinking of porting this library logic to do the triangulation https://github.com/Bl4ckb0ne/delaunay-triangulation
There is a Convert Grease Pencil operator in Blender which might be handy but sadly it does not seem sufficient enough yet to handle the whole task.
The triangulation should be done somewhere along the exporter.py execution. Some valuable data may also pop up by digging into grease pencil python api.
Ok, I have some free time again, I'm trying to get to rendering the lines, but I'm not sure how to proceed since there are multiple options. The alternatives I am investigating currently:

Not sure how much of extra complexity this would add to the engine though.
@luboslenco
My progress so far in my little experiment project:


My experiment is a bit of an "alien" implementation to the engine though... duplicate code in a few different places (things that are already done in iron) to avoid changing iron at least in this prototype.
I plan to move to proper implementation land soon. But I need a few things to be changed to have proper inclusion in the engine:
Geometry and MeshData currently prevents me from using iron to get them to be rendered out-of-the-box like normal meshes with MeshObject. So I'm planning to try to de-hardcode those classes and make them more flexible, with arrays. I'm currently on it and I got something working, I need to fully test it to make sure it works. Is that approach ok, @luboslenco ?z_index makes visible an issue and that is that too many shader files (config, frag, vertex) are created for duplicate shaders that only change one uniform value.z_index was implemented easily thanks to "bind_constants", but unfortunately those are unique per material, meaning that if two polylines or two fills have the "same" material but different z_index value, duplicate materials have to be created for the different z_index values. To fix this the idea is to introduce override "bind_constants" or something like that. Those would exist in the object data maybe, and when checking for uniforms in the Uniform class an extra check would be added to override the value with the one in the object data if it exists. This would save a lot of space, something very important on low-end targets. I thought about making it more general instead of just hardcoding z_index because there might be some possibilities for something more like base color or others...Look cool! Some attributes in geometry are packed together (position and normal) to preserve memory and I think even the order of attributes matters so it sounds challenging, but if it turns out to not be a big issue then it should be ok. Alternatively adding support for a few custom slots might do the trick.
@luboslenco my progress so far: project-geom (required change in the exporter), I think it's mostly done but for a detail: I used haxe.ds.Vector but probably could use the raw.vertex_arrays directly... though I read that haxe.ds.Vector works better so I'm not sure.

I did multiple tests with different combinations (skinning, uvs, tang) (skinning, vcols) etc. and it's working to the extents of the original, and deinterleaved seems to work too.
Should I change it to use raw.vertex_arrays instead of creating a new array or leave it like that? also, should I open a PR now or group it with the whole grease-pencil project later?
Using raw.vertex_arrays instead of creating new array sounds good (for js/krom, haxe.ds.Vector is just a regular Array). Please open a PR now, can already start taking it in. 馃檪
Hi,
what is the state of Grease Pencil with Armory recently ?
I am experimenting lottie and svg animations for the web and Armory with Grease Pencil support would be great :)
Thank you !
No further changes in my progress since, sorry. :sweat:. I haven't touched the code in quite some time, but last I remember, it was "working" but needed a lot of work to be properly implemented.
Most helpful comment
Update:
My progress so far in my little experiment project:
My experiment is a bit of an "alien" implementation to the engine though... duplicate code in a few different places (things that are already done in iron) to avoid changing iron at least in this prototype.
I plan to move to proper implementation land soon. But I need a few things to be changed to have proper inclusion in the engine:
The hardcoded nature of the
GeometryandMeshDatacurrently prevents me from using iron to get them to be rendered out-of-the-box like normal meshes withMeshObject. So I'm planning to try to de-hardcode those classes and make them more flexible, with arrays. I'm currently on it and I got something working, I need to fully test it to make sure it works. Is that approach ok, @luboslenco ?z_indexmakes visible an issue and that is that too many shader files (config, frag, vertex) are created for duplicate shaders that only change one uniform value.Currently
z_indexwas implemented easily thanks to"bind_constants", but unfortunately those are unique per material, meaning that if two polylines or two fills have the "same" material but differentz_indexvalue, duplicate materials have to be created for the differentz_indexvalues. To fix this the idea is to introduce override "bind_constants" or something like that. Those would exist in the object data maybe, and when checking for uniforms in theUniformclass an extra check would be added to override the value with the one in the object data if it exists. This would save a lot of space, something very important on low-end targets. I thought about making it more general instead of just hardcodingz_indexbecause there might be some possibilities for something more like base color or others...