Why programmers can’t program

Got this nice link from my colleague and just wanted to share it with you. It’s very funny and also horrible…


3D Software pricing

I just thought about getting a copy of Autodesk 3DS Max 2011 or Maya, but I didn’t believe the pricing! 3DS Max is about 3.9K $ and Maya is about 4.9k $! w00t?
So, I’ll continue using LightWave that was just 795 $. I have to say that I’m really really happy with LightWave – it’s a great modeling and animation software. I just thought about getting Autodesk software, because we want to support their fileformats, specialities and probably write a plugin for it. Maybe I can do it within the 30 day tryout… :D


Molehill API-Details

I just finished watching the new video about API-Design of Molehill on AdobeTV, hosted by Sebastian Marketsmueller.
I’d like to give you conclusion here:
First thing I have to tell, is that most developers won’t even want to “put their hands on Molehill”. Why? That’s quite simple. Most developers want to display 3D-content with ease and without having to read a bunch of books before they can use the technology. It is so that Molehill really requires not only advanced or professional programming skills – you’ll have to have coding in your veins! I for myself will really enjoy coding with Molehill – coding has just embedded in my DNA ;)

So what is this guy talking all about?
There’s still a drawTriangles-method in Molehill, but as you will have expected, it’s not as easy as the old one. As a matter of fact, there will only be a few calculations that will have to be done inside AS3, like building trees if you like them. All calculations concerning transformation, rotation, scaling, etc. is performed directly in the graphics hardware.
I thought they built a big wrapper around everything, so you’d only have a few options, but my thoughts were fortunately wrong. You have all the controls over the graphics device that a C++-Developer has (or nearly). The object-data won’t be saved in Flash’s memory, ’cause everything is being hold in the graphic cards RAM.
To actually work with the Molehill API, you’ll have to write Assembler-Code. Yes, that’s what I wrote: Assembler-Code. Some of you might have seen those codes like

mov eax, ecx
jmp 0x475927

If you want to learn this, you’ll probably figure out that it’s not as difficult as it seems to be. The asm you write for Molehill is being compiled to byteCode, then stored as byteArray and will finally be uploaded to the graphics card via the graphics pipeline.
The API contains only 20 OP-Codes that you should be familar with. If you’ve done 3D-mathematics on your own, it should be self-explanatory.
What will be delivered to the graphics adapter is called TokenStream. Each Token inside that stream is of fixed size: 192 Bits.
It starts with the OP-Code [32 Bits], followed by the Destination [32 Bits], then followed by SourceA and SourceB, each of 64 Bits. Are you still with me? If you answered no, just forget about reading any further… :D

Do you like matrices? I hate them! However, most engines use them and the API has a native OP-Code to do matrix transformations. There are m44, m34 and m33. These are OP-Codes used for matrices 4×4, 3×4 or 3×3.
Let’s say we wan’t to transform mtx2 onto mtx1 and we want to save the equation in output. What we need to do is just simply write Assembler-Code:

m44 output, mtx1, mtx2

Quite simple, eh?
I think about all the possibilities with this API. I’ll have to do a lot of benchmarking when I’ve access to the API. I don’t have any answer from Adobe yet, but even if the alternativa-people have a big head-start, we will be able to get close to them, also if we have to wait for the beta. With the new API, it’s sooo easy and fast to create an engine, I just can’t believe it :) You might think different.

The manner in which objects are hold in the graphics card is totally different than that of every 3D-Engine, including noob3D. I know this hierarchy:
Object -> faceList -> Face -> vertices
so every face has it’s own vertices directly in that class. the graphics hardware just has a buffer with all vertices in it. if you want to know a vertex, you’ll have to know it’s index position.

The readers that have not closed the page yet, may be interested in the session by Sebastian Marketsmueller:

Still wanna put your hands on it? Questions and discussion are welcome.

More information will be made public here, when I’ve seen the other movies. They will also be available at bytearray.org. Maybe Thibault writes some more info on this.

PNGEncoder: crunching and converting BitmapData

In my last post, I talked about the PNGEncoder. I spent some time to make this thing public and included it into a demo on wonderfl.net.

With opaque bitmaps, the encoder should always give you the best result, with transparency, it might give you the best result.

The encoder uses brute force. It processes every line with 5 different filters, then it checks which filter uses least bytes and saves it to the byte stream. The other 4 filtered lines are dropped.
It always depends on your image, which filter gives you the smallest file size.

My encoder has two extra options:
First, you can convert the image from ARGB (what’s used inside Flash) to BGRA. PNGs are written in RGBA-order by default. Converting to BGRA is very useful when using Alchemy, because Alchemy handles images in BGRA-order.
Second, you’re able to choose, if the PNG should be compressed. This is only useful, if you include that image into another kind of data stream that will be compressed with other content. If you just want to save a PNG-File, leave this on! Otherwise the PNG can’t be recognized as such and also the filesize won’t be reduced – surprise!

Here’s the source (and yeah, there’s still some space for improvement ;))

Fileformat for 3D web applications

