Adding 3D File Types and Animation



Adding 3D File Types and Animation

Planned from the start, Zest3D was to incorporate industry standard libraries and support for CPU physics, image handling and 3D model/animation support. To achieve this we understood that we would need to make use of the Crossbridge C++ compiler capabilities, to interface with leading C++ open-source libraries. These libraries would include (but not limited to):

  • Bullet Physics
  • OpenIL Image Library
  • Assimp Model/Animation Library

Since adding Bullet Physics and OpenIL to Zest3D (in dev branch, mostly complete), Zest3D already supports the majority of the following image formats:

  • Blizzard game textures – .blp
  • Windows Bitmap – .bmp
  • Multi-PCX – .dcx
  • DirectDraw Surface – .dds
  • Dicom – .dicom, .dcm
  • Flexible Image Transport System – .fits, .fit
  • Graphics Interchange Format – .gif
  • Radiance High Dynamic – .hdr
  • Macintosh icon – .icns
  • Windows icon/cursor – .ico, .cur
  • Interchange File Format – .iff
  • Interlaced Bitmap – .lbm, .ilbm
  • Infinity Ward Image (doesn’t work with MW2 iwi files) – .iwi
  • Jpeg – .jpg, .jpe, .jpeg
  • Jpeg 2000 – .jp2
  • Homeworld texture – .lif
  • Half-Life Model – .mdl
  • MPEG-1 Audio Layer 3 (Amazon MP3s work, Apple’s do not) – .mp3
  • Kodak PhotoCD – .pcd
  • ZSoft PCX – .pcx
  • Softimage PIC – .pic
  • Alias | Wavefront – .pix
  • Portable Network Graphics – .png
  • Portable Anymap – .pbm, .pgm, .pnm, .pnm
  • Adobe PhotoShop – .psd
  • PaintShop Pro – .psp
  • Pixar – .pxr
  • Raw data – .raw
  • Homeworld 2 Texture – .rot
  • Silicon Graphics – .sgi, .bw, .rgb, .rgba
  • Sun Microsystems, .sun
  • Creative Assembly Texture – .texture
  • Truevision Targa – .tga
  • Tagged Image File Format – .tif
  • Gamecube Texture – .tpl
  • Unreal Texture – .utx
  • Valve Texture Format – .vtf
  • Game Archive – .wad
  • Quake 2 Texture – .wal
  • Wireless Bitmap File Format – .wbmp
  • HD Photo – .wdp, .hdp
  • X Pixel Map – .xpm
  • Doom Graphics

We are now embarking on our next major compatibility feature. Thanks to ongoing work by Ben Whiting, we are currently rolling in some of the first major community additions into the Zest3D engine, which is incredibly exciting for us. 😀 As with our approach to image handling, early on we supported a very limited set of file types, we even ignored support for JPEG and PNG which may have seemed strange as they are both handled by Flash. However, we did this in favour of a single threaded image handling approach that uses the OpenIL C++ library to add support for all of the files mentioned above, which already includes support for JPEG and PNG 😉 All of this can now be handled by Zest3D using one single, concise and streamlined API.

We have therefore taken the same approach for 3D meshes, scene and animation file support. On our roadmap was full support for the Assimp C++ library and we are currently integrating this with the help of Ben. This library will provide users with a very large selection of file types that will soon be supported by Zest3D:

Common interchange formats

  • Collada ( .dae )
  • Blender 3D ( .blend )
  • 3ds Max 3DS ( .3ds )
  • 3ds Max ASE ( .ase )
  • Wavefront Object ( .obj )
  • Industry Foundation Classes (IFC/Step) ( .ifc )
  • XGL ( .xgl,.zgl )
  • Stanford Polygon Library ( .ply )
  • *AutoCAD DXF ( .dxf )
  • LightWave ( .lwo )
  • LightWave Scene ( .lws )
  • Modo ( .lxo )
  • Stereolithography ( .stl )
  • DirectX X ( .x )
  • AC3D ( .ac )
  • Milkshape 3D ( .ms3d )
  • * TrueSpace ( .cob,.scn )

Motion capture formats

  • Biovision BVH ( .bvh )
  • * CharacterStudio Motion ( .csm )
  • Ogre XML ( .xml )
  • Irrlicht Mesh ( .irrmesh )
  • * Irrlicht Scene ( .irr )

