Maya

A tálkát én is észrevettem már. Igen a textúra még hagy kivetnivalót, de még jócskán modellezek. A szoba túlfele még kész sincs. Ha meglesz a teljes szoba majd nekiállok normálisan textúrázni, addig csak feldobok valami alapot. A végén majd csinálok egy kameraforgásos videó rendert, ami a teljes szobát megmutatja.

Leszedtem egy Solidangle féle Arnoldot kipróbálásra, és szerintem nagyon jó. Egyszerû, és gyors. Nem kell annyit molyolni, mint a mentaray-jel. Majd még próbálgatom, csak akkor most megint minden materialt át kell rakni, mert a miát ugye nem eszi meg. De elõszedem egy régi cuccom, azt átmaterialozom rá teljesen.

Jelenleg 8.4.4 a Shadow Depth. a Render settingsben. Konkrétan most nem tudom hova, de az alpha két helyre is be van kötve. Az egyik a vetett árnyék miatt, a másik meg a láthatóság miatt. A lényeg, hogy ha csak az egyikhez tettem, akkor plane árnyék volt, ha meg csak a másikhoz, akkor meg plane levelek. A jóég tudja, kötögettem mindenhova, amíg nem jött össze így.. De most én is utánanéztem és valószínûleg tényleg az a cutout_opacity lesz. Elvileg transparency, meg diffuse_alpha, ahova kötöttem, de nem biztos.

Kösz a tippeket. Ahogy hazaérek, megnézem egybõl, és kipróbálok mindent, aztán majd, mondom mi van.

szerintem ez valami cutout opacity probléma lesz.
vagy transparency-t használsz a levelek alphájához?
ray depth mindenképp vedd magasabbra, az is lehet gond, ill van még 1 ötletem.
reflection ray depth és a shadow ray depth legyen magasabb, valamint a lámpádnál a shadownál a depth részt szintén növeld meg. lehet az a baj, hogy tükrözõdik a hátsó felén valami, ami árnyékba kéne hogy legyen, de nincsen, mert nem elég a shadow depth. ja igen és mia materiálnál reflection on inside is legyen (most nem tudom, hogy pipa be vagy ki, az a lényeg, hogy mindkét oldal tükrözõdjön)

és a tálkát emeld meg egy kicsit, mert belevág a fába😄 meg kerekítsd le az éleket meg ne ismétlõdjön ennyire nyilvánvalóan a textúra és a többi és a többi.

A Raytrace Shadows attributes-en belül (a fényen) a Ray Depth Limit-et növelve mi történik?

Amúgymeg dobd fel a scene-t is, az sokat segítene.

