Maya

Hát jó,nem számoltam másodpercre pontosan, de ahhoz elég volt, hogy egy értékváltoztatáshoz képest elérje azt, hogy elindítsak egy böngészõt és netezgessek,míg õ gondolkodik. 1 perc tuti volt. Ha nem 2.

Ha a Maya füst meg nem jó,akkor mi a jó,ami van Mayához? FumeFX-rõl hallottam,h kijött,de sokat nem tudok róla, csak hogy boldog-boldogtalannak megvan Maxhoz.

+ Van vmi GPU gyorsítás Mayában?

Ha meg már itt vagyok: Vannak must have cuccok Mayához,amirõl nem tudok?

PL. az új modellezõs cuccok 2014ben nem tûnnek rossznak viszont a büdös életbe' nem hallottam a Nex toolsról. Hátha vannak még olyan dolgok, amikrõl nem tudok. Pluginok,scriptek, akármi . Righez,animhoz nem kell semmi, azt nem akarok. Nem jön be.

Meg még esetleg vmi ahhoz, ami leírja esetleg, hogy bizonyos anyagok eléréséhez milyen beállítás kell?
Mittudomén aranynak ekkora reflectionje van, meg ilyen specularja, a márványnak amolyan, krómot így kell csinálni.

Milyen számolást indítasz a viewportban? Szimulációt? Az még szép, hogy ilyen gyenge gépen (értsd nem 3d munkára összerakott) sokáig tart. Gondolom a tutorial jóval erõsebb géppel számolt, és kész. A maya füst sosem volt jó, vagy gyors, vagy szép. :)

Arnoldban pedig, ha állítasz hdr képen értéket, akkor a shading networkot kiszámolja amit belekötöttél. Ha lassú a géped, akkor az megakasztja a maya-t. A display részen (vagy viewport vagy valami liyesmi), ezt a felbontást le lehet venni, és akkor gyorsabb lesz. De az 1-2 perc az tuti túlzás, még egy ilyen gyenge gépen is.

Mi okozza azt, hogy Arnoldban, ha betöltök egy HDR fájlt, renderelk, exposure, intensity értéket állítok és MINDEN esetben ezek közül, beszarik az egész program 1-2 percre,mielõtt újra használhatom. A füst is kurva lassú. Elindítom viewportban a cuccot hadd számolja, és a tutorhoz képest,ami alapján csináltam 5-7X lassabb framenként. A tutor 3 éves kb, a gépem meg 5. E8200 proci, meg 2Gb DDR2 ram. Melyik fogja vissza jobban?

És mit értetek übershader alatt? Ez most teljesen új fogalom volt nekem. Totál nem vagyok képben az ilyesmikben. Ez valami cgfx megoldás, vagy mi a túró? Azok meg nem videokari függõk? Az én gépem még annyira sem jó, hogy a viewport 2 elinduljon, szóval kilõve az ilyesmi jelen pillanatban. De totál nem értem, mit mondasz.

Jó volna olyan, ami minden rendermotorral megy, és van is ilyen. Úgy hívják lambert, blinn, meg phong. Csak ezzel nem úgy jön ki a linear work, ezt már én is tapasztaltam. Amíg nem próbálkoztam ezzel, addig tök jók voltak.

Na az indentálást kilõtte a fórum, bocs.

Nah, elkészült, berakom ide alulra, hátha van egy kettõ észrevételed. Kapszulákat rak a függvény a jointok közé. Amit próbáltam kérdezni, hogy ha megvan egy mátrix, azt ráállítani egy másik objektum transzformációjaként. Ahogy olvastam worldMatrixet nem lehet kötözgetni, translatian, rotation, scale az ellenben megy.

def joinTraversalDFS(node):
print node

# process parent node
worldMatL = cmds.xform('%s'%node, q=True, ws=True, m=True)
worldMatM = om.MMatrix()
mUtil.createMatrixFromList(worldMatL, worldMatM)
mTransformMtx = om.MTransformationMatrix(worldMatM)
trans = mTransformMtx.getTranslation(om.MSpace.kWorld)
quat = mTransformMtx.rotation()
eulerRot = quat.asEulerRotation()
angles =

