Importer/Exporter des .ac dans Blender 2.5.... cela vous tente ?

Je comprends la réaction de helijah, et je la soutiens.
Les modèles de helijah sont magnifiques. La modélisation est très bien faite. Mais, et il le sait qu'il y a un mais, les textures ne sont pas à la hauteur. Le dépliage uv, par exemple, ne permet pas de faire des textures fines. Il faut déplier le fuselage sur 4 cotés, dessus, dessous, droite et gauche, pour faire une texture précise. Par exemple si une face est quasiment horizontale, 1 pixel de la texture devra recouvrir une face de grande surface. En dépliant sur 4 cotés, l'angle entre la face et la projection sur le coté ne pourra pas excéder 45 degré. Le niveau de détail sera plus important. Sur les avions de FG, les textures ne sont pas au niveau de la modélisation. Il y a quelque exceptions.
Faire une bonne texture est au moins aussi compliqué que de faire une bonne modélisation. Une anecdote : il y a 2 ans, un copain infographiste était en vacances près de chez moi. Je l'ai invité à venir passer le week-end à la maison. Nous avons parlé d'avion, et je lui ai montré le programme que je suis en train de faire. Je bataillai pour faire une texture pour représenter de la fumée. En moins de temps qu'il ne faut pour le dire, il m'a fait une texture "à l'arrache". Le résultat était meilleur, lui à mis 30s et moi 2 jours.
Cette anecdote pour vous dire que le travail sur les textures, n'est pas aussi simple que l'on croit. Beaucoup de détails que l'on croit issu de la modélisation ne viennent que d'un travail sur les textures.
Par exemple, j'ai utilisé sur fg, un modèle de 109g, qui possède une texture de "normal-map". L'avion, au début, refusait de se charger. Après modification d'un fichier xml, j'ai eu l'heureuse surprise, de voir un modèle avec une "normal-map". C'est ce genre de détail qui fait la différence.
Faire ce genre de modélisation, n'est vraiment pas simple. Le travail sur les textures, est aussi long que le travail sur la 3D, et les avions ne sortirons pas à la même fréquence.
+++

Tout à fait d'accord avec toi _run_ mais c'est un choix volontaire. Et je vais expliquer ce choix.

Faire un véritable dépliage UV Map pour avoir des textures précises rend la création des textures très complexe. En effet, le résultat est un ensemble de profiles déformés (voir les texture de X Plane par exemple). Cela ne donne pas envie à tout à chacun de créer des textures rapidement et facilement. Mon choix est toujours et avant tout orienté vers les utilisateurs de base. Ceux qui ne croient pas pouvoir apporter leur pierre à l'édifice et qui lorsqu'il mettent les doigts dans une fichier texture.xcf.gz (par curiosité) se rendent compte que, en fait, il peuvent très bien faire quelque chose. Ce qui, dans la plupart des cas, ne serait pas si les profiles étaient ceux d'un véritable dépliage.

Bien sur, pour le fuselage, par exemple découper en 3 ou 4 parties (droite, gauche, dessus, dessous) peut être fait facilement et je l'ai fait par exemple pour le Me262, mais en fait, après de nombreux essais, la précision apporté ne vaut pas le travail supplémentaire. En effet 99% des détails de fuselage par exemple sont sur les cotés et non au dessus ou en dessous. Et du coup complexifier les textures pour un gain graphique minimal n'est pas franchement très utile.

Ensuite, comme cela a déjà été fait pour quelques appareils (Caravelle, TBM Avenger par exemple) refaire la texture en 2048x2048 (voir même en 4096x4096) permet de gagner en détail ce que l'on perd en possibilité. Il est même possible (comme sur le Do 335) de créer la texture en 1024x1024 et les bump map en 2048x2048, il n'y a rien d'incompatible et le résultat est tout aussi bluffant qu'avec tout autre méthode

Pour finir je dirais que en dehors du fuselage (dans 99% des cas) tout les autres éléments (ailes, roues etc...) n'ont pas besoin de dépliage complexe.

Voilà. Tout ceci est donc le fruit d'une réflexion longue qui a pour but d'ouvrir la création à tous et non de laisser cela à quelques talentueux créateur à l'égo souvent surdimensionné (je ne vise personne, mais j'en connais au moins un ... n'est ce pas Alexis lol )

Amicalement Emmanuel

Est-ce que par exemple le Rallye rentre dans le cas de figure que vous évoquez, on ne sait pas par quel bout le prendre si on veut créer une livrée?.

A moins de faire de la "barbouille" par dessus...

