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õ :)))
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:D
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?
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 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 :)
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!
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. :D 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:D nekem egy ilyen megírása tuti több hetes meló lett volna!:D 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... :D 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.
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? Meg, hogy a windows memory reportálása borzalmasan rossz és azért.
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.
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?
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. :)
Igen! Tudom! Nem akartam felrakni a maya 2013 Extension-re. :) De ez egy bug lesz, most már 80%-ban hajlok rá. Teganp egy total új legális win7-et tettem fel , és feltelepítettem a mayat. A legális vray demo is ugyanezt a hibát produkálta.
Közben találtam egy ilyet is a vray news oldalan: V-Ray: Fixed issue causing random crashes when updating material swatches with VRayCarPaintMtl material or bitmap textures;
Ne feledd, 2013-ból két verzió van. A sima és az extension. A két verzió nem binary compatible egymással, szóval ha 2013as plugint szedtél le, az 2013ext alatt nem fog menni. Mi is sokat szopunk ezzel, mert két verziót kell fordítani a pluginbõl...
razorback ne emlegessünk semmilyen illegális szoftvert pls... ki most a házigazda? tudja törölni a hozzászólást?
Szia!
Köszönöm, hogy foglalkoztál a problémámmal! :) Vasárnap egész nap ezzel foglalkoztam, hogy kiderítsem, hogy mi a probléma. Tehát, hogy pontosítsam a dolgot. Kimondottam ezzel jelentkezett a probléma maya 2013 alatt: V-Ray 2.30.01 for Maya 2013_x64.exe De ugyanezt csinálta a V-Ray 2.20.01 for Maya 2012_x64.exe is. Letöltöttem a demo verziót ezekbõl a chaosgroup oldalról, de azok is ugyanezt a hibát produkálták. Mert egyébként a crack-re gyanakodtam, hogy az okozza ezt.
Ez viszont tökéletesen mûködött: vray_adv_20004_maya2012_x64.exe
Lenne egy problémám, amit nem tudok megoldani. Maya 2013 SP2 x64 alatt jelentkezett, hogy a vray carpaint material-nál a coat colort ha állítgatom, akkor pár másodpercen belül kilép, vagy lefagy a maya. De ugyanez akkor is elõjön, ha a carpaint material flake color színt állítgatom. Ha valaki aki maya 2013-at használ vray-el, és kipróbálná, az jó lenne hogy másnál is adódik-e ilyen. Van amikor egy perc is kell, hogy kiakadjon a maya, de van, hogy 10-15 másodperc állítgatás után fagy ki.
A segítséget elõre is köszönöm!
"Nem mondhatom, ha pl tegyük fel, h ezzel foglalkozok majd,felvesznek vhova és modellezni kell vmit, ahol nem tudom elkerülni azt,h sík felületre kerüljenek az amúgy problémás smoothot okozó részek.* "
*, hogy bocsi ez így nem fog menni, mert pinchelni fog mindenhol, mondjad csávókámnak aki ezt csinálta, hogy rajzoljon egy másikat,"
Én feladom. Mi van akkor, ha nincs sík felület?
Nem mondhatom, ha pl tegyük fel, h ezzel foglalkozok majd,felvesznek vhova és modellezni kell vmit, ahol nem tudom elkerülni azt,h sík felületre kerüljenek az amúgy problémás smoothot okozó részek.
Itt ez a kép, nem is tudom hány órája ezt nézem... Egyszerûen akárhány módszert kipróbálok, szar.
Vízszintes és függõleges tengely mentén bendelt geo, lényeg az lenne hogy úgy nézzen ki control edgekkel együtt, mint a front view, no pinch. 1X sikerült vmit kihoznom,ahol nem látszott a pinch, viszont a fény rosszul tört meg rajta. Pedig viewportban nagyon minimális volt a hiba. Fõleg azokkal a szélekkel van bajom, amik a balo oldalt vannak, ahogy ott bemegy a cucc. A függõleges élesség meg van, de a vízszintes lehetetlen. Nincs megoldás. Ötlet? Hátha okosabb leszek, aztán többé nem kell ezekkel szarakodni. Ennyit,. Talán.
én betennék még egy loopot a kör köré, és ahhoz kötném akkor már inkább az alulról jövõ edge flowkat, úgy a kör nem fog pinchelõdni. A pinchelõdõ felületeket mindig érdemes sík részre tenni, ott nem tûnik fel, hard surfacenél ez elég nagy elõny...
Fúj? Mi fúj? :D A szél? Egyébként teljesen mindegy hova teszed, az edge slide tool-al bármikor tudsz változtatni ha szükség van rá. Csak select edge loop - edge slide és eltolod.
Fúj. De végülis mûködik, kössz. A control edgeket hova tennéd? Amik függõlegesen creaselik a széleket?
És van egy jó tutorial arra, ami segít abban, hogy ha görbe felületre kerülnek edgek szorosan egymás mellé és kevés a hely, hogy odébtologassam õket, hogy oldjam meg a pincheket? Ami tutorialokat megnéztem, vagy csak 1 control edget használnak mert nem kell nekik olyan éles sarok, v egyenes felületen dolgoznak, ahol nem számít az edgek közelsége.
Illetve, mivel a perspektíves képet utána néztem meg, a középsõ piros vonal nem játszik. Ez
A lényeg az lenne,hogy a cucc alján lévõ, itt különlevõ téglatest díszelemek a fõmodell részét képezzék. Tehát ne csak rá legyen dobálva,mint most, hanem belõle jöjjön ki, mert a) így kérik b) Én akarom "pro szinten" megcsinálni és úgy terveztem, hogy látni, ahogy egy enyhe ív van dísz és a modell közt,mint átmenet.
A kérdés, hogy hogy tegyem egybe õket úgy, hogy nem rontja el a lyukat meg az extrudeokat, ami felette van. Tegyük fel a bonyolultság kedvéért, hogy olyan megoldás kéne,ami mondjuk 3x ennyi díszelemmel is mûködik,mind megámogatva support edgekkel, hogy a függõlegesen futó szélek szép élesek legyenek, de a lyukat ne tegyék tönkre.
+ kérdés, az 1. kép jobb oldali változatához. Mennyire baj, ha akarok bele egy kis ívet és beleteszek oda 2 edget? Jó helyen vannak egyáltalán? a lyukat tönkrevágják smooth previewben, ahhoz hogy jó legyen feljebb kellene tolnom azt a 2 vertexet. Toljam feljebb? Akkor meg nem lesz szabályos 8 szög. :C (Igen, ilyen dolgokon vagyok felakadva).
Amúgy a modell kis kaksi 10mp-es baromkodás,tehát semmit nem akarok kihozni belõle, csak ha legközelebb belefutok olyan problémába, ahol a modell olyan bonyolult és nem darabokból van összerakva / a darab maga is kurva bonyolult, és ilyen egyszerû mintákat kellene beleilleszteni, akkor hogy oldom meg a topológiát,support edgestül meg mindenel együtt.
Hát, egyelõre itt tartok(lábakat még nem javítottam teljesen, ráuntam a modell bökdösésére, inkább anyagoztam)..
A feje tetejére lehet, hogy megpróbálok olyasmi vonalvezetést, domborulatot átvinni, mint ami a hátán van)az a szuper-aerodinamikus háromsávos taréj-szerû kiemelkedés. Aztán meglátjuk.:)
szerintem is szép lesz, tegyél még valamit a feje tetejére is :)) csápokat, amit észrevettem a szárnyaknál a gyûrûk furán állnak itt-ott de amúgy tényleg jó, olyan mesefilmes
Nézd és tényleg! Úgy emlékeztem, csak az elsõ pár lábuk hajlik elõre. De majd még nézek pár referenciát. Nekem sem tetszett a lábak "mûködése", de valahogy nem tudtam kitalálni, hogy hogy is kéne összerakni. A fejjel nekem nincs nagy bajom, de remélem a többiek is hozzászólnak, aztán ha szerintük is úgy van, ahogy mondod, akkor átdolgozom. (na, meg még ott a textil anyaga, ami túl vastag, meg a motorja mögötti része, az a lemez, ami körbefut... hát az nagyon kiugrik, vagy nem is tudom..)
Szóval van még rajta javítanivaló, köszi, hogy felhívtad párra a figyelmem.
Jól alakul. Nekem a lábai nagyon nem tetszenek, nagyon eltér az alap designtól. A rovarok lába elsõ ízület után visszahajlik felfele, és onnan le a földre. Ezen kívül igazából lehetne alaphelyzetben a földön, mert így már kezd egy gombostûvel kitûzött rovar hangulatot sugallni. A fejét is módosítanám talán, kicsit tojásosabb formára, az is eléggé eltérõnek tûnik a számomra. Amúgy ügyes munka, jó lesz ez! :)
Ejj, rég mutatkoztam itt, de azért olvasgatlak titeket folyamatosan. Én ezzel igyekeztem ma, barátnõmnek készülget..
szerintem amit keresel az a hard surface modeling lesz, próbálj meg ilyen tutorialokat keresni
És a karikásról van szó, a papíros nem tûnik annyira vészesnek.
Létezik vmi jó tutor arra, hogy lehet a kész modellt korrekten "megedgeloopolni"? Van ennek vmi neve egyáltalán?
Mikor a széleket support edgekkel aggatom tele, hogy subdivnél szép "feszes" legyen. Kipróbáltam egy szelektív hulladékgyûjtõn, de valami borzalom volt megcsinálni is.
Itt vannak. . Ezeket használtam alapnak,szépen meg is oldottam az egészet,de azok a hosszúkás kidomborodások nagyon betettek.
Pont alatta vannak a bedobónyílásnak,ha belevezetemvezetem az edgeket akkor az a baj, ha elvezetem mellette az a baj, mert egyszer belelóg és összeb*sz mindent, másszor meg túl sûrû lesz,ha mellette vezetem el. És még a support edgek rajta sincsenek. Minden egyes edge loop amit betettem, úgy éreztem, hogy egyre szarabb lesz. És a végén elég hányadék jött ki. Úgy néz ki, ahogy kell, kb 90%-ban, de égis úgy érzem, nem "produkciókész". Nincs vmi tutorial, ami segít ilyen helyzetekben?
Köszi :)) azért még van vele munka, sok a finomítani való apróság, pár nap alatt raktam össze, ez amúgy meló, egy kis stúdiónál dolgozom ahol az volt most a kérés hogy legyen egy kolibri szerû madár óra alkatrészekbõl, kaptam rá keretet hogy vegyek pár óra modelt, azokat kibeleztem és hajrá, legózás