Game file formats

  • Quake I ( .mdl )
  • Quake II ( .md2 )
  • Quake III Mesh ( .md3 )
  • Quake III Map/BSP ( .pk3 )
  • * Return to Castle Wolfenstein ( .mdc )
  • Doom 3 ( .md5* )
  • *Valve Model ( .smd,.vta )
  • *Starcraft II M3 ( .m3 )
  • *Unreal ( .3d )

Other file formats

  • BlitzBasic 3D ( .b3d )
  • Quick3D ( .q3d,.q3s )
  • Neutral File Format ( .nff )
  • Sense8 WorldToolKit ( .nff )
  • Object File Format ( .off )
  • PovRAY Raw ( .raw )
  • Terragen Terrain ( .ter )
  • 3D GameStudio (3DGS) ( .mdl )
  • 3D GameStudio (3DGS) Terrain ( .hmp )
  • Izware Nendo ( .ndo )

An asterisk indicates limited support. For a list of planned formats, see the wishlist.

As you can see, this is a huge selection of file and animation type and combined with the extensive image handling capabilities, this should mean that Zest3D can handle almost any model that you wish to load into your projects. 😀 We are excited as we are fully aware that these features are a requirement for many of your professional projects. We hope that these new additions will position Zest3D as the most performant, flexible, simple to use and the most feature rich library available for the Flash and Air platforms.

Posted in zest3d Tagged with: , , , , , , , , , , ,

Zest3D Community and Roadmap



Zest3D Featured By Adobe

After months of collaboration, we have officially been featured on the Adobe game frameworks website. This is a great move to a more open Flash platform and has enabled us to commit fully to the platform and start focusing our efforts on making Zest3D the free and open-source Stage3D engine of choice. Zest3D was built on clear goals and professional engine foundations, as well as our focus on targeting mobile devices from the very start. Today, Zest3D provides some of the fastest possible rendering speeds for Stage3D.

Over the recent months, we have seen many of the main Stage3D engines shifting focus to other technologies or their funding being discontinued but now, thanks to Adobes support, Zest3D has received funding that will set us on our future roadmap and continue to provide you comprehensive community resources and ongoing development on the Stage3D platform. This also means that we have been hiring developers who have already started work on some of the upcoming, advanced features of the Zest3D platform. More info on this coming soon but it’s a truly exciting time for Zest3D.



We are very happy to announce that you can access the Zest3D community site today! We have provided an area for you to collaborate and learn from other Zest3D developers. You can access the Zest3D forums, your own personal wall, free assets and a fully fledged social network that will keep you connected to other community members. You can also get the support that you may need to complete your projects or just stay up-to-date with the ongoing development of Zest3D. Documentation, wikis and a video tutorial service will also be available very soon so get started today, learn about the Zest3D engine and meet other Zest3D developers by joining the community at:



We are also excited to talk about some of the upcoming features for our v1.0.0 release of Zest3D. As well as these, we have been working on features that will lay the foundations for future developments of an advanced rendering pipeline solution for Adobe Flash & Air. In the mean-time, please check out our current release roadmap over at the community site:



We would like to take this chance to thank the community members that have directly or indirectly contributed to the success of the Zest3D platform. We are working hard to provide a fast, free, open-source and professional solution for the Stage3D platform and your contributions are received with our appreciation. Prior to being featured by Adobe, Zest3D did not accept financial contributions as we did not know if Zest3D would ever be a featured engine. Now we are fully commited to the Zest3D platform and we’ve provided a donation page and recognition wall. We understand that you care about the Flash and Air platforms and if you would like to pledge, even a small donation, we will use it to directly improve Zest3D with new features, resources and content. Thank you!

Posted in zest3d Tagged with: , , , ,

AGAL2 is here 2


This article is a continuation from my original ‘AGAL2 is Here’ blog post. For anyone who may have missed my introduction to the new features of AGAL2, you can head over to the original article at:


More AGAL2

Continuing on from the last article, I have 4 more features that I would like to cover and then I also want to talk about profiles and the fact that some of these features do not come under the new ‘standard’ profile and could be considered to be AGAL1 features. More about that later, for now, the remaining topics are:

  • Floating point textures (RGBA_HALF_FLOAT)
  • Partial derivatives (ddx, ddy)
  • Fragment depth (od)
  • Texture anti-aliasing


