63011

Kinetix

"Aki másnak felbontás...!"


  • Geccoka
    #56082
    Valaki korábban már linkelt erre megoldást:
    http://lumion3d.com/
    http://quest3d.com/
    Quest 3D-vel régebben játszottam kicsit, jó cucc.
  • putyi
    #56081
    aztán van vray scatter is, meg legális vray is, meg kifizeted az átállást?
    meg itt jön a régi kérdés: mit csinál 30-60 000 objektumal a c4d. mert adig ok. ,amíg egy ablakt kell lemodellezni, de vajon határidőre el lehet vele készíteni 2 négyzetkilóméteres területet is?
    amúgy ahogy néztem a programokat, ha váltás, akkor modo, de egy csomó dolog miatt egyenlőre nem lesz váltás.
  • zenoka
    #56080
    mondjuk akkor szamitogepes jatek motor kell hozza:D van egy csomo cryengine tol UDK ig mindenfele..
  • hunkircsi
    #56079
    Hali mindenkinek!

    A múltkor találtam egy céget, akik valósidejű 3D-s látványtervet tesznek a megrendelő orra elé. Egész pöpec a dolog, mert a megrendelő egy szimpla exe fájlt kap, amit bármilyen gépen elindítva számítógépes játék módjára mozoghat az általa megjeleníteni kívánt modell világában. Az alábbi linken letölthettek egy példafájlt: demo_01
    A kérdésem az lenne, hogy mi a legmegfelelőbb módszer, workflow, program arra, hogy ilyet készíthessen az ember. Mert néhol nem a fotorealisztikusságtól tojnak a gatyájukba, hanem attól, hogy valós időben repkedhetnek a 3D-ben ide-oda.

    Köszi a válaszokat előre is.
  • ThomasGins
    #56078
    Ha az első 20 oldalt bekopizod a könyvből én átmegyek:)
  • Met
    #56077
    Ez miért probléma? Azon kívül, hogy nem megszokott:)
    Nem értek a programhoz csak kattintgatok benne, azért kérdezem
  • zenoka
    #56076
    "Menjünk át cinema 4dre ott is van vray és jobb a poly egyéb modellezés is, és nem fagy le minden nap 25x"
    cinema4d konyv mikor gyun?:)
  • nenad
    #56075
    2010-2011 -ben az autodesk ott tart, hogy úgy generál alapvető fontossságú parametrikus objektumokat, hogy azok élei stb egymáson keresztül kasul mennek. Ez alapjaiban minősíti az autodesket. Aki teheti dobja a programot amíg nem késő. Ez nem lehet igaz, hogy a programozók ennyire primitívek, sem én sem más scriptiró ilyen primitívségre és hanyagságra nem vetemedne.

    Al-Putyi, az hogy vrayben ezek a cuccok jól képződnek le alapvetően vladó érdeme.

    Menjünk át cinema 4dre ott is van vray és jobb a poly egyéb modellezés is, és nem fagy le minden nap 25x

    Érdekes, most legtöbben azt gondolnánk, hogy na ez biztos kiakadt valamin és azért mondja ez. Alapjában véve már 3dzéshez is hozzá tartozik a szopás/szopatás. Szerintem itt lesz az ideje, hogy olyan szoftvert válasszak amelyik nem szopat, még akkor is ha megszoktam maxot, vagy egyszerűen uj szoftvereket írok hozzá, feltéve ha van időm rá....

    Hihetetlen mint el nem tűrünk a megélhetés szükségességének árnyékában.

    Ez mi ez:?

  • ThomasGins
    #56074
    Állat nagyon!
  • VisualHarmony
    #56073
    A kerék még egy régebbi (Bugatti 1922' type32 tank)modellhez készült és az egész modell:)

    WIRE
  • ThomasGins
    #56072
    Pofás nagyon!
    Küllőket hogy csináltad?
  • VisualHarmony
    #56071
    Nah kicsit haladt a vas, remélem így már nem annyira játék autós:D


    KÉP
  • nenad
    #56070
    a vége az lesz, hogy a kis procik amelyek össez vannak építva grafikus maggal simán leverik a nagy drága procikatz lebegőpontos számításban. Valahogy ez jöl le nekem az egészből. David Buracelli szerint is érdemes lenne ezekből egy szerver szekrénybe betenni egy 10-15racket és akkor kampó lenne mindennek amit eddig használtunk.
  • nenad
    #56069
    az AMD hamarosan debutáló architektúrájáról.

    http://www.brighthub.com/computing/hardware/articles/60144.aspx
    http://cyberneo.info/amd-bulldozer-performance-preview/

    Érdekes cucc, that the amd lépéseket tett annak érdekében, hogy a processor közvetlenül a gpu felé tudja irányítani a lebegőpontos számitásokat... illetve ezek 256 bites pontosságúak.
  • nenad
    #56068
    igen, de az adott távolságra kiszámolható a minta mérete a felbontás alapján stb és mégtalán a subdivs is megbecsülhető.
  • Aldaryn
    #56067
    Mivel screen space, ezért elég egyirányú utca. A renderelés is screen space, egy nyolcszáz méter hosszú anyahajót is csak 2px méretben renderel le, ha az a kamerától 2km-re van.
  • nenad
    #56066
    nem az a gond, a minták mérete a probléma, csak ha kisebbre veszem akkor meg több minta kell a kevésbé zajos megoldáshoz.

    tehát a csít a minták mérete illetve az, hogy a camerától távolodva a minta egyre nagyobb felületet reprezentál a jelenetben. Biztos van erre egy jó egyenlet, majd gondokodom rajta meg megnézem zenokáét is.
  • zenoka
    #56065
    Hetek óta kint van AP cimlapjan:)
  • nenad
    #56064
    bakker ma van ilyen találkozó?
  • zenoka
    #56063
    ap talira josz ma?
  • Aldaryn
    #56062
    Szerintem az nem csít, és nem meglepő, ha kevés mintával kicsi a részletesség, sok mintával pedig nagy. :)
  • nenad
    #56061
    nyilvánvalóan ez okozza a problémát, a minták száma és mérete nem megfelelő. Mivel screen-ről van szó ezért a camera távolsága is beszámít.

    A lényeg az, hogy kiderült a csít. Kell az lcachenek is subdivs illetve a kis mintaméret ahhoz, hogy tartani tudja a szinvonalat. Tehát nem falról visszaverődő fény az oka a világosodásnak amit a többi metódus nem számol ki, hanem csak szimplán kevés neki a param.
  • Aldaryn
    #56060
    Hát, nem tudom, én benyomom a megszokott gombokat, megnyomom a nagy rendert, és mosolygok a kijövő szép képek láttál. :) Már csak ennyire futja az időből. :D
  • zenoka
    #56059
    jah es screenhez scalelve nem worldhoz ez a gyokos szamitasos ize:D
  • zenoka
    #56058
    lcache subdivnal ha jol tudom a kozelitoleg helyes mertek a kivant kepfelbontas hatarozza meg:
    gyok alatt magassag a negyzeten + szelesseg a negyzeten
    mondjuk ezt annyiban nem tudom hogy ez igaz pl a croppolt kepre is vagy ott is egy teljes kepkockaval erdemes szamolni (szvsz az elso).
  • nenad
    #56057
    ..de ha az egész jelentet rendeltem akkor megint nem volt elég a minta, váltottam worldbe és ezerrel a kettő közötti eredményt tolta...
    Cumis a cucc nagyon.
  • nenad
    #56056
    a vicc az egészben az, hogy végül sikerült megoldanom... A lcache mértének állításával, a default 0,02 nem jó, csak a 0,005 körül jött elő ez a helyesebb kép.
    A kis lcache mintaszámhoz pedig azt tudom mondani, hogy fontos, hogy legalább 1000 sdivs legyen. Változik a fényereje a két képnek, ami 500 vagy 1000-el készült.
    Íme a helyes LCaches kép-



    Nincs mese ezt is állítgatni kell jelenettől függően...
  • nenad
    #56055
    csak referenciának egy igazi path tracelt kép. Alapjában véve csak a imapos és bruteforceos képeken látszik az ami a path tracelten egyértelmű. A lámpák nem teljesen a plafonon vannak és emiatt egy sötétebb sávnak kellene megjelennie, de ez nincsen az lcachesen, illetve a falak egymáshoz kapcsolódásánál is több fény van mint kellene.

  • nenad
    #56054
    csak azért nem olyan mert a store with imap be volt kapcsolva. 3 bounce volt bekapcsolva, interiorben ilyen nyilt szobában, ahol se folyosó se semmi bőven elégnek kellene lennie. Szóval nekem meg pont az nem jön le, hogy ott a lcache miért világosat ad mikor a másik fal meg brutal sötét a többihez képest.
    Szerintem az lcache jó, de nem elégséges arra, hogy az imap számítás alapjául szolgáljon.
    Na majd ezt még átnézem, egy leegyszerűsített jelenetben.



    mental ray interpolate glossy, samples 256 resolution same as scene extrem szitukban is jó kell hogy legyen, és jóval kisebb a renderidő. Majd postolok erről is.
  • nenad
    #56053
    az egészben az a legérdekesebb , hogy a lightcache talán azért született meg, mert a sarkok mindég sötétedtek egy kicsit. Nekem valahogy a sotétedősök természetesebben hatnak. És ha a brute forceban sem lehet megbízni akkor miben?
  • putyi
    #56052
    3. projektnek tökéletes. a 4-nél már talán elfelejted a szirupos naplementét. az ablaknak adj vastagságot és nem fog úgy kinézni mintha 1,5m vastag tömör üvegből lenne az utastér.
  • putyi
    #56051
    valami nekem itt nem kerek.

    a brute foce-ból nekem hiányzik az a beégés, ami a többiben bent van. mellesleg egyedül a lightcache-es verziónál látok a mennyezeten falról visszavert fényt. atöbbi olyan, mintha egy-vagykét bounce-ig lenne csak kiszámolva.
  • zenoka
    #56050
    meg mindig az irmap+bruteforce nez ki a legnormalisabban igy ha jol gondolom utomunka nelkul
  • nenad
    #56049
  • VisualHarmony
    #56048
    Szerintem maga a kép nagyon fakó , de a modell az így "messziről" szép.
  • zenoka
    #56047
    igy kicsiben jo..
    ilyen gamer tulhuzott naplementes filingje van..
  • raulrm
    #56046
    Üdv mindenkinek!

    No elkészült életem 3. 3ds max projektje és egyben a 2. autó modellem :)))

  • VisualHarmony
    #56045
    Áhháááá, oksa jegyzetelek mester:)

    Adaptiv dmc AA-t használok. AA filter(Mitchell-Netravali-t használok)? Vagy az kuka?
    Viszont szerintem ha felhúzom az AA-t 1-12; 1-25re ugyan ott leszek render időben nem?

    Több kérdéssel nem pofátlankodok már:)
  • Aldaryn
    #56044
    Arra többféle. Ez a threshold egyben szabályozza az összes dmc samplerelést, ebbe bele tartozik az irradiance maphoz vett minta is. Ha adaptív dmc AA-t használsz, akkor van lehetőség arra, hogy csak az AA mintavételezésének zajérzékenységét vedd feljebb. Ha nem adaptyv dmc AA-t haszálsz, akkor javaslom, hogy használj azt. :) Egy ilyen jelenetnél 1-12, 1-25 mintamennyiséggel jó is kell, hogy legyen.
  • VisualHarmony
    #56043
    Oksa kipróbálom, de a noist azért húztam ennyire mert a padló és a jelentben szereplő bútorok elég vad glosy-t kaptak arra meg asszem ez a megoldás(bár lehet nem).
    A 150subdivet nem értem:D