Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 May 2006
Offline Last Active Today, 04:38 PM

Posts I've Made

In Topic: [Debate] Using namespace should be avoided ?

03 February 2016 - 09:03 AM

I think it depends on the situation.


You should never use it inside a .h file in my opinion.

Code readability goes down a bit by not using it, but it is more clear what classes belong to what namespaces, so maybe that compensates for it again.


If your own engine uses only one core lib for example it is perfectly fine to do "using namespace CoreLib" inside your .cpp files in my eyes.

If however you later plan to add support for another library that happens to have the same class name, you have to explicitly name that one.


I personally prefer not to use "using namespace", as then you are always safe (unless there is a lib with the same namespace name lol).


I think generally it should be avoided, but in some cases it is fine I think.

In Topic: Looking for a free 2D engine

29 November 2015 - 02:20 PM

You should have a look at cocos2d-x, I think it is quite nice: http://www.cocos2d-x.org/

It has a very easy to use API, very straight forward. It also has some editor, but I haven't really used that so can't tell how good or bad that is.

In Topic: Software skinning for a precise AABB

07 November 2015 - 10:52 AM

The best solution that is good enough for 99% of cases is to save the AABBs at different frame intervals (granted, you need to do software skinning first) store them (e.g. in the mesh file), and then linearly interpolate between those AABBs.


I wouldn't do that, just go for a static AABB as mentioned before.

What you can do is simply rotate your model in bind pose in some loop or so, and find the maximum AABB, this works pretty well.


Storing AABB's and interpolating them is really overkill, and you need to pass it around your blend trees and handle all the blending and logic in there as well then to get the right AABB. It isn't really worth it I think. Then you could also just build the bounds from the transformed obb's at the end. I doubt that is much slower than this with large blend trees involved. 

In Topic: Problems with exporting FBX files

03 November 2015 - 03:16 PM

Local transformations are relative to their parent indeed.

In Topic: Problems with exporting FBX files

02 November 2015 - 08:48 AM

Are you using the same coordinate system as FBX?

What works for me is just storing the local transformations, but I have to convert into the right handed coordinate system where negative z points into the depth, y points up and x to the right.


fbxNode->LclTranslation.Set( FbxVector4(pos.x, pos.y, -pos.z) );
fbxNode->LclRotation.Set( FbxVector4( Math::RadiansToDegrees(-rot.x), Math::RadiansToDegrees(-rot.y), Math::RadiansToDegrees(rot.z)));
fbxNode->LclScaling.Set( FbxVector4(scale.x, scale.y, scale.z) );

Also make sure to use degrees instead of radians in this function.


I was able to export full characters including bone hierarchies etc for some clients using this code, and they appeared correct in Max after importing the FBX, so I assume this must work for you as well, unless something else is going on.