Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MapRender for quads #316

Open
wants to merge 32 commits into
base: develop
Choose a base branch
from
Open

Add MapRender for quads #316

wants to merge 32 commits into from

Conversation

kvanhoey
Copy link

Adding a MapRender for quadrilateral rendering, allowing to write shaders to do quad interpolation.
Tested on a personal side-application with quad interpolation enabled.

@pierrekraemer
Copy link
Member

@kvanhoey la classe MapQuadRender pourrait facilement être intégrée à la classe MapRender en ajoutant simplement "QUAD" dans l'enum DrawingType.
Ca serait plus simple, non ?

@kvanhoey
Copy link
Author

C'est fait et pushé.

@@ -261,6 +282,8 @@ class CGOGN_RENDERING_API MapRender
init_triangles(m, mask, table_indices);
indices_tri_.clear();
break;
case QUAD:
init_quad(m, mask, table_indices) ;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Il manque un break ici.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrigé. Désolé.

@pierrekraemer
Copy link
Member

Petite remarque globale d'ordre esthétique : on utilise partout des tabs pour indenter le code. Tes ajouts sont indentés avec des espaces. Est-ce que tu pourrais modifier ça pour mettre des tabs ?

@untereiner
Copy link
Collaborator

J'ai l'impression que d'un point de vue topo les objets square et parallélogramme sont des objets similaires. Ce qui change c'est la manière de les plonger. D'ailleurs, je me dis que le mot square est mal choisi. Cet objet construit une grille de faces à 4 côtés.

@pierrekraemer
Copy link
Member

Si j'ai bien compris, il me semble que le problème dans ce cas est que la topo et le plongement sont construits conjointement. On ne peut pas, comme dans les autres exemples de tiling, construire d'une part la topo (dont la nature peut être tri, quad, ..) puis plonger la grille obtenue. On ne peut donc pas utiliser l'objet SquareGrid (qui pourrait effectivement être renommée en QuadGrid) et lui ajouter un nouvelle méthode embed_into_xxx. Il faut nécessairement quelque chose de séparé et propre au problème.

@kvanhoey
Copy link
Author

Arf...
Désolé pour le break. C'est corrigé.
Pour l'indentation, je vais voir pour changer ça en effet, je ne m'en suis pas rendu compte.
Et pour le parallélogramme, je ne voulais pas le commiter à la base, mais ma mauvaise habitude de faire du commit -a -m m'a eu.

Je suis d'accord avec Lionel que Square est mal choisi.

Et pour le parallélogramme, ce qui change c'est que pour mon appli je dois absolument construire la topo et le plongement conjointement. C'est pas séparable (on pourra en discuter si tu veux), car je veux construire une topo qui couvre une certaine surface (un rectangle ; le critère d'arrêt est sur le plongement).
Je confirme donc totalement ce que Pierre dit.

En l'occurence, c'est peut-être pas opportun de pusher ça dans CGoGN ...

@kvanhoey
Copy link
Author

kvanhoey commented Sep 12, 2017

Dans QtCreator -> Options -> Text Editor -> Behavior -> Tab Policy
je suis en "Tab Only" (par opposition à "Spaces only" ou "mixed"). Du coup, je ne vois pas bien quoi changer, à part l'éditeur utilisé ...

@untereiner
Copy link
Collaborator

Utilise le style QtCreator à la racine de cgogn ;)

@untereiner
Copy link
Collaborator

Sinon c'était pas une question d'opportun ou pas. Ce que j'ai compris de l'algo m'a fait pensé que c'était factorisable. Au départ est-ce que tu connais la taille de la région à couvrir et le niveau de discrétisation (combien de sommets/faces en X et en Y) de cette région ?

@kvanhoey
Copy link
Author

J'utilise bien le IGGstyle ... malheureusement, ça marche pas.

@kvanhoey
Copy link
Author

kvanhoey commented Sep 12, 2017

Et oui, je connais la taille à couvrir et le parallelogramme (quelconque) que je veux (sa forme et donc taille géométrique)... c'est pas exclus que la topo soit pré-calculable sans plonger, mais ça reviendrait au même, car il faudrait calculer au fur et à mesure de la construction combien sera couvert déjà ...

Un screenshot de ce que je veux faire: couvrir une texture de parallelogrammes quelconques (et je vais devoir générer des millieurs de grilles avec des parallelogrammes différents):
parallelograms
Tout en ayant au moins un parallélogramme complet de marge entre le bord de la texture et le bord du maillage.

@kvanhoey
Copy link
Author

C'est bon, les tabs c'est fait et pushé !