Még látszik az oldal alján az elõzõ képen(#31400), ahol még csak blinnek voltak, hogy ott nincs ilyen probléma. Csak miután átraktam mindegyiket, mia_materialra. A levelek vetett árnyéka jó, csak a bútoron levõ tûnt el. Ja meg ami az ablakon kívül van fa, azzal ugyanez a probléma a leveleknél.

Hehe, gondoltam, hogy ez lesz. De itt a kép.

Szóval olyan világos, ahol nem kellene annak lennie. Oda vetülne a bútor árnyéka, csak az nincs ott.
Minden textúra a képen map. Illetve amiken nincs azok gamma korrektált ramp textúrák..

hát én ezt most komolyan nem értem, elég kurtán fogalmaztad meg, vagy csak nekem az, de én megvárnám a képet...😄 az többet mond ezer szónál

Volna egy kis gondom a mia-x materiallal. Konkrétan az, hogy van egyb plane felület, amin egy virág levele van textúrának. Valahogy rajta van és van neki egy alpha rétege, ami az átlátszóság ugye. Kész a render, tökéletesen jó. A levél az levél. Árnyékot is úgy vet, mint egy levél, tehát a fény megtörik ott, ahol nem látszik át. Eddig jó. Ami nem jó az az, hogy a planek azon részen, ahol átlátszó lenne nincs árnyék sehol. Ha most nálam lenne a kép minden tiszta lenne, de a lényeg ez:

Van egy bútor, oldalt ablakkal, amin süt a nap. Ha csak ezt renderelem, akkor a bútor oldala árnyékot vet a polc belsejére, ott sötétebb. Ha oda teszem a virágot, akkor a bútor részei, ahol sötétebbnek kellene legyen, nem az, hanem világos, vagyis a bútor árnyéka nem érvényesül. És csakis ott a levél plane átlátszó részeinél. Pénteken, ha jövök, majd felteszem a képet is, hogy lássátok is.

Nagy nehezen megoldottam. Az FCheck-el újra lehetett generálni.

Rossz beállítást használtál a filenevek generálásánál. A total commandernek van jó rename tool-ja, azt eséllyel lehet használni.

Legközelebb meg figyelj arra, hogy a legjobban használható mód a filenev.frame.extension (output.0015.iff pl) . És persze a paddingot se felejtsd el legalább 4-re beállítani, vagy a legtöbb progi hisztizni fog. Utolsó tanácsként, ha már nem exr-ezel, akkor érdemesebb lehet tif-et használni az iff helyett, azt több progi megeszi.

Nem tudom, annyira nem értek hozzá. Viszont én néztem el, nem 3800 frames volt, hanem 5700 és akkor is végzett. A problémám most az, hogy akármi.iff.4 formátumba mentette el és így nem igazán akarja elfogadni egyik konvertálóprogram se.

Ha több passot tolsz ki akkor egy framehez nem csak egy file lesz. Miért nem exr? 😊

Sziasztok! Az lenne a kérdésem, hogy maya -iff fájl hány frame-t tartalmaz, mert elkezdtem renderelni egy 3800 frames videót (még tegnap 😄) és lassan 4300 létrehozott .iff fájl lesz és még mindig nincs vége. Meddig kell még körülbelül várnom? Köszi!

Koszi a valaszt, de azota mar az egesz project torolve lett (win ujrahuzas miatt) 😊

volt valami ebben a gombában 😊)))))))))

Az árnyék távolságát nem lehet beállítani, de a fény erejét azt igen, illetve hogy szórt legyen vagy éles esetleg ezzel érdemes eljátszani. A sima lámpa vagy spot fénnyel érdemes eljátszadozni annak még állítható az sugara is. Az hogy mi vet árnyékot, és mire, azt is külön lehet szabályozni a megfelelõ beállításokkal. Itt nyilván nagyon fontos hogy ha mayások vagytok, akkor értsétek az adott kezelõfelületen mi mit jelent. Külön a fény egyes beállításainál lehet szabályozni azt is hogy a fény útjába kerülõ test ne vessen árnyékot. Sattara sattara 😊

Ha hálót szeretnél azt textúrával szokták megoldani. Alfa réteggel ami átlátszó marad az áttetszõ részeken. Belenderes vagyok, csak ép erre jártam és olvasgattam. Belehet a programon belül állítani hogy a textúrát milyen mód használja fel. S így az áttetszõ részeken áthalad a fény ahol meg nem tud azon a részen árnyékot vet a megfelelõ mód a közegre. Üdv

Még az UV-hoz annyi,h régebben RockGennel generált követ akartam UV mappolni UV pluginnal( Unwrella) és kaptam egy nagy f*st. Megcsinálni megcsinálta,kb 3-felé vágta,szépen ki volt pakolva UV editorban,de mikor rátoltam egy checkerboardot,akkor tele volt seammel az egész. Az nagy baj?

Hogyha utána úgyis vmi festõprogiba dobom be és azon festem meg a textúrát és azt teszem rá az UV-ra,akkor is benne marad a seam? Mert végülis UV ki van pakolva, a festõprogi viewportjában meg jól néz ki.

Én megvettem a könyvet, de nem az alapján tanulom a maya-t. Sokkal gyorsabban lehet haladni tutorial video-val. Hamarabb meg lehet érteni. A lynda maya 2013 essentials nagyon jó elindulni.

Az új könyv ugye frissített, meg végülis minden téren van benne plusz, de a régi is jó tanulásra. A neten mondjuk ingyen is van annyi tutor, hogy fel lehet zárkózni velük, tehát nem feltétlenül szükséges a könyv megvétele. Ha hajlandó vagy pénzt kiadni azért, hogy legyen egy magyar nyelvû korrekt összefoglalód (elemi szintû), akkor nyugodtan vedd meg.

Köszönöm szépen!
A DT-t ismerem, köszi....de a másikra rákeresek. Nekem a "Maya, a 3D világa" könyv van meg. Van annyi újdonság az általad írtban, hogy érdemes megvennem szerinted?

Deformációnál általában nem változnak a kapcsolatok az egyes face-k között (nem jut eszembe hirtelen a megfelelõ szó rá), így az nem probléma.

A ptex textúra nem egy sima képfájl, ennél jóval több információt tartalmaz. Meg lehet írni játékokba, nem nagy õrdöngõsség de sok a véletlenszerû lekérdezés benne, sok az extra adat azt pedig a gpu architektúrája nem szereti. (bírja, csak kérdés milyen sebességgel)

Seam-es hbiák a sima textúrázásnál a korábban említett filterezési problémák miatt van, mivel nem csak egy képpont kell hozzá, így olyan pixelek is beleszámolódnak az átlagolásba, amiknek nem kéne (ezért szokták õket túlfesteni pl). PTEX-nél ilyen probléma nincs, mert mindig csak azokról a területekrõl filterezel amire szükség van.

Az UV adatok azok magába a modellt tároló fileba kerülnek mentésre, és az-az adat, ami megmondja, hogy "képfájl melyik része tartozik melyik részhez". Lényegében a modellt alkotó pontokat/felületeket elhelyezi egy 2d-s koordinatá rendszerben, ahova behelyezésre kerül a textúra és így tudja, hogy a modell adott háromszöge pl mely textúra felületet fedi le.

Vannak autómata UV módszerek is, de ezek össze-vissza, vagy facenkénti seameket eredményeznek, amik problémát okozhatnak (pl realtime shadereknél).

A seamek azok az élek ahol kiterítve a vágások futnak. Ha valami 3d-s festõprogramot használsz magán a textúrán ezeknek nem szabadna látszania, de ahogy írtam, más esetekben okozhatnak gondot, ha szem elõtt vannak.

Ptex nagyon jó dolog, habár egy darabig nem lesz használható minden esetben. Sok replikátor alapú módszer pl az UV-kat használja (haj/szõr generálók). Az animáció önmagában nem probléma, a modell deformálódhat. Ami gondot okozhat ptex terén, hogyha valamiért módosítani kell a topológiáját a modellnek.
Játékoknál meg azért nem alkalmazzák, mert nincs hardveres gyorsítás ptexhez.

Na hát ebbõl nem sokat értettem 😄

Lehet el vagyok tájolva, de mondjuk ezt olvasva azt se értem, hogy a kiUVzott modell, az egy KÉPFÁJL,nem? jpg,png v vmi más.

Honnan tudja a program, hogy a képfájl melyik része tartozik melyik részhez?

Pl. Bal alsó sarokban van a lába. Honnan tudja a program, h azt a részt kell a lábához használni nem a közepét,ahol mondjuk a feje van? Sima képfájlba ilyen infók nincsenek eltárolva.

Ezt a fajta módszert meg azért kérdeztem, mert UVzás nélkül gondoltam megoldani dolgokat.


Meg együk fel, hogy a kép amit linkeltél, egy objektum kiterített UV mapja. hogy csinálod azt meg, hogy ha ez majd rá lesz hajtogatva az eredeti modellre, akkor a szélei úgy legyenek kifestve, hogy ne látszódjon, hogy nem passzol - tehát látni egy éles csíkot benne -. Négyzetes alakzatoknál még oké, de ilyen girbe-gurba cuccoknál nem értem a dolgot.

És ha vki az iparban akar elhelyezkedni,ilyen alap dolgokat tudnia kéne. Csak hát az UV-zást mindig is rühelltem, mert értelmét nem látom, fõleg abban a korszakban, amiben már egybõl a modellre is festhetünk,ennek ellenére még mindig kell UVzni. PTEX-szel az a baj, hogy bár jó, de a játékok nem tudják feldolgozni. Állóképre én is Ptexet használnék, mert nincs vele gond, bárki megcsinálja, de mi van ha egyszer majd meg akar mozdulni a ptexes modell? Akkor is mûködik? Miért nem lehet játékokba is és minden más területre, ahol még UV van, implementálni és végleg lecserélni az egész UV dolgot?

A ptexes relációkra kép

Amire te gondolsz azt már megcsinálták, méghozzá a disney a ptex-el. Pont a leírt okok miatt, elkerülni az uv-zást. Elõtte minden facehez külön textúrát használtak, de az túl sok I/O volt, és inkább kitaláltak egy speciális formátumot. Ezzel anno az volt a probléma, hogy nem volt hozzá festõprogram (már nyilván van), és így erre is írtak egy sajátot...

Az elv maga szép és jó, viszont van vele egyetlen probléma a textúrafilterezés. Mikor egy surface point shadingjét számolod, és lekérsz egy textúrát nem csak egyszerûen egy értéket kiolvasol a textúrából (lehet, de az ronda), hanem filterezed a textúrát. Különbözõ értékektõl függõen (dPdx, dPdy - a felületi pont deriváltja a screen koordináták szerint), különbözõ méretû és formájú területen kérdezel le elszórva x pontot (1-32 stb...), és az ott található textúra értékeket átlagolod. Ezzel kombinálva van az, hogy messze lévõ tárgyaknál, vagy az olyanoknál, amik majd merõlegesek a kamerára más mip szintekrõl is kérdezel le (nyersen hangzik, és nem pontosan ez történik, de ez jó áttekintés). A különbözõ mip szintek pedig nem mások mint a textúrának a kisebb méretû verziói a memóriában (ennek elõnye a kevesebb zizi, illetve nem biztos, hogy a maximális felbontású verziót is be kell tölteni, ez iszonyú sokat tud I/O-ban számítani).

Ezeknek a technikáknak a PTEX-el is együtt kell mûködnie, viszont amikor a filterezés sugara túllóg egy adott háromszögen (vagy négyszögen - elsõnek csak négyszögeket támogatott a ptex), akkor a szomszédos primitívrõl is kell textúra adatokat kérdezni, különben tele lesz artifactokkal az egész rendered (vagy nagyon zizis lesz). Ez feltételezi azt, hogy van relációs adat a különbözõ primitívek között (ki-kivel oszt meg egy edge-t), ezt ki kell menteni, le kell kezelni, kevés memóriával eltárolni és gyorsan kezelni. Ha meg subdiveled a mesh-t render time (ami kbra teljesen alap dolog manapság), akkor pedig valahogy úgy okosan letárolni ezt a relációs adatbázist, hogy még mindig gyorsan elérd, de mûködjön rendesen (a menet közben létrejött háromszögeket v négyszögeket megfelelelteni az eredeti mesh-en lévõknek és az alapján kezelni a textúra filterezést).

Röviden ilyen problémákkal nézel szembe ha per face akarsz textúrázni. PTEX-ben ezek többnyire meg vannak oldva, és jól mûködnek. (nyílt forráskódú, bele lehet nézni)

