We've patched our Collada files loader to provide much faster parsing times. In our tests, some of the files now take up to 10 times less time to load. You can now load 100+MB *.DAE files containing 600 000 polygons and more, including animations.

Another important addition is that we now parse a lot more data about the materials. We are now able to load material values such as the reflectivity, shininess and more to make it easier for the artists to customize the rendering using their favorite CAO tool.

A small patch will soon will soon not only read this data but use it properly to match the requirements of the new version of the lighting engine (minko-lighting). This patch should be available with the 2.0b branch of minko-lighting, which should be released at the end of next week.

Still, it's very important to remember that material settings and edition are very different matters whether you consider real-time or pre-computed 3D rendering. Thus, Minko Studio and Minko ShaderLab will always be the best way to work on real-time materials:

In this video you see how in just 30 minutes we go from a simple 3D shape to a photo-realistic rendering using only Minko Studio. Using code only, this operation would take hours, if not days.

We're dedicated to make those tools user friendly for the artists in order to provide a smooth developer/designer workflow to target both mobile, web and desktop platforms. Minko Studio is currently being tested by multiple game developers around the world and we've received very positive feedback.

We've also fixed a lot of minor bugs. It was also updated to fit Minko 2 new APIs of course. If you have questions or suggestions, you can post in the comments or on Aerys Answers using the minko-collada tag.

I'm very happy and honored to celebrate the 100th watcher on Minko's repository on github. As you know, we're making an increasing effort to deliver the most powerful, most extensible and yet simplest 3D engine ever created. And believe me when I say the beta release of Minko 2 is just the beginning: the tools - Minko Studio and ShaderLab - will give you just another incredible productivity and creativity boost.

And this is just a start... thank you all!

If you want to start working with Minko 2 today, you can get the core framework beta and the corresponding examples on github today.

The first public beta of Minko 2 is available on GitHub. For now, only the core framework is online. The extensions such as minko-collada and minko-lighting will follow in the next few weeks.

This new version of Minko will add:

• A much faster rendering pipeline (+3000% in the best cases)
• Support for the MK file format, optimized for web/mobile 3D applications with lossy/lossless 3D compression for files up to 50 times lighter
• Minko Studio to build 3D scenes and export optimized MK files
• Minko ShaderLab to create 3D hardware accelerated rendering effects
• Lightweight MVC architecture to easily add code for game/application logic
• Faster dynamic JIT shader compiler with more optimizations and support for the "kil" AGAL instruction
• Simplified API to program the GPU with ActionScript code
• Unified scene-to-shaders data binding API
• Procedural animations API
• Better performances for the Collada parser
• New open source examples in minko-examples
• Better quality for projected shadows
• Projected shadows on every light types
• Cubic, spheric and Blinn-Newell reflections
• Support for ambient occlusion maps

To learn more and ask questions about Minko 2, you can read the "About Minko 2" thread on Aerys Answers.

If you have questions or suggestions, you can post on Aerys Answers.

Spritesheets are a nice way to create nice effects with an extensive artistic control. You just have to create a texture with a series of cool-looking sprites to have a nice animation. They are widely used for particles, fog and explosions for example. We used spritesheets to render the explosions and the clouds in our latest game: The Mirage.

When you have the spritesheet itself, you need two things to get it working in your application:

1. A "frame id" value that will be updated to tell which frame of the spritesheet should be sampled.
2. A shader that will sample the spritesheet accordingly.

And here is what you get:

The first point is very interesting because it will allow me to introduce the new MVC architecture inside Minko 2. To animate stuff - and when I say "animate" I mean "update any kind of value depending on time" - we use a controller called the "AnimationController". The very interesting point here is that animating a 3D matrix to translate an object or animating our "frame id" works exactly the same way.

It really was one of our main objectives with Minko 2: make everything a lot easier. And being able to animate scene properties - whether they are used by the scene itself or the shaders - with a single API is a good proof that our work has paid. One would say that there is no such thing as a scene "property" that shall not be used in a shader. And at some extend it is a valid assumption. Thus, having a simplified general purpose API to automate the scene-to-shader marshalling is a must have

The Shader