Oui et non patten. En fait le dépliage est ici le même type que le mien. C'est à dire sans déformation. Malheureusement l'auteur n'a pas compris que la place disponible était infinie. Il suffit de doubler la taille pour avoir plus de détails. Se faisant il a volontairement négligé un coté du fuselage idem pour les ailes etc... En fait, là nous n'avons que la moitié d'un avion. Je suppose que la deuxième moitié est fait par symétrie. Mais du coup impossible de faire des détails droits différents des détails gauches. Et que dire des inscriptions. Lisible d'un coté et à l'envers de l'autre.

Donc oui et non. Car c'est quand même un très mauvais exemple effectivement

Ah le dépliage uv ..... c'est toute une histoire.

Dans le dépliage ou l' uv mapping ( en anglais beurk!! ) le but, est de garder des aires de surfaces équivalentes entre la texture et la facette. Par exemple : une facette faisant une unité de suface, fera une unité de surface sur la texture. Puis une facette de 2 unités fera 2 unités sur la texture. Il faut conserver les proportions des surfaces. Voilà pour la théorie. En pratique c'est quasi impossible, sauf pour les volumes simples tel que le cube, etc...
La fonction unwrap de blender tente de conserver les unités de surface. Mais le dépliage est très compliqué à peindre. Pour notre cas le dépliage en coté pour le fuselage, est très facile à peindre, mais aura des distorsions sur le dessus et sur le dessous. Il quasi impossible de peindre le rivetage de l'avion sur le dessus et sur le dessous. C'est pour cela que pour le fuselage le dépliage est souvent effectué sur 4 plans. L'angle maxi d'un facette par rapport à la surface de projection sera de 45°. Ce qui donne une surface 0.707 fois plus petite que la surface idéale. En ne conservant que 2 plans de projections, les surfaces peuvent avoir des rapports beaucoup plus important, jusqu'à zéro pour une facette perpendiculaire au plan de projection.

J'en reviens à blender, mais c'est un logiciel impressionnant. Il est possible de faire plusieurs dépliages. Par exemple un dépliage en projection simple, puis un autre avec plusieurs projections compliqués. Ensuite il est possible de réaliser une texture sur la projection simple et de fabriquer la texture compliquée à partir de la projection simple. Au final on retouche la texture compliqué. Le résultat est une texture qu'il aurait été impossible de réaliser sans cette artifice.

Et oui là encore, la 3D c'est pas si simple. Mais fg est sur la bonne voie ... ça avance petit à petit ....

Bon sinon je précise quand même, si un script import/export pour X Plane est en cours... perso je suis preneur (et testeur au passage). Petite info, même si X Plane est en version 9 maintenant il existe encore un grand nombre d'avion en version 8 (voir même 7 mais ils se font rare). et je sais qu'il existe des différences entre 7 8 et 9.

Amicalement Emmanuel

Mise à jour du script :
http://rene16.dyndns.org/blender/io_scene_ac.tar.gz

Suite aux tests fait par Couby.

J'ai modifié le script pour pouvoir utiliser les chemins windows. C'est utile pour les fichiers de textures. Donc actuellement, le script passe la frontière windows-linux, je pense que mac ne devrais pas poser de problème, car cet OS est issu de Unix comme linux

Je vous invite à faire des tests.

comme toujours l'adresse du script:
http://rene16.dyndns.org/blender/io_scene_ac

Amicalement René

Comme promis petit test rapide ce matin, avec le DHC2 et le Camel, et ca marche .

Est-ce que tu souhaites que dans la semaine je teste avec un tas d'autres modèles pour détecter d'éventuels autres problèmes ?

Encore merci pour ces scripts, c'est magique

Couby a écrit:Est-ce que tu souhaites que dans la semaine je teste avec un tas d'autres modèles pour détecter d'éventuels autres problèmes ?

Oui merci , si cela ne te gêne pas !!

A+

_run_ a écrit:...je pense que mac ne devrais pas poser de problème, car cet OS est issu de Unix comme linux

Je vous invite à faire des tests.

comme toujours l'adresse du script:
http://rene16.dyndns.org/blender/io_scene_ac

Amicalement René

Je teste ça sur Mac et te fais un retouir d'ici mardi.

Merci pour ton travail.

Amicalement,

_run_ a écrit:
Oui merci , si cela ne te gêne pas !!

Non c'est normal.

J'encourage ceux qui utiliseront ce script de voir ce post :
https://equipe-flightgear.forumactif.com/t641p15-spifire

Je vois que tu n'as pas très bien suivi !

