ofZach/inkSpace

语言: C++

git: https://github.com/ofZach/inkSpace

android绘图工具
android drawing tool
README.md (中文)

using the app

墨水空间

墨水空间是一个实验性绘图工具,它使用Android设备上的加速度计来移动您在3d中制作的绘图。这是Android实验计划的一部分。

项目本身可以直接向前绘制,通过向不同方向倾斜移动手机,调整您正在绘制的线条,创建一条脉冲线并重新绘制自己的动画线条并记录您制作的动画GIF。双击(或点击菜单中的垃圾桶图标)会清除应用程序。

作为一名艺术家,我一直在思考新型绘图工具,以及21世纪绘画的外观 - 墨水空间是该领域的研究。如果你的手上有一张图纸,那么在图纸周围移动会更像是一种需要你画画和移动的尺寸形式。

你可以在这里看到它:

app in action

它可以保存GIF(使用优秀的GifEncoder),如下所示:

example gif

这是一个Android实验

学分

这个项目很大程度上归功于Amit Pitaru的Rhonda,我帮助过的后期版本以及Matt Deslaurier的文章“画线很难”。我还要感谢Anthony Tripaldi的android调试和Arturo Castro(以及更广泛的openframeworks社区)。还要感谢谷歌创意实验室的人们让我做点什么!该应用程序是用openFrameworks 0.8.4编写的。

技术细节

让我的书呆子出一点!此应用程序的工作方式是它从加速度计读取数据并通过根据手机移动旋转图形来操纵图纸。输入的每个新点都在2d中输入(即,它的z值为零)但是当您移动手机时,它会在3d中被操纵。通常,大多数图形应用程序不会更改模型的基础点,但会更改矩阵(一个数字框)来操纵点,但是由于多种原因,实际操作点更容易,更快。这发生在这里。

所以,我们有一条折线(这是一组点)被操纵为3d - 我们如何绘制它?在这里,我要感谢精彩的Drawing Lines is Hard文章(参见“屏幕空间投影线”),了解如何在着色器中投影线以使它们“体积” - 即我们可以传入折线数据(加上一点额外信息)并在着色器侧计算“带状”形状的屏幕坐标,以给出线条深度。我们甚至可以(就像我在这个应用程序中那样)根据它与观察者的距离(着色器源)来细化或加粗线条。这是一些DOF线着色器的工作方式,fyi。

另一个重要的伎俩是移动设备上的opengl往往很慢,并且你的绘图方式会受到巨大的惩罚 - 即,如果你有很多状态变化等等。在我们的例子中,我们想要绘制线条作为尽可能快,所以我们将它们分成一个巨大的VBO(顶点缓冲对象)。但是,我们不希望它们被连接起来。有一种技巧可以在线之间传递一种简并形状(通过复制前一行的最后一个顶点和下一行的第一个顶点)。这个苹果开发者文档很好地解释了它。批处理对性能有很大的影响,你可以将所有绘制调用放在一个地方就越好。在我们的例子中,批处理发生在这里 - 我们从所有3d线获取数据并添加巨大的点阵列,笔划宽度等。

当你暂停或关闭应用程序时,上下文丢失时,opengl和android也存在一些问题。 openFrameworks处理大部分内容,但我发现我必须对FBO和VBO之类的东西进行大量的破坏和重新分配(在这里发生)。这是一种痛苦,但一旦你掌握了它(并理解它)就可以忍受了。

在这个应用程序中,我们还使用ofActivity.java与java方面交谈(参见此处和此处),我们使用JNI处理gif共享,并尝试使应用程序完全全屏(即沉浸式模式)。这需要大量的试验和错误才能做到正确,但是一旦我们这样做,调用android sdk并将它用于它擅长的东西是相当强大的。

OF android技巧

这里有一些在Android上使用OF的技巧:

  • eclipse是一种难以理解的IDE。我发现自己很累。一旦你得到一个工作设置,它是非常直接的,但那里有一些痛苦。很多时候我觉得这是与自己的对话,而我只是在偷听。我找到成功的关键是要学习一些小技巧来诱骗它成为幸福。耐心:)
  • 我把#defines放在我的代码中,所以我可以在android和osx中工作,然后来回走动。虽然我可以在eclipse中编码,但我在xcode中更开心,迭代更改的速度更快。
  • 当我想尝试不同的设置或修复错误时,我创建了一些不同的工作区。这样我可以保持一个工作的工作区,但试验另一个SDK /配置
  • 我使用eclipse kepler和android-ndk-r9b,如果这有用的话
  • 其中一个最重要的设置是每个项目,右键单击 - >属性 - > c ++ general - >代码分析。单击“使用项目设置”。这有助于防止有点精神分裂的行为,eclipse会忘记它对你的项目“满意”,并从编译到抛出数千个错误。
  • 根据本指南,我增加了日食记忆
  • adb是你的朋友!你可以用这个工具做很多事情,从列出文件夹内容,上传和下载APK,阅读logcat(即adb -d logcat,如果你立即崩溃,这是非常有用的)。了解adb - 我喜欢它。
  • ofLog()与logCat的效果非常好,所以我在代码中抛出了很多ofLogs()来查看发生了什么
  • 相对于IOS,将应用程序放在游戏商店是一块蛋糕,将应用程序放在您的设备上也非常简单,几乎是一种乐趣。我有噩梦想着配置文件。