I just thought it would be great to talk about fileformats for 3D web applications. As you should know, the new FlashPlayer will be able to display and handle a lot more triangles/faces than the current one. At the moment you may be using your 3DS- or Collada-Files; I prefer OBJ.
As a matter of fact, these formats were developed for offline-usage only. Does anyone know a 3D-Format that’s built for web applications? I don’t know anyone.
In our office we’ve got an internet-connection of 16MBit/s – that’s far enough for everything and I don’t have to wait a long time for any content. But at home, I only have 1MBit/s, what’s not that much. In Germany there’re still a lot of people that don’t even have 1MBit/s, no they still have those modems (biip biip) with not more than 56KBit/s. As you can image, it takes a looooong time to download 2 or 3 MB with such a connection.
I downloaded a tree as OBJ-file with about 61K triangles. That’s much you think? Well, for the current available engines it may be much. I want to try this on our own engine noob3D, but the engine does not yet support colored triangles (only textured), so I’ll have to wait til this is supported and I also have to make my parser working asynchronous.
With FP 11 (that one which will hopefully support Molehill), we shall be able to have a lot more triangles in our 3D-Scenes, like Thibault Imbert told us “hundreds of thousands”.

Well, I’m able to handle that much, but how do I load it? My tree, mentioned above, is approx. 8.31MBs as OBJ-File. Let’s consider a Scene with about 250K triangles – how big will that file be? 20MBs perhaps… WITHOUT TEXTURES! Most of the current engines will even crash on parsing a file with about 60K tris.
Is there a solution to reduce that file size? Of course there is! Otherwise I wouldn’t have written this down :D

About 3 or 4 weeks ago, I developed a fileformat especially designed for web-usage. At the moment it includes meshes, vertices, faces, materials, as well as textures(if you want them to be included).
I did try it with the Tree, but my parser also fails because of timeout and I can’t set it to a higher value than 15 seconds?! But I did the test with a small object of about 230 triangles. That OBJ-file was 22KB, then I converted it to my format N3D and got 7KB out of it. Finally I compressed that file with zlib and got 3KB – that’s a reduction of about 86%!
If I have this Tree now and would convert it to N3D and we predict it’s reduced by 86%, the final N3D-File will be just 8.31MBs * .14(ratio) = 1.16MBs.

That’s not everything. By including the textures into that file, we also save the http-request as well as some additional bytes. To get the textures into N3D, I convert the bitmapData into PNG, using a custom PNGEncoder I hacked together from different sources. My default test-picture was 256KB. Then I saved it using a professional graphics program with save for web-functionality and got 252KB. That’s fine, but there’s more :)
I tried converting the BitmapData by using the PNGEncoder provided by adobe (found that class somewhere on google code) and I got about 362KB – w00t? That’s 100KB more than the default image! The reason for this was that the default adobe-encoder didn’t use optimization-algorithms at all. After a short research I found those algorithms on wonderfl, but I wasn’t able to use them all at once, just one by time. That got me to point “do it yourself, daniel”. So I did it myself and combined all those algorithms to be used in one file and got finally a size of: 245KB. That’s less than the professional graphics software gave me :)

I will provide that class soon to the public community.

Let’s compare the results:
The OBJ+MTL-Files + PNG-Texture were 277KB and 3 http-requests.
N3D is 248KB and one http-request.

I will include support for Bone/Skeleton-animation. Who’s interested in this? ^^

btw.: that’s the tree I tried:

Flash 3D Revolution: DirectX and OpenGL directly in your Browser [MOLEHILL]

Hi there,
on Monday, my business-partner and I watched the Live-Stream of the Adobe MAX 2011. They showed a lot of stuff targeting mobile devices (that was the main content of the first session). There will be a lot of interesting stuff for designers to do really good publishing on almost every internet-connected device with just a few clicks.
For both of us, this was not too impressive, because you can already do most (not everything) of this stuff, by using AIR or Flash – but you’ll have to code it yourself. But as we all know: designers aren’t programmers. They don’t even like scripting imo. So for those people, the new features will be very interesting in future.

So let’s get back to the main topic: Flash 3D Molehill API.
This was the last thing that was presented, so we had to wait about one hour, fifty minutes to get informed about some “really interesting stuff”.
Flash will be supporting hardware-accelerated rendering on all plattforms, without having specific hardware requirements.
On Windows DirectX 9.0 will be used.
On Mac and Linux OpenGL 1.3 will be used.
On Android-driven phones OpenGL ES2.0 will be used.
On devices not supporting 3D hardware acceleration a software rasterizer, called SwiftShader, will be used.

