SugaR

Un peu tard sur la conversation, par contre pour l'écran je confirme vivement @Nicolas Caplat. Perso j'ai l'équivalent chez Samsung (dalle VA pour le coup au lieu d'IPS) et pareil, je ne reviendrait pas en arrière. Le seul petit default que j'y trouve, c'est le manque de hauteur finalement

Je regarde ca EDIT: @archimi essaie de remplacer "removeRollout SphereListerRollout SphereListerFloater" par "removeRollout ::SphereListerRollout SphereListerFloater" dans la fonction "updateSphereListerRollout" (ligne 14). Les "::" devant une variable la force en global. Ce qui est étrange c'est que elle est déjà censé l'être (ce qui ce vérifie en tapant "SphereListerFloater" dans le listener en exécutant le script au démarrage de max, ce qui retourne bien le rollout, donc c'est forcement une globale). Dans tous les cas ca ne change rien hormis que ca doit forcer maxscript a chercher aussi dans les variables globales

A la rigueur visual maxscript ne te force pas a coder un rollout juste avec des strings

Hello @archimi. Projet très sympa, j'avais jamais trop regardé le rolloutCreator perso, je trouve que ca pond vite du code assez pénible a gérer. Du coup ca m'a quand même motivé a essayer de faire quelque chose en partant de ce que tu as fait. Pour le coup c'est plus un test / exemple qu'autre chose puisque ca permet juste de gérer des sphères. Je le met ici si ca t'intéresse. Par rapport a ton script, j'ai enlevé la plupart des variables globales (il n'en reste plus que deux) et la liste est entièrement dynamique donc il n'y a normalement aucun besoin de rafraichir la liste manuellement (en gros, n'importe quelque changement dans la scène qui est exposé dans la liste met automatiquement la liste a jour). Si jamais tu es intéressé par le code et que tu veux en discuter, n'hésite pas à demander (plus sur discord qu'ici mais comme tu veux ). rol_creator_06.ms

Après une eternité sans etre venus ici, je vois que ca parle maxscript, ca m'intéresse Jamais lus ce bouquin donc je ne peux pas particulièrement en parler. Mais pour ce qui est du commentaire, que ce soit vieux, pas grand chose à dire. En revanche, assumer que l'utilisateur va devoir aller lire l'aide de maxscript, à mon avis c'est très bien. La réalité c'est que même en ayant fais du maxscript depuis maintenant 10ans, je passe toujours ma vie à lire la documentation maxscript. @Nicolas Caplat pourras largement témoigner qu'il y'a a bien souvent des précisions particulièrement utile dedans si on prend le temps de la lire correctement . Donc prendre ce reflexe dès le début me parait plus que nécessaire. Merci ? au même titre que à @Nicolas Caplat, je suis toujours prêt à aider (pas ici vu que je ne viens jamais, mais discord ou autre sans soucis). Et pour te mettre au script, le plus simple de toute façon c'est de démarrer avec un tout petit truc, à grand coup de macrolistener. Le code produit n'est pas fou, mais largement suffisant pour démarrer. En gros, MaxPlus était une vraie API python mais elle à été supprimée dans les dernière versions de 3dsMax. Pymxs n'est qu'un simple wraper de maxscript, mais à l'air relativement complet actuellement. Du coup, il me semble tout de même préférable de démarrer avec maxscript, le language étant plus simple que python mais offre tout de même largement de quoi faire (sauf question UI). Ensuite, passer de maxscript à python est relativement facile, puisque que pymxs c'est littéralement maxscript en python, mais il faut connaitre python bien sur Et pour le coup, 3dsmax est passé sur python 3.9 pour la 2023 je crois (ou ca sera la 2024, pas sur).

Je viens de tomber sur un article comparant les perfs en rendus sous blender 2.9. Ca donne je trouve une bonne indication de la situation Intel vs AMD: https://www.phoronix.com/scan.php?page=article&item=blender-290-performance&num=5

A mon avis, au lieu d'Intel, pars sur de l'AMD, meilleurs perfs pour prix inférieur (surtout dans le rendering). Au passage les nouvelles gammes desktop d'AMD sont pour cette fin d'année si tu peux tenir jusque la ? Sinon le Ryzen 3900X est très bien Ensuite question carte graphique, pars sur de la geforce à mon avis, les quadro sont inutiles hormis cas spécifique (que je ne peux te renseigner), mais habituellement si c'est juste pour 3ds max, un geforce devrait faire l'affaire et le rapport prix/perfs est largement meilleurs pour les geforce que les quadro. Au passage, la nouvelle gamme nvidia (RTX 30XX) va sortir très prochainement (l'annonce à eu lieu il y a peu). Et les moteurs de rendus GPU full ray-tracing arrivent (je pense à RedShift principalement), qui vont bien changer la donne, plus nécessairement besoin d'un gros CPU ou d'une render farm..., juste d'une grosse carte graphique plutôt). Dernière demo en date de Redshift: Tu peux sans problème partir sur un SSD pour le système et un HDD pour les données. Pour la tailles des deux, ça reste spécifique à toi... Si tu es short question budget, je ne suis toujours pas convaincu que 64Go de Ram soit utile à tout le monde, ça dépend surtout de ton utilisation. Dans tous les cas, tu peux tout à fait envisager de partir sur 2x16Go de RAM dans un premier temps, puis de rajouter 2x16Go plus tard si tu en as besoin

Quixel mixer, gratuit Je te confirme, le bas des galets est bien déformé en même temps que l'eau ^^. Mais c'est clairement très propre oui

A ma connaissance, les actuels GPU arrivent à peine à saturer un port PCI-E 3.0 en 8x, parler d'un quelconque avantage du PCI-E 4.0 en 16x me parait improbable, même si je peux me tromper bien sur. Le PCI-E 4.0 étant finalement surtout fait pour le stockage via SSD nvme et les gros GPU de calcul type nvidia tesla. Au passage, les nouvelles nvidia (RTX 3XXX) sont pour très bientôt (annonce vers fin aout / début septembre de tête). A voir aussi les futurs GPUs AMD en RDNA 2, même si j'aurais toujours tendance à privilégier nvidia, principalement pour cuda et le raytracing materiel. En tout cas les GPUs vont se renouveler chez nvidia et amd cette année donc autant attendre encore un peu selon moi. Sinon pour le CPU, un threadripper me parait effectivement nickel A voir pour la RAM, mais 2666Mhz, ca me parait faiblard (en tout cas, il est recommandé du 3200 voire 3600 pour les Ryzen, donc ca doit se valoir avec un threadripper) et l'architecture zen3 profite plutot pas mal des hautes fréquences et bas timing sur la RAM (dans la mesure du raisonnable bien sur) et voire aussi pour avoir une synchro avec l'infinity fabric (controleur mémoire des cpu amd actuellement), en gros pour de la ram en 3600Mhz, l'infinity fabric doit être à 1800 Mhz pour que le tout soit synchrone. Sinon cela rajoute une legere latence, réduisant de fait l'intéret de la monté en fréquence sur la RAM

@Nicolas Caplat A première vue c'est un poil plus complexe que ça pour myObjs = selection as array Le problème ici, c'est que tu veux choper la selection actuelle, hors la selection actuelle doit être le contrôler principal et pas les objets à modifier, à cause de: CustAttributes.add $.modifiers[1] SPRING_Control_Custom_attribute" donc ce qu'il va se passer ici, c'est que tu va stocker dans ton array 'myObjs' l'objet sur lequel tu ajoutes le custom attrib il faut donc changer l'une des deux lignes de codes dans ce cas, soit hard coder la manière dont tu récupères 'myObjs' (en utilisant par exemple les noms des objets), soit hard coder l'objet sur lequel tu veux ajouter le custom attrib. Et à mon avis aucune des deux méthodes d'ailleurs n'est à conseiller, le hard coding étant à bannir . Imagine un simple changement de nom, et faut reprendre le script, la misère... Pour ce genre de cas, ce qu'il vaut mieux faire à mon avis, c'est avoir dans la def du custom attrib une partie parameters avec soit un '#nodeTab' soit un '#maxObjectTab' SPRING_Control_Custom_attribute = attributes custom_Attributes ( parameters SpringControlParms rollout:SpringControlRollout ( nodeArray type:#nodeTab tabSizeVariable:true tabSize:0 ) rollout SpringControlRollout "Spring Control" (...) ) ou encore mieux en utilisant des weaks references SPRING_Control_Custom_attribute = attributes custom_Attributes ( parameters SpringControlParms rollout:SpringControlRollout ( weakRefArray type:#maxObjectTab tabSizeVariable:true tabSize:0 ) rollout SpringControlRollout "Spring Control" (...) ) et avoir par exemple un bouton en plus dans le rollout pour selectionner et stocker les objets à modifier derrière. Et ajouter au passage les deux paramètre type float pour "Mass" et "Drag", ce qui permet au passage d'accéder à tout ça par d'autre moyen, puisque ca devient de vrai parametre du contrôleur ($.modifiers[1].custom_Attributes.Mass via mxs par exemple), entre autres avantages (retenir la valeur actuelle par exemple). Certes ca complexifie le tout, mais bon... J'ai proposé à @Balboza qu'on regarde ça ensemble quand il aura le temps, je te transmettrais le tout si tu es intéressé

Quelle version de 3ds max ?

Si je comprend bien, à chaque fois que tu sélectionnes ton spring, la valeur affiché du spinner dans le control panel est celle par default ? Si c'est le cas et de tête (je n'ai pas touché à tout ça depuis, pfioouuuu... ? ), @Nicolas Caplat est sur la bonne voie, il faut que tu rajoutes un truc dans ce genre dans la définition de ton rollout: rollout SpringControlRollout "Spring Control" ( spinner spn_Mass "Height" range:[0,2000,500] type:#float spinner spn_Drag "Height" range:[0,10,2] type:#float on SpringControlRollout open do ( spn_Mass.value = $.position.controller.getMass -- je ne connais pas la syntaxe exacte pour ce contrôleur, à vérifier spn_Drag .value = $.position.controller.getDrag -- je ne connais pas la syntaxe exacte pour ce contrôleur, à vérifier ) on spn_Mass changed val do $.position.controller.setMass val on spn_Drag changed val do $.position.controller.setDrag val ) Au passage, je te conseille de lire la doc sur Scripted Plugins ansi que sur Scripted Utilities and Rollouts d'ailleurs, je constate que tu n'a pas de parameters dans ton custom attributes, c'est plutôt important car c'est ce qui permet de rajouter tes propres parametres à un objet, quelque chose du genre: $.myParameter01 $.myParameter02 etc..., le tout link justement avec l'ui dans le rollout, et qui te permet de modifier ces valeurs ailleurs. Pas forcement necessaire en fonction de ce que tu veux faire mais généralement utile. Sinon je te constellerais aussi peut-être de démarrer par quelque chose de plus simple que les custom attributes et les animations controler, qui sont de réel plaie a dev... N'hésite pas à partager une simple scène de test avec les scripts en question si tu veux que je regarde ça plus en détails

Ca à toujours été le cas, on a toujours eu des démos technique de fou mais aucun jeu n'est jamais parvenus à ce niveau. J'ai même en tête certaine démo technique sortis il y a quasiment 10 ans et qui sont toujours loin devant les jeux les plus poussés actuellement. Au passage, je dirais même que le "grand public" (donc corrige moi si je me trompe ici, mais aka les "gamers") ne sont pas franchement la cible, puisque ce ne sont pas eux qui utilisent les moteurs de jeu. En revanche, et c'est quelque chose qu'il est bien souligné dans la démo d'ailleurs, mais nanite par exemple est là, manifestement fonctionnel et va réellement permettre un gain en productivité énorme. Je ne parle même pas forcement de charger directement des scans 3D (je comprends pas, mon projet fait 1.5 Terabytes... ), mais la possibilité de charger des modèles nettement moins optimisés pour du temps réel ET ne pas à avoir à faire de LOD est quelque chose d'excellent (je me suis assez arraché la tête sur cette question pour en parler xD). Qui plus est, ça ouvre aussi à nettement plus d'industrie que le jeux vidéos, typiquement l'archviz ou le cinema, qui pour certain n'auront pas de soucis à avoir des projets excessivement massif, sachant que derrière il sera rendu uniquement des images et vidéos... Au passage, je trouve l'article de Lidia quelque peu acerbe sur certain point. Alors oui nvidia avait par exemple fait une demo technique similaire (celle des astéroids, que j'avais vu d'ailleurs et qui m'avait bluffé), mais la dernière fois que j'ai vérifié, nvidia ne produit pas de moteur de jeux, juste de la R&D (qui sert principalement à vendre son propre matos, ne l'oublions pas). Epic n'a certainement pas indiqué avoir tout fait lui-même, mais il y a tout de même une énorme différence entre une "simple" démo technique créé et optimisé dans un seul et unique but, et un moteur de jeux fonctionnel qui utilise ladite tech. Il en vas de même pour le ray-tracing en temps réel et tout plein d'autre chose. Faisant du temps-réel à titre pro depuis 10 ans maintenant, je suis clairement ravis de voir ça arriver dans un soft de production et plus juste dans des démo technique sortis de chez nvidia, peut m'importe qui à fait le taf derrière, c'est juste excellent. Sans oublié que l'UE4 et le 5 sont désormais gratuit (sans parlé de megascan et autre) tant qu'on à pas généré un million de $ sur le projet. Et ca, ca met une toute aussi belle claque que la démo

Je sais même plus si j'ai envie de rire ou pleurer en voyant ça...

Bah il suffit juste de faire une branche blender qui soit un clone de 3ds max et de cloner tous les scripts et plugins, easy ?