Lightwave, Blender.goldorak

[Yomgui]

Yomgui

#95150

s4m: bien-sûr… et les autres aussi. Ca m’intéresse de partager l’expérience sur Blender, je n’en connais pas encore tous les méandres (comme l’anim par bones et les shapes), mais la lecture directe dans le code m’aide beaucoup

En partageant on avance tous…

En plus ça m’aide à tester la version MorphOS et trouver les bugs.

[bLa]

bLa

#95151

[sayasupacrew]

sayasupacrew

#95152

Revenant du nass8, et comme tous les ans, j’ai encore fais de nouvelles conaissances et qu’est-ce c’est bien d’ailleurs.

Entre autres j’ai fais la rencontre de Fenrix, nous avons

conversé. L’idée de faire quelques choses comme avancé sur ce petit truc,il faut bien le dire m’as bien séduit.

Donc avec un petit soft de l’AmigaOs de rein du tout on peut beaucoup, je parle de showObjet disponible sur Aminet et qui sera utilisé cette fois ci sur un pegasos. Avec les .lwo de goldorak voici ce cela peut donner.

(fenrix sa tiens toujours pour faire quelques choses de plus avancés sur ton site.)

Modération de Tcheko : cassage de mise en page

Image 1

Image 2

Image 3

https://www.youtube.com/@sayasupa

[sayasupacrew]

sayasupacrew

#95153

donc sous blender.

cliqué dessus.

https://www.youtube.com/@sayasupa

[thellier]

thellier

#95154

C’est un bon débat

Effectivement il faut « trianguliser » tout les polygones qui sont pas plans: c’est uen évidence

Pour les polygones plans (genre face d’un cube) on peut les laisser tel quel : ca evite de transformer 2*3 points

au lieu de 4 par face

Par contre je comprends pas ton argument sur les normales:

une face de cube convertie en 2 triangles : alors les 2 triangles ont les mêmes normales ===> ca change rien pour les normales des points

Normals du point = (normale face 1 + normale face 2 + normale face 3)/3

rien ne change

C’est plutot « trianguliser » un polygone qui est plus ou moins beau (tristrip, trifan,etc…)

[sayasupacrew]

sayasupacrew

#95155

en me balladant sur la minette j’ai trouvé ceci

ldraw un visualiseur 3D en temps réel pour morphos. Mais il faudrais rajouté ceci

http://www.ldraw.org/download/software/ldraw/ldraw027.zip

un petit coup de configuration de MIME sous Morphos 14 et hop je n’est plus qu’as lancé les projets en cliquant simlement sur eux depuis le bureau.

vous pourrez donnez une rotation a votre objet choisi au pré-alable. Plusieurs options, comme effet de fil de fer, le zoom, la couleur du fond d’écran, enlever les reflets…

celui-ci prend votre 3D de votre carte graphique en compte.

Arguments:

-window use window instead fullscreen

-width x set window width to x (default: 640)

-height x set window height to x (default: 480)

-lowdetail reduces part details (obviously faster)

-highdetail use high detail primitives (when available) instead of normal ones –

NOT RECOMMENDED, doesn’t look much different, but will be a LOT slower

Example: will display car model on 1024×768 screen with low detail parts

ldview -lowdetail -width 1024 -height 768 MODELS/CAR.DAT

Controls:

numpad:

1,2,3,7,8,9 increase / decrease x/y/z rotation speed

4,5,6 set x/y/z rotation speed to 0

-,+ scale the model

cursor keys move the camera

b changes background color

m switches display mode (solids+lines, solids, lines)

l toggle lights

s toggle shading model

, and . cycles submodels & parts

e

https://www.youtube.com/@sayasupa

[Yomgui]

Yomgui

#95156

C’est un logiciel pour faire des LEGO … donc asser dirigé non ?

D’ailleurs voilà la news sur AI :

https://www.amigaimpact.org/modules/news/article.php?storyid=380

C’est dommage, mais il n’y a plus de news depuis 2005.

(en cherchant un peu on trouve des scripts pour importer du LDR vers Blender).

[sayasupacrew]

sayasupacrew

#95157

Yomgui: est il possible ajouté un son(wav, mp3) a une animation tracé par blender ?

Saya

https://www.youtube.com/@sayasupa

[Yomgui]

Yomgui

#95158

Pas sur la version MorphOS, j’ai pas porté la chose correctement pour le son.

Sinon oui.

[krabob]

krabob

#95159

J’ai réfléchi a tout ça et vérifié des trucs: c’est un problème politique au niveau des logiciels de modélisation:

– Lightwave a une notion de Polygone « N-Gone » comme primitive de base, convexe ou pas, qui définissent une surface, qui doit être dans le même plan (si on ne fait pas de connerie: rappel le format flottant IEEE, par définition, créée des imprécisions). ( NON, ça ne pose pas de problème, c’est même parfois très utile, un modéliseur ça fait de la géométrie aprés tout !.) Les formats .lwo prétendent aussi avoir une taille minimale, avoir des définition en N gone ça aide.

Par contre: pour qu’un polygone lightwave puisse passer en nurbs, ce doit être un triangle ou un quad. (chaque polygone d’un mesh peut être nurb ou pas.) comme sur blender.

– Blender ne connait que des triangles et des quads, c’est tout. La vrai raison (ce que j’avais pas compris l’année derniére):

ce sont les seules surfaces que l’on peut passer a coup sûr en nurbs sur un mesh. Du coup, un mesh blender peut toujours passer en nurbs. Comme pour du rendu on a toujours plus joli en nurbs, ça se justifie, mais pour des objets temps réel qui n’utiliseraient pas de nurbs, je conseille de rester en quad quand on peut:

Par contre je comprends pas ton argument sur les normales:

une face de cube convertie en 2 triangles : alors les 2 triangles ont les mêmes normales ===> ca change rien pour les normales des points

Normals du point = (normale face 1 + normale face 2 + normale face 3)/3

rien ne change.

si , ça change, parce que dans un cube passé en triangle, un point est relié a une face par *1 OU 2* triangle, ce qui fausse le poid de la normale de cette face (une face du cube va compter pour 1, l’autre pour 2 et la normale va dévier) Les moteurs temps réél ont beaucoup de mal à gérer ça: La preuve:

Image 3

Lààà regardez: on voit des triangles sur les cornes, là ou il devrait y avoir des quads: les normales sont légérement faussé, mais ça se voit ! nostradamus l’avait prédit: c’est l’erreur que je redoutait et c’est pour cela que je réagit chaque fois que j’entends dire qu’il faut forcément passer des quads en tri. On perds des informations topologique quand on fait ça,.

re-note pour être complet: il est possible de mieux recalculer les normales pour du temps réel, mais il faut calculer la moyenne des normales en prenant en compte l’angle que forme la face attaché, et s’en servir comme « poid » dans la moyenne (ce que personne ne fait apparemment, en général on a simplement: normale au point= moyenne de toutes les normales attachée), mais je ne suis pas sûr que cette methode éliminerait complètement les erreurs.

Modération de Tcheko : cassage de mise en page

[Yomgui]

Yomgui

#95160

Kradoupouillou à écrit:

c’est pour cela que je réagit chaque fois que j’entends dire qu’il faut forcément passer des quads en tri. On perds des informations topologique quand on fait ça,.

(…)

re-note pour être complet: il est possible de mieux recalculer les normales pour du temps réel, mais il faut calculer la moyenne des normales en prenant en compte l’angle que forme la face attaché, et s’en servir comme « poid » dans la moyenne (ce que personne ne fait apparemment, en général on a simplement: normale au point= moyenne de toutes les normales attachée), mais je ne suis pas sûr que cette methode éliminerait complètement les erreurs.

Et non, on ne pert rien: le nombre de points et leurs positions n’ont absolument pas changées => donc pas de changement topologique.

Ce qui change c’est la définition du nombre de bords (les edges) entre les points: 1 bord de plus pour 2 triangles format un quad.

Mais comme tu le dis ensuite: le problème ne vient pas de la topologie du modèle mais bien des mathèmatiques utilisées par le moteur de rendu. Les moteurs RT utilisent des fonctions d’ordre 1 (linéaires) pour leur rapidités, ceci implique que le calcul des normales sera correctes sur des triangles plutôt que des quads.

Voilà pourquoi on utilisent les triangles sur les moteurs RT.

Mais les choses évolues et maintenant les moteurs utilisent les copro des cartes GFX, plus évolués et utilisant des algo d’ordres supérieurs. Le remplissage de surface quad devient plus ‘beau’.

Comme le dit Wikipédia: « Un topologue est une personne qui ne sait pas distinguer une tasse d’un beignet. »

et oui mon cher kradoupouillou: c’est pas la topo qui change ici, mais la définition euclidienne!

[krabob]

krabob

#95161

Et non, on ne pert rien: le nombre de points et leurs positions n’ont absolument pas changées => donc pas de changement topologique.Ce qui change c’est la définition du nombre de bords (les edges) entre les points: 1 bord de plus pour 2 triangles format un quad.

Sauf que, dois-je te le rappeler, on calcule les normales d’aprés les connexions topologiques des surfaces, et donc oui, changer les connexions( comme quand passe des quads en tri) affecte les normales des points (qui eux ne bougent pas, d’accord) , et donc oui, c’est un problème de topologie. ( qui est visible sur le rendu temps réel du post précédent )

