/
@brief
* CodePatch: This code patch demonstrates how to determine the inverse any matrix transformation as would be applied in the pull
* routine together with a sample linked list used to keep track of the transformations on the primitive object.
Author: Nyah Check(Ch3ck)
Note: This code uses some directives defined in /include/vmath.h file. So please refer to brlcad source code.
/
/This is a sample structure that would hold the original and inverse matrices from the primitive together
with the original directory pointer./
struct pull_obj
{
/This determines the type of transformation which occured./
typedef enum{ROTATE, TRANSLATE, SCALE, NONE = 0}Trans;
mat_t Inv_Matrix;/*Inverse matrix*/ mat_t Or_Matrix; /*Original Matrix*/ struct pull_obj *next, *prev; struct directory *dirptr;/*directory pointer.*/
};
/
InverseTransf(): This routine computes the Inverse of a transformation storing the results on the linked list
Precondition: a 4x4 matrix(mat_t and push_obj structure with type of transformation
Postcondition: returns 0 if successfull or 1 - otherwise
/
int InverseTransf(mat_t transf, struct pull_obj result)
{
/This matrix will hold the inverse matrix transformations./
mat_t Inverse;
MAT_IDN(Inverse); /*initializes all matrices to identity. /*determines the type of transformation and determines the inverse.*/ if( result->Trans == ROTATE) MAT_TRANSPOSE(Inverse, transf); else if (result->Trans == SCALE) MAT_SCALE(Inverse, 1.0/transf[MSX],1.0/transf[MSY], 1.0/transf[MSZ]); else if( result->Trans == TRANSLATE) MAT_DELTAS_GET_NEG(Inverse,transf); else return 1; /*copies the results to the linked list and returns to the calling function*/ MAT_COPY(result->Inv_Matrix, Inverse); MAT_COPY(result->Or->Matrix, transf); /*deallocates memory for matrix.*/ bu_free(Inverse); return 0;
}
/
* Local Variables:
* tab-width: 8
* mode: C
* indent-tabs-mode: t
* c-file-style: "stroustrup"
* End:
* ex: shiftwidth=4 tabstop=8
/
Nyah, this is not a valid patch file. Please read up on how to make a proper patch file (or come onto IRC and ask questions) so this can be submitted properly.
Note that your attached file sources also have several issues. You do not conform to our coding style, you're missing a common header, your function parameters are poor... You use the 'result' parameter for both input and outputs. You also define an enum typedef within the struct context, but then use the enums outside that scope (bad style).
yeah Sean this patch I submitted before I had properly read the HACKING file. This was during the GSoC application period so I just came up with this just to demonstrate a concept; I did intend it to be implemented. But However you can check my most recent patches. They can easily be applied and tested.
Nyah, every patch is independently reviewed. What are we supposed to do with THIS patch submission?? Telling me there are others that are better completely misses this point.
You need to do something about this one. It either needs to be corrected, closed, or commented. This needs to happen for ALL your submissions. Please re-read my mailing list posting because I'm having to repeat this information to you.
ok Sean i'll review the code and make sure it conforms with the coding
Standards..
On Fri, Jun 28, 2013 at 8:54 PM, Sean Morrison brlcad@users.sf.net wrote:
Related
Patches:
#169Sorry for the earlier comment Sean I was saying i did not intend it to be implemented in brlcad just wanted to demonstrate a concept of separating the different matrix transformations present in 4x4 transformation matrix. However I would review it tomorrow and upload a better version of the code. THIS IS NOT MEANT TO BE INTEGRATED INTO BRL-CAD
Your work involves separating the different matrix transforms so a patch sounds completely reasonable. If it's not meant to be integrated, what needs to happen to make it integratable? Otherwise, it has no purpose being a patch submission either.
Patch submissions to open source projects are -- by definition -- intentions to change the code. I'm sure you just submitted it because of needing to do something for GSoC, but that's the lesson to be learned. How can you turn this exploration into proper code? We do exploration all the time. There's no reason this cannot be a proper (and useful patch). It's a principle of coding complete that everyone needs to learn.
Nyah, what's the status of this patch submission? There's not a proper patch file to review. Are you planning on turning it into one or should this issue be closed?
Yes Sean this patch should be closed I created the new ticket adding
orthogonal matrix support to the bn_mat_inverse(/src/libbn/mat.c)
routine to replace this.
On 7/16/13, Sean Morrison brlcad@users.sf.net wrote:
Related
Patches:
#169which is ticket 190
On 7/17/13, Nyah Check nyahcheck@users.sf.net wrote:
Related
Patches:
#169At the time I had no idea BRL-CAD had an implementation of the Inverse
of a matrix routine. So I added the orthogonal matrix support to
ticket 190. which replaces this.
On 7/17/13, Nyah Check nyahcheck@users.sf.net wrote:
Related
Patches:
#169