Jump to content

Nicolas Caplat

Moderators
  • Content Count

    4692
  • Joined

  • Last visited

  • Days Won

    164

Nicolas Caplat last won the day on June 17

Nicolas Caplat had the most liked content!

1 Follower

About Nicolas Caplat

  • Rank
    Membre Senior
  • Birthday 12/19/1976

Profile Information

  • Gender
    Male
  • Location
    Paris, France

Recent Profile Visitors

2745 profile views
  1. L'un de mes contacts cherche activement deux designers 3d (junior / senior) sur 3dsmax & VRay avec une expertise en retail et si possible une bonne connaissance du secteur du luxe. Les deux postes sont à pourvoir en CDI. Me contacter en PM si intéressé. Bonne soirée, Merci
  2. Ok ! Et tes settings ? GI en IM + LC, BF + LC ? Par curiosité
  3. Tu peux détailler un peu please, @Miaz3 ?
  4. Et aussi: Common Tips RailClone is able to create complex parametric structures by cloning and adapting mesh objects (called Segments) along one or more reference objects (such as spline). According to the spline's direction, elevation or other parameters, some Segments must be deformed and other simply cloned. In the supported engines, it's possible to render thousands of instances of the same object using minimal resources. RailClone uses this feature, identifying which Segments may be cloned, and creating native render instances of them. This process is automatic and invisible to the user, but you can optimize your renderings by paying attention to the following rules: If you are certain that a type of Segment should never be deformed (such as pillars or joints), turn off 'Bend' in the Segments parameters. The same is applicable for 'Slice'. It is possible to use meshes or proxies as Segments, but it is not necessary to convert high-poly objects to proxies to get better performance. The plugin converts all objects to native render instances internally, so there are no significant differences (on render time and memory used) between using meshes or proxies. Proxies cannot be deformed, so RailClone always creates instances from them, but obviously they cannot be bent or sliced. Some features are not available when using the native render mode: Vertex welding is disabled. Operator->Material and Segment->Deform->Mapping work only with V-Ray. RailClone objects cannot have any modifier applied. You can switch to the standard render mode turning by off Display->Render->Use Instancing Engine. When this is used the plugin creates a single mesh containing all the geometry. In any case, you can use RailClone Tools to generate the instanced geometry manually. This procedure is compatible with all render engines. V-Ray Tips RailClone offers some unique features using this render engine: Improved performance and reduced memory footprint for very large objects, generating the geometry dynamically inside the camera frustrum. We have included a debug mode, to identify visually from the render what segments are instanced. How to use it: Go to Display>Debug Mode and turn on Show Up Instances The default material ID is set to 100, leave this as it is or if you prefer, set to another number. Apply a multi-sub material that includes a material set to the ID specified in the previous step. All instanced geometry will be allocated the ID specified above and will render with the associated material.
  5. VRay si je me souviens bien ? quelle version ? quelle version de 3dsmax ? c'est bien de préciser au moins ça quand tu soumets un souci. Quelle est ta config, notamment de combien de RAM disposes-tu ? Tu peux poster des screenshots de tes settings de rendu ? IrrMap / LC, BF / LC ... ? As-tu essayé d'appliquer un matériau basique pour tester un rendu en Material Override, histoire de vérifier ? As-tu sollicité le support iToo ? Est-ce que tu aimes les films de gladiateurs ? 😄
  6. Pour t'expliquer rapidement: - un seul Manager sur tout le réseau, idéalement sur machine qui ne calcule pas, meme une machine peu puissante. Cette machine peut d'ailleurs agir également comme serveur de licences flottantes (VRay, iToo RC & FPP, etc.) -une appli Server sur chaque node et station. J'écris aussi les stations de travail, parce qu'en partant le soir, il suffit de lancer l'appli pour que les stations rejoignent les machines dispo auprès du Manager, pour participer aux calculs prévus dans la file d'attente. - le Monitor par contre, tu le lances quand tu en as besoin. Comme écrit plus haut, plusieurs instances de Monitor peuvent etre lancées sur différentes machines du réseau, mais une seule aura la main sur l'activité du Manager (gérer les priorités des jobs, en mettre en pause, les assigner à des Servers en particulier, etc etc). Le Monitor ne participe pas aux calculs au sens strict, c'est "juste" une appli de controle. En poussant le vice, on pourrait dire qu'une fois le Manager en route et les applis Server lancées sur les machines, le Monitor n'est pas utile. OK j'exagère, mais c'est pour que tu comprennes le role de chacun. Enfin, on peut si besoin combiner BB et le DR de VRay ou Corona, donc utiliser à la fois les applis Servers (BB) et Spawner (VRay) / DRServer (Corona). Je m'explique: 1) Disons que tu as ta station WS et tes rendernodes RN1 RN2 RN3 RN4 ; 2) Depuis ta station, tu actives le DR dans VRay / Corona, et tu choisis RN2 RN3 RN4 et WS comme spawners ; 3) Tu lances le rendu BB depuis ta station, MAIS au lieu de soumettre ton job avec l'option All Servers, tu passes en Selected Servers, et tu sélectionnes RN1 ; 4) Répètes l'étape 3 autant de fois que tu veux balancer de jobs différents de scène différentes (je ne détaille pas le cas où tu soumettrais en batch plusieurs caméras par exemple) ; 5) Tu as à présent une file d'attente de tes jobs dans le Manager, que tu peux checker / réorganiser / mettre en pause avec le Monitor ; 6) Chaque job ne sera soumis qu'à la RN1, qui agit comme master du DR, et qui invoquera les RN2 RN3 RN4 comme nodes pour prendre part aux rendus ; 7) Quand tu as fini de bosser sur ta station WS, tu lances le Spawner (VRay) / DRServer (Corona) de ta machine WS, qui va rejoindre les calculs en tant que node. Aucun problème avec les plugins iToo. En résumé, avec BB, tu peux: - soit calculer plusieurs images en meme temps, et donc chaque node calcule une seule image, mais elles mettent chaque fois plus de temps à sortir ; - soit calculer une image à la fois, avec plusieurs nodes qui calculent sur une image, mais qui sortira beaucoup rapidement. Pratique si tu es en plein rush, et que tu veux commencer la post-prod au fur et à mesure que les images sortent. Voilà voilà, j'espère que c'est clair, je suis un peu claqué, écrit un peu speed Bye.
  7. Oui, BB peut se révéler utile meme avec une seule machine, il agit alors comme un simple gestionnaire de file d'attente. En revanche, avoir un parc de machines, et lancer BB en local sur chaque (Manager + Server), ça n'a aucun sens ... pour t'expliquer rapidement: - un seul Manager sur tout le réseau, idéalement sur machine qui ne calcule pas, meme une machine peu puissante. Cette machine peut d'ailleurs agir également comme serveur de licences flottantes (VRay, iToo RC & FPP, etc.) -une appli Server sur chaque node et station. J'écris aussi les stations de travail, parce qu'en partant le soir, il suffit de lancer l'appli pour que les stations rejoignent les machines dispo auprès du Manager, pour participer aux calculs prévus dans la file d'attente. - le Monitor par contre, tu le lances quand tu en as besoin. Comme écrit plus haut, plusieurs instances de Monitor peuvent etre lancées sur différentes machines du réseau, mais une seule aura la main sur l'activité du Manager (gérer les priorités des jobs, en mettre en pause, les assigner à des Servers en particulier, etc etc). Le Monitor ne participe pas aux calculs au sens strict, c'est "juste" une appli de controle. En poussant le vice, on pourrait dire qu'une fois le Manager en route et les applis Server lancées sur les machines, le Monitor n'est pas utile. OK j'exagère, mais c'est pour que tu comprennes le role de chacun. Enfin, on peut si besoin combiner BB et le DR de VRay ou Corona, donc utiliser à la fois les applis Servers (BB) et Spawner (VRay) / DRServer (Corona). Je m'explique: 1) Disons que tu as ta station WS et tes rendernodes RN1 RN2 RN3 RN4 ; 2) Depuis ta station, tu actives le DR dans VRay / Corona, et tu choisis RN2 RN3 RN4 et WS comme spawners ; 3) Tu lances le rendu BB depuis ta station, MAIS au lieu de soumettre ton job avec l'option All Servers, tu passes en Selected Servers, et tu sélectionnes RN1 ; 4) Répètes l'étape 3 autant de fois que tu veux balancer de jobs différents de scène différentes (je ne détaille pas le cas où tu soumettrais en batch plusieurs caméras par exemple) ; 5) Tu as à présent une file d'attente de tes jobs dans le Manager, que tu peux checker / réorganiser / mettre en pause avec le Monitor ; 6) Chaque job ne sera soumis qu'à la RN1, qui agit comme master du DR, et qui invoquera les RN2 RN3 RN4 comme nodes pour prendre part aux rendus ; 7) Quand tu as fini de bosser sur ta station WS, tu lances le Spawner (VRay) / DRServer (Corona) de ta machine WS, qui va rejoindre les calculs en tant que node. Aucun problème avec les plugins iToo. En résumé, avec BB, tu peux: - soit calculer plusieurs images en meme temps, et donc chaque node calcule une seule image, mais elles mettent chaque fois plus de temps à sortir ; - soit calculer une image à la fois, avec plusieurs nodes qui calculent sur une image, mais qui sortira beaucoup rapidement. Pratique si tu es en plein rush, et que tu veux commencer la post-prod au fur et à mesure que les images sortent. Voilà voilà, j'espère que c'est clair, je suis un peu claqué, écrit un peu speed Bye.
  8. Ménage-toi, tu vas y laisser des plumes !!
  9. Quand je lis ça, je fais des bonds sur mon fauteuil Avec BB, sauf cas très particuliers, il y a UN SEUL Manager sur tout le réseau (de préférence une machine qui ne calcule pas, mais ce n'est pas trop grave), et un Server par machine. Point barre. Pour l'appli Monitor, c'est un peu différent, mais tu ne peux en avoir qu'un seul qui a la main, les autres instances de l'appli étant en lecture seule.
  10. Hmm étrange façon de faire en effet. Tu ne peux pas te trouver 30-45 minutes pour que je t'explique tout ça et que je fasse ton setup à distance ? Skype, TeamViewer, peu importe. Mais "perdre" 30 minutes pour le temps que tu peux gagner avec un setup correct, la question se pose, non ? bref, je te propose un coup de main, je ne vais pas te forcer non plus Dans mon ancienne boite, on était gros consommateurs de BB, et on avait aussi du RC et du FPP. J'avais fait tout le setup avec une dizaine de machines, avec dossier plugins centralisé pour les "petits" plugins (simples .dlm ou .dlo par exemple), tout fonctionnait nickel ... et si j'avais besoin de spawner pour un simple rendu distribué depuis ma station de travail, aucun problème avec RC ou FPP. Up to you.
  11. Hello, Qu'est-ce qui n'est pas clair pour toi ? De mon coté, je ne comprends pas "j'utilise le rendu via Backburner mais individuellement sur chaque machine" ... tu peux détailler ta façon de procéder ? Si tu veux, on peut faire ça via TeamViewer ? juste une histoire de fuseau horaire à gérer mais ça devrait le faire. Tu as quoi, 6-7 heures en moins qu'en France, c'est ça ?
  12. https://www.stateofartacademy.com/en/corona-4-caustics-tutorial/
×
×
  • Create New...