les moteurs RT utilisent des fonctions d’ordre 1 (linéaires) pour leur rapidités, ceci implique que le calcul des normales sera correctes sur des triangles plutôt que des quads.

Déjà: attention ! un moteur temps réel de nos jours, ça utilise des shaders, et on est plus du tout sur des modéles linéaire à la goureau simples ! on applique un modéle fin, plus du tout interpolé (pour peut qu’on mette les calculs dans les pixels shaders), et quand on fait ça, on à justement besoin de normales béton. et on subdivise moins les poly, paradoxalement , pour un meilleur rendu, puisque l’exactitude d’un éclairage se fait par le shader, et plus par subdivision de face. (cf jeux pc depuis 6/7 ans.)

Voilà pourquoi on utilise les triangles sur les moteurs RT.

Mais tu mélanges tout: les triangles (et meme plutot triangle strip ) sont effectivement mieux pour faire les algos de rendus (pour un tas de raisons complexe d’ailleurs), mais *pour calculer les normales* c’est pas bon, donc un moteur RT en général:

1. charge l’objet

2. calcule les normales au mieux -> (mieux en quad)

3. passe les primitives en triangle. *APRES*

et oui mon cher kradoupouillou: c’est pas la topo qui change ici, mais la définition euclidienne!

tu m’as l’air de faire bien le matheux théoricien, mais perso j’ai 15 ans d’expériences a coder des moteurs RT et j’ai une bonne idée de ce genre de problemes. attention, on est peut pas dans le complexe, mais on est dans le « détail » , dans l’affinage de poil de cul, à un certain niveau si on est daltonien ou qu’on refuse de voir certains détails, on peut pas comprendre.

[krabob]

krabob

#95162

et puis regarde la encore cette image:

Goldorack triangles pas droit

tu trouves vraiment ça joli ces triangles même pas droit qui ont pas le même gris que ceux d’a coté sur les cornes ? t’aurais pas préféré avoir une couleur grise PAR quad ? Tu te rends pas compte que l’éclairage est complètement biaisé tout le long de la corne parce qu’on l’a passé en tri ?

Quand tu veut faire du joli rendu, Oui c’est important.

Puis franchement: argument de poid: si tu garde un mesh en tri/quad, tu peut le passer en tri quand tu veux, alors qu’un mesh passé une bonne fois pour toute en tri, tu peux plus le repasser en quad ! cherche un algo tu trouveras pas ! Pourquoi d’aprés toi ? parce que tu as perdu de « l’information » sur la forme de l’objet. Ouiiii si tu code plein de moteur RT et que tu essai d’affiner leurs rendus, au bout de quelques années peut etre tu comprendras.

Modération de Tcheko : cassage de page par image

[Yomgui]

Yomgui

#95163

Ouiiii si tu code plein de moteur RT et que tu essai d’affiner leurs rendus, au bout de quelques années peut etre tu comprendras.

Oui certe… c’est vrai, j’ai arrêté de faire des moteurs RT il y a plus de dix ans justement.

J’ai du mal à te suivre, mais quel est ton problème? les quad c’est mal, les tri c’est génial?

Si c’est ça, je dirais oui… mais dans le cadre du RT et c’est tout.

A toute chose il faut un contexte, sinon elles ne valent plus rien.

Maintenant la modélisation en quad permet des concepts mathématiques bien plus subtile, qui ne peuvent être vus en tri.

Cf toute la théorie des N-Poles.

Par contre on parle plus de RT ici

[thellier]

thellier

#95164

> un cube passé en triangle, un point est relié a une face par *1 OU 2* triangle, ce qui fausse le poid de la normale

Tu as raison comme la découpe en 2 tris est pas symétrique (pour éviter ça il faudrait couper un quad au centre donc en 4 triangles pour le répartir équitablement sur les 4 points)

mais dans ton image on a pas l’impression qu’il s’agisse de normale de point mais de normale de face (normale d’un triangle)

Je crois cela car chaque tri a une couleur UNIFORME et non pas un dégradé entre les 3 sommets

S’il s’agit bien de normales de faces alors je vois pas comment 2 tri issus d’un même quad donc sur le même plan peuvent avoir des normales de face différentes

On a l’impression que le prog fait les normales de points puis une (fausse) normale de face en faisant leurs moyenne

Ou lors le gouraud est désactivé ==> des faces bien décrites comme dégradés se retrouvent en « à plat »

Il est alors possible que le calcul soit correct mais le rendu soit fait « à plat » par faces donc laid

Alain