Archive for the ‘flash experiments’ Category

Doodle/draw on PDF documents

February 2nd, 2012

Sometimes I get some PDF forms to fill in and send back by email.
To do this, one have to:

  1. print the PDF
  2. fill or sign in certain places and then …
  3. scan the document.

There are some drawbacks to this method:

  • you need money for printer ink
  • you need time for doing all these steps
  • you must have a scanner or at least decent camera
  • after rasterizing the PDF to JPG/PNG it won’t print again as pretty as it used to

I’ve been searching some online services with PDF editing, but there are no such things … at least I didn’t find it. There exists commercial PDF viewers which allows you to add text/ink to PDF documents, but they work either only on Mac or Windows, they are not online and they cost moneeeyyy

So here it is – free thing which allows you to fill out pdf (you will need a tablet though, it would be hard to do it using a mouse)

sgn.teleranek.org

It uses a huge but awesome javascript library for displaying pdf’s – PDF.JS (really, tremendous work by these guys to show PDF document on a canvas element) and makes use of the File API, so it won’t work on older browsers. But it is a known story concerning HTML5 thats why I’m not a big fan of it ; )

There are also other things that may not work:

  • PDF.JS may have problems with opacity or displaying some PDF’s
  • Encrypted PDF’s may not work
  • Some other PDF’s may not work, because I didn’t test hundreds but only several tens of PDF’s
  • THERE’S NO ERASER TOOL

Apart from that, I have used it for several documents with success. If your PDF don’t work, most possible cause is, that it is inconsistent according to PDF spec and you should print it again to PDF.
I had problems with newest Microsoft Word PDF Plugin, PDF’s there lacks of xref table and the references are all wrong.

Tags: , , ,
Posted in flash experiments | Comments (2)

AIR 3 PDF Renderer extension (Mac OSX only)

October 2nd, 2011

There’s this new feature in AIR 3 – native extensions, and there’s that ever-existing problem, how to render PDF documents in flash. In web player that’s still not possible (well, unless you sacrifice one year for writing PDF renderer) but it’s possible in AIR, for example using native extensions.
MacOS-X has the Cocoa library(framework) which performs great in rendering PDF files so I’ve written an extension which uses this lib to send BitmapData object containing rendered PDF to flash. Of course this is possible in windows and linux too, using XPDF library for example. AIR native extensions are easily extendable and altering several things in files that I’ve provided should make that extension work on windows, linux and even mobile systems.


RenderPDF extension contents:
There are many files in the archive, but all of them were used to make an extension.
PDFExt_framework contains compiled OS-X framework.

PDFExt_XCode contains an objective-c (objective-c is needed for Cocoa library) framework project.

PDFExtTest is a test app using an extension. In sample_commands folder you have bash commands to compile and package the test app. Test app displays a pdf, allows page changing and saving current page as PNG image. Test app illustrates usage of RenderPDF extension methods:
get pageCount():int,
RenderPDF.renderPage( pageNum, dpi ):BitmapData ,
loadPDF( source:String ):Boolean

PDFExtTest app screenshot:

PDFExtAS is the source code for AS3 interface for an extension.
compiled – this folder contains compiled swc, extension, extension xml descriptor and sample commands for compiling and packagind everything into an .ane file.


Several remarks:
Before compiling the framework, you must add the Cocoa framework and Air framework to the project, and then exclude them from linking, as described on “Extending AIR” article. In Info.plist file you must add the DYLD_FORCE_FLAT_NAMESPACE env variable and in project settings you modify the “Runpath search path”.

If you’ll take a look into PDFExtM.m source file, you will see that returning a BitmapData object from native function involves quite a few steps.
Also, flash BitmapData sometimes contains some extra bytes at every scanline, so memcpy from native uint array to copy the bitmap won’t work, you must iterate every pixel and skip the extra bytes at the end of a scanline (maybe there’s some super clever low-level-memory-hacking method to do it faster).
RenderPDF+sources

Tags: , , ,
Posted in flash experiments | Comments (9)

Molehill (away3d broomstick) 3D model viewer

April 1st, 2011

I’ve recently converted my old model viewer to away3D (it was using papervision3D).
molehill model viewer
This is the version which automatically loads well-known papervision3d x-wing model:
molehill papervision3D X-Wing
This is the version automatically loads a face generated with 3Doodler ( :P ), looks nice with subsurface scatterin 3Doodler face
(if you don’t see anything, you probably should have installed Flash Player version 11+)

ModelViewer supports OBJ, 3DS, Collada, MD5, MD2, blah blah blah…
Since Away3D Broomstick is in alpha stage, my viewer is alpha too. It supports Collada objects (DAE and ZIP files) because I had to write DisplayObject3D – to – ObjectContainer3D converter: “PaperAway

Usage:

var mesh:Mesh = PaperAway.fromDo3D( displayObject3D );

That’s all :P Well, there are some additional options, but I won’t describe them here, read the code yourself…

