Hey @Jonathan_Blow @cmuratori I was watching your stream on animations - FYI, you actually can do a change of basis via similarity transform without affecting all intermediate systems, I wrote up how to do it here (see the "one weird trick" section):https://towardsdatascience.com/change-of-basis-3909ef4bed43 …
-
-
Replying to @MoldyMagnet @Jonathan_Blow
Sure, but: A) That doesn't help with the problem Jon was having, and B) That doesn't help with the problem you normally use the similarity transform for (pretransforming _only_ the stored data, with no run-time changes whatever) B is what you normally sim-transform for.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @Jonathan_Blow
I thought Jon wanted to flip the Y axis without having lots of correction code, I think it works in that case. It also works in the asset import case: you have data in left-handed coordinate system, you can import it to a right-handed rendering system and only set the root Xf
2 replies 0 retweets 0 likes -
But anyway, I was just sharing because you commented that "you can't just mirror without affecting vertex skinning, etc" -- I just wanted to point out that you actually can.
2 replies 0 retweets 0 likes -
Replying to @MoldyMagnet @Jonathan_Blow
No, you can't, and that's not what I was saying. What I was saying is that if you want your system to operate completely without updates, you have to change the basis of the entire source data, which is correct.
1 reply 0 retweets 0 likes -
Your "trick" doesn't do anything of the sort. It assumes you still go ahead and put the opposite side of the similarity transform at the end of the pipeline (the camera transform). That is not the same thing _as not doing anything_.
1 reply 0 retweets 0 likes -
This is why properly functioning asset pipelines (eg., not Unity's, I guess?) just have a way to automatically sim-transform the entire dataset on export, so there is never any inconsistency throughout the code, such as hacking the camera matrix (like you did).
1 reply 0 retweets 0 likes -
This is the correct solution to the problem and prevents all run-time problems, and is free. However again, it has _literally nothing to do_ with what Jon was doing, which was needing to change a communication point because he wanted two systems to work in opposite bases.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @Jonathan_Blow
Well, I disagree, and it's not theoretical, I've carefully verified both are correct and equivalent, in theory and practice. Maybe some day we'll discuss it face to face and I'll have a chance to explain, it's not an easy topic for twitter.
2 replies 0 retweets 0 likes
I don't even understand what you're disagreeing about. One method operates entirely on the assets _and works perfectly with no changes to your code whatsoever_. That's the "right" solution because you literally don't change the run-time.
-
-
Your solution not only requires modification to the run-time code, but also has a bunch of caveats which you yourself listed in the article! I _understand_ your solution, I just don't think it is _good_. There's a difference between those two things.
1 reply 1 retweet 2 likes -
And again, the pretransform method has literally zero run-time cost. It operates entirely at export time and you never pay a single fmad for it at run-time anywhere. So I really just don't understand why you're advocating for a worse solution in all respects?
1 reply 0 retweets 1 like - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.