Maya

Köszönöm mindenkinek a kreatív hozzászólásait!
Maradok a Maya-nál, de egy kicsit bizonytalan lettem, amikor megláttam, hogy sok kép Max-el készült.
Kifejezetten örülök neki, hogy ez a téma nem ment át flame-be. 😊

Btw, a clara.io-nál nem az a lényeg, hogy weben keresztül megy minden?

Azért is látni publikusan több max szeretetet, mert ha sokan kezdenek 3d-vel, akkor a legtöbbször modellezéssel foglalkoznak (esetleg render), és mindezt windowson, erre pedig a max + v-ray kombó egy jó választás. No meg rengeteg tutorial van hozzá, stb... Cégeknél, meg a maya nagyon beásta magát, fõleg a nagyobb helyekre. Amikor bejött, ez volt a legkönnyebben bõvíthetõ, fejleszthetõ cucc, és mindenki erre alakította ki a pipeline-t, scriptek, toolok tömkelegét. Hiába lenne bármilyen progi is, ami maya-nál sokkal jobb lenne minden téren, a pipeline közepérõl nem lehet kiszedni, mert iszonyatos költségekbe és idõbe kerülne.

Amikor anno én is elkezdtem 3d-zni (2000 körül, nem volt az olyan régen, mint itt egyeseknél), akkor maxxal foglalkoztam a korábban említett dolgok mellett, egy kis render, egy kis modellezés, stb... Aztán elkezdtem dolgozni, és maya elé ültettek le. 😊 (bár fejleszteni hozzá, de az más téma) És most az egyetlen amihez komolyan nyúlnék maya-n kívül, az a houdini. Max csak win, xsi halálra van itélve, a többi program meg nagyon egyetlen dologra van ráállva és nem jó középre.

Technikailag vannak különbségek de ha jól ismered a szoftvered akkor meg csinálsz benne szinte bármit, általában nem a modellezés a kihívás hanem az ügyfelek extrém kívánságait megoldani határidõre, mi pl alig modellezunk, nincs rá idõ, inkább megvesznek modelleket hogy abból dolgozzunk...

Az autóiparban modellezéshez meg mindenki Maya-t használ, és nem csak a concept modellezéshez, hanem a második fázisban is, amikor már nagyon precízen kell milliméterre összehozni a dolgokat, és utána megy a nyomdába. A végsõ finomításra, meg gyártásra szánt modellezés persze még mindig surface-ben történik az arra való software-ekkel. Szóval itt is logikusabb lenne pl Modo-ra váltani, de egyrészt politika, másrészt az átképzésekkel járó nyûg, stb. Meg így is minden elkészül, és kellõen gyors is a munkafolyamat, szóval senki nem vált.

Nem a legjobb program lesz feltétlenül a legelterjedtebb, elég sok más tényezõ is közrejátszik, de ezt írták már mások is. Mondjuk más területein a cg-nek a Modo masszívan hódít mint alap modellezõ software.

Amikor elkezdtem mayazni, akkor azt mondták, hogy modellezni max alatt jobb, de animációban a maya a jobb.
Úgy gondolom, hogy ha gyengébb a max modellezésben, az nem vészes, mert ott Mudbox, Mari, Zbrush...

max vs maya

olyan mint a ios/android, osx/windows, szõke/barna

azt hallottam azért nagyobb a max rajongó tábora mert mayát állítólag sokkal nehezbb megtanulni, nem tudom, keveset maxozok, inkább csak alap dolgokra használom, viszont mayát 3éve tanítok is és szerintem nem olyan vészes, rá kell érezni a logikájára.
ahol most dogozom (bose collins) ott ketten vagyunk 3d-re és kompozitra még egy srác kompozitra és videó vágásra de mindenki csinál mindent, kollegam max és after effects, én maya, fusion, realflow, mudbox, zbrush
fbx-et használunk egymásközt, idõnként a send to max/send to maya opciót is bevetjük, sokszor kapunk .step .stl fileokat, ezekt mayából gyorsabban lehet használható polygonná konvertálni mint maxban...

