Jump to content

  • Log In with Google      Sign In   
  • Create Account

Allowing mixed handiness. Or maybe not.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Krohm   Crossbones+   -  Reputation: 2920


Posted 04 July 2012 - 12:18 PM

I guess everyone got an idea of what coordinate systems conventions are supposed to work.
[source lang="cpp"]^ y| z| / left handed (D3D9)| /| /+- - - - - - - - - -> x ^ y | | right handed (GL, Bullet...) | | +- - - - - - - - - -> x / //z[/source]

I have a component which encodes hierarchical rigid transforms using right-handed (GL) coordinate system. Problem is I now have an asset which requires the other kind of coordinate system as well (both are required in the same asset). I don't want to upgrade the transform management component to arbitrary transforms because of the redundancy involved and I don't want to have to support scaling as it has non-trivial implications in my system. The goal was to support rigid body transforms only. Albeit negating z is a scale by -1, from a certain point of view, this is ... some kind of odd rigid transform, one that becomes invalid just because the convention chosen has the unfortunate implication of putting z the wrong way.

While supporting this case appears necessary, from a 10,000ft view, what this asset really does (was intended to do) is to encode a generic coordinate system which is still non-scaling, this coordinate system was not intended to render but rather to be passed to scripts and in a certain sense, it got some elegance.
It's worth noticing the accompanying script does not work on this data as a rigid transform or a coordinate system, it rather mangles the three vectors somewhat independently, yet it appeared natural to try to abuse the rigid transform system to encode this information.

I'm inclined to add a flag to just negate z on need so this can become supported.
However, I'm rather torn on what's really happening. The convention is that only rigid transforms would be supported, and transforms are currently right handed and this does not qualify as a transform, albeit having an apparent "rigid" feel. After closer scrutiny, there might be a way to work around this issue (by encoding 4 points and extracting vectors, let's call this point system) but I had to agree this feels quite more cumbersome to handle (not to mention it requires quite some work as this code path is currently not implemented).

So in general, I feel this bitter taste of "something going bad" but I cannot quite objectively justify it. On the other hand, this asset is invalid... albeit the notion is useful.

Do you think I should allow mixed handiness or request the asset (and script) to be reworked using the point system?


#2 mhagain   Crossbones+   -  Reputation: 7343


Posted 04 July 2012 - 01:15 PM

First of all it's worth noting that neither D3D nor GL enforce an explicit handedness on you. D3D has -RH versions of all of it's projection matrix functions and the GL spec itself calls out the fact that it doesn't enforce a handedness in it's coord system (p. 223 v 1.2.1 spec, p. 447 v 4.2 spec, for example). Not relevant to this specific problem but important to note.

If you can ask for the asset to be reworked without cost (e.g. if you originally specified that it should be set up for an RH system) then do so. I think your taste of "something going bad" is quite valid here as you may end up with any number of arbitrary assets which may be set up for either RH or LH and you'll have to test and adjust for each one. This gets worse if you ever want to support user-provided content. Better to be clear and explicit about this up-front and at the start before you nose-dive into support-hell.

Otherwise run the asset through a preprocessing tool that converts it and ship with that version of the asset (then learn from this lesson and always request RH in future). Again, this is coming from the perspective of being consistent throughout your pipeline so that it doesn't come back to bite you in the ass at a later date.

Edited by mhagain, 04 July 2012 - 01:17 PM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

#3 Krohm   Crossbones+   -  Reputation: 2920


Posted 04 July 2012 - 03:07 PM

Yes, this is exactly the point.
I have, at the very least, a documentation problem, the current wording does not mention handiness (not near there at least) and encourages in thinking about independent vectors being packed into a matrix with no scaling nor shear rather than a rigid transform. And if I would encode them as a 3x3 matrix instead of a quaternion, it would likely work as expected as far as the core features (not the scripts) are concerned. Moving the axis in the correct place would not be a problem but I have no idea on how to rewrite the documentation to avoid that from happening especially as nobody ever wanted to encode a transform for real but pack three vectors instead.
It is clear the system was abused for good, it really appeared to slip through the cracks.

I have been thinking at the options I have including roughly estimating the work required. I cannot really see a way to reliably pour handiness information in the scripts without turning them in a real mess. So adding a bit to swap the axis would just move the bug to another piece of code.

Fixing the asset appears to be the only viable way. Problem is there's a very specific reason for which the Z axis has been flipped. I could {1} modify the script so I include a data-specific fix (pull out matrix and multiply z *= -1 if this transform point is PROBLEMATIC_TRANSFORM_NAME). It sounds somewhat ugly but after all the script is already data dependent when polling for a specific resource name and transform name so perhaps this is not as bad as it sounds. Invalid transforms will have to be rejected by the filter, as there's no way to make them work nor to fix them automatically.
Transitioning to {2} the "point system" would allow to encode those vectors; which are really named arbitrary parameters. The script would need to be modified as well, more or less on the same magnitude. Except the code implementing the "point system" is not there but with some re-factoring I should be able to get it working at a fairly reduced cost.

Thank you for your quick reply. I think I should probably go for {2}, this thing is not a transform and should not go through the transform system. I'm very tempted to go the quick {1} route but I'm afraid I have to bite the bullet.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.