zbrushban úgy hívják ezt a dolgot, hogy puv tiles asszem, de van egy másik ami meg talán huv tiles, nem vagyok a nevekben biztos, az egyik arányosan próbálja a face-eket elosztani a másik csak a dbszám alapján tölti fel a uv space-t. ez a módszer hagyományos textúrát használ, de nyilván így nagyon sok a seam, én nem igen használtam még, static objectekhez nem rossz végülis, de sztem zbrush textúrázásban amúgy sem jó.
másik módszer meg a ptex lenne, amit mudbox, 3dcoat és mari is támogat, bodypaintet nem tudom, de azt a progit annyira nem is ismerem. Ptex annyit csinál, hogy hozzárendel egy meghatározott felbontású textúrát minden egyes face-hez, pl 32x32 pixelest vagy nagyobbat, amekkorát beállítasz, de asszem ez ilyen 2 hatványai szerint mûködik. saját file formátuma van, amit nem eszik meg minden renderelõ. Én még ezt nem próbáltam, mert szerintem az UV-nak van elõnye is, nem csak hátránya, és igazából elég gyorsan lehet sztem UVzni a mai eszközökkel.

Programozós,UV-zós kérdés:

Ha van egy modellem,amit lefestek vmi programban,amelyikel festeni lehet. Akár saját magam által írtban,tegyük fel.

Van különbség aközött, hogy az ember fogja magát és elpocsékolja az idejét azzal, hogy szerencsétlenkedik az UV-zással és kap egy átláthatóbb UV mapot vagy fogom a lefestett modellt és nem tudom, meg lehet-e csinálni,de azt mondanám neki, hogy figyelj program, fogjad a faceket, és a rajtuk található képinfót tegyed be egy képre, ahogy akarod. És akkor kap az ember egy olyan képet, ahol minden face külön van szedve,egyesével, átláthatatlan az egész, de rajta vannak a szinek, ahogy rá festettem.

1.) Megoldható-e ez egyáltalán?
2. Ha igen, milyen okai vannak, hogy nem csinálták még meg?

Van a Digital Tutorsnak meg a Gnomonnak jó videói az alapoktól. Ott érdemes körülnézni elõször. Plusz magyarul megjelent a "Maya -3D modellezés és animáció" könyv, ami összefoglalja az egészet. Igazándiból kezdésnek ennyi szerintem.

Ha combineled a kockákat akkor self shadows kikapcsolásával ez megoldható. Amúgy pedig a shadow linking-et nézd meg.

http://download.autodesk.com/us/maya/2010help/files/BoL_Shadow_linking.htm

Sziasztok!

Kérnék egy kis segítséget. Hosszabb kihagyás után ismét szeretnék Mayázni. Találtam jó pár tutorialt, de biztos van jó néhány tényleg hasznos segítség, amit nem találtam meg. Kérném, hogy tud ilyesmit (lehetõleg videó), legyen kedves megosztani. Elõre is köszönöm 😊

üdv.
Péter

Sziasztok, lenne egy kérdésem, amire nem találok választ...
röviden felvázolt szitum:

képzeljetek el egy spirált. ezen vannak kockák, végig. namármost berakok egy fényt, mondjuk jöjjön bal felülrõl. a lényeg, hogy a spirál önmagára ugye árnyékot fog vetni.

ezt nem akarom. tehát kihúzom a render beállításoknál a "cast shadow" fülecskét. ezidáig rendben, de az új rendernél a spirál nem vet már önmagára árnyékot, viszont a kocka, ami rajta van, keresztülveti az árnyékát oda, ahol a spirál árnyéka volt eddig. tehát dupla árnyéka van, egy a felületen, amin közvetlenül rajta van és egy pedig ahol a spirál árnyéka eddig eltakarta....

erre tud valaki valami megoldást? próbáltam light linking-gel megoldani, de nem bírtam kitalálni semmit. illetve minden amit próbáltam szarul sült el és nem oldotta meg a problémám... tud valaki esetleg valami olyan opciót a mayában, hogy az árnyékot ne a végtelenségbe vesse a program, hanem mondjuk x távolság után megszûnjön? illetve találkozott már valaki ezzel? esetleg ti hogyan oldottátok meg?

ja, mental ray alaprender, de ugyanezt produkálja a maya software és hardware is.

köszi

Félre ne értsd, shaderek terén az alapkészletet említették. A munkádról csak elismerõen nyilatkoztak. 😊

en leragadtam az mr-nel 😊