a reklámfilmekhez videoklipekhez stb. általában mindkét programból jönnek a renderek (vray) a shadereket mi építjük alap anyagokból, ritkán használunk kész materialokat, tökéletesen össze lehet hangolni rendernél a 2 szoftvert, kis utómunka és nem mondod meg hogy melyik honnan jött, a max és maya vray közt nincs túl nagy különbség, próbáltunk azonos render settinget beállítani, nagyjából ugyanannyi idõ alatt dolgoznak...én még használok maxwell rendert is mellette de inkább csak stillekhez...ha nagyon nincs idõnk a renderre akkor mental ray és jó nagy adag postwork 😊) elég sok pass-t renderelünk általában, próbáljuk a renderidõt leszorítani amennyire lehet, inkább az utómunkára koncentrálunk.

azt tapasztaltuk mayában sokkal jobbak az animációs megoldások, nagy poligonszámnál gyorsabb a viewport (2.0) , fluid, particle stb. szimulációkat fõleg mayában csináljuk, 100x gyorsabb, karakter animációk szintén mayában mondjuk ez ritkán van...a GPU render megoldások gyorsabban mennek maya alatt, vray rt-t próbálgatjuk, maxvell fire-t, caustic visualizert, max alatt a vray rt egyáltalán nem stabil.

kollegam nagyon penge maxban de azért sokszor pislog hogy mayában mennyivel egyszerûbbek a dolgok és amivel õ szenved az nálam pikk-pakk összejön, rengeteg plugint használunk, itt is a maya gyõzött...

de mindkét program nagyon jó, kell egy kis megszállottság, az se baj ha kicsit õrült vagy 😊) , szinte ugyanarra képesek, érdemes mindkét programhoz érteni és még sok másikhoz, gyorsabban is találsz munkát...én pl délelõtt mayázok aztán beesik egy kompozit és akkor fusion, de itt kell videót vágni, élõ anyagot forgatni, mocap-hez konyítani, szeretik ha van saját ötleted egy munkára, mi írjuk a brief-eket is, sokszor dolgozunk 12-14 órákat naponta vagy többet az irodában, fent is szoktam aludni sokszor 😊)
ja és persze kellenek nagyon jó gépek

de a végszó hogy kapják be a maxosok, maya a királynõ 😊))

Clara.io elérhetõ mayához is amúgy

Szerintem azért van, mert a Maya korábban sokkal jobb volt, mint a Max, de drágább is, ezért a nagy stúdiók be tudtak rendezkedni Maya pipelinera, a kicsik meg maradtak az olcsóbb Maxnál. Közben a Max iszonyat fejlõdésen ment keresztül, árkategóriában felhozták Maya szintjére, és sok dologban sokkal jobb is lett. Alapvetõen amúgy szerintem a kiépített pipeline sok helyen Maxra épül, ezért maradtak amellett. Most a 2014-gyel a Maya is sokat javult, bár próbálni nem próbáltam, csak videókat néztem róla, de nagyon ígéretes újítások vannak benne. Mondjuk én még mindig csak a 2012-vel játszom, szóval...
Arnolddal akarnék többet foglalkozni, mert egyszerûen egy álom ez a renderelõ! Így képzeltem el mindig is az alapokat, aztán innen csillagos ég a határ😄

Nézegetem a nyertes képeket a CGblog oldalon, és mindegyik jóformán Studio Max-el készûlt.
Majdnem úgy néz ki a dolog, az én szemszögembõl, hogy mindenki Max-et használ.
Sok plugin is hamarabb megjelenik Max-re, mint pl. Maya-ra.
Pl. Vray 3.0 beta már van Max-hez, Maya-hoz majd jóval késõbb jelenik meg. Mindig is hamarabb jelenik meg Max-re.
SigerStudio alkalmazásai jóformán csak Max-hez van, egy kivételével.
Solidrocks is csak Max és Cinema 4D.
Clara.io is csak Max-re jelenik meg. Elég jó kis program, nem szívesen hagynám ki.
Tehát a kérdésem az lenne, hogy miben jobb a Max, hogy sokan azt használják és nem a Maya-t?
Amit számításba vettem az az, hogy Max már a DOS-os idõktõl van Pc-n. A Maya késõbb jelent meg.
Kb. 2 éve használom, tanulgatom a Maya-t, de most kíváncsi vagyok a véleményetekre, hogy miért élvez a Max szemmel láthatóan nagyobb "rajongói" tábort.

