QTriangle3D

[GoogleCodeExporter]

Representa un triángulo en el espacio tridimensional. Aporta la funcionalidad 
básica referente a transformaciones en 3 dimensiones, entre otras cosas.

Más información en:

http://quimeraengine.googlecode.com/files/QTriangle3D.pdf

Original issue reported on code.google.com by Lince3D@gmail.com on 9 Apr 2011 at 10:06

[GoogleCodeExporter]

Original comment by txan...@gmail.com on 23 May 2011 at 1:19

• Changed state: Started

[GoogleCodeExporter]

Libero la tarea, hasta que se complete QTriangle. Ya existe hilo en el Tracker 
del foro.

Original comment by txan...@gmail.com on 24 May 2011 at 7:35

• Changed state: New

[GoogleCodeExporter]

Retomo la tarea.

Original comment by txan...@gmail.com on 5 Jul 2011 at 9:54

• Changed state: Started

[GoogleCodeExporter]

No puse el owner, corregido.

Original comment by txan...@gmail.com on 5 Jul 2011 at 10:02

[GoogleCodeExporter]

La implementación de GetOrthocenter se dejará para otra extensión, según lo 
hablado.

Original comment by txan...@gmail.com on 28 Aug 2011 at 12:16

[GoogleCodeExporter]

Ready for review

Original comment by txan...@gmail.com on 28 Aug 2011 at 2:07

• Changed state: ReadyForReview

[GoogleCodeExporter]

Resultado de la revisión:

-Operator=: Es una chorrada, pero pega el ampersand (&) al tipo de salida ;)

-Operator=: Ponlo inline.

-Nomenclatura en general: Normalmente a los vectores los llamamos con un 
prefijo v-. ¡Recuerda actualziar el nombre de un parámetro en la 
documentación si lo cambias en la firma!

-Documentación de GetNormal: Esta es una norma general, nunca menciones un 
tipo de datos dentro de la descripción. En este caso, en lugar de decir 
QBaseVector3, di vector sin más. Hay que hablar con conceptos naturales en 
lugar de hacer referencia a nombres que pueden o no cambiar.

-GetNormal: No está mal que ofrezcas 2 sobrecargas para los tipos permitidos, 
pero ambas deben usar internamente la misma función, que sería una plantilla 
(en la cual además no haría falta hacer la conversión con reinterpret_cast).

-Documentación de GetCircumcenter: ¿Podrías incluir las fórmulas que 
permiten calcularlo en forma de documentación de MathJax? Pregunta a Jwladi 
sobre cómo hacerlo. Como mínimo sí que podrías incluir un enlace del sitio 
donde esté la fórmula en que te basas.

-GetCircumcenter: Variables sp y fk. Si tienen algún significado matemático o 
algo así, estaría bien que le pusieras el comentario encima. Además, todos 
los floats llevan una f- como prefijo.

-GetCircumcenter: En lugar de usar pow, cuando se trate de elevar solo a 2, es 
mejor poner la multiplicación del valor por sí mismo.

-Documentación de Translate, Rotate y Scale: No hace falta especificar lo que 
recibe la función en el summary, ya va implícito en los params.

-Translate, Rotate y Scale: Los parámetros de entrada deben ser const y ser 
pasados por referencia. Además, aquellos que sean de tipo float_q, deben ser 
nombrados con el prefijo f-. Dale un vistazo a las convenciones de nombres ;)

-Documentación de Translate y Scale: En lugar de decir Float type, podrías 
decir Value, o Scalar, o directamente decir sólo "Translation on X axis."

-Cuando existan versiones de un mismo método donde uno tenga parámetro de 
salida y el otro no, el que tiene parámetro de salida consistirá en una 
asignación a this y luego una llamada al método que no tiene parámetro de 
salida. Hay que evitar la repetición de código. Puedes ver muchos ejemplos de 
ello.

-Haz un reemplazo de la palabra wich por which. Hay una errata.

-Documentación en general: Trata de usar tiempos verbales impersonales, evita 
el "I" y el "we".

-RotateFromPivot y ScaleFromPivot: Lo que se hace con las versiones "FromPivot" 
es añadirles el desfase del pivote y a continuación llamar a la versión 
normal, restituyendo nuevamente el desfase del pivote.

-Documentación SpaceRelation: Cuando se utilizan tipos enumerados, 
generalmente no se ponen los valores directamente. Usa el lenguaje natural.

-SpaceRelation: ¿sRelationA, sRelationB y sRelationC son productos escalares? 
Si es así, por qué no has usado el método DotProduct?

-SpaceRelation: No estaría de más que incluyeras un pequeño comentario junto 
a cada valor devuelto explicando qué caso es. Es dificil saberlo a primera 
vista.

Original comment by Lince3D@gmail.com on 16 Sep 2011 at 8:18

• Changed state: Started

[GoogleCodeExporter]

Modificado.

Original comment by txan...@gmail.com on 22 Sep 2011 at 9:27

• Changed state: ReadyForReview

[GoogleCodeExporter]

Resultado de la revisión:

-GetNormal que recibe OtherVextorType: Mantén la estructura del parámetro de 
salida, ya que si devuelves un vector con return lo que haces es copiarlo y eso 
penaliza el rendimiento.

-Nombre parámetro circumcenter: Debería ser vCircumcenter. Actualiza también 
su nombre en la documentación.

-GetCircumcenter: Los nombres crossvAvB, etc. deben usar el prefijo v-.

-Documentación de parámetros de Translate, Rotate y Scale: Se ha colado un 
espacio en mitad.

-SpaceRelation: ¿fRelationA, fRelationB y fRelationC son productos escalares? 
Si es así, por qué no has usado el método DotProduct?

-El cartel METHODS aparece má de una vez, no es necesario utilizarlo para 
cambiar a otro bloque de visibilidad, sólo debe aparece una vez cuando 
empiecen los métodos.

Venga que esto ya está casi :)

Original comment by Lince3D@gmail.com on 25 Sep 2011 at 7:39

• Changed state: Started

[GoogleCodeExporter]

Ready for review

Original comment by txan...@gmail.com on 27 Sep 2011 at 10:59

[GoogleCodeExporter]

Original comment by txan...@gmail.com on 27 Sep 2011 at 10:59

• Changed state: ReadyForReview

[GoogleCodeExporter]

Resultado de la revisión: Correcta.

-Documentación de GetCircumcenter: Por favor, mueve la URL a un comentario 
interno, que no aparezca en la documentación pública.

Original comment by Lince3D@gmail.com on 27 Sep 2011 at 7:18

• Changed state: Done

[GoogleCodeExporter]

Subido en la revision 810.

Original comment by txan...@gmail.com on 29 Sep 2011 at 8:36