Teleranek

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.

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)

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.

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


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.

When something bad happens, you can observe specific emoticons on the internet. Overwhelming amounts of [*]’s which I’m seeing now, has born a demiurge of artistry in me and inspired me to make this >>enormously highly artistic piece of high end artsy art<<

I called it “stupidity” ;)

3Doodler is… I will save my work and just ctrlv-ctrlc this paragraph from 3Doodler’s help:

3Doodler is one and half in one application. You can use it to generate 2D images ( simply by drawing them on canvas ) or to generate/texturize 3D models ( thus the number 3 in front of the application’s name ). 3Doodler took its name from merging of 2 expressions: “doodle” and “3D” which means the third dimension. So you can either doodle on 2D canvases or doodle on 3 dimensional models, or create new models by doodling on 2D canvas. In the end of this help, you will find some screencasts which explains how to complete certain tasks in 3Doodler, however these demos weren’t made by the real artist, so their artistic value is negligible.
After you finish your work, your doodles/sketches/models won’t go into the abyss of oblivion – by clicking “save”, you will store your sketch, and even replay of your work on server – this means that you can share your sketches with other people. When you create a new model, you won’t be able to save it on server – but you can save your work on your disk.

I’ve just quoted myself, so probably the quoting isn’t necessary, but… whatever.
To make this post more eye-catching, I will put some screenshots. From the logical point of view, they aren’t necessary, because you can just click this link and check everything out by yourself, but everything what concerns things like design,look and appearance isn’t too logical ( look at the appearance of some currently famous celebs, not too logical :) )

This is the 2D sketchpad ui ( ok, maybe not entire UI, I’ve cropped upper main menu and cut some grass on the bottom )
2D sketchpad uses different brushes: textured ones, photoshop-like ones, sprays.
The spray uses gaussian probability density function to make spray look more natural. Different sprays uses different blendModes.
There are also 3 special brushes I’ve “ripped off” ( he didn’t provide a source code, so I had several sleepless nights of working out how he did this ) of awesome Peter Blaskovic’s “Flame” – http://www.escapemotions.com/experiments/flame/#top . And I didn’t manage to obtain the same great effects that he had. But I don’t surrender my weapons and will try to get a bit closer to awesomeness of his flame ;)
EDIT: It appears that Peter Blaskovic didn’t invent these Flame-like shapes, this is an actual existing fractal structure by Scott Draves – http://en.wikipedia.org/wiki/Fractal_flame , I must include these thingies into 3Doodler

And now a few words about a 3D mode:

This is the texture editor:

This is a close-up to texture editor on real models:

And this is a screenshot of “custom model painter”, you paint your models and convert them to 3D. The screenshot is using the “Color” view mode, so the textures aren’t visible, but of course you  can change the view…

Now a little bit of gossip – 3Doodler allowed me to win polish FlexChallenge contest : ) yaay