Beépített shaderek nem tudják. (design döntés, nem technikai akadály) Az Anders Langlands féle shaderek támogatják, és talán a Kettle is.

Vrayben van olyan, hogy light element aov, amivel elvileg egy számítás alatt az egyel lámpák fényerejét külön aov-ként ki lehet küldeni pl exr csatornaként (vagy külön file, mind1).
Arnoldhoz van ilyen, vagy minden egyes light (group)-nál külön le kell renderelni, és ezzel csomó idõt "pazarolni" az AA-re meg samplingre?

Boldog Karácsonyt!

Boldog Karácsonyt Mindenkinek!

2 nap alatt 2,872,030 nem rossz

Kár a desing typo-ért, ami csak azért tûnt fel a végén, mert már vagy 20x megnéztem reggel óta. Nagyon király lett 😊
Szép nézettsége lesz napokon belül, az fix!

A Delov Digital karácsonyi üdvözlete 😊)

www.delovdigital.hu

Uh, ez nagyon király....köszönöm szépen a segítséget és a fáradozásodat!

A boolean szét barmolja a mesh-t, sok a szívás vele mire szép lesz a végeredmény egy ilyen modelnél, mudbox inkább, de mayán belül is meg lehet csinálni normal map-el, gyorsan felvettem én hogy állnék neki, azért még van mit dolgozni, csak ráhánytam az uv-t de egy kis finomítás és mûködhet

boolean?

Köszönöm, de a labdát - ahogy a képen is látszódik - meg tudom csinálni 😊

http://www.youtube.com/watch?v=xSZAakOfBio

Sziasztok!

Egy kis segítségre volna (ismét) szükségem. Szeretnék egy labdába mélyedést tenni a mellékelt kép szerint...de nem tudok rájönni, hogy hogyan. Tudna valaki segíteni?
Elõre is köszönöm!

<#nevetes1>

Nézz utána a dolgoknak, mielõtt butaságokat állítasz. Python-ban szoktam írni a gui-t, ott pedig pl nem kell újrafordítani a dolgokat, sõt akár újraindítani a programot. Elég reloadolni a modult, átírom, egy sor és máris másként mûködik az egész.

De mint mondtam, nem látsz bele elég mélyen a programozási feladatokba, csak a saját limitáld területen, amire jó a vex és az ice. (és ez inkább 1%, minthogy 95% lenne) A houdini kötözgetõs részét programozásnak hívni elég nagy túlzás. Ügyes-ügyes, de iszonyúan limitált. Persze, amíg nem tanulod meg a másik oldalt, ezt nem fogod látni.

Az esetek 95%-ban elvégezhetõek vele azok a feladatok, amelyekre kellenek. Szerintem éppen ellenkezõleg van, a python és a c-is alapból nagyon limitált bizonyos értelemben. Tehát semmiféle interaktív valós idejû visszajelzés nincs, abszolúte nem rugalmasak, sõt merevek mint egy hulla. 😄 Fordítani, gui-t irkálni, és utána majd kipróbálhatod, bármit változtatni akarsz akkor kezdheted ezt a folyamatot elölrõl, megint fordítani stb, tehát ez így együtt olyan körülményes és annyira munkaellenes folyamat, hogy döbbenet.

Nem véletlen, hogy ki lettek találva a vizuális programozási nyelvek, az a feladata, hogy felgyorsítsa és gördülékenyebbé, valós idejûvé tegye a munkafolyamatot, az a célja, hogy magából a programból programozhasd magát a programot, lásd houdini.