Arnoldban alapban be van kapcsolva a gamma korrekció, azzal a megfelelõ színeket kapod vissza. De az is tény, hogy normális lineáris workflowot még nem láttam beépítve renderelõbe (arnoldban sem jó...).

Az alap arnoldos shader, pontosabban az egyetlen, az aiStandard egész jó (sok dolog szerintem rosszul van megoldva benne), de mindenképpen jobb mint a beépített maya-s shaderek.

Csak kipróbálásra teljesen jó a vízjeles dolog is. A maya-s exporter renderelésre, és batch renderelésre is jó, csak a shaderek írásához kellõ filek hiányoznak.

A shaderek miatt folyton szekáltak, így v-ray, úgy v-ray. A shaderezõk amit kértek, azt mindig megkapták. Ha nem mondják mi kell nekik, én nem tudom belerakni... De Chupa-val (és fõleg xcom-al), már megszokott volt a folyamatos anyázás v-ray vs arnold témakörben. 😊

én kipróbáltam ezt az arnoldot, és azt kell mondjam, hogy elsõ blikkre tényleg csak annyiban kontra mr-hez képest, hogy alap shaderek gyenguszok, de nagyon támogatott szinte minden maya native shader, és azokból már egész jó dolgot ki lehet fabrikálni szerintem, de majd még tesztelem.
ipr nagyon tetszik benne, hihetetlen jó megoldás, nagyon jól lehet vele dolgozni, és nagyon tetszik a magas fokú maya integráció. jobb, mint mr. mondjuk ebben vray is elég jó volt, de arnold talán még jobb.
színekhez én csak annyit mondanék, hogy ha mások, mint mr-rel, akkor ott valami el van állítva, pl gamma beállítások (vray picit másképp közelíti meg a gamma dolgokat, bár lehet ez így nem teljesen pontos😊 )
elvileg minden renderbõl a megfelelõ alap beállításokkal pontosan azokat a színeket kell kapjad, mint amit a textúrád tartalmaz.

Egyszer kiprbáltam a vRayt egy egyszerû maya jeleneten. Semmi extra. Alap materialok egyszerû modellek, és pár lámpa. Alap production renderbeállítások. Szó, hogy a vRay gyorsabb volt mint a Mental, de a színe a Mentalnak sokkal szebb volt. AV-nél mintha beégtek volna a színek. Talán majd most megint kipróbálom.

Nekem is még mentalray van. De csak mert nem vízjeles. Van egy tök jó renderelõm, de minden renderelés elõtt felmenne a netre ellenõrízni a licencet, és mivel nincs netem, el sem indul a program. (Mellékesen a Cryenginnel ugyanez a problémám.) A többi ami van az meg demo és vízjeles. Kivéve a renderman, csak az meg összességében bonyolult nekem. Épphogy csak értek hozzá valamicskét.

Megnéztem én is ezt az Arnoldot, csak épp nem jöttem rá, hogy lehet beszerezni. Egyedül az exporter van meg. Azt írták itt ott, hogy írni kell nekik és akkor küldenek egy demot. De az meg megint csak vízjeles. Szóval mi értelme lenne úgy. Tényleg csak kipróbálni.

Megy most itt az "fmx 2013" többnapos kockulás, szerdán megyünk mi is. A fõ célpont számomra a Pacific Rim robotjainak elkészítésérõl szóló elõadás, kíváncsian várom. Mondjuk annyi minden van itt, hogy nehéz volt napot választani.

link

😄

Amikor beszéltem velük errõl, akkor fõleg a shadereket emelték ki. Meg pár szót ejtettek róla mit láttak azokból a projektekbõl, amikben te is részt vettél, meg amikben már nem. Ebbõl nekem az jött le, hogy inkább V-Ray, azzal a hozzám hasonlók is elboldogulhatnak.

Jah még egy fontos kontra.

Belsõ tereknél lassú. (még mindig az)

A pro :

