[Crystal-develop] [Crystal-cvs] SF.net SVN: crystal:[39466] CS/trunk/include/csutil/variant.h

[res]

@@ -38,7 +38,7 @@
/// Type of the values that can be contained within a csVariant.
enum csVariantType
{
- // Signed 32-bit integer (long)
+ /// Signed 32-bit integer (long)
CSVAR_LONG,

Hm, I probably would have rather chosen a name like CSVAR_INT32.
Unless it's really a long, then the current name is appropriate.
– The pitfall here is that “long” is _not_ consistently 32-bit… on Win64
it is, but on Linux x86_64 it's 64-bit!

/// csMatrix3 type
+ // TODO: quaternion instead?
CSVAR_MATRIX3,

…I always though 3x3 matrices could represent more potential
transformations than quaternions. (Aren't those limited to rotations? My
knowledge is somewhat lacking here.)

/// csTransform type
+ // TODO: remove?
CSVAR_TRANSFORM,

Removal because (a) it doesn't really fit into the envisioned use
case(s) for csVariant or (b) because you don't like csTransform?
If it's (b), perhaps you'd like a 4x4 matrix more?

-f.r.

[Christian Van Brussel]

Post by res

@@ -38,7 +38,7 @@
/// Type of the values that can be contained within a csVariant.
enum csVariantType
{
- // Signed 32-bit integer (long)
+ /// Signed 32-bit integer (long)
CSVAR_LONG,

Hm, I probably would have rather chosen a name like CSVAR_INT32.
Unless it's really a long, then the current name is appropriate.
– The pitfall here is that “long” is _not_ consistently 32-bit… on Win64
it is, but on Linux x86_64 it's 64-bit!

The 'CSVAR_LONG' name has been defined long time ago, a priori by Jorrit
back in 1998, within the file 'iutil/pluginconfig.h'. The description
has been changed recently though, although the previous one was better:
"Long type, obviously also valid for integers". And it's actually a
'long' variable that holds the value in the implementation.

About the 32/64 bits inconsistency, maybe we can introduce the explicit
types CSVAR_INT32 and CSVAR_INT64? Maybe also CSVAR_UINT32 and
CSVAR_UINT64? And we would deprecate CSVAR_LONG?

Post by res

/// csMatrix3 type
+ // TODO: quaternion instead?
CSVAR_MATRIX3,

…I always though 3x3 matrices could represent more potential
transformations than quaternions. (Aren't those limited to rotations? My
knowledge is somewhat lacking here.)

Yes, quaternions are somehow limited to rotations only, and the comment
was actually about that question: "would we limit the 3x3 matrices
parameters to rotations only?"

A posteriori, I would say that a type for 3x3 matrices can be
interesting, and that we can either add another type for quaternions or
add utility methods to convert from a CSVAR_VECTOR4 to a quaternion.

Post by res

/// csTransform type
+ // TODO: remove?
CSVAR_TRANSFORM,

Removal because (a) it doesn't really fit into the envisioned use
case(s) for csVariant or (b) because you don't like csTransform?
If it's (b), perhaps you'd like a 4x4 matrix more?

Here the question was whether or not limiting transforms to be
orthogonal. Most transforms in a rendering engine are a priori
orthogonal, but non-orthogonal transforms may also be interesting in
some specific contexts.

If we limit to only orthogonal transforms, then it becomes possible to
expose separately the rotations, translation and scale components of the
transform instead of the transform itself, and that type wouldn't be
needed anymore.

As for matrices, I would now say that a type for generic transforms
might be interesting too.

[res]

Post by Christian Van Brussel
About the 32/64 bits inconsistency, maybe we can introduce the explicit
types CSVAR_INT32 and CSVAR_INT64? Maybe also CSVAR_UINT32 and
CSVAR_UINT64? And we would deprecate CSVAR_LONG?

Yeah, using explicit bit sizes sounds better.

Post by Christian Van Brussel
Yes, quaternions are somehow limited to rotations only, and the comment
was actually about that question: "would we limit the 3x3 matrices
parameters to rotations only?"

Ah, okay.

Post by Christian Van Brussel
A posteriori, I would say that a type for 3x3 matrices can be
interesting, and that we can either add another type for quaternions or
add utility methods to convert from a CSVAR_VECTOR4 to a quaternion.

So “it's a quaternion” could be seen as a semantic?
csVariant is probably not the right place for storing that


Post by Christian Van Brussel
Here the question was whether or not limiting transforms to be
orthogonal. Most transforms in a rendering engine are a priori
orthogonal, but non-orthogonal transforms may also be interesting in
some specific contexts.

Hm. Semantics again?

AFAIK you're using csVariant for editor purposes. So
 is there a
mechanic to specify a semantic for some variant value in the editor?

If there is, I would think the approach is to store the “most generic”
type in a csVariant and have the semantics handled in another layer on top.

Then again, sometimes it's rather cumbersome to go from a generic to a
special representation – case in point, extracting rotation from a
matrix. So some less-than-generic types (eg orthogonal transforms) look
rather practical to have.

-f.r.

[Christian Van Brussel]

So “it's a quaternion” could be seen as a semantic?
csVariant is probably not the right place for storing that…

Yes, a quaternion is represented in CS through a csVector3 plus a float,
that is 4 float in total, that's pretty much the same as a csVector4. So
“it's a quaternion” could definitively be seen as a semantic, although
the conversion between one and another type is not straightforward.

AFAIK you're using csVariant for editor purposes. So… is there a
mechanic to specify a semantic for some variant value in the editor?

The csVariant are used to represent the parameters of a iModifiable, and
the semantic of the parameters are defined through the interface
iModifiableConstraint. There are currently constraints for bounded
values, enums, VFS paths and text entries, and we will probably add much
more in the future.

If there is, I would think the approach is to store the “most generic”
type in a csVariant and have the semantics handled in another layer on top.

OK, then here I would not introduce a variant type for quaternions, but
instead add a new constraint specifying that a csVector4 is a
quaternion.

Then again, sometimes it's rather cumbersome to go from a generic to a
special representation – case in point, extracting rotation from a
matrix. So some less-than-generic types (eg orthogonal transforms) look
rather practical to have.

OK, I'll let a variant type for csMatrix3 and csTransform, then add
iModifiableConstraint's for rotational matrices and orthogonal
transforms.

Thanks for the insights!