I'll start by creating the shader and then see how we can add the animation. The vertex shader just makes sure the quad always faces the camera. This effect is achieved by transforming (0, 0, 0) into view space and then use the actual (x, y, z) position of the vertex as an offset. Because (0, 0, 0) will not be affected by any rotation, we end up with a view space quad facing the camera. It has nothing to do with spritesheets per say, but in the end they are mostly used for particles effects so rendering camera-facing quads is a must have:

override protected function getVertexPosition():SFloat
{
	var id		: SFloat	= vertexId.x;
	var corner	: SFloat	= vertexXY.xy;
	var position	: SFloat	= float4(0, 0, 0, 1);
 
	position = localToView(position);
	position = add(position, float4(corner, 0, 0));
 
	return multiply4x4(position, projectionMatrix);
}

Then we have to sample the spritesheet. Here is how a classic explosion spritesheet looks like:

The pixel shader just needs to translate/scale the actual per-vertex UVs according to the frame we want to sample:

override protected function getPixelColor():SFloat
{
	var frame	: SFloat = floor(meshBindings.getParameter(
		"spritesheetFrameId",
		1)
	);
	var uv		: SFloat = add(0.5, interpolate(vertexXY));
	var diffuseMap	: SFloat = meshBindings.getTextureParameter(
		"diffuseMap",
		SamplerFiltering.LINEAR,
		SamplerMipMapping.LINEAR,
		SamplerWrapping.CLAMP
	);
 
	var spriteSheetOffset	: SFloat = float2(
		modulo(frame, 5),
		floor(divide(frame, 5))
	);
 
	var spriteSheetUv	: SFloat = divide(add(spriteSheetOffset, uv), 5);
 
	return sampleTexture(diffuseMap, spriteSheetUv);
}

You can then setup your scene like this:

[Embed("../assets/explosion.png")]
private static const ASSET_SPRITESHEET	: Class;
 
scene.addChild(new Mesh(
	new BillboardsGeometry(1),
	{
		diffuseMap		: TextureLoader.loadClass(ASSET_SPRITESHEET),
		spritesheetFrameId	: 0
	},
	new Effect(new SpritesheetShader())
));

You can send change the value of the "spritesheetFrameId" property and see how the rendering changes. Now how to make the spritesheet "playable" like a real animation?

The Controller

The first (crappy) solution is to implement a timer or something like this. Don't get me wrong: it works. Yet, you'll have only the basics of the animation: you'll be able to play it. You'll have to add some code to be able to stop it, play it reversed, etc... And I'm not even speaking about naming frames to have multiple animations in a single spritesheet.

But wait! As I explained earlier, Minko provides the AnimationController. Controller like in "Model View Controller". In Minko 2, your scene is the View, the "properties" and the data binding API handle the Model and you can use/create/add Controllers. The AnimationController is one of those controllers and it is specially designed to animate stuff.

Here is how we can use it to animate our spritesheet:

var ssc : AnimationController = new AnimationController(new <ITimeline>[
	new ScalarRegularTimeline(
		'properties.spritesheetFrameId',
		1000,
		new <Number>[0, 24]
	)
]);

You can then use all the methods of the AnimationController to animate your spritesheet:

• play/stop
• goToAndPlay/goToAndStop
• setPlaybackWindow

The AnimationController.setPlaybackWindow is very cool because it makes it possible to dynamically setup the "bounds" of the timeline in order to play only a part of it. It's very useful to store multiple animations in one timeline and then play each of them separately. To put it in a nutshell, you have the same control than you have on a MovieClip. But everything is happening on the GPU and the timeline is created programmatically and can animate any property.

Here we use the ScalarRegularTimeline because our "spritesheetFrameId" property is a scalar value. You have other timelines to animate 3D matrices or colors for example. Here is the full code for the scene setup:

var sprite : Mesh = new Mesh(
	new BillboardsGeometry(1),
	{ diffuseMap : TextureLoader.loadClass(ASSET_SPRITESHEET) },
	new Effect(new SpritesheetShader()),
));
 