children = cmds.listRelatives( node, c=True )
if children:
# get bone height from first child
worldMatL = cmds.xform('%s'%children<0>, q=True, os=True, m=True)
halfDist = worldMatL<12>/2.0

# create default capsule at origin
boneName = 'bone_%s' % (node)
cmds.polyCylinder( n='%s'%boneName, r=1, h=worldMatL<12>-2, sx=16, sy=1, sz=4, rcp=True, ax=(1,0,0) )
cmds.makeIdentity( boneName, apply=True )

# place capsule at parent joint joint
cmds.setAttr('%s.translate'%boneName, trans.x, trans.y, trans.z, type="double3")
cmds.setAttr('%s.rotate'%boneName, angles<0>, angles<1>, angles<2>, type="double3")

# position capsule between the parent and child joint
cmds.xform(boneName, r=True, os=True, translation=(halfDist,0,0))

for jointIt in children:
joinTraversalDFS(jointIt)


Meghívni a root jointra, és akkor bekapszulázza a joint chaint - joinTraversalDFS('jointChainRoot')

Elég lekérdezni a mátrixot, és azt beállítani, felesleges komponensekre bontani.

De biztos ezt akarod csinálni? Nem jobb kötözgetni a dolgokat? Vagy constraineket használni?

Köszi, sikerült megoldani.
MDagPath segítségével lekérdem a forrás objektumról a MFnTransform mátrixot, megszerzem ebbõl a translate, rotate és scale értékeket és setAttr paranccsal beállítom a másik objektumra.

Esetleg transformation node-t nem lehet létrehozni MFnTransform-mal, és ezt beállítani egy másik objektumra, jóval elegánsabb lenne! :) Valami hasonlóra gondolok, mint amit alul ír a hozzászóló.

Transzformációk kezelésére, állítására, számítására MTransformMatrix (vagy MFnTransform). A scene beli elemek bözgetésére MDagPath, MSelectionList, MItDag (vigyázat, lassú... jobb manuálisan traverselni a scenet) és MFnTransform.

Csinálj egy shadert (vagy többet), ami közös a rendermotorok között, ha sima node-kat kezdesz összekötözgetni akkor az elõbb utóbb szétesik a különbözõ programok között. Így meg tudsz saját linear workflowot megvalósítani benne.

Az, hogy most sok kicsi shader, vagy egy nagy... Ez örök vita. Az osl-es rendszereken kívül a sok kicsi shader mindig lassabb lesz mint egy jól megírt übershader. De a szokás az, hogy van egy übershader és abba van belekötözgetve pár kisebb graph. Ez ami megfelelõen rugalmas és kellõen gyors.

Nekem most olyan van(lesz, nincs teljesen kész), hogy kijelölöm a vieportban ami akarok, rábökök a material ikonjára, akkor létrehozza, és rádobja. Aztán felugrik egy ablak, amiben be lehet kötni az összes textúra elérését és lesz mellette egy check, hogy akarok-e gamma correkciót, ha akarok, akkor azt is létrehozza és beköti. Meg az összes megadott textúrát.

Na erre gondoltam magamnak, az elsõ fele kész van.

Jelenleg is per textúra van.

Értelme az lenne egy ilyen file node-nak, hogy nem csak egy rendermotort használok, hanem többet is. Ugyanazt a képet, többel is megnézem, és eldöntöm, melyikkel lesz jobb. Számomra egy átok, hogy minden egyes valamire való rendermotor, de saját shadert használ. Persze tudom, miért, de akkor is. Ilyenkor átkötözgetni mindent, újramaterialozni. Rengeteg idõ és macera. Ezért is örültem meg neki, mikor eszedbe ötlött, hogy meg lehet oldani a dolgot mia materiallal is.

Minden egyes color textúrához, betenni a gamma correctet számomra feleslegesítõen idegesítõ. Az egyszerûsítés híve vagyok, ami lehetne egy lépésben megoldani, akkor azt miért kelljen 3-ban vagy 10-ben. Ha egyre inkább elterjed ez a linear workflow, akkor miért nem vonják össze a két node-ot. És az attribute editorban a file tulajdonságok mellett ott virít a gamma correkció is. Ugyanúgy mûködik, mintha külön lenne, csak egyetlen node és nem kettõ van ott.