Ce n'est pas ton script, ni même le travail fantastique que tu as réalisé sur le Sptifire (dans le cadre de ton super simu de compat) mais les réactions que cela engendre.
Ton travail sur le spitfire est justement fait dans le cadre d'un simulateur façon IL2 est cela est franchement génial. Car justement dans ce type de simul ou les zones de vol sont limité, ou les instrumentation et les interaction entre elles sont aussi limité, toutes les ressources ou presque peuvent être placées dans les avions. Et c'est ce qui fait de IL2 un superbe simulateur vue depuis l'avion. Et il en est de même du tiens qui en fait baver plus d'un.

Non le soucis est que ton simu comme IL2 n'ont pas la même façon de faire que FG... et c'est normale, le but n'est pas le même.

Quand au script, il n'a rien à voir dans tout cela. Que le simu soit un IL2 like ou un FG like, le script restera utile à tous et toute. Je sais qu'il n'est jamais agréable de se voir critiquer (quoique là la critique n'était pas dirigé vers toi - même si c'était peut être mal exprimé), mais c'est aussi par la critique que l'on avance. Si j'avais avoir ta réaction à chaque critique il y a longtemps que j'aurais cessé de créer des avions pour FG. Bien au contraire, soit j'ai écouté et adapté mon travail d'après les critiques, soit j'ai démontré que j'avais raison et les critiques ont disparues. Dans les deux ca, il faut surtout mettre son ego dans sa poche et son mouchoir par dessus.

Amicalement Emmanuel

Salut,

Sur le forum anglophone un certains "majic79" a lui aussi créer un script d'import/export AC3D pour Blender 2.5

Le post est là : http://www.flightgear.org/forums/viewtopic.php?f=18&t=13442
Et les fichier ici : https://github.com/majic79/Blender-AC3D

Cette personne a été mise au courant du travail de René cependant il semble que le code de majic79 soit nettement plus documenté (il suffit d'ouvrir les fichiers pour s'apercevoir qu'ils contiennent une documentation!)
De plus je crois que la version fournit par René pose quelques problèmes (après un export puis import on retrouve beaucoup de vertices non relié)

Donc pour ceux que ça intéresse... allez-y

Amicalement,
Clément

Et bien voilà une nouvelle quelle est bonne

J'essaie de suite

Amicalement Emmanuel

Et pour finir on prend lequel

Aucun des deux??
Ça fait maintenant quelque temps que j'utilise celui-ci. Quelque part avec beaucoup de regrets! Non pas a cause que ce script qui n'est pas fini (voir, smooth all, pas de double faces et d'autre truc basic comme l'import non-fini...) Mais plutôt du fait que il est a l'abandon! Je me retrouve a faire des bâtiments qui ont un smooth all sur tout les faces. C'est un peu incontrôlable et ridicule... Ok, le edge split marche a merveille, mais si c'est pour rajouter des points non contrôler est surtout inutile pour certains objets vraiment basic ... Mais bon, il était en plein développement ce script et j'en suis bien conscient...

L'autre script, euhm, celui qui regarde la capture d’écran qui ce trouve dans ce poste, va même pas prendre la peine de regarder le script Du n'importe quoi C'est a ce demander si il a déjà modeler quelque chose avec Blender... Puis a quoi bon pouvoir importer, si l'ont sais même pas exporter.

Enfin bon, voila quoi...
J'ai repris mon bon vieux Blender il ya un bonne heure, le 2.49 que je déteste tant maintenant. Machine arriere, ca fait mal!

Personnellement j'utilise le nouveau de majic79 pour l'import (en effectuant à chaque fois une rotation de 90° sur x) puis celui de _run_ pour l'export en ouvrant ensuite le .ac dans un éditeur de texte pour enlever les chemins sur toutes les texture.

Résultat, vous pouvez le voir sur le Dc 3, sur l'Astir et quelques autres. C'est assez lourd à gérer mais en attendant mieux cela permet de travailler avec Blender 2.59 sans soucis.

Amicalement Emmanuel

Alors deux choses à annoncer à propos de l'importation dans Blender.

1 - Tout d'abord, majic79 continue de travailler sur ces scripts d'import/export. L'import est maintenant quasi parfait. L'export reste encore pas mal perfectible, mais il y travail d'&arrache pied

2 - Je viens de recevoir un mail de Melchior FRANZ m'annonçant qu'il avait enfin installé Python 3.2 et donc du coup Blender 2.6. Ce qui fait qu'il se lance enfin dans la conversion pour blender 2.6 de ses scripts. Import_Yasim et les autres

Amicalement Emmanuel