本文使用googletrans自动翻译,仅供参考, 原文来自github.com

en_README.md

using the app

ink space

ink space is a experimental drawing tool which uses the accelerometer on your android device to move the drawings you make in 3d. It's part of the android experiments initiative.

The project itself it fairly straight forward you can draw, move the phone by tilting in different directions, adjust line that you are drawing, create an animted line which pulses and re-draws itself and record an animated gif of whatever you make. Double-tapping (or hitting the trash icon in the menu) clears the app.

As an artist I'm constantly thinking about new types of drawing tools, and what does drawing in the 21st century look like -- ink space is research in that realm. If have a drawing basically in your hands, what does it look like to move around that drawing and experience more as a dimensional form that requires you to both draw and move.

You can see it in action here:

app in action

It can save gifs (using the excellent ofxGifEncoder), like this:

example gif

this is an android experiment

credits

This project owes a great deal to Amit Pitaru's Rhonda, later versions of which I helped with, and to Matt Deslaurier's article "drawing lines is hard". I'd also like to thank Anthony Tripaldi for android debugging and Arturo Castro (as well as the broader openframeworks community). Also thanks to the folks from google creative lab for asking me to make something! The app is written in openFrameworks 0.8.4.

technical details

So let's nerd out a bit! The way this app works is that it reads data from the accelerometer and manipulates drawings by rotating them based on the phone movement. Every new point that's entered is entered in 2d (ie, it has z value of zero) but as you move the phone it gets manipulated in 3d. Typically most graphical applications don't change the underlying points of the model but alter a matrix (a box of numbers) to manipulate the points, but here, for several reasons, it's easier and faster to actually the manipulate the points. That happens here.

So, we have a polyline (that's a set of points) that been manipulated to be in 3d - how do we go about drawing it? Here, I have to thank the excelled Drawing Lines is Hard article (see "Screen-Space Projected Lines") for some tips about how to project lines in the shader so that they are "volumentric" -- ie, we can pass in just the polyline data (plus a little extra info) and on the shader side compute the screen coordinates of a "ribbon" like shape to give the line depth. We can even (as I do in this app) thin or thicken the line based on it's distance away from the viewer (shader source). This is how some DOF line shaders work, fyi.

Another important trick is that opengl on mobile devices tends to be quite slow, and there are huge penalties for how you do your drawing -- ie, if you have lots of state changes, etc. In our case, we want to draw lines as fast as possble, so we batch them into one giant VBO (vertex buffer object). But, we don't want them to be connected. There's a trick where you pass in a kind of degenerate shape between lines (by duplicating the last vertices of the previous line and the first vertices of the next line). It's explained pretty well in this apple developer document. Batching has huge implications for performance and the more you can put all your draw calls in one place the better on gles. In our case, batching happens here -- we take the data from all the 3d lines and add them giant arrays of points, stroke widths, etc.

There's also some issues with opengl and android where the context gets lost when you pause or close the app. openFrameworks handles most of this, but I found I had to a fair amount of destroying and reallocating for things like FBOs and VBOs (happens here). It's a pain but once you get the hang of it (and understand it) it's bearable.

In this app we also talk to java side using the ofActivity.java (see here and here), we use JNI to handle the gif sharing as well as try to make the app fully fullscreen (ie, immersive mode). This took a lot of trial and error to get right, but once we did, it was pretty powerful to call on the android sdk and use it for what it was good at.

OF android tips

Here's a couple of tips for working with OF on android:

  • eclipse is kind of difficult IDE. I found myself fighting with it alot. Once you get a working setup it's pretty straight forward but there's some pain there. Many times I felt it was in a conversation with itself, and I was just eavesdropping. The key to success I found was to learn little tricks to coax it into hapiness. And patience :)
  • I wound up putting #defines in my code so I could work in android and osx, and go back and forth. Although I could code in eclipse, I was much happier in xcode and it was faster to iterate on changes.
  • I created a few different workspaces when I wanted to try different settings or fix bugs. That way I could keep a working workspace around but experiment with another SDK / config
  • I used eclipse kepler with android-ndk-r9b, if that's helpful
  • one of the most important settings was per project, right click -> properties -> c++ general -> code analysis. Click "use project settings." This helps prevent a somewhat schizophrenic behavior where eclipse will forget that it's "happy" with your project and go from compiling to throwing thousands of errors.
  • I upped eclipses memory as per this guide
  • adb is your friend! there are alot of things you can do with this tool, from listing folder contents, uploading and downloading APKs, reading logcat (ie adb -d logcat, this is super useful if you have an immediate crash). Get to know adb -- I loved it.
  • ofLog() works pretty well with logCat, so I threw quite alot of ofLogs() in my code to see what was going on
  • relative to IOS, putting the app on the play store was a piece of cake and putting the app on your devices was also super easy, almost a joy. I have nightmares thinking of provisioning profiles.