Igen, Arnoldban, lehet globálisan, de a többiben nem, vagy nem olyan jó, ahogy Peet mondja, tehát marad a per textúra. A default gammára a .454-et értem, vagy .453, kinek melyikkel szokta, egy ezred nem sok különbség.

A másik ilyen a mental ray lightportal. Csinálni egy area lightot, bekötni a light shaderbe a portalt. Mennyivel egyszerûbb lenne, egy olyan lámpa, ami eleve egy portal light. Nevezzük, mondjuk areaportalnak. Create areaportal, és megjelenik a viewportban egy piros arealámpa közepén egy P betûvel, hogy meg lehessen különböztetni, és nem kell kötözgetni bele light shadert, mert alapból tudja.

Azok most biztos, hülyének néznek, akik úgy vélik, hogy jobb, mindent atomjaira bontani, és akkor mindenki, azt kötözget össze, amit akar. Minden egyes szubrutint külön dll-ben elmenteni, hogy aztán újrafelhasználható legyen más programoknál, programozási szemlélet, és nem felhasználói.

Vagy legalább lenne egy node group, és akkor az attribute editorban együtt jelennek meg, egymás alatt az értékek. Bár, jobban belegondolva, asset-tel, lehet, hogy meg lehet csinálni. csak annak nem tudom milyen lenne az input output része.

Sziasztok,
ha már python elõ jött, nekem is lenne egy kérdésem.

Ki milyen módszert használ maya scripteknél a mátrixokkal kapcsolatos mûveletekhez, illetve milyen módon kérdi le, és állítja be egy objektum transzformációs mátrixát?

Sima mel esetén nem nagyon találtam tiszta, egyszerû megoldásokat, python jóval kézenfekvõbbnek tûnik. Többféle képen is sikerült lekérdezni és dolgozni a mátrixszal, viszont sehogy se tudom ezt a mátrixot alkalmazni mondjuk más objektum térbeli pozíciójának beállításához.

legyen egy sima kocka, vhova bepozicionálva:
cmds.polyCube( n='myCube', ch=1, w=5, h=5, d=5, sx=1, sy=1, sz=1 )
cmds.setAttr('myCube.rotate', 0, 30, 45, type="double3")
cmds.setAttr('myCube.translate', 4, 5, 7, type="double3")

1) MScriptUtil-t használva:
mUtil = OpenMaya.MScriptUtil()
worldMatL = cmds.xform('myCube', q=True, ws=True, m=True)
worldMatM = om.MMatrix()
mUtil.createMatrixFromList(worldMatL, worldMatM)

2) MFnTransform
selList = om.MSelectionList()
selList.add('myCube')
mDagPath = om.MDagPath()
selList.getDagPath(0, mDagPath)

transformFunc = om.MFnTransform(mDagPath)
mTransformMtx = transformFunc.transformation()

Hogy tudnám beállítani a kapott, és mondjuk módosított új transzformációkat más objektumra rárakni?

Elsõ esetben xfrom-al kéne beállítani gondolom, de nem találtam meg a createMatrixFromList "inverzét", ami a belsõ reprezentációból visszaforgatja a 16 float tömbbe.

Második megoldásnál meg egy másik DagNode-ra kéne alkalmazni a dolgot.

Ezt nem tudod csak pythonban megoldani.

Egy, pythonnal tudsz olyan node-t írni, ami ezt neked megcsinálja, de az a renderben nem fog látszódni. Mental Ray-hez, és Arnold-hoz külön shadert kell írni (V-Ray-t nem ismerem, de valszeg ahhoz is), hogy ezek rendertime is mûködjenek. Export time alatt esetleg tudnád módosítani az exportált hierarchiát, de ezt csak MtoA-ban tudod megcsinálni, mental ray és v-ray nem ad hozzáférést az exporterhez (vagy ha igen, akkor is csak macerásan). És ehhez persze c++-ra van szükséged nagyrészt.

Kettõ, használd a beépített gamma correct node-t, és expression-el meg tudod csinálni, hogy egy (vagy jelen esetben több) hozzáadott extra attribute tudja vezérelni a gamma attribútumot. Ez folyamatosan számolódik maya-ban, és ekkor nem kell a renderelõhöz írnod kiegészítéseket.