Some strange things I’ve noticed in molehill’s/away3d’s coordinate system – uv coords are assigned to vertex indices, not face indices. This forces you to do either of two things:
– make too many vertices, one vertex per face vertex
– check for vertex UV coords and create new vertex only if the uv coord of given vertex is unique. This is confusing explanation, you can check it in the source code for PaperAway.as , starting from line 242.
Class PaperAway is not fully featured, it does not create materials according to Papervision3D’s shadedMaterials. Also it does not transfer interactive events of displayObject3D.

These are the issues with Away3D which I’ve spotted so far (some descriptions are very sketchy, sorry):
-material.dispose() generates null exceptions
-model.clone is erroneous because SubMesh system is not fully implemented
-model.dispose() is kinda erroneous too
-submeshes materials does not resemble corresponding scenegraph meshes materials.
-parser of OBJ files – OBJParser – falls into infinite loop when supplied OBJ file has materials defined, by the material file does not exist. In errorMtl() function writing after the trace command “_mtlLib = false” solves the issue.
-there are some problems with updating textures. You can see them by clicking on wireframe and then on “normal” – texture’s not getting updated.

Tags: , , , ,
Posted in flash experiments | Comments (6)

Fixing Twease – tweaxing

January 24th, 2011

Yup, I know that everyone’s using TweenLite or Tween-something from GreenSock, but some time ago TweenLite wasn’t free for commercial use so I had to grab something different. I’ve found Twease – nice’n’small tweening lib with bezier tweening and several other fancy options. Then I’ve used to it, and it appeared in various projects. But there is annoying bug – Twease (newest version, 2.0) doesn’t render tween if your computer slowed down during the time the tween was taking place.
Imagine – you are building an app which initializes thousands of different stuff at the beginning and animates an alpha component of DisplayObject’s, so that they could appear after launching your app. But they won’t appear if somebody has 300Mhz Athlon or 1000 tabs opened in firefox.
Debugging a tweening classes is quite unpleasant, due to asynchronousity and hundreds of anonumous classes with strange short names and properties (yup, I think that majority of Tweening libraries are written in this hard-to-read way ;) ), so I never fixed this but used different hacks… until now. Jeez… the fix is simple and I could do this two years ago, but I wanted to write a pile of workarounds rather than to look into Twease’s code.

Ok, so finally, this is the fix –

1. You get rid of the “import flash.utils.getTimer;” at the beginning
2. You define some global vars

private static var frameCounter:uint = 0;
// 1000 miliseconds / 50 frames per second = 20ms for displaying one frame
private static var _ms:Number = 1000/50;

3. you write your own getTimer function

private static function getTimer():uint{
    return frameCounter*_ms;
}

4. at the beginning of an “update” function you increment “frameCounter”:

public static function update(timerevent:Event):void {
    frameCounter++;
    (...)

5. And to add a pinch of a spice to our masterpiece, we add setter and getter of “_ms” variable:

public static function set fps( val:Number ):void{
    _ms = 1000/val
}
public static function get fps( ):Number{
    return 1000/_ms;
}

What we do here, we change Twease’s getTimer() method which gets time since flash vm start, to quasi-getTimer which returns the same, but with respect to frame-drops – so if we will loose some frames during tweening, our getTimer will slow down too. This is rather a hack than a bug fix – a real fix would involve changing something in Twease’s “render” function, to force rendering of the tween at the end.
At the beginning we should provide our movie’s frameRate:

Twease.fps = stage.frameRate;

Otherwise we assume that the framerate is 50. Ok, Im talkin obvious things right now so this is the end of this post. (“hacked” twease: here)

Tags: , , ,
Posted in flash experiments | Comments (0)

Particle-based fluid simulation

January 15th, 2011

I’ve recently stumbled upon this paper about fluid simulation – “Particle-based Viscoelastic Fluid Simulation by S. Clavet et. al.

This paper just screams “implement me”, because its content lacks of unnecessary formalism and entire idea of particle simulation is explained with a pseudocode. So all I needed to do is just rewrite the pseudocode into an actionScript code…
So this is the demo:

There are bunch of parameters which controls the fluid properties – this is an advantage of using the particle fluid model.
Make/grab option lets you add the particles, as well as grab them (when clicked in the center of the particle )
Yield ratio influences stickyness or “stretchyness”. The lower the value, the stickiness or “stretchyness” is higher (of course if “sticky” or “stretchy” sliders are nonzero).
“Smooth jitter” and “smooth pulse” smoothes fluid velocity field, “smooth jitter” handles fast velocities and the other handles slow velocities respectively.

There are many possibilities of how to optimize this, mainly PixelBender to calculate the distance field and alchemy to optimize some vector operations. I believe that there exists some tricks to optimize the goo rendering – it’s taking 50% of frame evaluation. Another subjects to optimize:
– highly unoptimized collision system
– getting rid of Vector’s splice function in spring adjusting function
Maybe somebody in the future (most probably – me;p) will “pixelbenderize” this thing, mainly because I’m curious how much faster can it be.

Additionally I’ve written a “library” (1000 lines of code, the “library” term is an exaggeration) which lets you create your own goo, main class of the library is instantiated via
var gg:GooGen=new GooGen( stage.stageWidth , stage.stageHeight );
There is a bunch of methods for adding,deleting particles, and most important – for simulating them:

gg.addParticle( x,y ); // add particle at x,y
gg.step(delta); // one step of simulation
gg.drawParticles(); // renders all particles, since GooGen extends Bitmap class
gg.getParticleAtPos(mouseX,mouseY); // gets particle at x,y
gg.addBody( x,y,width,height,rotation); // adds a wall. avoid adding too many walls, or optimize my code ;p

I don’t believe anyone will try to do something using this class, so I saved myself a trouble of writing any documentation :P Wide programmers will always figure out how to use it from the demo source I’m providing:

demo source
GooGen “lib”

Demo uses (as you can see) bit101’s minimal components.

Posted in flash experiments | Comments (3)

Papervision3D real-time level of detail ( LOD )

July 24th, 2010

I’ve changed my old quadrics decimation library to make it run in real-time.

Previous quadrics were intended to work with big meshes ( that is over 5000 faces, meshes with such number of faces slows pv3d down very much, and they can’t be used on the web ) and task of decimating such mesh involved converting to my mesh format ( instead of papervision’s TriangleMesh ), decimating and then converting back to TriangleMesh. This type of workflow excluded the possibility of real-time LOD ( for games for example ) because to make LOD work in real time in papervision, we must extend TriangleMesh class and refine geometry that is currently displayed on screen.

New library, “qemlive” depends on HEMesh ( the name comes from Half-Edge mesh because it uses half-edges for adjacency lookup ) class that extends Papervision’s TriangleMesh class and during decimation, HEMesh refines TriangleMesh’es GeometryObject3D. It also remembers everything that was changed during decimation, to effectively revert decimation and come back to the original form of a mesh. To speed-up the decimation process, edge collapses don’t compute new vertex positions, best vertex is chosen among face’s vertices.

Now, the examples ( notice the speed-up in fps )
CYLINDER

CUBE


SPHERE

Here, uv coords and normal’s prevervation ( described further ) was used to preserve spherical shape of the sphere
X-WING
For an x-wing, click HERE

When decimating xwing, uv and normal preservation was used, to preserve two “antennas” in the front of the xwing. The texture mapping breaks down a bit while decimating, this is because there are many discontinuities in xwing’s texture.

All models use almost the same decimation settings, only interpolation method was changed. There are many other settings that changes algorithm’s behaviour… but yah, too lazy to document it. Nobody likes to make a documentation I suppose ; )

The library isn’t public-ready because the code is without documentation and with some debug variables ( as always :p ) but I’ve decided to show the source code, it’s available on googlecode:
http://code.google.com/p/bartekz/source/browse


Zipped qemlive:
http://code.google.com/p/bartekz/downloads/list


Demo source ( not too clean, but the hell … )
http://dl.dropbox.com/u/1268089/QEMLive.as

To instantiate HEMesh, just do this:

var model:HEMesh = new HEMesh( null , null, null , TeleQEM.INTERPOLATE_UV_AND_NORMALS );
model.init( new Sphere( new WireframeMaterial(), 100 , 20 , 20 ) );

See the null’s at the beginning of the constructor? This is one of the reason’s that this library isn’t “public-ready” :p
The fourth parameter controls the way the mesh is decimated ( there are million of other parameters that you can figure out yourself in TeleQEM class ). The possible values are:
TeleQEM.INTERPOLATE_NOTHING – look only at geometry when decimating
TeleQEM.INTERPOLATE_UV – look at uv coordinates during decimation – algorithm tries to preserve correct uv mapping
TeleQEM.INTERPOLATE_UV_AND_NORMALS – look at face normals during decimation as well as uv coordinates – algorithm tries to preserve correct shape of a geometry

We can listen for mesh creation completion:
model.addEventListener( Event.COMPLETE , initComplete );

private function initComplete( e:Event ):void{
do some stuff…
}

To decimate triangles:
model.newqem( model.numFaces*PERCENT_OF_FACES_WE_WANT_TO_LEAVE );

We can set up a listener to listen for decimation completion:

model.addEventListener( TeleQEM.COMPLETE_DECIMATION , decimationCompleted );
private function decimationCompleted( e:Event ):void{
do some stuff…
}

ps. This LOD can be optimized by changing as3’s arrays into vectors. My old decimation algorithm has been made for flash player 9, but the science moves forward … ;) So maybe this will be fixed in the future.

ps2. During “undecimation”, geometry is “forgotten” to free up some memory. If it weren’t, the second decimation could use this fogotten information to decimate the model faster. I think I will make this as an option in HEMesh class in the next update of qemlive – to reuse the decimaton info.

Tags: , , , ,
Posted in flash experiments | Comments (0)