Unificar métodos de las geometrías

[rejurime]

Hay muchas propiedades y métodos que debería estar en una súper clase.

[rejurime]

Por ahora el comportamiento y estado interno que vi en todas las geometrias fue:

public bool AlphaBlend { get; set; }
public TGCVector3 Position { get; set; }
public TGCVector3 Up { get; set; }
public TGCVector3 Right { get; set; }
public TGCVector3 Rotation { get; set; }
public TGCVector3 Scale { get; set; }
public TGCMatrix Transform { get; set; }
public abstract void Init(); // Podria no estar ya que muchas lo hacen en su constructor, pero podria ordenar.
public abstract void Update();
public abstract void Render();
public abstract void Dispose();

[rejurime]

@DNAngeluS @Javier-Rotelli @mysery que opinan?

[Javier-Rotelli]

tengo que mirarlo mejor, pero a priori me parece que esos metodos deberian subir a la superclase

[rejurime]

Claro @Javier-Rotelli esos son lo que vi que deberian ir en la super clase, salvo que detecten algo que este conceptualmente incorrecto en alguna geometria me parece que se imprime asi jaja.
La duda aun me queda con el Init si lo subo o seguimos laburando con los contructores como ahora y no forzamos a que toda geometria tenga un Init. Aunque creeria que todas las geometrias algo por mas minimo que sea tienen que inicializar.

[mysery]

Creo que todas deberian implementar un Init, sacaria los constructores raros que hay.
Falta el Vector3 Front y estamos perfectos creo yo.

[rejurime]

Hace falta tener el Front? no sale de up y right? o mejor tenerlo asi se evita una operación?

[mysery]

mejor tenerlo para no hacer el crossproduct cada vez que se quiere. de ultima se pueden calcular al inicio. 2017-07-29 19:25 GMT-03:00 René Juan Rico Mendoza <[email protected]> :

…

Hace falta tener el Front? no sale de up y right? o mejor tenerlo asi se evita una operación? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACyX9lZ6zwVlpubYrt027An1okxxt2ktks5sS7FogaJpZM4Nf8xk> .

[rejurime]

Retomando 😋 deberiamos agregar tambien

public TGCVector3 Front { get; set; }
public Color Color { get; set; }
public Effect Effect { get; set; }
public string Technique { get; set; }

a lo que puse arriba?

[rejurime]

o efecto y tecnica deberia ir en IRender? #76

[LeandroJavierLaino]

Esto quedo en un limbo o se puede agarrar?

https://memegenerator.net/img/instances/14804138/que-mierda-es-esto-lo-puedo-romper.jpg

[rejurime]

Quedo en la discusión que lees acá jaja quería llegar a un consenso antes de hacerlo así opinábamos todos pero como veras... nunca paso. Si tenes una idea de que onda podemos verlo 😉.

[LeandroJavierLaino]

Basicamente y revisando que metodos hay en las geometrias encontre esto (sumado a lo que se venia hablando en el issue) :

`
public bool AlphaBlendEnable { get; set; }
public TGCVector3 Position { get; set; }
public TGCVector3 Up { get; set; }
public TGCVector3 Right { get; set; }
public TGCVector3 Front { get; set; }
public TGCVector3 Rotation { get; set; }
public TGCVector3 Scale { get; set; }
public TGCMatrix Transform { get; set; }
public bool Enabled { get; set; }
public Effect Effect { get; set; }
public string Technique { get; set; }
public Color Color { get; set; }

public abstract void Init(); //O dejamos el init o los constructors no tiene mucho sentido las dos cosas
public abstract void Update();
public abstract void Render();
public abstract void Dispose();
`

Hay una clase abstracta "TGCGeometry" que ya tiene la unificacion de metodos, pero nunca se usa en ninguna geometria.

[rejurime]

Claro esa es la clase que cree con las cosas que fueron saliendo de acá pero no hice que la implementaran las geometrías hasta tener algo mas fundamentado, por ejemplo que rol juega irender?

[rejurime]

A lo que voy, es si por ejemplo tiene sentido el concepto de una geometría que no se pueda hacer render #76

[LeandroJavierLaino]

Entonces, en ese caso sería mas lógico que los métodos relacionados con hacer render de una geometría esten dentro de IRenderObject y no en TGCGeometry.

Que una geometría no haga render no tiene mucho sentido, solo si estas buscando hacer una optimización pero lo manejas del lado de la lógica de la aplicación no del lado de una geometria.

Basicamente IRender tiene pinta de que deberia tener esto:

public bool AlphaBlendEnable { get; set; }
public TGCVector3 Position { get; set; }
public TGCVector3 Up { get; set; }
public TGCVector3 Right { get; set; }
public TGCVector3 Front { get; set; }
public TGCVector3 Rotation { get; set; }
public TGCVector3 Scale { get; set; }
public TGCMatrix Transform { get; set; }
//public bool Enabled { get; set; } -> No tiene mucho sentido ya que lo que queremos es hacer render
public Effect Effect { get; set; }
public string Technique { get; set; }
public Color Color { get; set; }

//public abstract void Init(); Pensandolo mejor es ideal que cada geometria tenga su propio constructor en vez de un Init()
public abstract void Update();
public abstract void Render();
public abstract void Dispose();

[rejurime]

Supongo que lo de enable es por si tenes una escena y a todos los objetos render los queres hacer render y cada uno internamente saber si tiene que mostrarse o no. Recordá que también tenemos la interfaz ITransform 😝 #72 y hay cosas que son de ahí y no del IRender 😄
De ahi a que creer las 3 issues porque esta como todo medio mezclado, el concepto de IGeometry tenia que nacer, ahora hay que ver que interfaces tiene que implementar, claramente IRender y ITransform y que tiene que hacer cada una de ellas.