Floating point textures (RGBA_HALF_FLOAT)

When we create a texture, we can actually render our scene to that texture, this is called a render texture or offscreen buffer. Previously we only had a single texture option and would create a texture that contained 8 bits per channel. We instantiated this with Context3DTextureFormat.RGBA. Now we have access to a new texture type Context3DTextureFormat.RGBA_HALF_FLOAT which provides us with 16 bits per channel. To make use of this texture type is very simple, let’s say that we are going to create a render texture which is rectangular, we could use the following:

var rtt:RectangleTexture = context.createRectangleTexture(800, 600, Context3DTextureFormat.RGBA_HALF_FLOAT, true);

Having a wider bit range is particularly useful when working with deferred HDR rendering. Remembering that data in a shader is computed component-wise, 8 bits per channel can be very limiting and unable to simulate realistic lighting over a large range of colors. The color depth of texel data is known as the dynamic range and the new RGBA_HALF_FLOAT provides us with an increased range allowing for more realistic looking lighting conditions.  We must later compress the results back into the standard RGB color space and this technique is called tone mapping.

The picture below shows a two scenes from Half-Life 2. Notice the difference in detail and contrast provided by the high dynamic range (HDR) version on the right.



Partial Derivatives

The new ddx and ddy operations allow us to compute the gradient of surrounding fragments on either the x or y axis, for each fragment in the sampler. This is useful for a few reasons and notable when we need to perform anti-aliasing or blending between values in height maps.

Below is the result of a very simple AGAL2 test that I wrote. The original image contained black and white chequered triangles on 4 colored backgrounds. The result was then sent back to the output color channels and output into the color channel.



The following fragment program shows my usage of the ddy operation to generate this output:

tex ft0, v0, fs0 <2d,linear,anisotropic16x,nomip>
ddy ft0, ft0
mov oc, ft0

The operations here are:

  • Load the texture from fragment sampler 0 into the temp fragment register 0.
  • Perform the ddy operation on temp fragment register 0 and store the result back into the temp fragment register 0.
  • Moving the contents of temp fragment register 0 into the output color register to be displayed.


Fragment Depth

Having the ability to write to the depth buffer can be used to influence depth passes and the new ‘od’ operation makes that possible. In the same way that we use ‘oc’ to output the color to the backbuffer, ‘od’ enables us to output a depth value to the depth buffer. By writing to the depth buffer and then testing against the buffer with depth tests, such as:


We are now able to influence the way in which the depth buffer is written. This new feature enables effects that were not possible when the buffer was affected only by the geometry. An example of this might be a shader where geometry is created in the fragment shader, such as a fur effect. The depth information can also be written to the depth buffer so that the data doesn’t get overridden with another geometry.

In a similar use-case, Ariel Nehmad of Flare3D points out that this is also useful for volumetric particles.

Another cool use of output depth is volumetric particles, basically writing particles depth based on a grey scale image.


Texture Anti-aliasing

Texture anti-aliasing is the ability to reduce artefacts and pixelation of textures by combining data from surrounding fragments. Again, this is as simple as passing an argument such as:

context.setRenderToTexture(texture:TextureBase, enableDepthAndStencil:Boolean, antiAlias:int=0, surfaceSelector:int=0, colorOutputIndex:int=0):void

Stage3D makes use of multisampling anti-aliasing (MSAA). By passing a value to the third parameter, we can assign an anti-alias value which is an integer within the closed range of [0-4]. 4x anti-aliasing provides the highest quality anti-aliasing but with that quality comes a performance hit so it may be useful to allow your users to configure these setting in accordance with their device’s capabilities, that way they can get the best quality gaming experience.


