[SOLVED] dot(): unknown type of arguments (dvec3,vec3)

[brian.firfer]

So, I have a vector from PeekStart to PeekTarget, and if there is an object within the vector, I want to shorten the vector to the location of the collision minus the players radius * 1.4 buffer   However, in the case that this new location breaches the users position (ie the player is right up against the wall) I want to just cap the position.  I determine this by doing the dot product of the original vector and the new one.

 

The below code seems to work, however there is one line there (commented out) which was causing the unknown type of arguments (dvec3,vec3) error message to pop up.  float dotProduct = dot(newForceNormalized, originalForceNormalized);  However, as you can see, both of the variables are vec3, so I am not sure why it thinks there is a dvec3.  The stranger thing is, just reversing the parameters causes the error to go away.   Thoughts???

 

vec3 return_id[0];

Object returnObject = engine.physics.getIntersection(v3_PeekStart_g, v3_PeekTarget_g, ~0, return_id);

if(returnObject != NULL)

{

//log.message("Peeking Into Wall\n");

vec3 originalForceNormalized = normalize(v3_PeekTarget_g - v3_PeekStart_g);

v3_PeekTarget_g = return_id[0];

v3_PeekTarget_g += normalize(v3_PeekStart_g - v3_PeekTarget_g) * player.getCollisionRadius() * 1.4;

 

vec3 newForceNormalized = normalize(v3_PeekTarget_g - v3_PeekStart_g);

//float dotProduct = dot(newForceNormalized, originalForceNormalized);

float dotProduct = dot(originalForceNormalized, newForceNormalized);

if(dotProduct < 0 )

{ // We are basically against the wall

v3_PeekTarget_g = v3_PeekStart_g;

}

} 

[ulf.schroeter]

just guessing, try multiplication by 1.4f (not just 1.4 which might be causing double precision conversion)

[brian.firfer]

The 1.4 is in fact the issue...

 

The += operator is changing a variable type? Are all objects pointers?  And dvec inherits off vec?

Seems like a bug.  Shouldn't the += final result be the type of the object you are adding to?

[ulf.schroeter]

No, your multiplication of vec3 (float) with double scalar causes conversion of the result to dvec3 (double) for keeping precision. This is no bug, its a feature. Keep in mind that UNIGINE script its untyped an variable types can change during operation.

 

Simple variables are passed as values until & is used in function declaration e.g. void foo( int& valueByRef ) Arrays and user classes are always passed by reference.

[brian.firfer]

Is there really no way to ensure type safety?  Dynamic typing is nice, but I would much rather be explicit with my type conversions then have it happen behind the scenes.  A way to have the code be less error prone would be something along the lines of tagging all variables, and converting all results before assignment, but I assume such a thing would be expensive?  variable_vec3 = vec3(math Stuff);  In a case like this, the code would simply look wrong if there was a type mismatch, and normal precision truncation would occur.  However, the assumption again is that casting all results would be expensive.

[ulf.schroeter]

no, UNIGINE scripting does not enforce type safety by design. In general this is no major problem as long as you use consitent type specifiers on all constants  e.g. 1.4f.

 

Of course type casting eg. from dvec3 to vec3 costs performance and should be avoided when ever possible, except in cases were intermediate calculations have to be done in double precision (float too inprecise) and only the final result should be once again in float precision.       

[binstream]

Here is some more info on data types conversion in UnigineScript: https://developer.unigine.com/en/docs/1.0/code/scripting/language/types

[frustum]

You can use pragma directives to increase the verbose level:

#pragma warn_double

Or skip double types at all:

#pragma no_double