the Fiddler's picture

Vector[234] contains C# 3.0 code

Project:The Open Toolkit library
Version:1.0-beta-2
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
Description

Issue reported here: http://www.opentk.com/node/1028#comment-7346

Quaternion v = new Quaternion() { X = vec.X, Y = vec.Y, Z = 0, W = 0 };
; expected (CS1002) - C:\svn\opentk\Source\OpenTK\Math\Vector2.cs:911,82

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Version:1.0-beta-1» 0.9.x-dev
Status:open» fixed

Fixed in rev. 2505.

kvark's picture

#2

wow, you're fast :)
thanks

kvark's picture

#3

Status:fixed» open

hmmm... I already have rev 2505 and it's definitely not fixed there...

the Fiddler's picture

#4

I just realized I forgot to mention that this fix went to the 1.0 branch. You need to pull from: https://opentk.svn.sourceforge.net/svnroot/opentk/branches/1.0

kvark's picture

#5

hm... you implemented the multiplication in a different order then me.
Your way:
inv(q) * v * q
My way:
q * v * inv(q)

I guess it's just a matter of convention.
But still, as far as I see (http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternion...), you took non-standard approach.
Maybe it should be the other way?

BTW, is 0.9,x-dev is planned to be frozen or the quaternions fix will eventually appear there?

the Fiddler's picture

#6

Status:open» fixed

I think there's a logical explanation behind this but I can't remember what (It's too late in the night for me to derive the math right now...) The important thing is that it works (try it!)

0.9.x-dev tracks the 1.0 branch (e.g. 1.0 beta-1 has a version number of 0.9.4). 1.x-dev tracks the trunk. I have backported the fix to both branches now.

kvark's picture

#7

Thanks for the backporting.

About the Q * V implementation:
I can't use it, because it behaves like Q is inversed for my case.
Please, make sure the convention you choose matches the one most of people use.
(Already scanned 3 links, all pointing to the way I need).

Moreover, I expected the implementation not to be straightforward (Q*V*inv(Q)), but use the knowledge of V.w = 0.
In GLSL my transform function looks like this:

vec3 qrot(vec4 q, vec3 v)	{
	return v + 2.0*cross(q.xyz, cross(q.xyz,v) + q.w*v);
}

I guess it's faster than straighforward way.

the Fiddler's picture

#8

I know I'm annoying, but please open new bug reports for these issues (inverted Q and optimization). :)

Annoying as this may be, it really helps keep track of what needs to be done and when.

kvark's picture

#9

You are not annoying.
It's my fault not opening the issues initially.

the Fiddler's picture

#10

Version:0.9.x-dev» 1.0-beta-2
Status:fixed» closed

Closing issues fixed in 1.0 beta-2.