Hova tovább maradjunk a konkrét példánál, vex-ben vagy ice-ban pillanatok alatt összetehetsz egy könyvespolcot olyan könyvekkel, hogy tetszés szerint állíthatod a szélességétõl kezdve mindent a könyveknek, az elhelyezkedésüket, akár csoportokban és vagy akár egyesével is. Ezekre a feladatokra, kimondottan ajánlott.

A vizuális programozási nyelvek limitáltak, komolyabb programozási tapasztalattal nagyon limitáltnak látszódnak, és sok feladatra szuboptimálisak, mégtöbbre pedig alkalmatlanok. Persze vannak olyan dolgok amire jók.

Na látod ezért szeretem a vizuális programozási nyelveket, mert nagyban felgyorsítják ezeket a munkafolyamatokat, nem mellesleg pedig a grafikus interfészeket is kapásból személyre szabhatod.

Pythonnal kell írni 1-2 ezer sort, addig ugyan ezt 40-50 node lerakásával meg tudod csinálni, nem mellesleg pedig valós idõben tesztelheted a programozott tool-dat.

Ebben semmi pengeség, vagy extra sincs, és neked sem tartana hetekig. Ehhez kell egy minimális programozói affinitás, és böngészni kell a maya helpet. (nekem annyi elõnyöm van az x év tapasztalatommal, hogy tudom mit kell meghívni, és hol van a specifikáció a pontos függvénynevekhez)

Ez egy jópofa kis példa, ami mutatja, hogy lehet egy ilyen egyszerû problémára elegáns scriptet írni. Persze, ahhoz hogy ebbõl egy rendes tool legyen, még nagyon sok munka kell. (gui, vissza kell tudni fordítani a folyamatot, egyszerûbben cserélgetni a random generátorokat, gyorsítani kell a tényleges számítást, vagy valszeg jobb lenne egy külön uv rétegbe lementeni ezeket a dolgokat stb...) Ez a tipikus TD feladat, és ehhez életet tud menteni egy minimális python tudás, és API olvasgatás.

wow, nagyjából ennyit csinál a másik script is, amit említettem legutóbb, nem gondoltam volna, hogy olyan penge vagy, hogy hip hop összedobsz egyet😄 nekem egy ilyen megírása tuti több hetes meló lett volna!😄 Gz!

Pl itt van egy hót primitív script, amit most dobtam össze erre a feladatra

http://pastebin.com/JjaPCVgP

C++-ban természetesen gyorsabb, de most nincs kedvem plugin-t fordítani. 😊

Ez így néz ki : https://www.dropbox.com/s/k1icqwnt9mc7as2/Screen%20Shot%202013-11-11%20at%2022.31.26.png

Annyi különbséggel, hogy ez különálló objektumokra mûködik, nem mergeltre. (a példa scene-ben külön volt mindegyik obj) Jah igen, és ez feltételezi, hogy mindegyik objektum uv tere 0..1 között van.

Jah, ez így is van. Már régóta baszogatja mindenki az autodesket a thread safe api-val, és a többszálú nodegraph kezeléssel, de iszonyú sokmindent át kéne írni ahhoz.

Amúgy megnéztem, nem 200 könyv van, hanem inkább 2000... Azon meg a tripleswitch shader nagyon lassú lesz amúgyis. Pl a mental rayes verzió lineáris keresést használ, hogy meghatározza melyik shapehez, melyik shader kell. 😊 Valszeg a v-ray-es sem jobb.

Ilyen esetben a legjobb írni rá egy scriptet ami ledarálja az egészet, és áttranszformálja az uv-kat egy kissebb térre, és akkor egy shaderrel és egy textúrával tud futni az egész. A tripleswitch shader okos, meg hasznos, de túlságosan is okos. Ennek nyilvánvalóan megvannak a költségei, és ez nemcsak viewport sebességben nyilvánul meg, hanem render sebességben is. Szóval ilyen masszív scene-re nem ez a legjobb megoldás.