The image above (credit to illustrates the use of MSAA to reduce harsh edges and artefacts. This improves the overall visual quality of the final render by interpolating the values around the edge of the model, causing the model to blend into its surroundings.


Stage3D Profiles

Earlier I mentioned that I would comment about profiles. It’s worth noting that with the release of Flash Player 14, we get a new Context3DProfile.STANDARD profile. We are able to allocate this when we make our context request:

content.requestContext3D(Context3DRenderMode.AUTO, Context3DProfile.STANDARD);

Some of the features that I have discussed in these two articles are capable of working in previous versions of the player. Cheng Liao from Adobe, who has been working on these features, has kindly stated which features will be capable outside of the standard profile in his comments on my previous blog post:



This is a very exciting time to be working with Stage3D, the additional functionality will provide the basis for some great new features. Zest3D will incorporate these into the general pipeline allowing us to start testing a deferred rendering pipeline with a view to creating a physically based rendering (PBR) pipeline.


Next Time

In my next blog post I will post the code that I am currently using to test multiple render textures (MRT) and I’ll show you how to address and write to multiple textures from within a single shader pass. Until next time, please follow me on twitter for updates 🙂


Gary Paluk

Posted in AGAL2, stage3d Tagged with: , , , , , , , , , , , ,

AGAL2 is here


After a bit of a start and stop first round, the Adobe team recently stated that they were back and working on the AGAL2 specification, a feature that was previously available in an earlier beta version of the Flash player, but later dropped but a feature set that I had been eagerly awaiting.

Anyone who joined us at the last Stage3D online conference will have seen the Adobe Flash team showing off some of the great new player features, which included demonstrations of AGAL2 in action, amongst other features. Today, I’m really excited to see that the new beta player is available for download and the AGAL2 features will be available publicly in the next iteration, which is scheduled for public release next month. Meanwhile, we can download the latest beta player from Adobe labs:


What’s new in AGAL2?

AGAL2 offers a set of additional features that can be used to improve the visual fidelity of rendering output in your Stage3D projects. This means that Flash graphics are about to got a lot sexier. Features such as MRT help to increase the speed of rendering by referencing multiple render to target textures from within a single shader pass, we have additional features and memory space. So what can you expect to be playing with? Here is a quick overview of some of the new features:

  • Multiple Render Texture (MRT)
  • Anisotropic filters
  • Conditional forward jump
  • Increases in register space
  • Floating point textures (RGBA_HALF_FLOAT)
  • Partial derivatives (ddx, ddy)
  • Fragment depth (od)
  • Texture anti-aliasing


Multiple Render Targets (MRT)

MRT is a feature that will allow a shader to access a number of addressable render targets. This is useful when considering the concepts used in deferred rendering. Deferred rendering is a technique in which multiple images are rendered sequentially and then those images are composited back into a final result. The memory space used during this process is often referred to as the GBuffer and will contain channels such as; albedo, light, normals, depth etc. There are a number of advantages to this technique, perhaps most notably, the ability to render lights to an independent light map, which is then combined with the scene accordingly.



Anisotropic Filtering

Anisotropic filtering is used to improve the artifacts that are caused by viewing a surface at an oblique angle. The image below illustrates the difference in output quality where the texture on the right is being anisotropically filtered.


To make use of this feature is very simple. A new sampler parameter is now available that can be placed within a tex operation as such:

tex ft0, v0, fs0 <2d,anisotropic8x,miplinear,wrap,dxt1>

The anisotropic sampler parameters can be any of the following:

  • anisotropic2x
  • anisotropic4x
  • anisotropic8x
  • anisotropic16x


Conditional Forward Jump

If you are familiar with an if statement, you are already well equipped to dealing with conditional jumps on the GPU if you’ve used that with an else statement, then you’re really ready to roll. Prior to this, AGAL required various hacks to achieve similar functionality with branching that required checks against register data. The conditional flow controls of AGAL2 allow for execution of shader code upon a particular condition. These operations are:

  • IFE – (if equal)
  • INE – (if not equal)
  • IFG – (if greater than)
  • IFL – (if less than)
  • ELS – (else)
  • EIF – (end if)

Collectively they serve to provide developers with more granular control over the flow of their shader programs but I must add a quick note to say they should be used judiciously. Using conditional statements inherently means that you will be using more operations, which can impact the performance of your shader code. That being said, conditionals are great when used to simplify workflow and their advantages often outweigh the negative performance hit. It’s probably wise to see what works best and monitor execution speed of your shaders. There is always Adobe Scout or Intel GPA etc for such tasks 😉


Increased Register Space

In the previous AGAL spec, we had access to the usual set of registers. Vertex and fragment registers were made available, allowing us to intermediately store resources and make them available to the programmable graphic pipeline. Whilst this is exactly the same with AGAL2, the amount of memory that each shader can access has been increased. Here is a chart that shows a comparison between the numbers of available registers.

AGAL Resisters

We can see from the table that we have access to well over double the number of registers on most registers. Possibly the two most notable would be the number of tokens that can be used, which directly translates to the overall size of your shader programs, and the VC register. My guess is that the large increase of the VC register is balanced like this for one important reason, bone animation. Bone animations are used for manipulating vertices, the technique is also known as skinning, and requires that either matrices or quaternions to be uploaded to the GPU via the VC register. The original AGAL spec was quite limited in this regard but the increase means that more than double the number of bones can be uploaded, offering the ability to produce more detailed animations.


Half Time Conclusion

Well, that’s half way! We can see that Adobe are really bringing exciting and much awaited set of features and whilst many of them are nothing new to the 3D community, it’s important to realize that the emphasis for Adobe is on platform reach. Adobe are seemingly striving to provide cross platform GPU support to as many users as possible by offering subsets of features that target as many GPU chipsets as possible. In this regard, it makes complete sense that the Flash Player team are trying to ensure that Stage3D doesn’t need to fall back on its software rendering mode and the result of that is a good overall experience to the end-users.


Next Time

Next time I will cover the remaining features and provide you with code examples. Be sure to check back or follow my Twitter account for more updates. 🙂

Gary Paluk


Posted in adobe, AGAL2 Tagged with: , , , , , , , ,

Response from Adobe 2


I’m happy that say that I got a response to my last message to Chris Campbell (@liquidate) regarding the lack of developer PR from Adobe and he asked for feedback that could help with regards to developers and teams marketing their Adobe based projects and how Adobe could play a role in enabling that. I genuinely think that Chris aims to support the developer community, I’m sorry for the barrage that he’s getting right now. He’s definitely not to blame and seems very supportive so I want to thank him.

Chris’s post can be read on the Adobe blog at:

Chris Campbell says:
March 30, 2014 at 11:32 am
Thank you Gary. Your open letter was read by many members of our team.

I agree that our marketing could be better. I’d love to hear suggestions on how we can leverage the strength of the community to improve this.

I’ll also work on getting blog posts created that go into technical detail on some of our upcoming feature work.

Work is still being done on the Linux version of Flash Player (PPAPI) and you can expect that to continue. Adobe is also committed to making sure the NPAPI version is updated with security fixes. There are no plans to resurrect the Linux AIR target at this time. However, we worked with Valve recently to make sure that the AIR based movie “Free to Play” was available on SteamOS so there are some options still available depending on the version of AIR required.


Below is my reply which aims to bring light to one of the biggest issues, the lack of equal opportunity for all developers that work on the Flash and Air platforms. I believe the lack of equal opportunity led to many developers abandoning the Flash platform and is one of the major topics that I personally hear about from very skilled developers, most of which are struggling to get exposure due to Adobes preferred supplier chain. I have focused on my own experience as a developer during my main project.

Hi Chris,

Firstly, it’s great that you’re listening to the community and acknowledging a lack of community support. I look forward to reading about the upcoming features and as requested, would like to offer some ideas from a developer perspective. I took you up on your offer of communication. I sent you an email a few days ago regarding this, I’m yet to receive a response.

Adobe’s singled out strategic partnerships cause a biased limitation for other developers attempting to gain attention to their products. Regardless of whether a technology is superior at a given time, to maintain a good developer community, developers must be enabled to have equal opportunities to the market. This, in turn, would say that funding should also be delivered based on the ‘potential’ merit of a given platform, including its current development state. This would in turn create a competing environment (@see open market) which would be more fair and better for both developers and end user choice.

As well as my own platform, developers of other platforms are telling me that they are also struggling because peoples inherent gravitation to your partnered products. I am just one of many developers who are feeling this effect. I am the developer of Zest3D, a fast, opensource 3D engine that evolved from code by Microsoft’s principal software development engineer, David Eberly: the platform is designed to be fast and performs with excellent results on mobile devices. The engine is mostly dismissed due to Away3D being your partner product, but then so is Flash as a mobile platform, when it come to 3D. So let’s see them both in action and understand why people might feel this:

Flare3D is a paid product yet that’s simply another business model, I feel that they should be supported as another Adobe platform focused product, it is a great platform. Genome2D suffers the same lack of exposure and bias towards Starling, an inferior performing engine. MadComponents is an excellent UI component library that caters to the use cases that was claimed that Flash shouldn’t be used for, perhaps missed because of the funding of FeathersUI. An argument exists that these products have good community support, but I believe this is exactly what happens when those products have official support and is not conducive of a platforms ability.

I’m sorry to diverge a little here but I feel like Adobe have actually been going in the opposite direction and even cutting funding to some of these groups. This applies to technology that Adobe are shouting about their support. Please let me explain. I worked on the WebGL/HTML5 version of Away3D and our funding was cut after the first round. Myself and Karim Beyrouti worked on this. The decision to mimic the Stage3D API and cross compile the AGAL to GLSL came from myself and was met with opposition, which would have been a very bad technical decision. Karim and I had to push to make that happen against opposition from your preferred supplier. Whilst I ported the math library, integrated WebGL, simulated the Stage3D API, worked on AGAL to GLSL converters, supporting classes amongst others, Karim’s attention was on porting large amounts of the AS3 codebase. We did the majority of this in 8 weeks and personally, I don’t think that it could have gone any more perfectly for Adobes small investment. You can see the results here: Many would consider Away3D to be a competing engine to my own Zest3D so not only does this show my commitment to trying to push web technologies forward but it also gave me an insight to Adobes choices and left me with a lot of questions about the lack of commitment to any of the platforms that Adobe publicly say that they are supporting.

On retrospection of some of these decisions, I found myself feeling that most of them were ludicrous and started making considerations such as; Why are Adobe not realizing the huge potential for a collaborative and economic ecosystem around Adobe products. I’m sure that your users, promoters, key partners etc probably do care about the developers that use your tools as they have a dedicated interest in your tools and what people produce. Your own partners maybe interested in sponsoring, helping or working with the Adobe communities, including Flash and Air and the communities at large. Many companies are based on the continued research and development in key areas of evolving web technology, many of which can be traced directly to Flash development over the last 15 years. Perhaps this would even attract new Adobe partners, who could have an easier platform and take the opportunity to talk directly with developers about their projects. This would undoubtedly show that Adobe has a commitment to the future of the developer community. I also suspect that would make your sponsors and partners feel like those developers might not abandon Adobe platforms like they have continued to do so in the last few years due to giving them very few reasons to stay too combined with the obvious lack of trust from the developers.

Therefore, would Adobe consider working with partners/developers/sponsors etc to create an open, unbiased environment where Adobe developers (whatever the technology) can can share their projects, create investment opportunities, create tooling, engines and applications that can make good returns on those investments, helping developers to continue the great work that is so valuable to the web at large?

Will Adobe also be at the heart of this with serious commitment to enabling that community and supporting ALL of their developers by removing the currently biased preferred supplier system and continue or (as you state in your response) increase their support with additional funding on a case by case basis, with attention to the actual return on their investment and project scope?

I hope that my opinions as a developer are considered. I feel that these suggestions would undoubtedly increase the developer communities equality by removing a major barrier to entry, create an open platform, create investment opportunities, increase Adobes ethics profile, increase exposure to Adobe products, increase developer satisfaction, increase PR opportunity… the list goes on.

Many thanks for listening.


From a developer perspective, I consider this to be the most basic first step to enabling a rich and diverse developer community. To other engines, platforms and frameworks etc that I did not mention, please comment below and share your resources.

Gary Paluk

Posted in adobe

Response from Adobe


A couple of days ago, I posted an open letter to Adobe which outlined developer concerns about the lack of PR and future roadmaps of the Adobe Flash and Air technologies in favour of their HTML5 based tools. This was sparked by comments in a blog regarding a new set of UI tools for their PhoneGap product.

I had a huge amount of support via email, on this blog and on the original post that I made on Facebook. I’m happy to say that Adobe responded very quickly and the official Adobe response can be found here:

The response takes a positive stance that implies the continued development of both the Flash and Air platforms into the future. I followed this up with the following comment on the Adobe site:

Thank you for the response Chris. I had a lot of messages and support from the Flash and Air community regarding my open letter to you The main topics addressed by developers on my blog, by email and via facebook were:

  •  The lack of Adobe PR at events and mediocre action to the promotion of Flash and Air platform technologies that should be considered when companies make decisions on web products. Managers are looking for stable platforms and Adobe are not vocal in contesting the general false rhetoric that Flash is a dead technology.
  •  The slowdown of feature releases. I understand that Flash and Air are mature technologies, however, developers feel that more can be done to ensure that Flash and Air keep up with mobile and GPU technologies, hopefully these will be fully addressed by AGAL2. Perhaps more technical information about this could clarify what developers can expect.
  • That ASNext being cancelled was considered to be a lack of commitment to the platform. Perhaps outlining in more depth the reasoning behind that would serve to help developers understand that decision.
  • Over the last few years, some large gaming companies have moved towards Linux, is there a possibility of Adobe acknowledging that this will increase the Linux user base and reverse their decision on not supporting the Linux platform?
  • General outreach to the developer community, community projects and general dialogue. You have been good enough to provide your email address here, but as well as a games promotion, projects too. I know that my own project, Zest3D would benefit from that.

The announcement that Adobe is committed to the future of the Flash and Air platforms will be great news to many developers. I thank you for your continued work on the products and hope that Adobe address what seems to be a massive lack of PR around its Flash based technologies. We are eagerly awaiting your response on these topics.

Gary Paluk

I really do hope that Chris and Adobe bring real action to the PR table and help developers to promote the Adobe Flash and Air technologies as capable and viable products that already drive millions of games and applications with seamless cross platform capability on desktop, mobile, SmartTV and web. Their gaming support has pushed the platforms forward to near native speeds and it would be great for community projects, such as my own 3D engine, and many others to get more developer coverage and Adobe support.

The future progress of the web should not be limited to the idea that the pace of Adobe Flash and Air development aught to slow down in order to make the progress of HTML5 seem faster than it really is. Instead, people at Adobe could take the time to recognise that HTML5 standards are not what people had been hoping for and that many large companies have reversed their own decisions on HTML5 policy. Perhaps Adobe can take that and use it to cross promote their other great tools whilst maintaining one of the best ecosystems of developers and to take care of them them rather than alienating them into moving to competitors, who would do almost anything for such skilled and dedicated developers.

We should also be realistic about our expectations of Adobe. I think that the Flash and Air community can take this away. We are united in our opinions that Air is a superior platform, not only for gaming and video, but across the entire cross-platform scope. Adobe have been doing a very poor job to promote it that way in order to promote their HTML5 technologies and regardless of what Adobe do in response, we can all help to make people understand that Flash is not a dead technology, that it is a mature, cost effective solution that is superior to current alternatives and that millions of applications, mobile apps, RIAs and frameworks are using Flash and Air very effectively. Flash is still active and continually being developed and excels where HTML5 will always fail as HTML5 is a specification that can not change.

Gary Paluk

Posted in adobe Tagged with: , , , , , , , , ,

Open Letter to Adobe



The following message was originally posted on facebook:

Hi Loni, firstly, thank you for your response to questions. I was a developer of the Away3D TypeScript HTML5 project which was funded by Adobe. I wrote my own Flash/Air 3D engine called Zest3D which had no funding from Adobe, so I’m in quite a good position to comment given my experience with the technologies being discussed.

The comments here illustrate just how concerned developers are, developers that have invested in Adobe technology over the years. I have invested 13 years of my own development career in Adobe products and evangelized the technology over that time. Your users can see that there is a perfectly good technology that does more than the new HTML5 offerings and they are evidently frustrated that you are not supporting developers that do not understand why they are being forced to retrain to use inferior technologies.

Whilst I understand business choices are being made to support HTML5, Adobe should understand developers will leave rather than use inferior technology. I, for one, would resent moving to your HTML5 technology and every highly skilled developer that I have spoken to has said the same. You can see that in the comments already received.

Many of those developers feel that Adobes evangelist attitude to HTML5 is misplaced and a PR/market bending directive that is damaging their livelihoods and the skill-sets that they have accumulated and as most people would understand, developers and artists want to use the best products and workflows to get a job complete. In this case, the best product is Adobe Air and certainly not PhoneGap. So why do we keep seeing Adobe pushing the technologies that the developers do not want?

I would like to take the opportunity to ask Adobe to speak out and offer their support to existing developers with serious PR and coverage and continued accelerated roadmap for the Adobe Flash and Air product before all of your best developers leave and take their years of development and programming skills with them. Adobe has seen this already as developers have sought to find other native solutions, Unitiy has become the entry level tool of choice and companies like myself and Minko are essentially planning or working on building superior tools that may soon make Air obsolete whilst supporting native and HTML5 development without the need for an Adobe toolchain. This is the effect of alienating your development community and will surely impact sales of your supporting tools.

Personally, I do not want to see Adobe Air or Adobe Flash disappear as they both have a formidable user base, excellent workflow, perfect cross-platform capability. With a small amount of investment, I feel that Flash and Air could be a much superior technology and with this approach Adobe might regain the trust of their developer community whilst continuing to enrich the lives of those developers who have continued to champion Adobes history of excellent web technologies.

Gary Paluk

If you are a developer that is affected by Adobes technology policies, please leave a comment below to show your continued support. Thank you

Posted in adobe Tagged with: , , ,

Zest3D Real-time Demo



Creative 3D

I’ve always been captivated by the talented artists that create demoscene 3D visual art and audio. I’ve watched and listened to both chiptunes and followed retro graphic demos for many years all the way through to modern remixes and GPU based demos. I’ve always been inspired by them and hoped that one day I might understand 3D mathematics well enough that I could even make a 3D demo of my own. It has been this desire that has led me down the path of 3D graphic programming and has resulted with 3D programming being my full-time job.

A few months ago, I made a conscious commitment that, when I got some time, I would start working on a set of features that would allow developers to create 3D graphics that would be representative of demoscene style creative art. My focus would be to guide Zest3D toward creative visuals and that a new developer API would ensure that they could be implemented as simply as possible. I would also continue to focus on high performance so that these creative visuals could be seen on the widest range of mobile, tablet and desktop devices.

One Step Closer

I’m an extremely busy person and whilst I’m still yet to start work on a full blown demo using Zest3D, I am able to show you a real-time example of Zest3D running in the browser, with just a hint of demoscene style visuals. This gets me one step closer to my goal of making mathematical art more accessible and also takes me one step closer to creating my own demos.


Real-time Demo

You can see the live real-time HERE – (Flash player 11.8 required)

It is possible to move the scene with the following keys:

  • W, A, S, D
  • Up, Down, Left, Right
  • Home, End
  • Mouse wheel


Gary Paluk

Posted in zest3d Tagged with: , , , , , , , ,

Away3D TypeScript at Mosaic3DX


Away3D are preparing to present at Mosaic3DX, a science and technology conference that focuses on imaging, visualization and 3D graphics systems. Away3D will present a one hour-long session and will then be available for discussion and demos in the exhibitors hall throughout the rest of the conference. The Mosaic3DX conference has a great line-up of speakers & exhibitors that include:

The conference will be hosted on the 30th and 31st October 2013 and will be located at the Microsoft Research Center in Cambridge, UK. The Microsoft Research center in Cambridge was set up in July 1997 with three researchers. Today over 100 researchers, mostly from Europe, are engaged in computer science research at the lab.


Gary Paluk


Posted in away3d Tagged with: , ,

Away3D TypeScript 4


Away3D TypeScript Dev 4


After an amazing 4.1 alpha launch, Away3D Typescript gained wonderful reception from the developer and web communities. Thanks to all the people who have contacted me to offer their positive feedback. With this in mind, work on the library has continued in preparation for Mozfest, London 2013. This had led to a new collection of examples that really start to show off some of the more advanced features that are already available in Away3D TypeScript, such as:

  • Animators
  • CubeTextures
  • MD2 File Parsers
  • Shadow mapping

Rob Bateman put together this excellent demo, that really shows off a combination of these new features:

Click HERE to see the live, real-time demo and a collection of other demos (Requires a HTML5 and WebGL enabled browser)

Gary Paluk

Posted in away3d Tagged with: , , , , , , , , , ,