This is amazing, isn’t it?
However, I have to stop your euphoria right now, right here. There’s not yet a beta available of this and they are still in early development-stages. If I’d be asked to do a prediction about a release-date of the new Flash-Player, I’d say: “Flash Player 11 with Molehill API will come out in Q4 of 2011″. That would also mean that the first 3D-Content using this API will be published in Q1 2012. So this is my prediction :)
BUT: There is a software-company that already has access to the new API. It’s alternativaplatform from Perm, Russia.
At the moment, I’m in contact with Adobe to also get access to the new API, because we at badnoob.com also do our own 3D-Engine for our project awesay – the virtual and interactive 3D Online-Shopping-Center right in your browser. We do another aproach than the alternativa-guys with our own engine noob3D: we have a real z-buffered 3D-Engine, written in Alchemy. This is that kind of stuff the new SwiftShader will do for us in future. If you’d like to have a look at it, try out the online demo or watch our first demonstration video on youtube. We’re still searching for companies to join us.
What I wanted to say before telling you about awesay is that alternativa is a competitor for us, and it wouldn’t be nice if they were the first company with a DirectX/OpenGL-powered Flash 3D-Engine only because they had access to the API earlier than we have.
I’ll keep you informed, if I had luck with Adobe and if so, provide some nice demo videos :)

More details will come with the presentation by Sebastian Marketsmueller on Wednesday 27th of October 2010 (tomorrow).

finally here’s the link to Thibault Imbert’s page with the first demonstration videos of Molehill API.

stay tuned!

Flash’s Text Engine and it’s incredible behavior

It’s been a while since my last post concering AS3. I’m currently developing the HUD/GUI for awesay and yesterday, I came in contact with the new flash text engine for the first time.
For the HUD, I created a window, where I want to display a title centered on a sprite (horizontally, as well as vertically).

So, after reading some docs about how to create a simple line of text, I finally got it on the screen. To me, the process of creating such a simple line of text, seems horrific. However, you’re able to do a lot of nice things with the FTE, and the good old TextField won’t be improved in future, but is still supported. Because we want our HUD to be multilingual, I decided using the FTE would be a good choice. OK, I went a bit off-topic, so let’s get back to it.

How do I positon a simple line of text (flash.text.engine.TextLine) centered on a sprite? The horizontal positioning is easy, because it behaves like every DisplayObject, so we do it like this:

var sptMyTitleSprite:Sprite = new Sprite;
sptMyTitleSprite.graphics.drawRect(100, 25);
var tlSimpleTextLine:TextLine = myTextBlock.createTextLine(null, 100);
tlSimpleTextLine.x = (sptMyTitleSprite.width >> 1) - (tlSimpleTextLine.width >> 1);

What I do in the code above, is creating a Sprite and draw a rectangle (100 width, 25 height) onto that Sprite. After adding the Sprite onto my displayList, I create my textLine from a TextBlock(not defined in the code above), and finally add the textLine onto my Sprite. When this is done, the textLine’s x-position is centered with the calculation(bitShift by 1 is a simple divison by 2, where the result is an integer).

Ok, that wasn’t too hard, it’s something I do very often. Well, I thought positioning the title in the vertical center of my Sprite is even that simple – Naaah, it’s not! Did you really thought it was that simple, hrhr :D

tlSimpleTextLine.y = (sptMyTitleSprite.height >> 1) - (tlSimpleTextLine.height >> 1);

That does not work. The 0, 0 Point of a TextLine (Roman) is always on the very left of the baseline.
(I catched this image from the Adobe docs).

This behaviour causes the main part of our textLine to be in the negative y-direction(up) of it’s DisplayObject. The Adobe-People may again have smoked one pipe too much while coding this ;-) just kidding!
So when I calculate the vertical center of the Sprite (sprite.height >> 1), and I position the textLine at that position, it will nearly be centered, because it’s baseline is now at y: (sprite.height >> 1).
What we have to do, to position it at the absoule center, is subtracting the half of the textLine’s decent-value. That is everything what’s below the baseline. For example the lower parts of “j, g, y”.
The final solution will be:

tlSimpleTextLine.y = (sptMyTitleSprite.height >> 1) - (tlSimpleTextLine.descent >> 1);

I wrote this post, because I didn’t find any solution to this in the net. This will hopefully help other people.

awesay.com – presentation website online

badnoob.com just published the presentation website of our project awesay.
awesay is going to become a virtual, interactive shoppingmall in 3D!

Visit http://www.awesay.com (German language only)

company blog started

I just wan’t to inform my visitors that we (my company badnoob.com) has started it’s own blog. Main topics are our new Flash 3D-Engine, which is currently under heavy development, and also our project called “awesay” – more information can be found on the blog: http://blog.badnoob.com

Flash’s internal functions scuk!

yeah, it’s not a typo in the title, but it’s almost true!
Flash’s own functions and/or method are slow as I can say. I first noticed this while having a look at TweenLite’s easings.
Math.pow is slow. It’s faster doing x * x * x and so on – yeah really! Don’t believe me? Give it a try!
I assume this behaviour not only to sin, cos and other trigonometric functions (as already found out to be right by polygonal labs), but also to Flash’s own graphics-library.
So I’m on trip atm where I’ll do EVERYTHING myself. I’ve already done a small Bitmap-based Font-Engine, Textfields, unbelievable fast OBJ-Parser and a lot of more stuff… just wanted to let you know this :D (if anyone reads this at all – I dunno)

I also think about y everyone doing flash 3d on this planet, uses sin/cos and so on with radians, instead of creating a lookup-table “once”. horrific – it’s just that what’s done in code these days… ugly code! ever had a look at papervision, away3d, and some more google code project? blehyawk.
enough for know – have a nice day :)