Hát ha a maya nodegraph csak egyetlen magon dolgozik, akkor az inkább azt jelenti, hogy a rendszer teljesítményének még a felét sem képes kihasználni... 😄 Persze lehetne többszálú is, mint softimage ice, ami egyébként teljesen többszálú, csak ahhoz a mayát alapoktól kéne újraírni. <#mf1>

Nem ez az?

link

én a Marinál tapasztaltam ezt a fél CPU kijelzést, de igazából nem nagyon izgatott a dolog, mûködött, csinálta, úgyhogy csak nincs nagy baj😄

A maya nodegraph csak egyetlen magon dolgozik. Ergo 50% azt jelenti, hogy a rendszer teljesen le van terhelve és 100%-on pörög.

Ja, 2. E8200.

Persze nem úgy gondoltam. 😄 Igazából minden programnak vannak gyenge meg erõs oldalai is.

na pont az ilyen színezgetésekben max jobb, mint maya...
van valami script, most nem jut eszembe a neve, felosztja az UVját egy objectnek (mergel-t könyvek) 3x3-as (pl) kis UV részletekre az 1:1 UV térben. Így 9 féle színt tudsz adni nekik egy sima lowres texture-rel is. Falevelekhez láttam már ilyet használni, egyszer kipróbáltam, jó kis script. Ha megtalálom a nevét, vagy a letölthetõségét, belinkelem.

Nehogy azt akard már mondani, hogy kétszáz darab könyv random színezéséhez erõmû kell? <#hehe> Meg, hogy a windows memory reportálása borzalmasan rossz és azért. <#nevetes1>

Hány poligon egy könyv 100? De legyen ezer, na és kétszáz 1000 poligonos könyv? Még az is csak 200 ezer poligon lenne, még azt is bírnia kéne lazán mindenféle swap nélkül.

Szerintem inkább a triple switch node a tré, ha szimpla kétszáz objektumot nem lehet vele átszínezni. Persze van a mayánál szarabb program is, pl a 3d max. 😊

Ok, elsõ körben a windows memory reportolása borzalmasan rossz. Ha kiírja 500 megád van, nem azt jelenti, hogy minden program a memóriában van, és van még 500 megád. Itt már a cuccok fele valszeg swap fileból mûködik. Az pedig magyarázza az ilyen szintû lelassulást.

Hány magos procid van? 2?

Ha gyenge lenne,akkor nem 100-on menne a proci és az utolsó bájt a memóriából is arra lenne fordítva, hogy számolja a cuccot, nem hagyva, hogy akármi mást csináljak? Volt 500 szabad ramja,nem kellett neki, a fél proci ott volt még, nem kellett neki. Miért gyenge, ha azt se használja ki,ami van?

8ból 8at?

Szimplán csak gyenge a géped hozzá.

Mert egyébként melyik vga kártya az, ami már jól lehet dolgozni?

nekem 460GTX-el is ment a mari, egész jól, komolyabb projectekhez persze kevés

A szakmában kb hány órát töltenek munkával az emberek? Kb. 200 könyvet próbálnék különbözõ színûre festeni, egy triple switchcsel tutor alapján megcsináltam, de a rampokat kb 3 percig kötötte hozzá, zoomolni kb 8 percig tart "5"-ös módban, át kellett tennem wireframebe, most meg "6"-os módba próbálnám tenni,de már vagy 10 perce csinálja. Ez aztán a tempó. És még így is csak 50%-on megy a proci és Ram is van még vagy 500MB. (a 2GB-ból).

Nem akarlak elkeseríteni, de marihoz sajnos GTX 480 az alja, kb innentõl használható.

Sikerült beszerválnom egy msi9400GT kártyát.Ha nem is egy csúcsmodell, de ezzel már mennie kell a marinak. Meg persze végre két monitorral is mûködhetek. 5-ért szerintem megérte. Pöccre mûködött win7-tel, de azért majd felteszek valami forceware-t hozzá.

Ah, ok, visszaolvasva kicsit félreértettem.

Igen, az a bug nagyon gyanús, hogy az a problémád forrása. 😊