De pl ennek a node-nak az ötlete nekem furának tûnik, mit akarsz elérni vele? Pl arnold-ban van lehetõség gamma korrekciót használni központilag a nem float-os textúrákra. (gondolom mental ray-re és v-ray-re is igaz ez) A use default values pedig mire vonatkozik? A gamma korrekció értékére? (linear workflowhoz globálisan kell ezeket az értékeket meghatározni, érzésre rossz lesz per texture beállításokkal)

én olyat csináltam mel-ben, hogy amikor új shadert hozok létre, akkor automatikusan létrehozza a gamma correct node-ot beállítva a megfelelõ értékre, amihez vagy egy ramp vagy egy file van hozzákötve.
persze a legjobb az lenne, ha a file node-nál állítható lenne, hogy milyen gamma korrekciót végezzen rajta, de a maya beépített gamma correction valamiért sose mûködött még jól...

Na elkezdtem pythonozni. A GUI-t már sikerült megcsinálni, és azt hiszem kezdem megérteni a dolgot. Alap tekintetében sokban különbözik a meltõl.


Volna egy érdekes kérdésem a témában:

Adva van két node. mondjuk a maya file és gammacorrect. Ezt a kettõt pythonnal össze lehet vonni? Értem azt, csinálni egy új file node-ot, amiben lenne egy checkbox, hogy use gamma correct. Egy másik checkbox, hogy use default values, vagy custom, amivel értékeket lehet adni..

Ez most csak egy ötlet, de számtalan ilyet tudnék kapásból felhozni. Meg lehet csinálni? Vagy szükség lenne az adott node(ok) forrására?

ránéztem erre a pymel-re, hát érdekes, kicsit olyan objektum orientáltnak tûnik, abban meg aztán végképp nem vagyok járatos sajnos, pedig kéne...

Kösz. Hát lehet, hogy akkor tényleg ez lesz. És inkább xml részemrõl átláthatóbb.. Most vettem észre a minap, hogy az a pymel már benne van a 2011-ben, de azért leszedtem a legfrissebbet is. Majd elkezdek ezzel is ügyködni, majdcsak belejövök elõbb-utóbb ebbe is.

Értem. Ilyen esetekre pl jobb lenne egy python, és pl xml-ben vagy json-ba lementeni az egyes adatokat. Rugalmasabbak, és nagyon jó beépített libek vannak a kezelésükre.

A pluginek lekérdezésére :

pluginInfo -q -loaded mtoa;

ill

import maya.cmds as cmds
cmds.pluginInfo('mtoa', query=True, loaded=True)

Egy kis off(on)topic. E3 alkalmából a Digic ismét megmutatta mire képesek, mindegyik maya és arnold. A watch dogs a legjobb, a többi sem rossz azért. :)

Watch Dogs - http://www.youtube.com/watch?v=Q1DS3RAAofc
AC4 - http://www.youtube.com/watch?v=T4rLOcNCXek
AMD reklám - http://www.youtube.com/watch?v=MQcjEA3it90

Konkrétan egy toolboxon dolgozgatok maya alatt, ami kiváltja nekem teljesen a shelfet, meg a status linet. Elméletben ugyanúgy van, mint a shelfnél, hogy a gombok listázva, külön fileokban vannak, amik includeolva vannak a programba. És volna neki egy ablak, ami ugyanazt funkcionálja, mint a shelf editor, amivel további gombokat lehet(ne) hozzáadni. Szóval meg kell nyitni a filet, és hozzáadni az új gombot, illetve kitörölni, szerkeszteni, stb. És elmenteni, majd frissíteni a toolt.

Meg olyasmi is kéne, amivel lekérdezem, hogy egy plugin be van-e töltve. Például a lámpák résznél, megjelenjenek az mr fények is, vagy csak a standard, meg ilyenek.

É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.

Példa.

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. <#idiota>

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..

Mariska már megy a HD79**es szériával.

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

test értem amúgy memória kell még gondolom

De köszi!!

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!

Based on Banshee from Starcraft

ü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.

Ha azt mondom, hogy nem, veszel jobbat? :)

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.

Sziasztok!

Ezzel a géppel rendelkezem.:

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. <#pias>

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