La guerre est déclarée sur Mapcore, un forum composé de nombreux Level Designers et Level Artists professionnels à propos le l’obsolescence du format BSP, notamment sous Unreal. Le débat vire rapidement sur les méthodes de prototypage. Morceaux choisis :
by Pericolos0 (GRIN Suède) on Tue Mar 17, 2009 8:12 pm
you guys are still using bsp???? lmao
Etant moi-même un inconditionnel du BSP, en phase de prototypage, ça m’intrigue, d’autant plus que 2d-chris (Crytek Francfort) semble abonder dans ce sens :
by 2d-chris on Tue Mar 17, 2009 8:38 pm
but yes peris, we’re not artists remember, we need to prototype levels before making it look good~! it’s a darn sight quicker doing it in a bsp editor than max.maya and importing all the time.
by Steppenwolf (GRIN Suède) on Wed Mar 18, 2009 11:23 am
Why do you think so? I really see no advantage that bsp has these days. Maybe a bit more control and freedom for the level designer but thats something that gets lost anyway with the job becoming more and more specialized. Visualy it doesn’t make a difference on what your engine is based as long as the renderer, art assets and everything is top notch. The main difference is in the workflow and in that regard bsp is just a painfull thing from the past.
Oui, on sait bien que tout la géométrie va être remplacée par des meshes au final, mais malgré tout on continue à prototyper en BSP, même si c’est vieux. Amusant tout de même de constater que deux collègues de chez GRIN ne sont pas d’accord. Peris intervient et marque des points :
by Pericolos0 on Wed Mar 18, 2009 11:38 am
no it’s not, its an ancient, extremly slow and limiting workflow for modelling your level geometry. You guys just don’t want to learn how to model. Learn how to model some simple modular geometry and your whiteboxing will be way faster and free. You could even do it in sketchup. Modelling is easier than working with brushes!also bsp is just really expensive to render with all its material swithces and whatnot. Batched modular geometry is where its at now. Bsp is dead i tell you!!
Mmh, BSP contre géométrie modulaire, ça commence à devenir intéressant. Je n’arrive pas à voir comment produire et importer des modèles 3D pourraient accélérer le processus de prototypage. Robert Briscoe reste sceptique:
by robert.briscoe (DICE Suède) on Wed Mar 18, 2009 11:43 am
I strongly disagree, I have years of 3d modelling experience and if you are blocking out and prototyping a level there is a high amount of iteration and testing and bsp is the most durable, fast and efficient method of doing this. Going back and forth between two programs and reimporting etc is not good workflow.
by Pericolos0 on Wed Mar 18, 2009 11:55 am
Well having to compile a level and then start up the game to play it is not a good workflow either imo. Working in unreal editor with max open next to it to work on the geometry of your meshes works pretty well i think, importing and exporting takes just a few clicks, and you’ll be doing most of the actual leveldesign work in unrealed anyway, moving around modular meshes. I’ve felt alot more free and capable doing leveldesign once i stopped using brushes. And yes you’ll be doing iterations on the geometry, but changing around geometry is way faster in a modelling program than changing around brushes, so the extra 5 seconds it takes for importing/exporting is no problem at all really, you can set up a really good workflow for this if your editor has good asset management. Like unreal’s unit browser or cryengine which will export it straight from max into the editor basically.
Pas mal d’avantages en effet sur l’utilisation de la géométrie modulaire, car en effet, construire des blocs de meshes qui tilent et qui snappent permet de les agencer comme on le souhaite, sans avoir à rebuilder la géométrie. Par contre, il ne parle pas des collisions, le sujet fâche peut-être 🙂 J’ai quelques doutes sur le fait que compiler la géométrie et lancer le jeu ne soit pas un bon workflow; après tout c’est un processus obligatoire il me semble.
by Hourences (Starbreeze, Suède) on Wed Mar 18, 2009 12:18 pm
Modeling a mock up IS easier, but as said, export importing etc is indeed not exactly very fun. I rather rebuild/compile BSP than exporting importing meshes all the time really.So for me the way to go would be an engine that can read for example .max files, and auto reload that file as soon as it is modified. That way you can just do ctrl s in Max, and your changed floorplan shows up in the game. Unity does this I believe, and I believe this is the next big thing for tools to do really. It is a shame Unreal, however simple its importing process is, doesn’t allow you to speed up that process even more.
Hourences va un peu plus loin et pointe les manquements des moteurs actuels à ne pas faciliter le réimport des modifications effectuées sur un modèle 3D. Sous Unreal, le système de packages est un peu lourdeau et force de nombreux réimports au fur et à mesure que l’on itère sur son mesh. Je me demande si d’autres moteurs qu’Unity proposent ce genre de fonctionnalité.
by Steppenwolf on Wed Mar 18, 2009 12:26 pm
What you discuss now is really more of concern for the artists. In Diesel engine i don’t necessarely have to switch around modeling program and level editor as a level designer. We have like a set of legos (different sized and shaped models) that we use for doing the map layouts. This works _a lot_ faster then doing the map layouts with brushes.
And i would estimate that if all art assets are provided i can create a whole map in like 10-20% of the time that a similarly detailed map would take me in Source or Radiant.
Vu comme ça, il est évident que ça fonctionne. Utiliser un set de briques modulaires gabarisées comme des Legos rend la création d’un layout très rapide. Et surtout facilite la vie des graphistes derrière. Mais est-ce que ça marche pour tous les types de jeux ?
by Pericolos0 on Wed Mar 18, 2009 12:35 pm
That would be a nice feature, but making your entire floorplan in max is a really bad idea imo and not at all what im talking about =). My workflow now is more like: making a bunch of simple modular meshes, constructing a crude level out of them, and then iteration, adding extra meshes where i need them and iterating on the geometry of my modular set. The nice thing is your working on just a few pieces of instanced geometry that you reference to for your entire level. This makes the process of detailing and iterating on your level so much faster than compared to a level uniquely made out of brushes.Really dont understand why you rather rebuild BSP than import a simple mesh though, its really a very easy process in unreal, not ideal, it could be a few clicks less, but very very easy and fast.
by Hourences on Wed Mar 18, 2009 12:55 pm
Using modular content is not modeling. Well it was made through modeling of course, but if you say « model a mock up » that for me means doing what you would have done with brushes, but in a modeling package. Using existing modular meshes is more like a third way of building a mock up/real level. Could work as well of course.I dont see why modeling an entire floorplan is such a bad idea. Plenty of studios do this. It would basically work the same as using BSP in combination with some meshes. There are certainly some cons to this approach, just like there are also some cons to using just modular bits and pieces everywhere. Kind of depends on the situation really. Indoor basement level vs large open landscape for example.
Nous y voilà. Au fur et à mesure, les deux méthodes prouvent leur avantages, le type de jeu ciblé va probablement permettre de les départager.
by 2d-chris on Wed Mar 18, 2009 2:14 pm
I don’t think anyone suggested that BSP is still alive from an artistic or even performance point of view. The only real advtange of using solids for game development is for fast prototypes of layouts, scales and player leading.[…] Yes you CAN use max/maya for rough layouts, but i’d rather have the option to adjust everything in seconds than have to fart around in a 3d program. I’ve had experience making everything in maya and exporting to Unreal, it’s not a bad approach but defintely slower. it depends on what stage of a project you are working on, how much your expected to change a layout and when you consider a whitebox ready for an art pass.
Just when you consider the game engine and pipeline to be so important, take a look at Valve … the ability to change a layout drastically AFTER an art pass is done undoubtably helps them create some of the best games in the industry.
Effectivement, Valve possède sa manière de monter les niveaux, même si leur façon de prototyper a été décrite en détails par Dario Casali dans ce post sur tf2maps.net et ne diffère pas énormément du prototypage par BSP. La faute aux outils archaïques fournis avec le moteur. Seul avantage de Source ? Probablement les textures gabarisées collées sur les BSP (Les Orange Boxes). Mais c’est inapplicable à des meshes qui ont leur propres UVs.
by Steppenwolf on Wed Mar 18, 2009 2:50 pm
Chris, as i already wrote for Diesel we use a set of lego like models for the rough layout. That is way faster then brushing because we will just overlap and wildly angle stuff to get the shapes that we want. It doesnt matter at this stage because it will be replaced anyway. And there is no fear that something could break the map or hurt performance like this would be the case for bad brushwork.This is a really bad example because this is exactly where i feel that source is way behind. You have to fix so many tiny things afterwards alone to make the map compilable again. I did some serious layout changes for bionic commando within a couple of hours. When i was on Insurgency stuff like this always took 1-2 days to fix and was a real pain in the ass to do.
by Minotauro (Ubisoft Sao Paulo) on March 18th, 2009, 2:07 pm
It all really depends on beforehand planning imo. Both methods have their cons and pros but if you don´t have a big picture of what you want before you start you will have definitely troubles, with both approaches. You can´t model with a BSP mentality and the other way around is also true. It´s just a matter of getting used and learning the shortcuts. A few years ago the idea of making an entire level in max scared the shit out of me, but I can see it completely doable now. It would be perfect if it had an a-la Hammer texturing tool. Adding UVW map modifier to each piece is a real pain in the butt. Oh and a decent texture browser would also be neat.I really like Grin´s solution to prototyping levels, maybe I´ll try that myself next and build a non-bsp level in Unreal 3.
by Pericolos0 on March 18th, 2009, 1:58 pm
again, im not saying to create an entire layout in max or maya, I also think thats a very bad workflow. I’m suggesting using modular meshes to create your layouts with. Quick pieces of geometry you block out in a modelling program and place as if they were brushes. This way it also takes seconds to move around stuff in your editor, except your not working with blocks but nicely defined pieces of geometry that can be made into good artwork. No flat surfaces everywhere with tiling textures but an organised set of instanced geometry. Nicely defined pieces of geometry you can give to an artist. This is where level design is inevitably heading, and alot of companies are working this way. But yeah you guys can be the dinosaurs of game development and keep using brushes, sorry to sound like hessi here .
Anyway i’m just saying i really believe this is a way more efficient way of creating levels, and you should really try it more, good recent example i’ve seen on mapcore was nurb’s unreal3 level in the wip thread.by Pericolos0 on March 18th, 2009, 2:11 pm
2d-chris wrote:
There are tons of ways you can make levels, but suggesting that BSP (solids) is a dated and doomed method is not really correct, if you keep it in perspective of what it’s used foryeah making 90 degree corner hallways and rooms. You could be making so much more interesting stuff!
Il n’a pas tort. On est souvent limité à la grille et du coup on se retrouve à faire des morceaux de BSP orientés à 0, 45 ou 90°, et l’utilisation de modules de meshes permet effectivement de se retrouver avec des morceaux de géométrie mieux foutus que s’ils avaient été faits avec du BSP. Ah putain ils sont en train de me convaincre !
by Hourences on March 18th, 2009, 4:04 pm
So Peris, exactly how would you build a large open landscape with a large surrounding mountain ring a la demon army camp in Spellborn Chronicles with using just modular pieces and lets say you had no actual unreal terrain available to make the floor with? Sure it is doable, but would it be that much easier/nicer in that specific situation? I dont think so really.Thats where modeling the entire thing comes in, even when it is only just a mock up. Now the details on top would be modular of course.
The same thing can be extrapolated to small indoor levels. And that is what Unreal does, and has been doing for 6 years now. Unique shells, with modular details. Instead of all modular.
If you go all modular, you get a game like Oblivion or Fallout, and it is cool, but it does look less defined sometimes.
The bottom line is that it is not just black and white. This sucks, that rules. This depends on the specific game, the specific needs, the skills of the artists and designers, the budget, the time, etc. A game like Fallout benefits from it as they need this approach to save time since the game is so huge. A game like Spellborn benefits from it because it is lower budget and a small team, thus you need to speed it up as much as possible. A big budget title however does not neccy require this. They can take the time to get a higher level of quality going, and that is good. Killzone for example was built like this, even its mockups. And I am not saying that is the best game ever, or that they had a very speedy production, but if you have the budget and money for it is not neccy a bad thing.
Shades of grey… Hourences pointe à juste titre les spécificités des différents jeux, qui peuvent très bien être open space à la Crysis ou bien très confinés. Du coup une méthode pourrait être plus adaptée qu’une autre, en prenant également en compte les impératifs de production (prototyper reste un luxe de nos jours, et les outils sont bien souvent merdiques à ce niveau). Il s’agit donc de bien identifier le type de lieu qui sera représenté dans votre niveau et de choisir la méthode de prototypage adéquate.
by Pericolos0 on March 18th, 2009, 6:24 pm
That demon army camp is a fun example because i think in retrospect i would have done it different. Not having terrain editing would be annoying in that example since the level is basically a big terrain, but for the rocks i would have made just a set of rock faces that i’d place around everywhere the player can get close to. Like 4-5 different large pieces, then i could make them pretty detailed and good looking and just place them around in the editor, I’t wouldnt look all lowpoly and tiling like it is now, and it would be a lot less work than uniquely modelling and unwrapping the entire thing. We did it like this in bionic commando: http://www.bioniccommando.com/img/site/ … ghtbox.jpg
I could build the terrain out of modular terrain patches too if terrain editing was really out of the question =). Like 4-5 different terrain meshes just placed everywhere mashed inside each other, the use some vegetation or decals to cover up the seams. All of this could be LODed, instanced, would occlude away nicely, so it would end up looking more detailed while still being very cheap to render.Of course you shouldn’t use modular stuff for everything, you could make unique geometry for some special areas or whatever. It’s just a way of organizing your workflow and a very efficient way of making stuff detailed in a short ammount of time. And if you are good at making good modular meshes that can be used in various ways, you can really achieve big budget looks!
Intéressant. Méthode un peu crade (empiler les meshes les uns au dessus des autres et masquer les transitions avec du foliage), mais qui a le mérite de proposer une autre solution au même problème.
Pour conclure, parce que j’ai été un peu long. Il n’y a pas de méthodo absolue et divine. Ca dépend d’un certain nombre de facteurs (qualité du moteur, des outils, temps de prod, ressources humaines), mais ce qui semble émerger est l’utilisation conjointe de modules modélisés à l’aide d’un éditeur polygonal et de BSP (ou approchant).
Le but à atteindre :
- Faciliter la vie des graphistes enviro qui vont habiller votre map : avoir des pièces gabarisées, qui snappent sur la grille, de taille en puissance de 2
- Faciliter la vie des level designers, qui vont assembler ces pièces comme des Legos, et itérer le plus aisément possible sur leur map.
24 réponses sur « Whiteboxing Wars »
Presque tl;dr Mais nan … On se laisse prendre dans le débat. Intéréssant !
J’hesite entre un concours de taille de bite et un débat d’enculeurs de mouches.
Moi je dis, le bsp ça pue, surtout quand on aime pas se prendre la tête avec les outils…
Une chose est sure je pondrais un layout de map bien plus rapidement en posant mes modules avec des unités prédéfinies, que de tenter le full bsp en se faisant chier avec les grids.
Je supporte pas d’être bridé et ralenti par des méthodes archaiques avec des editeurs pondu avec les pieds qui ne font que crasher a la moindre occaz.
En passant au tout mesh, on tombe sur des trucs abberrants comme le moteur de STALKER (je sais pas si ça utilise du BSP, mais le peu que j’en ai vu utilise 100% de mesh).
J’ai mappé des années au BSP, et je ne me suis jamais senti limité par la grille. Dans QuArK, la grille descend jusqu’à 0.5 et il y a un hack pour descendre à 0.1 dans UnrealEd en créant un bind hasardeux. Au contraire, ça donne une géométrie régulière est plus facile à manipuler. Mapper en mesh est bien plus complexe et irrégulier. Forcément, c’est plus puissant, on peut faire du UVWrapping sur chaque élément etc.
Les rares fois où je me suis essayé à faire des mesh, développer les UV et faire la collision me prenait infiniment plus de temps que de faire un équivalent BSP. C’est sur, c’était mieux optimisé pour le moteur, mais au niveau de mon workflow, c’était tellement mauvais que j’ai fini par renoncer.
Ensuite question de goûts. Moi j’aime avoir un truc régulier, avec des angles assez réguliers, et pas seulement des angles de 90 degrés, j’ai vu bien des maps BSP super courbes. Le type qui dit ça oublie un peu facilement que depuis Quake 3 et les patch mesh, les courbes peuvent être aussi lisses qu’on veut. Même UT99 qui ne supportait que le BSP dur a eu sa part de maps toutes en courbes.
Sans compter que cela force à se former à deux logiciels : l’éditeur et un soft de modelling. Quand je regarde un de mes derniers travaux par exemple, je sais que faire un truc équivalent en mesh m’aurait pris des centaines d’heures en plus.
Et puis je suis un vieux con, j’aime le BSP >: On a bien vu ce qu’à donné l’introduction des mesh dans la génération précédente : uniformisation du contenu. Surtout quand les amateurs y ont accès.
Sans compter que cela force à se former à deux logiciels : l’éditeur et un soft de modelling. Quand je regarde un de mes derniers travaux par exemple, je sais que faire un truc équivalent en mesh m’aurait pris des centaines d’heures en plus.
Ben voilà, falalit commencer par ça 🙂
Quand tu viens du modeling, réapprendre a utiliser un soft qui est hyper limité et qui en plus plante sans arret (j’ai fais worldcraft, hammer, unreal 4 tous sont instables) tu comprendras qu’on a plus vite fait de tout faire en mesh meme avec des unités prédéfinies (ce qui évite le prb des alignements que tu décris).
Et inversement : si tu t’es fait à un éditeur BSP, apprendre le modelling c’est ‘achement plus gros et plus dur. Surtout si c’est juste pour prototyper ton layout :[
C’est sur on va venir au tout Mesh, mais cracher sur le BSP quand on parle juste du layout de base, je trouve ça absurde.
Oh, quand à l’instabilité de UnrealEd 4, oui, j’ai discuté avec pas mal de gens, et le support du BSP est devenu complètement catastrophique (lightmaps cassés entre les surfaces, instables, limités etc…). A titre de comparaison, les versions précédentes (qui reposaient sur une grosse structure BSp et du mesh par dessus) était parfaitement stables.
Ca m’a jamais vraiment dérangé le BSP (j’ai dû commencer sur worldcraft), mais dès que j’avais un truc à faire autre que des formes basiques, j’ai toujours utilisé un soft 3D, parcequ’effectivement, le BSP, tu bidouilles un peu et tout plante.
Tiens ça me donne envie de relancer le Source SDK tout ça.
Cet article n’aurait-il pas sa place sur la page « jeux » des blogs wefrag ?
Apparemment non.
Merci pour vos commentaires, j’aime bien lire vos retours d’expérience à ce sujet. Avec Hammer, on est un peu obligés de prototyper en BSP. C’est le moteur et la suite d’outils qui veut ça. Si ma mémoire est bonne, je crois que c’est une galère sans nom d’importer des meshes dans le moteur.
Par contre, il est inutile de passer bcp de temps en modélisation externe. Le mesh peut être dégueux et fait à l’arrache, du moment qu’il respecte le gabarit établi, c’est parfait. Faut juste passer un peu de temps sur les collisions.
(Dams je t’ai grillé s’pèce d’aigri…tu dis ça parce que tu peux pas sacquer hourences –remarque moi non plus :D)
Roh, encore la grande mode de dénigrer Hourences. Il a pourtant rien fait de mal le pauvre garçon (mis à part son bouquin). Il même fait pas mal de bien. Il a même gagné le MSUC… Ah non, on me signale que c’est pas l’exemple le plus approprié…
L’avantage indéniable de modéliser *sans* BSP me semble être dans le côté production & productivité, et ça ça intéresse pas mal les studios.
Une fois que tu as assemblé des « blocs » venant de Maya, tu as déjà *factorisé* les éléments de ta map. Une fois qu’il faut produire les morceaux, c’est déjà presque pré-découpé. Il reste plus qu’a updater/remplacer.
De plus, tu peux réutiliser des morceaux des prods précédentes pour démarrer plus vite. Au bout d’un moment, tu n’as plus besoin de beaucoup de nouveaux blocs pour prototyper.
Un autre avantage hyper important que les « 100% artistes » sous-estiment, c’est l’utilité des blocs pré-fabriqués pour les programmeurs. C’est hyper utile de designer le niveau en ayant sous la main le bon bloc qui va bien qui a la bonne largeur de porte, ou la bonne pente d’escalier, le bon « trou » qui passe juste avec un double-saut, etc… Ces éléments permettent de prototyper aussi des éléments de gameplay réutilisables et cohérents… Combien de fois je vois dans les jeux un saut ou je crois que je peux sauter, mais non il fait 10cm de + que celui d’a coté et ça passe pas !
Pour les collisions, la version la plus simple est qu’elles soient dans les « blocs ». Après, au cas par cas, on peut optimiser (remplacer 10 boites de mur de 1m par 1 boite de 10m par ex).
Donc une solution qui semble sympa:
1-(éventuellement) Avoir un éditeur de heightmap pour créer la base du terrain, car c’est pas facile à faire avec des blocs
2-Prototyper avec des « legos » (des gros blocs de la taille d’objets ou de buildings (a) aux petits style parpaing que l’on peut assembler pour faire les formes qu’on veut (b)) + des blocs « spécial gameplay »
3-Itérer pour avoir un level bien cool
4-Remplacer les blocs de design par des « vrais blocs ». Si les blocs de design ont été bien conçus (type a), on fait un remplacement 1 pour 1. Sinon, pour les assemblages cahotiques (type b) on remplace par d’autres blocs. Et voila !
Avec le temps et l’expérience, les blocs de (4) et de (2) vont se ressembler de plus en plus, et on peut torcher des niveaux hyper rapidement !
Pour l’import direct de .MAX : oubliez, c’est un format proprio (de merde). En gros problème avec ce format c’est que les données pour créer le mesh sont stockés sous forme d’itération, les itération contiennent données des petits plugins que les artistes utilisent. Du coup pour charger un .MAX tu es :
* obligé de supporté l’archi de .MAX et être capable de charger tout les plugins que l’artiste a utilisé.
* aplatir a chaque sauvegarde la scène pour ne plus avoir de « plugin » dans la liste d’itération.
Discreet (après 11 versions toujours pas capable d’avoir un soft stable), dans sa grande gentillesse, a release une lib « MAX reader » en 2003 (lol), qui est capable de charger le minimum syndical (mesh, matériel, etc.).
Bien sure on n’a pas la source, donc ca sert a rien.
Donc tant que 3ds ne change pas le format, ca restera un doux rêve.
Pour les néophites comme moi, l’article est assez technique. Est-ce que quelqu’un aurait un article théorique avec des exemples sur le comment faire une map avec les bsp par exemple.
le_poulet : Faire une map en BSP, c’est ajouter de gros blocs de matière pour faire tes murs, tes sols, tes plafonds etc. Quand tu veux faire quelque chose d’assez complexe, genre un arbre ou un rocher, en BSP, il faut découper ça dans tous les sens, essayer de le lisser comme tu peux, et aligner les textures face par face.
L’autre solution, c’est les mesh : tu fais ta map polygone par polygone dans Max ou Maya, tu créé une texture sur mesure et tu déplie les polys dessus. Le ésultat est nikel.
Le BSP, c’est ce que tu vois dans les jeux jusqu’en 2002 à peu près. Quake, Quake 2, Quake 3, Unreal, UT, tout ça, c’est du BSP. A partir de 2002, on a les static mesh sous Unreal, mais on utilise encore beaucoup de BSP (pour des grands volumes qu’on habille ensuite en détail avec des mesh). Dans le Next-Gen, les moteur supportent encore le BSP, sauf que ça n’a pas évolué depuis presque dix ans, alors que les mesh, tout le monde les optimise depuis leur apparition. On se retrouve avec des éditeurs dans lesquels on se contente d’importer des mesh faits sous maya, et l’éditeur n’est plus en fait utilise que pour faire la pathing des bots et calculer l’éclairage.
A noter que Source est probablement le dernier moteur actuel à utiliser autant de BSP.
gruiiik : Je ne suis pas très exactement rompu aux logiciels de modé, mais je pense qu’il doit surement être possible d’automatiser l’exportation dans un format bien précis via un raccourci clavier (au hasard, en ASE) ? Il ne « resterait » (lol) alors qu’à créer un plugin d’auto-import côté moteur qui vérifie à intervalles fixes si un ou plusieurs .ASE ont été modifiés pour les réimporter dans le jeu automatiquement.
il doit surement être possible d’automatiser l’exportation dans un format bien précis via un raccourci clavier (au hasard, en ASE)
Sous maya on peut le faire avec un peu de scripting. Mais comme tu le dis, comme toujours le bas blesse du coté du dev qui utilise des outils de merde (crytek tente de changer ça avec un toolset vachement plus interactif, mais c’est pas encore tout a fait ça).
Hellkeeper: Merci pour ces précisions. J’avais tenté à l’époque de mapper une peu pour Q3 et j’en avais bien chié pour les formes complexes effectivement. Donc en gros, la théorie pour mapper en bsp, c’est de faire les gros volume avec des formes cubiques et de faire les détails en mesh?
Aujourd’hui, la théorie c’est de faire un niveau uniquement avec des mesh (UT3, Stalker, Crysis).
A la génération précédente, c’était de faire de gros volumes cubiques en BSP et de les habiller en mesh (pense DOOM 3, UT2004).
Quake 3, UT99, Deus Ex, Half-Life et autre, on avait que du BSP. C’est à dire que tu mappait tout en gros blocs, et que pour faire des petits détails, il fallait passer du temps, notamment niveau alignement des textures et tout ça. En plus, les moteurs étaient moins puissants, donc les polygones devaient être plus économisés.
Après, entre les mains de mappers qui savent ce qu’ils veulent, le BSP est tout aussi facile à utiliser que les mesh, et on peut le faire on the fly sans faire des imports/exports à tout bout de champ. Si aujourd’hui on se dirige de plus en plus vers le mesh, c’est parce que pouvoir texturer sur mesure chaque mesh, c’est quand même mieux (pas de tiling de textures), et que l’artiste peut faire directement son oeuvre sans devoir l’adapter au BSP du designer proprement dit (celui qui fait le plan, étudie le placement des items, etc…)
à les lires il n’y a que des éditeurs avec bsp =) Sans vouloir lancer de troll gratuit, comment auraient-ils fait pour mario galaxy? :p
Au delà des aspects techniques, ce n’est pas un débat sur la répartition des rôles entre mappers (BSP) et modellers (mesh) ?
(c’est peut-être une connerie ou une évidence, parce que le seul éditeur que j’ai connu c’est bsp -oui c’est son nom-…)
Bon point Holi 🙂 J’essaie de comprendre comment Nintendo aurait pu prototyper les niveaux de ce jeu sans la gravité multidirectionnelle et…je sêche 😀 J’espère qu’un jour les mecs nous expliqueront comment ils font !
Winston : ben si on part du principe que ces meshes sont très simplifiés (quelques primitives empilées en quelque sorte), un mappeur pourrait très bien sortir son 3DSMax pour les créer. Or, ça s’apparente un peu à sortir l’artillerie lourde pour pas grand chose.
Winston : ben si on part du principe que ces meshes sont très simplifiés (quelques primitives empilées en quelque sorte), un mappeur pourrait très bien sortir son 3DSMax pour les créer. Or, ça s’apparente un peu à sortir l’artillerie lourde pour pas grand chose.
Ah bah oui mais 3ds…
Sinon dans l’idée je trouve pas, il pourrait sortir des meshes très simplifiés ++. Parce qu’on a beau dire, quand on maitrise un package 3d, c’est quand meme bien plus rapide de sortir de la géo (et en plus de la géo plus avancé: plus détaillée tout ça dans le meme laps de temps).
channie: malheureusement ils en ont déjà parlé mais de manière très évasive et à mon avis on aura pas les secrets de cuisine d’aussi tôt :p
Extrait de l’interview:
Koizumi:
Bien sûr que non. Pour ce projet, je me suis mis dans la peau d’un cuisinier. Tout d’abord, j’ai montré la recette à tout le monde en disant : « Je veux préparer ce plat sur Wii. » Mais personne n’arrivait à visualiser le plat fini.
Iwata:
Leur montrer la recette ne suffisait pas pour qu’ils sachent si ce serait bon ou non.
Koizumi:
Pourtant, Miyamoto-san m’a dit que ça avait l’air bon. Mais la plupart des membres de l’équipe m’ont dit qu’ils étaient incapables de cuisiner un plat aussi grandiose. Alors, je me suis dit qu’il fallait un échantillon, pour goûter. J’ai rassemblé quelques membres de l’équipe et, en trois mois environ, nous avons réalisé un prototype. La forme sphérique est facilement associée à une planète, nous l’avons donc placée dans l’espace et y avons ajouté de la gravité. Ce logiciel était la forme primitive de « Super Mario Galaxy » et c’est à partir de là que le développement a vraiment commencé.
http://fr.wii.com/wii/fr_FR/software/iwata_demande_super_mario_galaxy_-_volume_1_1820.html
Ca fera peut être pas avancer énormément le débat, mais en tout cas CryEngine régle à la foi les problemes de compil et d’update de mesh: ses BSP n’ont pas besoin d’être buildés et ce manipulent en temps réel, les mesh s’update en 1 clic dans max, 1 dans l’éditeur. Très pratique tout ca, en revanche ya de gros défauts, comme l’absence de grille locale, du coup c’est crado pour aligner les mesh sur des axis non perpendiculaires…
Je pense que la « meilleur » technique dépend non seulement du type de jeu à prototyper, mais aussi du moteur utilisé et de la méthode avec laquelle le designer est le plus à l’aise.
Perso, je trouve les bsp très pratiques et rapides, mais les briques sont moins prise de tête et plus clean en général.