Shirt MkII
As an exercise this afternoon, I decided to recreate an earlier demo, though this time in WebGL, via Unity3D.
If you didn’t see the previous post it’s here..
And the WebGL/Unity version here…
There certainly were more differences than similarities working with Unity as opposed to Stage3D/AS3 (don’t want to use the F-word!). Here’s a brief summary.
Setting up the scene
In Away3D, there is quite a bit of boilerplate code you need to take care of before you actually get anything on the screen. Manually setting up materials, lights, camera, model parser, etc in code.
In Unity this took less than 2 minutes. Drag/drop bosh. 1 point to Unity 🙂
Creating a Bitmap Generator
In the demo, you can dynamically set the name and initial shown on the trim of the shirt. In the Flash environment (there, I said it!) this is quite straightforward, and you can work visually. All the diffuse and normal maps were created dynamically and then converted to BitmapData for use in Away3D. In Unity, not so simple, however once I found a strategy it wasn’t that difficult, although the bitmap quality, as you will see couldn’t match Flashes vectors. So that’s 1 point each.
Coding
The nice thing about the first demo was the dynamic “physics”. Actually not physics, but a Twist modifier reacting to the speed and direction you move the camera. This took a fair amount of time in AS3, and due to changes in the Flash Player Matrix since it was made, it’s now a bit jerky. At the time I was just impressed it could modify all the vertices in a single frame cycle.
In Unity I was amazed how quickly this went. Coding in C#, I was interesting how little code was actually necessary. I did have a smooth camera orbit script ready, but the rest was from a blank page.
I’d have to say, coding in Visual Studio, with the advantage of being able to choose which parameters to set in code, and which to work on WYSIWYG is the only way to go. The whole project from start to finish took 2 hours in Unity (with a bit of messing about with HDR maps under way) vs. about 10 hours in Flash, although that was an early beta of Away3D for Stage3D. Unity wins here hands down. 2-1 to Unity.
Quality
Now let’s consider the final outcome. Bitmaps definitely crisper in Flash, due to the vector text, and I also used a blend mode to make the text look more realistic, i.e applied to the underlying material. Performance wise, the Stage3D version does seem to run slightly better. I could have used a lot more time on materials and lighting, and there are of course many more options in Unity, but when targeting WebGL you can’t quite go to town. I’m saying it’s a draw, for web based 3D. Although 2 sided shaders don’t appear to be working in Unity’s webGL (they do in the authoring tool), so the back faces are transparent. This can be fixed by having two meshes, with the normals flipped, but that would be an extra 100% overhead in this example.
File Size
Flash wins, hands down. Under 1 megabyte, including the model which itself is quite high-res, and weighs in at 700Kb.
In WebGL, using the current Unity exporter, we’re talking almost 7Megs, that is seven times the size of the equivalent Flash file. Admittedly the normal maps etc. accounted for a very small increase, as they are raster as opposed to vector, but you do have to expect a file over 4Mb just for the engine itself. I wonder whether that engine could be stripped considerably, as in this example I am not using hardly any features of the engine. Flash scores big in this area, as it stands.
Conclusion
I make the score 3-2 to Stage3D on this particular example, though that’s not the whole story. If you asked me which I would rather work with, it has to be Unity. And in the real world, where time isn’t free, you would be a lot more productive in Unity. Perhaps next I should compare with developing the same thing in Three.js?
13th February 2017 @ 12:31 pm
Thanks for posting this test. Great info. It seems Flash still has something to say. I’m also curious about how it would be with Three.js and AwayJS 🙂
13th February 2017 @ 1:09 pm
AwayJS and the Typescript version meant the death of Away3D proper. What a waste. They’re not nearly as advanced as three.js. I have a project coming up that uses three.js, so I will give it a bash 🙂
28th July 2017 @ 4:48 pm
Out of interest, what did you reckon to three.js on your project? Have you used BabylonJS at all? I was wondering how the two compared.
28th July 2017 @ 6:46 pm
ThreeJS does an admirable job. The issues I’ve had have been regarding the external javascript code and its lack of OOP functionality.
I notice BabylonJS is born with Typescript, that may be an avenue worth looking into. I’m on holiday for another week, but when I get the time I’ll look into it, possibly rebuild the demo in BabylonJS. It’s the only way I know to really get to grips with an engine. On the surface, BabylonJS looks quite a polished framework. Would be nice if someone did a feature comparison, as often is best to choose the framework that covers most your requirements out of the box.
28th July 2017 @ 8:21 pm
Thanks, interesting. Will be cool to see your Babylon test if you decide to do that. Enjoy you’re enjoying your holiday! 🙂
28th July 2017 @ 8:23 pm
*Hope you’re enjoying… .(-_-).