I finally "stress-tested" (wasn't my intention) Unity 3 together with Richi007 and here is our result:

We love Gamestudio. Really!

When I first opended up Unity, it was like "Touch me, drag me, design me, I am so fresh, light and easy to use!". I bought a model from Turbosquid because I knew "Unity is for designer, it basically can import anything!". Well, after 1hr I managed to get the animation from FBX 2010 to Unity (2009 wasn't working, 2011 is to new for the lastest Unity version). Okay, the whole model was black, even if Unity at least showed me the right texture in the "Inspector" on the left side. The animation was named "Take 001" instead of "fly". How to deal with 50 animations from all different models? o.O Anyway, let's go on!

I started to use Javascript because I had the strange feeling, C# isn't that easy in Unity (also if C# itself is great (don't even think about bashing!)). Unity crashes while moving the camera upwards, Unity even crashes while doing nothing (Visual C++ Runtime: Crash -> Unity isn't working anymore -> Close -> Loose progress).

I opended up MED. Chose FBX Import. Selected my Model. Imported it. Skin...Check! Animation...Check!

It just works!

I <3 you, Gamestudio

That's called OOP, it may looks cumbersome at first, but once you get a hang of it, you'll realize that 3DGS could get more benefits from it.

Yeah, Unity su*ks, especially if you get a hang on 3DGS for a long time. Shadow baking takes forever even on simplest scene. Material importing can(or always) get messy, you need to assign each texture to material and you got no clue "which texture is this material".

I guess Unity3D is really for those designers that want to get their design up and running fast, it's like learning in high school, just follow what your teachers said and you'll graduate. 3DGS in the other hand, is more suitable for those who want to take everything deeper. It's like learning in University, here's the books, here's the classes, do whatever you want, learn whatever you want, if you do it right you'll graduate.

Actually that's encapsulation -- a design decision that any object should only be manipulable using its own methods. It's relatively "safe", but sometimes a fella just wants to use good old-fashioned addition on a component he understands.

Jibb

Probably something is wrong on your end. We are using it daily, I released dozens of packs already on their asset store and programmed 2 little games. I imported tens of thousands of models and textures in DAE and FBX, with and without animations.


So you base your experience on one model from Turbosquid, maybe exported with a bad FBX tool? I tested FBX files coming from Lightwave, Modo, Ultimate Unwrap 3d and from many of our artists working with Max and Maya. They all worked, without an exception, old FBX versions as well as newer ones. We have very old files here and they still import into Unity.


First it can be that the diffuse color of the model is black. Change it to white or grey and you will see the texture, that has been already applied automatically.
I guess this is another problem with your FBX.

Also when we split an animation in UU3D into several sequences and name each sequence then all these names and sequences transfer via FBX into Unity. We have all animations already split in one file, perfect and easy workflow. Even Blender can save such sequences in a FBX file.


This is no usual behaviour. It must be a problem on your side. I use it daily and there are hundreds of thousands of developers using it regularly. Most of our customers at Dexsoft are Unity users.
A mere movement of a camera cannot crash it unless there is something badly wrong with your drivers or with your installation.


I am sure, MED does not split the animation automaically into sequences, it also cannot recalculate vertex normals with a smoothing angle of your choice and it does not optionally merge similar materials (using the same diffuse texture).

So really, when working with a hundred models in a pack, it does not just work. It would take me a couple of days in 3DGS. But in Unity I put everything in a folder and let Unity do the work in minutes. I can even create an editor script to re-scale all models during import at once.

And when it comes to serious programming then object oriented code will lead to less code in the end. It might look like you type a couple more letters in the beginning, but later, when you have a more complex system it will be a time and a code-saver.


This depends on your system. On a multi-core system like mine I could bake shadows for a complete level with several sci-fi corridors in just minutes. It takes more time when you change your rendering options to max of course. You have to chose quality setup and texture size as well as your second uv-set wisely of course.


Then something is wrong with your model. When I copy 100 files into a project folder, they all appear correctly with materials and textures applied. All textures using bricks01_d as an example get (optionally) merged to a single material. This is extremely helpful and optimizes rendering in the end. I only drag normal maps to each material, change spec values and a new Unity package is done.

I made models, textures and maps for different engines like Unity, 3DGS, Torque, C4, Leadwerks, Lawmaker, Neoaxis, Vision3d, Irrlicht and UDK. I often got paid for projects like that and dealt with hardcore-users of these engines. We have a customer support at Dexsoft and get feedback from different users. So this is quite some unbiazed information I can give you.
And yes, there is no doubt, that Unity has the best automated workflow. Even the big ones like Vision and UDK cannot beat that. There are things for critics when you compare with Vision3d or UDK, especially when it comes to performance, but the import workflow and the mere number of options and tools is the highlight of Unity.

Of course I just used my own experiences. The model was avaible in FBX, 3DS, MAX and OBJ. I know there are thousands of satisfied Unity users where I am sure they've got great experiences, I just wanted to bash a bit in order to show my Gamestudio love

At the end of the days, I don't care if it is a Unity problem or a problem on my side: Unity messes my things up, MED doesn't.

I don't have a particular problem with the OOP camera code but Unity crashed everytime I tried to assign the camera as var attached : Transform to another script, so this was the only method for me to get it working.


I didn't wanted to bash against Unity more than showing my love for Gamestudio.

This attitude sounds ok for a consumer, a gamer, maybe a guy, who wants to play on a console without any tweaking, it should just work there.

But we are developers, we want to create something. And when there is a problem with a driver or with a missing tool or whatever, then we should be able to look a bit more into that to find a solution, to create games for the consumers. Bashing and ranting is what gamers do in Gamestar or 4Player forums. We are the good guys intelligent enough to look behind the scenes.

That's one thing I love from Unity.


But it still uncomparable to WED's lightmapper.


I exported the model from WED, so, yeah, I guess it's all messed up.

You guys know that A8 also uses an object oriented way, right? Its okay if you write only procedural code in Lite-C but still, A8 uses an OOP approach.

Yeah, the engine uses objects with data structures consisting of data fields, but there are no encapsulated methods, no data abstraction, no polymorphism and no inheritance.

There are tricks you could use to implement class-like behaviour (for example, polymorphism through a struct full of function pointers) but these won't be strictly type-checked. And good luck implementing inheritance through custom vtables.

C, or better Lite-C, is procedure-oriented programming.

[EDIT] I would like to see a real OOP C++ or C# SDK in the feature for A9 or so for Visual Studio, with a wrapper, that exports the functional behavior, so that it is still compatible to Lite-C. And I don't mean a wrapper that adapts on the current engine interface (like that from Stromausfall), I mean a rewrite and a wrapper for Lite-C.

...because it is more powerful.

Unity has a very sophisticated lightmapper, they integrated a professional tool that has been used for games like Mirrors Edge as an example. It renders not only simple lighting, but also radiosity and ambient occlusion. It can use HDR image as light source. I can even do the entire lighting only from textures, where a texture contains light emission channels. For instance some of my sci-fi textures have lights painted in and I have additional glow maps make them bright even when no light is around. These glow maps can be the source to calculate the lightmaps and create amazing soft lighting.

Besides that you can combine shaders and dynamic lights with your lightmaps.

There are way more examples. You can believe me, this technology is far behind the WED lightmapper. Also there will be directional lightmapping in the next release, similar to UDK, Source and Vision. This means that normal and spec mapping will read the lighting directions from the static lightmaps and will be more realistic when moving around.

Also some light probes will be in the next edition that allow to influence moving objects by the static lightmaps. So even a flying object gets correct light, color and lighting direction without a trace to the ground, just by moving through a volume with lighting information attached.