32214
Maya
-
#30291
akkor már én is hozzászólnék xfrog témához. beszereztem ezt a cuccost, de én azt hittem, hogy itt már kész dolgok vannak és csak egy listából kiválasztom, hogy mit akarok és azt berakja maya-ba. de ahogy látom itt magamnak kell megcsinálni mindent... ez pedig egy laikusnak elég nehézkes :D -
#30290
Ezt most így nemigazán értem.:) beimportáltam az .xfr filet mayába. Már nem emlékszem nekem hogy volt, de mikor ráböktem valahol a fára, akkor kapásból az egész kijelölődött, aminek a talpához vittem a pivotot, és scaleltem meg arrébb vittem. De ha arra gondolsz én még így nem építettem vele növényt csak beimportáltam a készeket standalone programból. De van még egy másik nagyon jó ilyesféle program a SpeedTree. -
montressor #30289 ha mar elokerult az xfrog, nem tudjatok , h lehet elmozditani az origobol? Merthogy valamihez szeretnem a novenyt termeszteni.. Hiaba huzom az egesz root Branch pivotjat a celhelyre, meg a path curve pivotjat is, a kesz noveny teljesen mashol fut, vhogy tudja, h nem az origoban van...
koszi -
#30288
-
#30287
egyébként területe válogatja, hogy mit miből kell megoldani... vannak olyan helyek, anyagok, feladatok, amire az uv/textúra nélküli sima shader tökéletesen elég... -
Kakaduduka #30286 Értem. Igyekszem minél több információt összeszedni erről a textúrázásról, aztán majd csak lesz belőle valami. Viszont ezt a puskát nem akartam így hagyni, szóval shaderrel oldottam meg az ügyet, ezt sikerült készíteni:
-
#30285
oda is sokszor jó a darabokba modellezés, sima projektionok és az unfold uv... -
Kakaduduka #30284 Igen, én is a youtube-ot bújom általában, lehet hogy idő kell neki. Anno a modellezéssel is így voltam, bár még most sem megy olyan hihetetlenül jól, de talán a sok "tanulásnak" köszönhető hogy az első modellek nem ilyen kockák meg egyszerűbbnek mondható alakzatok lettek, hanem kicsit haladóbb kategóriájú, már ha szabad ezt mondanom. Csak nekem a sablon szürke nem nagyon tetszik, a befejezetlenség tükröződik így a modellekről. Nekem egyébként megvan azt hiszem mindegyik ilyen MTS videód, bár az abban lévő példák ilyen egyszerűek. Amivel nincs is bajom, csak egy nagyobb poligon számú modell esetében már nem megy az a módszer, amit pl. anno a kardnál mutattál. -
#30283
hát én azért nem felejteném el ezeket a dolgokat :) legalábbis még nem :) http://www.youtube.com/results?search_query=maya+uv+mapping&aq=f
Sajna mást nem tudok mondani, mint ami eddig is el lett szerintem mondva... videótutorok, html tutorok, maya súgó... csináltam anno én is erről videót (MTS 3), de nem tudom hogy hol lehet meg neten (nekem már nincs meg).
-
Kakaduduka #30282 Nagyon állat, nekem nagyon bejön. Viszont azt áruld már el, hogy mégis hogyan lehet ezt a textúrázást megtanulni? Tudom, számtalanszor kérdeztem már, mindig kaptam rá mindenféle választ, többnyire hogy az UV-t felejtsem el, meg Mari illetve Mudbox a jó, és én ezeket értem is, de mégis honnan tanuljak? -
bnd42 #30281 na már megint nem tudtam aludni éjjel és addig extrudálgattam egy gömböt hogy ez lett a vége...nem tudatosan de szerintem a rakéta porszívó emléke ihlette...
-
#30280
azzal az volt a bajom, hogy elkezdtem modellezni, elkészült az autó úgy ahogy. Utána betöltöttem a vue-t, és rohadtul elállította a gridet meg a kameráimat. Gondolok itt arra, hogy ha a vue kameráját használtam, akkor oké volt minden, de mikor lecsuktam a vuet, hogy más módszerrel renderelek, a kamerát elfelejtette visszaállítani. Belőttem az autót pontosan a képre, és olyan volt, mintha teleobjektívet használnék. az autó kilométerekre a távolban. Ha letettem egy új kamerát, akkor ugyanez volt.
Most már helyre tudom ezt hozni, de akkor még nem tudtam, és erősen kívántam a program alkotójának nagyon sok kistestvért. -
#30279
csak annyit szólnék az egész mr sun and sky és hasonló megoldásokhoz, hogy VUE ;) -
#30278
jajj tényleg, régebben már én is beszereztem, de soha nem használtam. thx -
#30277
Röviden: xfroggal.
Még rövidebben nem én csináltam a fákat, azok már készen voltak, én csak beimportáltam őket a maya pluginnal, de a külső standalone xfroggal módosítani lehetett volna őket. Ágak sűrűsége magasság, vastagság, etc. -
#30276
az első az ilyen mennyország stílusú :D legalábbis én ránéztem és tökre olyan érzésem lett, mintha mennyország lenne :D
am a 2. képen a fákat hogy csináltad?
-
#30275
Tessék, ez lett a ibl+megatk render. Kicsit nem értem miértlett ilyen sötét, mikor a renderviewben meg pont jó világos. Talán a color manage miatt. A régebbi renderrel első ránézésre tételekkel rosszabb: Holott mindkettőnél ugyanaz a color management. A ház picurit újra lett építve, most elviekben kompatibilis az UDKval.
Régebbi:
Visszatérve, ehhez a ibl megvilágításhoz nekem szükségem lenne egy csomó felhőzetre. Ha egyszer csak letekerem a napot, és azt mondom most naplemente van, akkor új felhőt kell kikeresni, és akkor pontosan oda kell tennem a napot, ahol a felhőzeten is van. Legalábbis így célszerű. Ez sokkal kötöttebb ilyen téren. Sun&Skyban oda tolom a napot ahová akarom, és magától kitalálja az alapszíneket. Villámgyors, hogyan fog kinézni rendernél, számomra most még az egygombos makeitbeautyful a tutinyerő. Ha már abban kitaláltuk, milyen napszakban mutat jól, akkor elő lehet venni a komolyabb időigényesebb technikákat. -
#30274
amúgy hogy precízek legyünk, elég
dockControl -l "Unreal Grid" -allowedArea "all" -area "right" -content jbU3GridWindow
ez az utasítás is, mivel a ` ` azt jelenti, hogy futtassa le a kódot, és a visszatérési értékét (ami gyakorlatilag egy szöveg arról, hogy milyen néven illetve helyen elérhető az ablak) tegye bele a $dockedWindow-ba... de mivel nem csinálunk a későbbiekben semmit vele, így felesleges letárolni... szóval elég csak simán lefuttatni a két ` közti utasítást... -
#30273
a mel-hez én sem értek különösebben (sőt), annyit csináltam hogy sorról sorra futtattam (sor kijelöl, num enter), és megnéztem mi mit csinál... aztán a súgóban megnéztem a többi layout-ot (ezek java-ból ismerősek), és sorban haladva a c-nél már meg is találtam ami kell :D aztán rájöttem hogy layout sem kell ehhez :) -
#30272
ááá kösz. Így lesz a jó. A sima egysorossal is működik szupi. Sokat kell még tanulnom melből is. -
#30271
de amúgy felesleges is az egész marhaság, mert ha lefuttatod egyszer a nagy scriptet (ugye felugrik az ablak)
a
$dockedWindow = `dockControl -l "Unreal Grid" -allowedArea "all" -area "right" -content jbU3GridWindow `;
utasítással máris dokkolhatod (tehát a parancs hogy dokkolja a jbU3GridWindow -ot (!!!!!, nem a tablayout-ot) jobbra ... nem kell a többi... -
#30270
global string $gMainWindow;
$columnLayout_1 = `columnLayout -parent $gMainWindow -width 180 -height 260`;
$dockedWindow = `dockControl -l "Unreal Grid" -allowedArea "all" -area "right" -content $columnLayout_1 `;
jbU3Grid;
control -e -p $columnLayout_1 jbU3GridWindow;
gyakorlatilag lecseréltem a tablayout-ot column layout-ra (igaz így veszett a scrollable tulajdonság, de ahogy látom az ablakon nincs is minek scrollozódna , legalábbis nálam)... -
#30269
Igen procedure, és showWindow. A teljes script innen: http://www.cgartistry.com/experimentation/scripts/jbU3Grid.zip
És konkrétan ez a gondom vele itt:
De valószínűleg át kellene írni az alap scriptet eleve dokkosra és nem utána bedokkolni, csak nem akartam belekontárkodni a máséba.
-
#30268
nem egészen értem a problémát magát...
-a kód amit belinkeltél azt csinálja, hogy létrehoz egy $gMainWindow nevű String-et,
-lefuttatja a tabLayout -parent $gMainWindow -width 180 -height 260 -scrollable true utasítást (létrehoz egy tab csoportot, aminek a szülője a $gMainWindow, megadja a méretét, és hogy scrollozható legyen), visszatérési értéke egy string az elérési útról, ez bekerül a $tabLayout_1-be
-lefuttatja a dockControl -l "Unreal Grid" -allowedArea "all" -area "right" -content $tabLayout_1 utasítást, ami Unreal Grid nevet rak a címkére, bárhova dokkolható, alapból jobb oldalon kezd, és a tartalma a $tabLayout_1
-kiadja a jbU3Grid parancsot (ami várhatóan egy másik script, ami procedure)
-kiadja a parancsot, hogy a jbU3GridWindow szülője legyen a $tabLayout_1 (ha jól veszem ki)
hogy most ez miben mást csinál mint amit akarsz, azt nem tudom...
lehet hogy más layout fog neked kelleni (van még pár). de ahhoz hogy tudjam hogy pontosan mi a gond, a teljes kód kellene (az is amit meghív), meg mondjuk egy kép, hogy mi is a gond... -
#30267
Magnificat!
Múltkor említetted, hogy mostanában kódra áll az agyad. segíts nekem légyszi, Van egy script mayára, amit szeretnék bedokkolni. ha az ablak már nyitott, akkor simán beírom az egysoros dokkolási parancsot alulra, és tökéletesen beteszi zokszó nélkül. Ha kiteszem ezt az egy sort egy shelf gombra, ott nem működik ugye, hogy magát a programot is ezzel hívni meg, csakis ezzel a megoldással:
global string $gMainWindow;
$tabLayout_1 = `tabLayout -parent $gMainWindow -width 180 -height 260 -scrollable true `;
$dockedWindow = `dockControl -l "Unreal Grid" -allowedArea "all" -area "right" -content $tabLayout_1 `;
jbU3Grid;
control -e -p $tabLayout_1 jbU3GridWindow;
Ezzel csak az a baj, hogy létrehoz föléje egy kis tabfület, ami által az egész lejjebb kerül, és nem fér ki és scrollozni kell. Nem elég, hogy ott van oldalt a tabfül, még a tetejére is betesz egyet. Hogy szedjem ki belőle a felső tabfület?
-
#30266
mert az olyan szintű és típusú párhuzamosítás, amit a gpu tud, nem olyan régóta van... nem is olyan régen még csak grafikai műveleteket tudott a gpu számolni, mára értünk el addig (azaz nem rég), hogy úgy alkották meg a gpu-kat, hogy legyen hozzájuk egy programozási felület (cuda vagy opencl), amivel általános kód is le tud futni. A CPU és GPU magok közt elképesztően nagy a különbség, a GPU csak bizonyos dolgokat tud számolni, de azt valóban nagyon gyorsan... Mivel még nem olyan régóta tud majd bármilyen kódot futtatni a gpu, és mivel még mindig nem alkalmas mindenre, ezért még nem rég vannak olyan render motorok (azokat is fejleszteni kell), amik gpu-val renderelnek. no meg emellett még mindig nem tudnak minden cpu által futtatható kódot futtatni (tudtommal), ezért annak helyét még jó ideig nem fogják átvenni.
Végül pedig nem könnyű jó, párhuzamosítható kódot csinálni. Nem csak annyi, hogy adva van a kód, és azt mondom fusson minden magon vagy shader procin... Úgy kell felépíteni, megtervezni a kódot, hogy az jól párhuzamosítható legyen, és ennek a módszertana még nem olyan iszonyat régi... gondoljunk csak bele, 10 éve még 600 MHz-es PIII-as konfig 180k volt, akkor még úgy tűnt (sőt még jócskán utána is), hogy a procik majd 1-2-3000 MHz-esek lesznek eleinte, aztán majd jól felmennek 10 GHz-re is... de csak egy mag... aztán a gyártás során rájöttek, hogy egyre kevésbé tudják emelni az órajelet, mert nem bírják az elemek, nehezebb hűteni, stb... úgyhogy lett a párhuzamos feldolgozás, amivel utána meg kellett tanulni bánni programozás tekintetében is... és ez kb azóta volt, hogy én egyetemre járok, szóval végtelen tapasztalat nincs még mögötte... iszonyat koponyák dolgoznak rajta időről időre, hogy megkönnyítsék másoknak a párhuzamos kódok korrekt futtatását, de ettől még ez egy totál más gondolkodásmódot igényel...
amúgy nem értem ezt a "ha egyszer nem erre lett kitalálva" dolgot... a kód lett elsőnek cpu-ra kitalálva... -
#30265
Már rájöttem. Csak hát textúra, akkor oda kötni kell valamit gondoltam. Fel sem tűnt az utána levő színnégyzet meg csúszka. Talán mert már késő volt. :)
Csak még arra nem jöttem rá, hogyan tudok olyan kék átmenetes textúrát adni neki, mint amilyen sunskyban van. Ha ramppal próbálkozok, az egész fekete lesz és óráig akarna renderelni. Most minden renderem előtt photoshopban el kéne hozzá készíteni hozzá a gradientet? Marhára nem értem, hogyha a surface shadert beveszi, akkor a rampot miért nem. Ráadásul akárhány tutorialom van, mindegyikben hdri képet használnak hozzá, ezért át is ugortam mindig a fejezetet, mert nem érdekel a hdri. Szerintem soha nem is fog.
Én általában outdoor környezettel, azon belül is mostanában inkább házakkal, épületekkel dolgozom. Alaprendernek eddig tökéletesen megfelelt ez a sunsky cucc is. Aztán majd, ha már lesz egy utcányi házam, akkor elkezdhetek gondolkodni nappali, meg éjszakai megvilágításon. -
Kakaduduka #30264 Hát hogy őszinte legyek, csak belefutottam, még nagyon nem nézegettem, de lehet. Azt nézem még, hogy ezen az oldalon van más is, ez az Arion ha jól láttam akkor GPU-val renderel. Elvileg a GPU gyorsabban megcsinálja nem? Akkor mégis miért nyúzzuk a CPU-t, ha egyszer az nem erre lett kitalálva? -
#30263
a fry render is unbiased render nem? (gyakorlatilag elsőnek renderel egy minőséget, aztán folyamatosan finomítja, ergo nem egyből a tényleges minőséget állítja elő minden pontban, mint az MR és a VRay... ilyen a maxwell is, nagyon szép eredményt ad, gyorsan kiderülhet, hogy jó-e a fény vagy sem (legalábbis nagy vonalakban), ugyanakkor lehet hogy még 5 óra render után is zajos lesz az eredmény... és addig fut, amíg csak engeded (ha 10 nap, 10 nap...) -
Kakaduduka #30262 És ami lemaradt, a link: Fryrender -
Kakaduduka #30261 Igen, én is így vagyok a Physical Sun-nal, a kezdőnek elég, a renderelés egy másik fejezet. De ha már ez a téma, most néztem egy videót a Fryrenderről, nem tudom hogy ismeritek-e. Egész egyszerűnek néz ki, és szép eredményt is ad. Picit körülményesebb lehet, de a minőségnek ára van. :) -
#30260
Kivalo, akkor elkezdem kutatni ezeket a shadereket, meg jobban belemegyek a rendereles rejtelmeibe. Legalabb sosem lesz vege ennek az utnak, hiaba hiszem, hogy mar tudok valamennyit. :)
Csodalatos ez a modern technika! -
#30259
azt kell hogy mondjam, hogy amíg nem használtam vray-t, addig nekem is sokszor a sun and sky volt az első renderem (aztán néha elégedett voltam vele, néha meg összedobtam mást). Az tény hogy nagyon kötött, és hogy akinek konkrét elképzelése van minden világítási részletről, annak nem felel meg, de én, aki alapból nem szeretek renderelni, örültem hogy van egy ilyen beállítás, amivel valamennyire jó képet kapunk könnyen... ezt szeretem a vray-ben is, csak ott még ráadásul a beállítási lehetőség is adott (mégha nem is olyan szinten mint az mr alatt). persze ezt renderidőben kell megfizetni mindenhol, de nem fogok 150 fénnyel világítani egy hobbi projektemet csak azért, mert úgy gyorsabb a renderidőm (ha meg nem animációhoz kell, akkor meg pláne felesleges). Igen, software renderrel is lehet elképesztő minőséget elérni, ha az ember pontosan tudja mit miért csinál és hogy, de én modeller vagyok :D nekem a render csak egy művelet, amivel látványosan prezentálhatom azt, amit modelleztem... :)
persze azért alapvető igényeket én is támasztok, pl hogy post-ban a lehető legjobban lehessen alakítani még a képen, passokba renderelés, vray is tud 16-32 bittel dolgozni, stb...
Peet: azért emlékszel, hogy nálam is mit tököltünk ezzel a surface shaderes megoldással, mivel szép eredményt hozott a templomomon :) -
Obicsek #30258 Nekem az a bajom ezzel a physical sun and sky-al, hogy 1: baromira kötött, allig tudsz állítani valamit és testreszabni a light setupot. 2: mivel próbál helyetted okos lenni, ha állítod a fény irányát, az MINDENT állít. Fény intenzítás, szín, árnyékok softossága, environment színe (és ezzel az FG megvilágítás). Én annó kipróbáltam... és fél óra után a hajam téptem ki. Archviz-re lehet, hogy jó, nemtudom. Engem idegesített csak. -
#30257
nyah, hát ezt meg se hallottam:D
szürke surface shadert nem értem, ibl-en belül kell megadni neki a színt, nem kell hozzá shadert adni.
ezzel a módszerrel is használhatsz dir lightot, annak a szögnek a beállítása sem bonyolultabb, mint a sunsky dirlighté.
renderelni pedig marha jó! -
#30256
a számból vetted ki a szót :D én is utálok renderelni, de muszáj :D -
#30255
Lelkem rajta, kipróbáltam ezt a módszert. Ibl+szürke surface shader. 1db direction light raytrace (1/20/2 árnyékkal. És a renderidő 49 mp volt, míg a sun&sky alap 37mp. Ráadásul ez úgy 37 míg beállítom a nap szögét. Mondjuk 1 perc és render. A másiknál, meg tucatszor rendereltem mire eltaláltam a megfelelő árnyékbeállítást. És még ez is csak nagyon árnyék. A finalhoz meg majd megint tökölhetek vele jó darabig. (persze, aki fejből tudja az értékeket...) Meg a szürke surface shadert is el kell találni. Hát... időben jóval több. Ráadásul nem is photoreál képeket szeretnék produkálni, hanem játék engine szerűeket. Vagy amolyan fantasy világ szerűeket.
Azt nem is számítva, mennyire utálom az egészet. A Renderelés számomra egy szükséges rossz, ami nélkül nem lehet meglenni. Csak annyit szeretnék érteni hozzá, amennyi feltétlenül kell hozzá, a többi részét meghagyom a profiknak. Nekik is kell élni valamiből. -
#30254
szerintem azért használják "sokan" (igazából nem tudom mennyien, de beleértve engem is :D) a sun and sky cuccost, mert 1 kattintás és megcsinál magától mindent egész jó minőségben (mondjuk ezt is félve írtam le, mert nem tudom, hogy tényleg jó-e :D). lehet hogy kicsit lassú, de egy kezdő ilyen szinten úgysem tudja megcsinálni (lehet csak én vagyok a béna :D), így a magamféléknek jó lesz egy darabig. aztán majd ha rátérek a renderelésre akkor ráérek belecsapni a lecsóba és elsajátítani a dolgokat, de addig a célnak megfelel ez is :) -
Rashen #30253 Rendben van, köszi a segítséget Tőled is. Azt hiszem nulláról majd újrapakolom a gépem. A bsp2-t pedig kipróbálgatom ^.^ -
#30252
Rashen, valószínűleg azért szállt el, mert valami displacementet használsz. Approximation editort használni kell, és limitálni a dolgokat. Oda, ahol a sziluett már nem változik, több displacement felesleges, normal mapel sokkal többre mész. Nézd meg MR render globalsban a quality tab alatt raytracing/acceleration-nél, hogy a bsp2-re van-e rakva a cucc. Mióta azt behozták mr-be, azóta nem érdemes semmi mást használni, az egyszerűen annyira zsírkirály.
Másik, észrevettem, hogy az OPrendszered XP SP3, ha jól tudom ez egy 32bites OPrendszer. Ez öreg hiba, azonnal rakj fel magadnak egy 64bites XP-t vagy inkább win7-et ilyen gépre, mert 8gb ramot 32bites XP-n soha nem fogsz kihasználni. Amúgy meg 64bites maya stabilabb, gyorsabban renderel és ráadásul használ 3gb memóriánál többet (azért 3, mert a vidikarid 1GB-ot rögtön le is vesz az egészből). Ezt kb ki kéne írni mostmár a bannerba, hogy 32biten nem mayazunk!
Kakaduduka nálad meg annyi volt a probléma szerintem, hogy amikor a physical sky-t létrehoztad, akkor létrehozta a létező kamerákhoz bekötve a lens shadert, ami a rendszer része ugye, de amikor új kamerát hoztál létre, hogy abból renderelj, abba nem köti be automatikusan. Render globals/indirect lighting/physical sun and sky -> és ott update camera connections.
Amúgy én mindenkinek azt javaslom, hogy felejtse el a physical sun and sky cuccot, mert baromi gagyi. Az a mental ray kb make it beautyful gombja, csak az a baj vele, hogy nem lesz tőle szép.
Lens shadert se nagyon használok, mert postban sokkal jobb a színeket állítani. Kiteszel egy 16-32bites float pointos képet linear workflowban (istenem hány éjszakát kutattam a netet és hallgattam Obicsek kiselőadásait, mire megértettem, hogy mi a tökről van szó:) (-btw, utólagosan is thx Obi:), és postban szépen színkorrekciózol. Lens shader majdnem ugyenezt csinálja, sok különbség nem lesz. De ha használsz lens shadert, akkor legalább a physical lens shadert használjad, mert a simple az gagyi:)
én amúgy azt szoktam, hogy bekapcsolom az FG-t, a következő értékekkel:
accuracy 50, point density 0.3, interpol 30, sec bounces 4. Ez így gyorsan renderel, és egész tűrhető eredményt ad, ez a tesztrender minőség, final renderhez nyilván fel kell majd húzni a dolgokat picit.
indirect tabon fent IBL node-ot adok hozzá, ott kiválasztom, hogy textúra alapján, és annak meg adok egy színt, vagy egy rampot. Vagy persze hdri képet is lehet, ha olyan rendert akarsz, de tesztekhez én egy középszürke színt szoktam alapvetően.
Így kapsz egy olyan környezetet, ami szép szórt fényt vet a modelledre, minden szépen fog rajta látszani.
Mindenkinek javaslom, hogy tanulja meg használni a mental ray production shadereket, vagy mip shaderek, ezek alapvetően rejtve vannak mayaban, nézzetek utána neten hogy kell aktiválni, illetve ott van még a puppet shader is, a MegaTK, az egy nagyon jó kis komplex gyors shader, érdemes vele próbálkozni, majdnem olyan szép eredményt ad, mint a mia_material_x, de vagy 3x gyorsabb és pipeline barátabb!
Nah én mentem nyaralni, 10 nap múlva leszek, de ha lesz net elérhetőségem, lehet benézegetek 1x-2x:)
Üdv néktek!





