DaDonik

Those are just some predefined collision types. According to the docs (http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitysetcollisiontype-r35) you can choose any value between 0 and 99. LEt me remid you that i don't own the engine and just took a quick look at the documentation, so no guarantee ^^

Axis aligned means they won't rotate, which makes things faster to calculate. Normally they are aligned wo the world axis, but who knows what Josh implemented.

Of course it will be as good as that one! The fact that newton runs on the CPU and the demo you show runs on the GPU doesn't affect speed at all! Get a brain...or stop trolling... @ Shadmar Can't try that demo, as i don't have LE3 installed, sorry.

At least you now accept that you have serious problems

It's a no for LE2 and LE3 doesn't even have dynamic shadows atm.

Be patient guys, the more questions you ask, the longer it will take Josh to release LE3

The easiest way is to have two TPivot's that you use to get the desired rotation. Position one pivot right where your model is and the other at the place you want to look at. Let the first pivot point at the second one and then get the rotation from your first pivot. Now use that rotation in CalcBodyOmega and you are done.

All of these full screen post effects are working on a per pixel basis, which is why the number of pixels is the most important performance factor. In the case of DOF it is always working on all pixels, so it doesn't really matter what near and far distance you set. It might be that the per pixel calculation gets more or less complicated when you change near and far distance, but that would be not a huge factor.

Thats indeed good news. Now we just need a LE3 beta to play around with and get used to how things are done.

Error handling in the LE2 Editor is not really existing. I would highly suggest not to use LUA with LE2 if you are new to programming. Even though i'm quite proficient in C++, i still have problems using LUA scripting. A simple typo will cause that "EXCEPTION_ACCESS_VIOLATION", while any C++ compiler will complain about it. Normally after the main loop a program closes. At that point the engine is already unloaded. So why are you calling ShowMouse()? =)

You have to live without Framework, because Frameworks intention is to keep exactly these things away from unexperienced users.

The solution is pretty simple, but not obvious if your are not used to C++. You just can't compare a char* and a string. if(GetEntityKey(entity1,"name")=="test_box") Where GetEntityKey(...) is returning a char*. One way to do it would be to convert the char* to a string and then compare the two strings: std::string strEntityName = GetEntityKey(entity1,"name"); if (strEntityName =="test_box") { ..... } if the compiler complains about the std::string, just include the string header: #include <string>

EntityDistance() works on the origin of the entity, so that wouldn't be accurate with such a huge plane. Since the world is just a huge box, all you need is to check if one of the coordinates is near the size of the world in that direction. You could also make a physics box and scale it so it is more or less a plane. Then use the collision callback to free any entity that collides with it. Do that for all 6 sides and you have it. Oh and make sure the physics boxes are inside the world, otherwise it won't work.

Thats not quite true, the callbacks can also be static class member functions.

The character contoller code was available at some point. Sadly i can't find a link to it anymore. Maybe someone else can help out...