Gyors nyers raytraceben, és hajban.
A haj sebessége miatt nem kellett külön light rig a hajhoz.
Stabil és kiszámítható, ha elindítod a rendert akkor lemegy (mental ray-nél ez nem így volt).
Elég volt 2-3-4es AA-val fényelni és anyagot beállítani, teszteket küldeni, aztán csak felvetted az AA-t és eltûnt a zaj.
Nem kellett 15-20 renderbeállítás egy projecthez, scene függõen, elég volt 3-4 a végsõ minõségre, és még pár draft beállítás.
Nagyon jó a support, és figyelnek a kérésekre. (még mindig az)
A shading api-val nagyon sok dolgot meg lehet csinálni.
Nagyon jó a scene API. (python és c++ - egyszerû jelenetet felépíteni, és kimenteni fileba, így rugalmas nagyon)

A kontra:

Rossz volt a dokumentáció. (már jobb)
Nem volt volumetric api. (már van - ennek ellenére volt olyan flexibilis az API, hogy bele lehetett rakni)
A hivatalos maya exporter rossz volt. (már egész jó)
Nem volt multiple uv set. (még mindig nincs publikusan)
Nem jók az alap shaderek. (szerintem még mindig nem, de ilyen méretnél úgysem számít már)

és mik voltak a pro kontra dolgok? csak hogy okosodjunk😄

Tudom, én voltam az az illetékes munkatárs. 😊

Nem mondom, hogy nem volt kontra, de akkoriban a legjobb választás volt (ma is az lenne). De fõleg olyan szempontok szerint, amit egy modellezõ kevésbé lát. (ne értsd félre, mindketten nagyon tehetségesek, de renderelõknél nem látnak bele a kellõ mélységekbe)

Azért a Digic-es Arnold-on hegesztett az illetékes elvtárs nem keveset, hogy olyan legyen, amilyen lett (az utómunkával is javítottak még rajta nagyon sokat). Van két ex-Digices kollégám, õk mesélgettek róla mi lett pro és kontra az Arnoldra váltásnál. Nyilván azóta fejlõdött a program, de az elején még nagyon kellett hozzá a szakértelem.

Amíg nincs 2014re fordított plugin, addig nem fog menni. A maya semennyire sem képes korábbi verziók pluginjeit betölteni.

Jah nem lett rossz a januári reel, csak szerintem borzalmas a zene alatta. 😞

Amúgy, ha már arnold meg maya, http://www.youtube.com/user/arnoldrenderer az yt csatornán van egy rövid bevezetõ (6x10-20 perc). Nagyon az alapokról szól csak, de nem vészes.

Ugyanaz aki ezt csinálta (Ben Greasley a SpehereVFX-tõl, õk ilyen trainingre specializálódott cég), összerakott egy hat és fél órás anyagot http://spherevfx.tumblr.com/post/48045620928/arnoldformaya . Ez már nem ingyenes, de alapos és részletes. Nem lesz benne sok advanced dolog, viszont végigmegy 1-1-ben szinte az összes paraméteren.

És végül ha maya és arnold, akkor itt egy hazai gyöngyszem : http://www.youtube.com/watch?v=OASKtZLYNzA . (csak 2009tõl kezdve anrold, elõtte mental ray és renderman)

Hali!
Próbálta már valaki használni a V-Ray 2.30.01 verziót a maya 2014-el? Kompatibilis vele?

elég beteg ez az arnold, ahogy látom a 2013 januári reel-jében 😊

nagyon sokan, mert jelen pillanatban az a legolcsóbb megoldás, sok kis cég nem teheti meg, hogy vrayt rendermant stb-t vásároljon, mr meg be van építve mayaba/maxba.
amúgy mr nagyon jó kis renderelõ én nagyon szeretem, csak az a baj vele, hogy nemigen történt jó fejlesztés vele kapcsolatban az elmúlt 4-5 évben, ezzel szemben meg pl arnold egy iszonyatosan jó motorral rendelkezik, vray is nagyon sok booston esett át. szóval összegezve mr kicsit elavult.