32214
Maya
-
sirpalee #31453 Ha több passot tolsz ki akkor egy framehez nem csak egy file lesz. Miért nem exr? :) -
Laura22 #31452 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 :D) é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! -
#31451
Koszi a valaszt, de azota mar az egesz project torolve lett (win ujrahuzas miatt) :) -
#31450
volt valami ebben a gombában :)))))))))) -
#31449
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 :) -
#31448
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 -
#31447
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. -
razorback #31446 É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. -
#31445
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. -
#31444
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? -
sirpalee #31443 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. -
#31442
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. -
#31441
Na hát ebből nem sokat értettem :D
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? -
sirpalee #31440 A ptexes relációkra kép
![]()
-
sirpalee #31439 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) -
#31438
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. -
#31437
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? -
#31436
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. -
sirpalee #31435 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 -
#31434
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 -
#31433
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 -
#31432
Félre ne értsd, shaderek terén az alapkészletet említették. A munkádról csak elismerően nyilatkoztak. :) -
Midas #31431 en leragadtam az mr-nel :) -
sirpalee #31430 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. -
sirpalee #31429 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. -
sirpalee #31428 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. -
#31426
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. -
#31425
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
-
#31424
:D
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. -
sirpalee #31423 Jah még egy fontos kontra.
Belső tereknél lassú. (még mindig az) -
sirpalee #31422 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:D -
sirpalee #31420 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) -
#31419
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. -
sirpalee #31418 Amíg nincs 2014re fordított plugin, addig nem fog menni. A maya semennyire sem képes korábbi verziók pluginjeit betölteni. -
sirpalee #31417 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) -
razorback #31416 Hali!
Próbálta már valaki használni a V-Ray 2.30.01 verziót a maya 2014-el? Kompatibilis vele?
-
#31415
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.
