While testing the patch, I kept running into some issues with certain U-shaped filled strokes, where there would randomly be some extra triangles getting created. After drawing heaps of those recently, to figure out whether there were any trends/reasons for this to fail, I realised that they would look pretty awesome in motion.... So, I had a bit of fun + relaxation doing some straight-ahead animation with Grease Pencil :)
Note 1: After a long week, it turns out to be quite relaxing to just zone out for an hour, randomly scribbling away, doing some straight ahead animation.
Note 2: No I'm not actually that good at reliably redrawing stuff from frame to frame - the sculpt tools really come in handy to fix up wonky strokes
Note 3: The green stuff was inspired by the green onion skinning ghosts I had on in the background while animating. They aren't actual onion skinning ghosts (since those don't get drawn during OpenGL rendering), but since the effect I was going for at the time was based on having those there, it looked weird to not show them at all.
Note 4: Here are some examples of the glitches I've been running into - the tessellation uses Blender's existing Polyfill2D API, so it should be relatively robust already. However, I've running into some weirdness here where every time the stroke gets retriangulated (even without modifying it - just be reloading the file repeatedly), there is so much variation in the results (i.e. different number of triangles, sometimes with extra triangles added in crazy places, etc.). It's really annoying, as I'd really love to just get this into master already! Arrgggh Blender... just behave yourself, ok?!
There is a lib that has been widely used for 2D vector graphics where these and other issues are already solved: http://www.antigrain.com/
ReplyDeleteThis library is used in the known 2D animation software Anime Studio:
http://my.smithmicro.com/anime-studio-2D-animation-software.html
Thanks for the link! It's interesting to see that this is in fact GPL licensed :D
DeleteHowever, there are several reasons why it's not that applicable for what we're doing "as-is" (though whether we can benefit from some of the general principles is another matter that needs further investigation :)
The issues are:
- We're not just doing this in 2D. (Sure, the patch as it currently stands itself only does 2D planes in 3D, but it'd be great to ultimately have something that works in 3D too)
- From the sounds of things, the library is just optimised for drawing direct to the screen, using "native" api's instead of an OpenGL backend. This is incompatible with the way that Blender's UI and viewport are drawn.
- Unless I'm remembering wrong, I don't think Mac uses X11, so this sounds like it would only work on Windows/Linux...
Anyway, thanks again for the link. Hopefully we find some useful stuff in there to pick out :)
I think is advantageous use 2D render engine api instead OpenGL. It is agnostic regarding the OS and CPU / GPU. It is useful for large or medium-sized 2D projects (rendering farm).
ReplyDeleteI think we need own agnostic rendering engine for 2D style, same cycles for 3D, if we want to use for 2D quality productions.
thanks for your great work
= :-)
"The library is just optimised for drawing direct to the screen"
ReplyDeleteI think the lib render in memory
http://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0001
"AGG does not dictate you any style of its use, you are free to use any part of it. However, AGG is often associated with a tool for rendering images in memory."
Finally..
ReplyDeletehttp://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0001
Rendering Buffer is a buffer in memory that will be displayed afterwards. Usually but not obligatory it contains pixels in format that fits your video system. For example, 24 bits B-G-R, 32 bits B-G-R-A, or 15 bits R-G-B-555 for Windows. But in general, there're no restrictions on pixel formats or color space if you write your own low level class that supports that format.
:-)
2D render engine = buffer in memory = Texture
ReplyDeleteTexture (low quality) + OpenGL (3D transformation/representation)= Blender's UI and viewport draw.
Texture (high quality) = render high quality output
I think that's the way to have high quality 2D graphics in Blender, vectorial textures ...
Render with this lib in low quality is fast ( http://www.antigrain.com/demo/aa_demo.tar.gz);
You can test the compiled examples
linux: http://www.antigrain.com/demo/examples.tar.gz windows32:http://www.antigrain.com/demo/examples.zip