sprite.addController(new AnimationController(new <ITimeline>[
	new ScalarRegularTimeline(
		'properties.spritesheetFrameId',
		1000,
		new <Number>[0, 24]
	)
]);
 
scene.addChild(sprite);

If you have questions, you can post in the comments on or Aerys Answers.

I've met a lot of people willing to start working with Minko. That's why we've decided to organize our very first workshop ever!
This first workshop would be about Minko's basics:

• how to create a simple scene
• how to manipulate a scene (add animation, change textures...)
• how to handle the camera
• how to load Collada/3ds/Obj files
• the best practices

This first workshop is free.
The current date is set to the 23rd of May.
This workshop will take the entire afternoon and will be set in our Paris office.

We just need to make sure we will have enough participants first so if you are interested, please post on Aerys Answers:

"First Minko workshop in Paris, France!" on Aerys Answers

I hope a lot of people will attend

During last week "Starting With Shaders" workshop, nicoptere asked me about Render To Texture (RTT). RTT is a very common technique used for multi-pass rendering. The principle is quite simple: the pre-passes render the scene in one or more textures. This texture can then be sampled to provide per-pixel data during the rendering pass.

A very common use for RTT is shadow mapping. Shadow mapping is a technique to create projected shadows. The shadow mapping rendering pass will require access to the depth of each pixel as seen from the light source which is "emitting" the shadow. Therefore, each mesh will have more than just a rendering pass. Indeed, we will have to add a pre-pass for each light in the scene to generate it's "depth map".

RTT can also be used to create portals! So it's a very cool feature.

RTT might look quite simple. It reads like it's just like rendering in a texture. But it's not that simple: the goal of rendering in a texture is most likely to use that texture afterward during another pass. Therefore, some rendering passes will depend on other pre-passes. So you have to be able to sort all the passes. It's yet another symptom of the scene tree VS draw calls list paradox: the 3D scene is a tree but the rendering is performed as a list of passes/draw calls. As a developer, you want to affect the rendering effects to the meshes. It's a scene node/geometry centric paradigm. But the rendering API expects a list of passes and each pass will perform a draw call for each mesh it affects.

With Minko 2, it's very easy to perform RTT or multi-pass rendering. Each Mesh as an Effect object. And this very Effect object is a collection of passes. Each pass is a shader, and each shader can render in a texture or directly in the back-buffer. The RenderingController does all the job and creates, organizes and performs all the mesh-to-passes operations. Here is a simple demo:

// setup lighting
scene.bindings.setProperties({
	lightDirection		: new Vector4(.1, .1, 1.),
	lightDiffuseColor	: 0xffffff,
	lightDiffuse		: 1.,
	lightEnabled		: true
});
 
// create render targets
var normalsTexture : RenderTarget = new RenderTarget(
	128, 128,
	new TextureResource(128, 128),
	0,
	0x000000ff
);
var positionsTexture : RenderTarget = new RenderTarget(
	128, 128,
	new TextureResource(128, 128),
	0,
	0x000000ff
);
 
// create the teapot
var teapot : Mesh = new Mesh(
	new TeapotGeometry(),
	{
		diffuseColor	: 0xffffff00,
		lightEnabled	: true
	},
	new Effect(
		// RTT passes
		new VertexNormalShader(normalsTexture),
		new VertexPositionShader(positionsTexture),
		// rendering pass
		new BasicShader()
	)
);
 
teapot.transform
	.appendUniformScale(.5)
	.appendTranslation(0, -0.6);
 
scene.addChild(teapot);
 
// create the sprites to see the result of the RTT
scene.addChild(new Sprite(
	10, 10,
	128, 128,
	{ diffuseMap : normalsTexture.resource }
));
 
scene.addChild(new Sprite(
	10, 148,
	128, 128,
	{ diffuseMap : positionsTexture.resource }
));

The shaders I use for the RTT are debug shaders provided with Minko 2. Here is the code for the VertexNormalShader for example:

public final class VertexNormalShader extends BasicShader
{
	public function VertexNormalShader(target	: RenderTarget	= null,
					  priority	: Number	= 0.)
	{
		super(target, priority);
	}
 
	override protected function getPixelColor() : SFloat
	{
		var normal : SFloat = interpolate(
			vertexAnimation.getAnimatedVertexNormal()
		);
 
		normal = normalize(normal);
		normal = divide(add(normal, 1), 2);
 
		return float4(normal.xyz, 1);
	}
}

A very interesting thing here is that this shader extends the BasicShader. BasicShader handles all the "usual stuff" and its vertex shader does all the animations. So being able to extend it only to override the behavior of the pixel shader is a very cool feature.

RTT combined with ActionScript shaders is incredible. You have to remember that every AS shader you write can fork into many actual shaders on the GPU to handle all the rendering situations. It's yet another problem: it means a "pass" is not just a "shader", but multiple shaders forked from the original AS shader you wrote. For example, a normal pre-pass (rendering the normals in a texture) will have to work for both animated and static objects. So it's actually two passes: the normal pre-pass for the animated objects and the normal pre-pass for the static ones.

Thanks to the AS shaders and the rendering API, you write your shader once and Minko will figure it out all by itself: when to fork your shaders, how many passes are actually needed, what objects should be rendered during each pass, what pass has to be rendered first, etc...

If you have questions or comments, you can post here or on Aerys Answers.

Update 2: I patched the sources to add a few comments and fix a little mistake reported in the comments. Make sure you download the updated sources.

I had the pleasure to animate a workshop just yesterday about "Starting With Shaders" here in Paris, France. It was very nice to meet new people and see what's going on in the heads of some of the most talented French Flash developers. It was also a nice occasion to gather feedback on the new implementation of Minko that we will soon share on GitHub.

I would like to thank the Regart.net formation institute and all the attendees for their attention and support during the event. I think all went well and I will try to do more events like this in the near future.

I presented:

• why shaders are the very fabric of 3D applications
• what shaders really imply on the development workflow
• why AGAL is good for 3D engine developers, but not for game/application developers
• what are the constraints inherited from the classic shader workflow
• how those constraints are solved with Minko

AGAL is explained through 4 examples: solid color, texture, directional lighting and cel shading rendering. Each sample is implemented using both raw AGAL and Minko. Doing AGAL was a bit a pain in the a**. But it was a good reminder of how Minko, ActionScript shaders and the ShaderLab can really empower the developers and the artists. If you don't understand the AGAL implementation, have a look at the ActionScript one which is - of course - much easier to read/work with.

You can download the sources and the slides. They feature an intermediate version of Minko 2 which is basically what we will release in the next few days...

Working with trees as a representation model is something XML is very good at. XPath is a part of the XML specification and it defines a specific syntax to select a subset of XML nodes in an XML document. I think the syntax is quite obvious and very intuitive as it inherits most of its design from the UNIX/URI paths.

That's why we chose to add a simple XPath implementation in Minko 2. You can now write this kind of things:

var visibleMeshes : SceneIterator = group.get("/group/mesh[visible=true]");

The Group.get() method takes the XPath you wan to match and returns a SceneIterator object. This object acts as a wrapper for the fetched collection of nodes that matched your XPath request:

var visibleMeshes : SceneIterator = group.get("/group/mesh[visible=true]");
var numMeshes : uint = visibleMeshes.length;
 
for (var i : uint = 0; i < numMeshes; ++i)
  visibleMeshes[0].visible = false;

The "[]" operator can be used to get the nth item of the fetched collection. To override this operator, we simply extend the Proxy class and override the flash_proxy getProperty() method. Extending the Proxy makes it possible to add two new features:
- iterator: our SceneIterator object can be used in "for each" loops if we override the proper Proxy methods
- property setters/getters overriding: set/get properties on all the selected nodes at once

// fetch all the visible meshes and hide them
group.get("//mesh[visible=true]").visible = false;
 
// fetch all the white meshes and make them white
group.get("//mesh[@diffuseColor=0xffffffff]").bindings.setProperty(
  "diffuseColor",
  0xff0000ff
);
 
// fetch all the visible white meshes and remove them from their parent
group.get("/group/group/mesh[@diffuseColor=0xffffffff][visible=true]").parent = null;

"About Minko 2" on Aerys Answers

Please feel free to ask there any question you might have about Minko 2 and the new features! You can also read this thread. It contains a lot of technical questions/answers about how the framework works and what it provides.

This HTML5 magic is achieved with Orbit, our multi-platform real-time networking technology. And The Mirage is now available on the Chrome Web Store!