Unity can do any kind of game and the flexibility is just => than 3dgs flexibility. I use Unity for a year now and i used 3dgs for many years and believe me, the workflow and flexibility are awesome and i never reached any "limit" when i wanted to realize something.

And about the friction. Do you know about Physic Materials? You can create your own physic material with different friction and apply it to different kind of textures or whatever. That could solve your problem

Regarding math and vector / matrix calculation. Actually sometimes it is even better and faster to setup your own routines. I tell you why:

If you want to do translation, rotation and scaling within the same frame then you have to use 3 operations. If you do that on a mesh with 100 thousand vertices, then you get 3 times the amount of operations.
But if you create a combo matrix / vector first, that combines translation, scaling and rotation in one matrix / vector, then you have only 1/3 the amount of operations, resulting in higher speed.

But you dont need to write your own engine only because of this. It is just some kind of optimization.

why would that need my own routines? it's just a normal matrix concatenation.

matrix = tm * rm * sm
for v in vertices: v = v * matrix

...and transforming 100 thousand vertices isn't something you usually have to do in gameplay code.

Why writing an own class?
Newton comes with a very nice dMatrix class

And I agree with Ventilator that Newton is the better physics engine. At least compared to what is possible in A7. The ODE integration in ODE is insufficient. Fast turning objects can cause colission problems because a higher fps is needed for calculating the physics. A7 does not allow to e.g. double the physics engine framerate. It's always tied to the engine fps (unless I missed something).
I know that ODE can do more than what is possible with the current A7 integration, but that doesn't help as long as the internal interface stays the same in A7.

For my test project I saw no way to do this properly with the integrated ODE. With Newton it works a lot better (but still needs tweaking).
And thanks to Ventilator and VeT there is a really easy to use wrapper available.

Yep, it's help you to create a new partition for windows and makes it able to boot the new partition. It has also drivers for mac hardware like the mouse or iSight camera. It is a native windows installation.

Yes but you can assign one friction factor only to each texture i.e either grass or sand, for example
In 3dgs you can even read and manipulate each pixel of the texture
You can for example paint an irregularly shaped sand road on a grass terrain
In the gameplay you can detect if your hovercraft is on the road or on the grass
I dont think that this extreme flexibility is allowed to Unity users

Once again , ok for shaders and all the graphic stuff but a game must be first all:

Interactivity

Apart from that, generally speaking ,I agree that Unity workflow and programming language is better than 3dgs
However it seems to me that it is the direct opposite as far as the set of commands are concerned
Every new release 3dgs supplies some new commands
From this point of view I agree that 3dgs is more programming oriented than Unity

On the other hand I can not really understand how someone can claim that the Lite_c / action / entity based 3dgs architecture is better than the C# / JavaScript components Unity based architecture



Maybe these people are simply more familiar with 3dgs than with Unity

You got it. This is exactly what I mean. I just wanted to point out that it might be better to do it that way instead of using roate(), move() and scale() after each other for such a big mesh.

I am not sure about your example since in most books and in the OpenGL examples it would be matrix*v, but maybe you are talking about an DirectX notation.

And yes, a standard mesh will probably not have 100 thousand vertices. This was just an example to exaggerate the performance problem a bit. You will rather do something like that for smaller meshes but maybe several ones.

Frank, you usually don´t have to transform vertices at all

Slin: Yes, you are right, but if you for instance rotate a model then the engine will do this internally. Somewhere has to move the vertices in the world.

This was just an example for optimizations.

I think vec_ commands are quite nice.
I hate matrices. They are a bunch of numbers which mean nothing to me when I look at them.
I feel more comfortable when working with angles and vectors since I see directly what I'm doing.
It is true that for 3d calculations matrices are the best way, but I'm happy when I don't have to use them outside that area