namespace modeling
{

//template class CGOGN_MODELING_API ParallelogramGrid<CMap2,Eigen::Vector2d>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Est-ce qu'il y a une raison pour laquelle c'est commenté ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non. Ou du moins, je ne m'en souviens pas. En fait, je devrais vraiment exclure cette classe du pull request car cette classe n'est absolument pas finalisée (c'était un effet de bord de mon pull request pour le MapRender).
C'est faisable facilement ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Je pense que le plus simple est de faire un commit dans lequel tu enlèves les parties non-finalisées. Sinon ça peut très bien rester en l'état le temps que tu travailles dessus, faut voir avec Pierre.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouai mais j'aimerais quand même avoir le commit et le push sur mon github à des fins de backup ... mais pas dans le pull request pour ne pas polluer CGoGN.
@pierrekraemer, un avis ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tu peux créer une nouvelle branche de backup à partir de celle que tu utilises pour la PR. Puis tu continues tes modifs dans l'ancienne branche.

bool is_valid() const
{
bool res = Ti_[0] > 0 && Tj_[0] >= 0 && Tj_[1] > Ti_[1] ;
cgogn_assert((acos(-Tj_[1] / Tj_.norm()) > acos(-Ti_[1] / Ti_.norm())) == res) ;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ici je pense qu'il faudrait éviter le cgogn_assert dans la méthode is_valid ? vu que plus haut tu fais déjà un cgogn_assert(is_valid()).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merci :).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Au passage: c'est quoi la différence entre les assert et les ensure ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aucune diff en dehors du nom.

{
bool res = Ti_[0] > 0 && Tj_[0] >= 0 && Tj_[1] > Ti_[1] ;
cgogn_assert((acos(-Tj_[1] / Tj_.norm()) > acos(-Ti_[1] / Ti_.norm())) == res) ;
return res && p_.norm() > 1e-10 && Ti_.norm() > 1e-10 && Tj_.norm() > 1e-10 ;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a des fonctions almost_equal_absolute et almost_equal_relative qui pourraient être utilisées.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merci

@pierrekraemer
Copy link
Member

@kvanhoey Ce n'est pas très embêtant que ces classes dédiées aux parallélogrammes intègrent la lib. Elles n'interfèrent pas avec le reste de toute manière. En revanche, on peut laisser la PR ouverte tant que ça n'est pas terminé si tu veux.
Si tu préfères ne pas les intégrer, alors tu peux faire comme proposé par @etienneschmitt : à savoir, tu crées une nouvelle branche "parallelogram" à partir de ton commit courant, tu reviens sur la branche "kvanhoey", source de cette PR, et tu ajoutes un commit qui supprime ces fichiers et tu pushes, modifiant ainsi cette PR. Tu peux ensuite retourner sur la branche "parallelogram" et continuer à travailler comme si de rien n'était. En revanche, je pense que des problèmes apparaitront quand tu voudras intégrer des mises-à-jour de CGoGN vers cette branche..

@sylvainthery
Copy link
Contributor

Pour info comment ne pas polluer une PR en continue avec un WIP:

  • checkout -b work
  • bla bla commit push bla bla commit push PR work ->cgogn:develop
  • Ahh je veux continuer !!
  • checkout -b work_continue (depuis work)
  • bla bla commit push bla bla commit push
  • checkout work + merge work_continue + push

Il faut faire des branches, c'est l'un des points forts de git

Sinon tu peux mettre dans l'index (et donc commiter) des morceaux de fichier avec git add -i

Mais une fois que c'est commité et pushé c'est trop tard ( sauf remove + push)

@kvanhoey
Copy link
Author

Merci pour vos suggestions, j'ai bien noté la recommandation "faites des branches!" ;).

Je propose de faire au plus simple pour l'instant: laisser la PR ouverte tant que ça n'a pas convergé.
Si quelqu'un a besoin de rendu QUAD, vous commentez ici et on ré-évalue ça.

@kvanhoey
Copy link
Author

Hmmm ... des avis sur les "checks".
@pierrekraemer : j'ai rien changé depuis vendredi ...

@pierrekraemer
Copy link
Member

Ah oui pardon les checks ne sont pas configurés pour le moment et échouent systématiquement.. Il ne faut pas en tenir compte. Désolé..

@kvanhoey
Copy link
Author

Je viens d'ajouter un fichier "geometry/algos/convexity.h" qui vérifie si une face planaire est convexe. Il y a donc deux fonctions: isPlanar et isConvex. J'ai testé le isConvex dans le cas 2D (avec Vec2 et Vec3), pas au-delà. Je pense que ça peut être utile à intégrer, mais c'est à votre discretion bien sûr ;).

@pierrekraemer
Copy link
Member

Pour info, la convention de nommage pour les fonctions et méthodes dans CGoGN 2 est le snake_case..

@kvanhoey
Copy link
Author

kvanhoey commented Oct 27, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants