Én néztem egy blendshape tutort,de ott az egyikbõl alakult át a másikba. Tehát új test nem keletkezett,csak ami volt az más lett. Nekem meg olyan kéne, ami az összes átmenetet megcsinálja egymás mellé.
blendshape, igen sokat használt eszköz és alap szinten nagyon egyszerû.
Mayában létezik olyan, mint Illustratorban a blend? Hogy van két akármilyen kinézetû valamim és X db átmenettel átmegy az egyik a másikba. Tehát h van egy gömböm és azt akarom, hogy 8 lépésbõl kockává alakuljon, akkor kapok a gömb meg a kocka közt 8 olyat,ami a kettõ közt van.
A http://www.sg.hu/listazas_msg.php3?id=977751129&no=31484 hsz-t nem neked céloztam, hanem peetmaya-nak. Csak mindig elfelejtem megnyomni a válasz gombot :) . (úgy érzem a nekem szánt válaszod nagy része egy kis félreértésbõl ered)
Miért akarsz mel filet kódból megnyitni és átírni?
(erre van szükséged : http://download.autodesk.com/global/docs/maya2013/en_us/Commands/fopen.html meg a Related-ben megadott többi parancsra)
Ritkán van szükség tényleges forrásfájlok menet közbeni átírásáról (és ha tényleg szükség van rá, akkor szerintem a program tervezésével van probléma), ha meg kódot akarsz generálni on the fly, akkor eval / evalDeferred / evalEcho -ra lesz szükséged.
Peet kipróbáltam a fánál, hogy kiszedtem, a levelekrõl a transparency és diffuse alpha kötést, és betettem a cut_opacity-nek, de akkor a levél egyáltalán ott sem volt. Nem volt ott semmi, csak az ágak Pedig diffuse color be volt kötve.
sirpalee:
Momentán sosem tanultam programozást. Érdekelt ez a téma, hogy hogyan tudnék cd autostarot írni a lemezeimhez, és nekem azt mondta az info tanár, hogy legegyszerûbben úgy, ha leszedek egy browsercall programot bizonyos pc magazinról, és írjam meg html,ben, és majd a böngészõben elindul. Addott egy kis jegyzetet róla, és így kitanultam a html-t, ami ugye nem programnyelv, de jó kezdés, meghát mindenkinek tudni illik. De neki volt igaza, mert utána rámentem a php+sql-re, és ezzel megtanultam a programozási alapokat. Így, hogy ment a html+php egybõl megértettem mel-t, hogy mayázni kezdtem. Vannak foltok ott is, például nem tudom még, hogyan lehet mel filet, megnyitni, változtatni és menteni kódból.
Aztán próbálkoztam a pythonnal, feltettem, de egyszerûen nem ment a fejembe. Fogalmam sincs miért, de nem. Írni akartam pár gui programot, régi parancssoros cuccokhoz, és nem boldogultam vele, még sima c nyelvben sem. c#-ben, meg pillanat alatt összedobtam, egy egyszerû toolboxot. Meg egy start menüt magamnak felülre. Linux alatt mplayer tv tuner kezelés. Már a linq.xml kezelés is megy, és egy adatbázis progin ügyködök. Szóval azt hiszem nekem már csak ez lesz a nyelvem, ameddig annyira el nem mélyülök benne, hogy egykettõre megértsem a többit is.
Erre áll az agyam. Persze mikor hazaértem már nekem is bennem volt, hogy melben könnyebb lenne. Ötletem rengeteg van, hajjaj.... Mayához, meg máshoz is. A megvalósítás már más tészta lesz. Jelenleg a maya toolboxom render meg light részénél, ki van listázva az összes elérhetõ lámpa meg ikon, ezt is úgy kéne, ha le tudnám kérdezni, meyik render plugin aktív, és csak az ahhoz való cuccok látszanának.
QT designerrel tele van egy halom blog és tutorial, de a legegyszerûbb ha letöltöd és kipróbálod magad. (nem vagyok nagy UI huszár - szóval az én példáim nem a legjobbak)
Solid Angle-nél vagyok, mi csináljuk az arnoldot.
ehhez tudsz linkeket adni, hogy, hogy néz ki egy ilyen qt ui designer meg hasonlók? amúgy te hol dolgozol? gondolom akkor soft develop téren
Ha a maya core scriptekre gondolsz, akkor igen, azoknak a nagy része még mindig mel. De ezek nagy része kb 10 éve ott van a rendszerben (és 10 éve bugos némelyik), és egyszerûen nincs kapacitásuk / lelkierejük újraírni. Munkában használt toolok nagy része python, a korábban említett okok miatt ahol csak lehet python.
Amin én dolgozom (Maya to Arnold), ott a scriptek 99.5% python. (van pár mel script amit át kell írnunk a mayaból, és betöltéskor újrasourcelni - de ez megint mayas hülyeség miatt van) A csak python hozzáállással voltak gondok, fõleg UI részen, de ez leginkább a 2011nek volt köszönhetõ. Pl 0.22es verzióba raktam color temperature control-t a fényekre, azt egyszerûen rémálom volt megírni 2011-re és 2012+-ra, mert 2011 alatt az az attrFloatSliderGrp csak mel commandot volt hajlandó megenni, python-t nem.
A másik jópofa dolog, hogy a maya-hoz már alapból adják a megfelelõ pyqt könyvtárakat, és közvetlen QT ui-t tudsz benne meghívni. Ami sokkal de sokkal jobb mint az alap maya-s ui. QT designerrel generált .ui filekat be tudsz húzni, és rá tudod akasztani a saját kódodat.
ha jól tudom akkor a UI még mindig melben van, nem?
Ezt megértem, meg azt is hogy nem vagy programozó. De azért a c++-t ne hasonlítgassuk a mel-hez, teljesen más az egész. Nagyteljsesítményû, jól karbantartható kódra még mindig a c++ a legalkalmasabb.
Amiért jobb a python mint a mel. - Jobban átlátható, jobban szervezhetõ, modulárisabb és karbantarthatóbb kódot lehet benne írni. (ennek az üzleti értéke már alapban jobb mint a mel) - Jobban együtt tud mûködni kismillió másik tool-al. (3d-ben a pipeline toolok 95% pythonban íródik) - Nem csak scripteket, akár node-kat is írhatsz benne, mindkét területen egységes elérést biztosítva (api és script felület). - Simán el tudom képzelni, hogy gyorsabb mint a mel. Fõleg a tárolóknál. - Jobbak a fejlesztõi eszközök. (python kódot tudsz debuggolni rendesen vs-el pl maya-ban futtatva) - Kismillió külsõ könyvtár létezik, amit egy pillanat alatt be lehet húzni maya alá. - Van pymel, ami jobb mint a sima scriptes felület. (én spec nem használom - de ez más téma)
Épeszû ember mel-ben nem kezd új fejlesztést may alatt, legacy kódok karbantartásánál még kellhet a mel, de sehova máshova.
Én ezt két okból nem tudom elfogadni. Egyik, hogy a C++ is régi, mégis használják a mai napig, másik meg, hogy pythonnal valami MEL-t helyettesítõ dolgot akarsz csinálni, akkor rohadtul a MEL parancsokat fogod ott is használni, csak python spéci deklarációval, szintaktikával, de a parancsok ugyanazok, és le merem fogadni, hogy a háttérben ugyanaz a kód fut le, amit a MEL is meghív, tehát nem igen látom, hogy mi elõnye lenne a pythonnak, hacsaknem az API, mert ugye evvel azt is lehet...
Jobb a python-t használni.. Mel szép meg minden, de már régi...
Wollf, a külsõ program használata felejtõs, mert nem csak ma filek léteznek ám. :)
ehhez nem kell c#, elég a mel is (vagy python, de azt nem ismerem:( ) sõt, mel sokkal jobb erre, pár for ciklussal megoldható szerintem, nem egy bonyolult dolog.
A shader kötések nem jók. nem kell transparency nem kell semmi szarság, csak a cutout opacity-be kössed be az alpha-dat, ettõl gyorsabbat nem tudsz renderbõl kihozni, és amúgy is ez így a korrekt. Amikor odajut a render, akkor kapja az infót, hogy hoppá, itt cutout van, akkor lövöm tovább a ray-t és kész (azt most hirtelen nem merem biztosra mondani, hogy nem vesz el újabb raytrace számítást, valszeg igen, szal a raydepthre azért még szükség van, hogy kellõ mélységbe tudjon hatolni).
amúgy a ray depth settingsnél érdemes õket felhúzni maxokra, a max raydepthel tudsz játszani, hogy limitálj, illetve shadereknél (fõleg refraction) is van egy korlátozó, amivel szintén elejét tudod venni a felesleges kalkulációknak.
Az jó lesz, ha benne lesz.
Én meg már egy olyan programon töprengtem, ami megnyitja a "scene.ma"-t létrehozza az összes ai-standardet (mia_valami ->ai_valami), bekötötögeti a textúrákat, rádobja a materialt a modellre. ibl-bõl csinál arnold sky/backgroundot meg ilyenek. sun/sky-ból hasonlóképp. Kitörli a mia_materialokat, meg minden mr cuccot, és egy másik scene file-ba elmenti.
Azt még c#-ben is meg tudnám írni (jelenlegi szintemen jó pár év alatt :D ), tekintve, hogy az ma, az szövegfile.
Ezt az átalakítóst meg lehetne csinálni az összes saját materialos rendermotorhoz.
Peet, mire gondoltál, hogy azok nem jók? a renderbeállításra, vagy a kameraforgásra?
Amúgy a ray beállítás nem 8:4:4 volt, hanem 4:4:8, csak elírtam. De a shadow depth-tet kellett növelni. És így már jó.
De +1perc lett a render. Kipróbálom majd a cutoutot is.
valóban radeonok nem is vészesen drágák mindegy ettõl függetlenül más progik annyira nem támogatják az atit, lehet hogy csak egyelõre... nvidia tapasztalatom szerint amúgy stabilabb, bár nem rosszak a radeonok sem..
kenyeresdani nekem az avataros helikopáter jutott eszembe róla, mert a star craft 2-t nem ismerem jó az irány, csak így tovább:) legyen szép részletes hipoly:D
Whysper, cuda támogató kártya nem azért kell mert drágább és lassabb, hanem azért, mert nagyon sok mindent openCl támogatásra még nem írtak meg, cuda-ra viszont igen. Pl mayaban szimulációk GPU gyorsítása (ruha, soft és rigid body, dmm asszem, ebben nem vagyok biztos, fluid és particle) mayan kívül pl textúrázásra istenkirály mari, cuda nélkül el se indul, premiere mercury szintént cuda alapú... sajnos az nvidia támogatottabb, hiába csinál erõsebb kártyákat az ati/amd
Köszi Vga cserélve lesz majd és néztem teszteket mostani atik hiába cuda jobban teljesítenek és van másik HDD benne ez csak a 120 gb csak rendszernek van meg a fontos progiknak!
üdv. felraktam a Mayat. szabadidomben modellezgetek. Várom az építõ jellegû kritikát :)
én még annyi kiegészítést tennék hozzá, hogy kéne egy másik winyó, nagy kapacitással, mert azt a 120GB-ot úgy, hogy rendszer is van rajta, nagyon hamar ki fogod nõni.
Amúgy, igen, persze. Amíg kezdõ vagy (1-2 év), addig ez bõven elég. Esetleg az AMD videókarit dobd ki és vegyél helyette NVidia-t, megspórol némi fejfájást hosszútávon.
Gigabyte GA-990XA-UD3/AMD FX 8120 (4,2 Ghz)/alpenfohn Broken XFX 550w P1–550S–UKB9 OCZ agility 3 120Gb 8GB (2x4GB) Corsair Vengeance Blue VTX3D 6850 X edition 1 Gb ASUS XONAR DG
Szeptembertõl kezdem a sulit ahol Maya programot igyekszem magamévá tenni. Kérdésem ,hogy ez a config elég lesz a Mayaval való munkálatokhoz?
Ez most adott egy jó ötletet.
0.25-ös (a 0.24 release branch-ja holnap indul, szóval abba feature már nem lesz) maya to arnoldba belepattintunk egy konverter scriptet, ami lecseréli majd a mia_material gányságokat aiStandardra.
hát azok nemjók... csak a cutout opacity-t kell alul az advanced lenyílóban van. arnold istenkirály...:D
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:D 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...:D 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 :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!
Koszi a valaszt, de azota mar az egesz project torolve lett (win ujrahuzas miatt) :)
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.
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?
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.
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. :)
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.
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.
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
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.
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)
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.