jestli jsi ten, co jsem po nem musel predelavat Miss, tak bud rad, ze Te neznam :-))
ale je pravda, ze tech lidi bylo vic, takze asi puvodni system nemusel byt spatny
Nechci prudit, ale s VRML jsem si hrál někdy v roce 2000 a od té doby mám pocit, že to čím dál víc umírá. Tehdy byly nějaké podpory v prohlížeči a teď po tom neštěkne ani pes, nebo se pletu?
To se nepleteš, textový formát pro ukládná modelů ? má autor představu kolik mají dnes modely vrcholů ? O "rychlosti" interpretů a renderů VRML raději nemluvit. Tohle je jenom hračka.
Jde o to, na co se VRML pouzije. Samozrejme i na modely ziskane skenovanim (to je vlastne ten nejhorsi format, bez vyhlazeni povrchu apod.) jde VRML pouzit (a pouziva se - viz ona zminovana Minolta Vivid).
Mate predstavu, jak se zmeni velikost souboru s 3D ploskami pri ulozeni do binarniho formatu? Kupodivu ten rozdil neni nijak velky, cca 20-30%, ovsem musi se pouzit ty spravne VRML tagy.
Mimochodem - objevila se tady zminka o X3D. Ten je pro jistotu zalozeny na XML, takze taky tvori pekne bumbrlicky.
20-30% ? leda tak když budu zapisovat "nepřesně" pomocí dvou číslic nějaké krabice ale co složitější detailnější model kde je v souřadnicích vertexu nezbytně hodně numer (detailní struktury) ? už i ta pohybová souřadni jich má hafo - "0.053033 0.000000 0.053033," - hned osm znaků, tomu říkám humáč. Ale to by se dalo, HDD jsou velký internet rychlej ale ty aplikace v kterých se tohle používá... blé. To už je lepší si napsat vlastní engine a render a firmy to taky dělají, třeba v Javě, pomalost plus mínus stejná (i s odleskama a global illumination !) ale funguje to alespoň všude.
Osm znaku je snad v pohode. Nebo snad double ma min nez osm bytu :-) (a pri pouziti fixed pointu bych taky neriskoval pouze 4 bytu, ale aspon sest). Nehlede na to, ze 0.000000 snad rozumny program nemusi zapisovat ne? Stejne tak ten prvni bych zapsal .053033.
Jde spis o to, ze se souradnice vertexu daji napsat do jedne struktury a spojnice vertexu (trojuhelniky) do druhe struktury. Ty spojnice jsou celkem kratke - pri 1000 vertexech pouze ctyri byty. V porovnani s nekterymi binarnimi formaty, ktere zapisuji kazdy trojuhelnik zvlast, je VRML dokonce uspornejsi (ale to uz jsme nekde jinde, uznavam).
Je jasne, ze vstupne-vystupni rutiny jsou u textoveho formatu mnohem pomalejsi, nez nacitani binarky - o tom neni sporu.
Většina formátů ukládá stripovaně bo už to tak dostanou z modeleru. Unwrap na samostatné trojúhelníky ? proč proboha ? které prasecké formáty to takto dělají ? VRML... ;-)
Jednak je pomalé načítání ale o to zas tak nejde to se udělá jednou, jde o rendering v realtime, v době kdy byl VRML aktuální jsem neviděl render který by nebyl pomalý jak prase... a dneska už tenhle formát nikoho nezajímá, každý průměrný student si nadefinuje lepší proprietální i s napsáním enginu a renderu nebo si napíše importní modul třeba pro formát 3DMAX Studia, blenderu nebo čehokoliv...
Rendering v realtime - pravda, v dobe, kdy VRML vznikl moc 3D aplikaci v realtime stejne nebezelo :-) Snad krome Descenta, ale i ten mel tusim portaly predpocitane a ne generovane az po nacteni modelu. A i ten Descent by mel problemy se skutecnymi 3D objekty (zadne sprity), ale to je uz na jinou diskusi.
Otazka je, jestli struktura formatu ovlivnuje rychlost renderingu - jak proboha? Stejne si to kazdy engine nacpe do sve vlastni datove struktury a potom si treba (kdyz se uz bavime o realtime) vypocita occludery, portaly, hierarchicke mrizky, BSP nebo neco podobneho. No a kdyz to neni realtime aplikace ale hi-end renderer, tak si opet tu scenu vezme, vytvori neco na zpusob stromu objektu+BSP a zase renderuje - proste ten vstupni format na front-end renderovaciho engine nema zadny podstatny vliv.
Teda nepocitam SGI, ale VRML je v tomto ohledu podobny OpenInventoru, takze na SGI to problem nebyl (narozdil od PCcek, ktere v dobe rozsirovani VRML taktak utahly Windows, natozpak nejakou 3D aplikaci). Pravda je ta, ze prohlizecu VRML se okolo roku 1995-1998 vyhrnulo spousta a byly dost primitivni.
Mozna se kazdy bavime o trosku jinem tematu. VRML jiste neni dokonaly, ale alespon EXISTUJE a je rozsireny (staci se podivat, co ktere programy nabizi za import a export). Ten skvely format, ktery prumerny student vytvori, az tak skvely nebude, protoze se s dosti velkou pravdepodobnosti pouzije prave v jednom jedinem projektu, ktery nakonec odevzda jako semestralni projekt nebo diplomku. Pak - konec. I kdyz (ponevadz jsem grafiku na VS par let ucil) az tak nemam iluze, ze se mu podari napsat format lepsi nez VRML napriklad ohledne aktivnich objektu, hierarchickeho modelu sceny, ale to uz je jina vec.
Naproti tomu v prumyslu si tezko vytvorite vlastni skvely format, vetsinou byva mnohem lepsi pouzit nejaky stavajici (i kdyz to bude treba DXF, ktere je na 3D mizerne). To je prave duvod velkeho rozsireni formatu zalozenych na XML - je to silene slozite na zpracovani i objem dat, ale vysledkem je format (idealne s DTD), ktery ma sanci na kooperaci mezi ruznymi aplikacemi a taky na moralni preziti minimalne nekolik let. Jako programator jsem se samozrejme priklanel k variante navrhnout "co nejlepsi" vlastni format, ale praxe je opravdu trosku jina (pokud tedy nepracujete pro monopol, ten si vlastni formaty muze dovolit prosadit :-)))
Mam dojem, ze prave tak X3D vzniklo - nekdo potreboval VRML zapsat XML syntaxi, tak se vyvinul novy format. Docela to chapu, protoze nastroji na zpracovani XML je dneska opravdu hafo. V dobe vzniku VRML jeste SGML-like jazyky nebyly tak rozsirene (krome HTML, samozrejme), tak se zvolil C-ckovy zapis, ktery uz predtim pouzival zminovany OpenInventor.
To je problem vice formatu nepropagovanych silnou firmou (SGI uz mezi velke hrace nepatri), ovsem zrovna pro VRML toho existuje docela dost, http://cic.nist.gov/vrml/vbdetect.html
Haha, dobrej vtip. Tenhle formát byl mrtvej už v době, kdy nám jím před šesti lety pletli hlavu na fakultě. A to jsme to museli ještě skriptovat a ovládat javou. Najít nějaký historický plugin, který by tohle uměl, a úspěšně ho nainstalovat, už to byla akce jen pro ty nejotrlejší.
A herní firmy místo toho aby napsaly lepší a rychlejší prohlížeče VRML s lepšími možnostmi skriptování a použily je a pomohly tak komunitě raději znovu vymýšlejí celý 3D formát od začátku.
Vykradou nápady z VRML a vyškvaří na svém Second Life a WoW Online spoustu peněz.
Vaše posmívání se VRML není fér, ono tu bylo první dlouho před teenagerovskými herními "endžajny".
uvést, na čem to VRML prohlížet. Kdysi jsem měl Cosmo Player, ale Netscape už nemám, Mozilla a Firefox to neumějí. V repozitáři Mandrivy jsem našel jen white_dune, která ovšem při pokusu instalovat přes HardDrake chcípne a zůstane viset.
Přestože mám VRML rád, tak mám trochu pochybnosti o jeho smyslu do budoucna, zejména pak pod GNU/Linux.
VRML mělo sílu právě v prostředí WWW prohlížeče, plugin znám FreeWRL, ale ten mi načte jen jednodušší světy.
wings3d mi hlásí Erlang (BEAM) emulator version 5.5.1 [source] [async-threads:0] [kernel-poll:false] Eshell V5.5.1 (abort with ^G)1> Segmentation fault (core dumped).
vrweb mi ani jeden z mých souborů, které normálně v Cosmo Playeru (dokonce i ve FreeWRL) běží nenačetl.
gtklookat se chová stejně jako vrweb.
Osobně se domnívám, že VRML bude zapomenuto a jako nový jazyk pro VR bude k dispozici KML 3.0 (dnes je pouze 2.2 a zdaleka se neblíží možnostem (teoretickým) jazyka VRML).
No a ted se nachazime v takovem mezicase, kdy se hledaji nove cesty vyvoje. VRML naznacilo (a implementovalo) spoustu moznosti ze strany VR, z druhe strany jsou tady vyrobci her se svymi enginy podporujicimi skriptovaci jazyky. Mozna dojde ke spojeni techto dvou technologii, protoze co si to nepriznat - komercni vyrobci her vetsinou vytvori praktictejsi aplikaci, nez univerzity. A naopak univerzity maji spoustu moznosti v hledani novych cest vyvoje.
Hry typu Duke nebo Quake (novejsi neznam :-) by totiz bylo mozne deklarativne popsat v nejakem standardizovanem VRML-like jazyku podporenym napriklad (opet standardizovanym) JavaScriptem nebo Pythonem. Ale to je hudba budoucnosti.
Já jsem vývojem her jenom líznutý ale tomuto se fakt musím smát, VRML je naprosto nadbytečná věc stojící totálně mimo, 3D softy produkují dnes tolik typů a množství dat... pak se to co vyprodukují načte pomocí importního modulu do nějakého editoru scény a přiřadí se animace, vlastnosti, udělají sestavy objektů, přiřadí proprietální funkce logiky, fyziky, scripty, konkrétním objektům shadery atd. atd. a nyní co ? uložit nesmyslně do praseckého a omezeného VRML... LOL, tak velký prd.
Leda tak udělat analýzu všech proprietálních (interních firemních) formátů, enginů. Zadefinovat nový "standard" a udělat pro něj "přehrávač" + nezbytný editor, kolik na to máte miliard $ ? :-)
Na opačné straně je onen student který si dnes udělá importní modul který bude umět načíst jen ty (např. čtyři) nejnutnější věci třeba z formátu 3DSMAX a je vymalováno, na co podobně omezené VRML?
Ovsem ten vyvoj do podobneho stadia pravdepodobne dojde. Ta unifikace ve formatech a skriptovacich technologii je snad jasne viditelna. nemyslim si, ze by to zastresovala nejaka komise, protoze by vysledek asi nebyl moc prakticky (staci se podivat na perly, ktere dneska odpadnou napriklad z W3C nebo skupiny pro ISO C++), spis si jedna ci dve firmy prosadi svoje reseni. Osobne mam dojem, ze vysledkem bude nejaky plnohodnotny skriptovatelny 3D engine zabundlovany spolu s hardwarem. Ostatne vyrobci her byli vzdy tlaceni do pouzivani stale rozsahlejsich unifikovanych API, takze proc to nezabalit cele do jednoho rozhrani?
Ale to se porad bavime o pomerne omezenem pouziti 3D modelu, tj. o hrach. Ovsem 3D je (napriklad v prumyslu) uz nekde jinde, tam jde predevsim o prenos geometrie modelu, jejich hierarchie atd. V prostredich, ktere pouzivaji stejne vypocetni jadro, neni VRML/IGES/blabla az tak potrebne, ale data se prevadi i z jinych vstupnich ci na jina vystupni zarizeni a tam standard proste je zapotrebi.
Tím chcete říct co ? že proprietální herní formát nepoužívá hierarchie ? a co třeba modely aut, tanků nebo postav ? božínku, hry jsou ta nejsložitější věc k vytvoření, ukládání a "renderingu" co existuje a kdyby na to byl výkon prováděla by se v nich i simulace magnetických elektrických a bůhvíjakých ještě polí a jiných ptákovin co si jen jde vycucat z prstu.
Jediný co by bylo pro výměnu "profi dat" potřeba tak zavást do "standatd" formátu SI jednotky a fyzikálně korektní rendering. IMHO
Vývoj sem pravděpodobně nikdy (nebo v dohledné době) nedojde, nikdo tohle nezaplatí a neudělá, dělat takový engine, editor a formát na free bázi je čirá utopie, jsou tisíce projektů které zdechli v počáteční fázi a to měli setsakra střízlivější ambice.
Stačí se podívat na WWW prohlížeče, jak to jde ztuha, jak trvalo než byly free prohlížeče na podobné úrovni jako "proprietální" (MS), to samé free|open HTML editory a všechno související (GFX editory atd.), tohle je o několik řádů náročnější "projekt".
Porad mam dojem, ze si nerozumime (mimochodem o vyvoji her neco vim, ale taky vim, co se "pece" jinde) - nikde jsem netvrdil, ze by to melo byt na free bazi a v poslednim prispevku jsem dokonce jasne rekl, ze predpokladam, ze to udela nejaka firma, ktera bude hodlat prosadit svuj HW a/nebo SW. Naopak vyrobci her toho delaji stale "mene" (resp. se soustredi na veci, ktere umi, tj. vlastni hru a ne blbosti okolo). Chcete priklad te unifikace prave v oblasti her?
1) prvni generace konzoli: jak HW, tak i SW a vetsinu her dela jedna firma (Atari, Vectrex)
- role tvurcu her: delaji vse, HW, SW i samotnou hru
2) domaci pocitace: zakladni HW a minimum SW dela vyrobce, tvurci her musi pouzivat pouze jednoduche API
- role tvurcu her: delaji hru+veskere podpurne knihovny (ze SW vyrobce vyuziji tak maximalne rutiny pro ovladani disketove jednotky)
- v teto dobe uz nebyvalo zvykem, aby si kazdy vyrobce her mohl dovolit udelat si vlastni konzoli, proto ta unifikace s domacimi pocitaci
3) personalni pocitace: HW dela spec. vyrobce, OS dela spec. vyrobce, API je stale jednoduche
- role tvurcu her: delaji hru+vetsinu podpurnych knihoven (ovsem treba cteni z disku uz resi OS, stejne tak VM)
- udelat hru napriklad pro DOS, ktera by potrebovala samostatny diskovy oddil naformatovany na proprietarni format si taky (pokud vim) nikdo "nelajznul", proste se pouzivalo standardni API DOSu
4) pocitace s OpenGL/Direct X: HW dela spec. vyrobce, OS dela spec. vyrobce, API uz pomerne mocne
-role tvurbu her: delaji hru+vlastni engine+pouzivaji API (OpenGL/Direct X)
- tady je to jasne, nebo snad vite o nejake moderni hre, ktera by sama renderovala trojuhelnicky nebo obchazela ovladace a sahala primo na grafickou kartu. ne, tvurce her proste pouzije OpenGL/Direct X a soustredi se na dulezitejsi veci, nez je nejaka rasterizace
5) moderni GPU
- podobne predchozimu, akorat si tvurci her mohou opet ulehcit praci, napriklad se specialnimi efekty - pro jejich akceleraci lze pouzit shadery
6) budoucnost: HW spec. vyrobce, OS spec. vyrobce, kompletni API pro herni engine
- role tvurcu her: samotna logika hry
- proc bych napriklad mel jako mala firma zamestnat tym dvou-tri lidi, kteri me za nejaky rok (mozna) udelaji 3D engine, kdyz mohu pouzit uz hotovou vec? Vsak jiz dnes je spousta her, ktere jedou na enginech od ID softu.
Jasně jenomže kolik taková věc jako engine stojí peněz, víme ? a to je důvod proč pro linux nejsou hry (výjimky potvrzují pravidlo), ani specializované programy, nemá je tam kdo zaplatit, proto jsem tuto možnost vyloučil a mluvil jen o free, ostatně koupit engine jde o formát řešit nemusíte vůbec, tak jaképak VRML...
Ano unifikace probíhá ale je to spíš dílo komerčního monopolismu, nakonec zbude jeden KOMERČNÍ systém, jeden engine, jeden editor, jeden formát... ale VRML ani nic jiného "open" to nebude, a i když reverznete formát, stejně nebudete mít editory. Amen.
Priznam se, ze kolik stoji licence engine nevim (ale trosku tusim, co to stoji oficialne vydat hru napriklad pro PS2 nebo pro X-box a ten unifikovany engin o kterem mluvim a ktery se na nekolika mistech na svete chysta by byl/bude dostupny asi prave touto formou). Protoze priznejme si, pro firmy podnikajici v oblasti konzoli to bude obrovska konkurencni vyhoda, neco podobneho nabizet. nehlede na to, ze co se "upece" na konzolich, se da prevest na PC (o jedne firme, ktera podnika v oblasti operacnich systemu na PC i v oblasti konzoli, jste slysel, ne :-)))
Na druhou stranu vim o par ceskych firmickach, ktere podnikani v oboru her zacaly presne tim zpusobem "vsechno udelame sami", od formatu dat, pres fyzikalni system po detekci kolizi a AI (sam jsem si prosel podobnym obdobim, i kdyz ne zrovna v oblasti her - vzdyt "tuto jednoduchou vec mam sam a lepe vyresenou za dva dny"). Po dvou letech vyvoje engine ty firmy zjistili, ze samotna logika hry je v nedohlednu a stale se resi zakladni problemy, ktere ma konkurence davno za sebou (samozrejme je to pekna skola, pracovat na 3D enginu, ale trosku draha).
Jestli ten format ci API nakonec bude uzavrene ci ne, to zalezi i na pristupu uzivatelu. napriklad v teto chvili probiha "bitva" mezi formaty pouzivanymi pro office-aplikace. Ta je taky iniciovana od uzivatelu, jejich firem, vlad atd. Take by se dalo rict - vzdyt je to jedno, pro svoji aplikaci si import splaca kazdy vyspelejsi student, ale jak je videt, uz i firmam nutnost existence otevreneho formatu dochazi.
Ke vsem prispevkum.
1) Proc nepouzit VRML k tomu, k cemu bylo vytvoreno - k zobrazeni 3D objektu vyrobku , krajiny , mesta , popis cesty , manualu atd. na internetu. Myslim, ze VRML je elegantne jednoduchy, pruhledny (tj. citelny uzivatelem) a umi toho dost - podivejte se na Page of the week na parallelgraphics.
2) Kdysi jsem si s VRML hral a bavilo me to. Dokonce jsem na nej napojil i ECMAscript a javu. Myslim, ze umi dost. Ze v nem je malo aplikaci (sikovne jsou napr. manualy - viz parallelgraphics) a prohlizecu, mam dojem, ze zbyl jen Cortona.
3) Rychlost renderovani je vec implementace. Vyhodou textoveho univerzalniho prenosneho formatu jsou prave jeho vlastnosti. Da se snadno parsovat. Rychlost prenosu po internetu take moc neobstoji - vzdyt je normalni, ze je pouzit gzip.
4) Jeden cas jsem mel dojem, ze se VRML venuje kdekdo - amatersky, dokonce se delaly zapoctaky a seminarky na vysokych skolach. Skoly kupodivu drzely krok s dobou, ale vyuziti VRML nejak nepostupuje. Existuje zobrazeni mest na webu (napr. virtualni Praha).
Ja bych ho nezatracoval, spis povysil a rozsiril.
Jo, když by tuhle sráčovinu podporoval každý prohlížeč tak proč ne, jenomže nepodporuje, na nějakou prezentaci výrobků tohle navíc postrádá fůru featur, třeba ochranu dat - alespoň základní, určitě nestojím o to aby mi někdo výrobek kopčil z mnou poskytnutých dat, schází podpora pokročilých renderigů (GI, RA, RT), různých normálových map a podobně. No a že můžu použít "vypůjčený" parser ? to je fakt výhoda jak prase BTW ten můžu použít tak jako tak pro svůj proprietální formát, softrender taky není problém jak jsem už psal existují i dostatečně rychlé softrendery v Javě tímpádem takový "proprietaly format" podporuje automaticky každý HTML prohlížeč co umí pluginy (Javu), na co potřebuju VRML ? na nic.
Pro chytre to napisu kratseji:
Jednoduchy zpusob, jak prezentovat 3D objekty na webu a jak ukladat 3D data v meziformatu.
Pokud nechci, aby mi nekdo sebral pracne vytvorena data (napr. model hradu), pouziju neco jineho nebo tu ficuru pridam. (Vzhledem k malemu pouziti asi nebyla potreba.)
U manualu Boeingu se asi nikdo neboji, ze zjednoduseny model podvozku s nosniky a srouby ukradnou Japonci.
Vy jste se opravdu v praxi nesetkal s potrebou pouzivat standardizovany format? Proprietarni format je fajn napriklad pro hru - udelam, prodam, za dva-tri roky po tom nestejne ani pes (cest "nesmrtelnym" klasikam). Ale snad si dovedete predstavit, ze kdyz nejaka firma zainvestuje do tvorby 3D modelu, ma zajem na tom data prenaset, uchovavat (treba dvacet let je bezny pozadavek, typicky doba vyroby nahradnich dilu, ne vse moralne zastarava tak rychle jako pocitace) a publikovat - treba svemu subdodavateli.
Treba i z tohoto duvodu "lezou" z 3D skeneru data v OpenInventoru nebo VRML. Ma to svuj smysl - i kdyz po deseti letech budu mit uplne jiny operacni system, kde stavajici soft nepobezi (i Java neni 100% zpetne kompatibilni, kdyz uz jsme u toho), porad znam pouzity format, takze s tvorbou noveho parseru nebo importniho filtru pro MS 3D Studio 3000 :-) vetsi problem nebude. Kdo si data ponecha v proprietarnim formatu (i takovy DWG je pekne hnusnej), muze taky splakat nad ne-vydelkem.
"Vy jste se opravdu v praxi nesetkal s potrebou pouzivat standardizovany format?"
Jo, a ten formát se jmenuje *.3ds a jiné na svůj obor specializované. V nich se vyměňují i prodávají modely. Pořát nechápu o čem tu blouzníte. Všeobjímající open standardizovaný formát neexistuje ani nebude je to utopie a navíc nadbytečná věc (která by ještě byla složitá a nepřehledná jak prase).
Jaká lezou z čeho data je celkem šumák když to načtu kam potřebuju, že lezou z nějkého 3D skeneru data ve VRML se ani nedivím protože tam mají ještě nepestrou dataTYPovou strukturu a na této úrovni to asi načte kdejaký modeler, to VRML zároveň usvědčuje jak je nepoužitelný pro výstupní data.
Co se týče uchovávání a archivace dat tak ta od grafiků zůstavají stále v *.3ds a ten si 3DSMAX načte i ve verzi 3000, proprietální formát stojí úplně mimo a slouží ke koncové distribuci, jak ve hrách tak pro web a že je uzavřený, zdá se, všem firmám vyhovuje, alespoň kdejaký hejhula nevykrádá modely zvuky textury a pod.
Jen pro zajimavost. V prumyslu se napriklad pouziva SurfCAM (http://www.surfware.com/). Uznavam, je to pomerne specializovany program, ale prave na nej se da ve vyrobe narazit mnohem casteji, nez na nejake vytvorky posilane pres 3DS. (nevim, mozna je to tim, ze CR je velmoc ve vyrobe automobilovych dilu a take ma velmi slusne nastorjarny?) Catia a spol. je dostatecne znama, takze ani URL snad posilat nemusim. (tim nezhazuji 3DS, ale je nutne si uvedomit, ze se jedna o program s jinym urcenim)
Opakuji - jednoduchy a citelny format. Nikdo v nem nechce delat strilecku. Ale muze ukazat cestu mestem, vyrobek, model domu, planovanou podobu mesta, sidliste, krajiny. Muze v nem byt JEDNODUSE udelany manual, treba i interaktivni pohadka, co ja vim.
Dokonce jsem zazil i skriptem rizenou masinku, kde si nasazite koleje do ctvercu a uz to jezdi. Prohlizel jsem si zdroje a neni to tak jednoduche. Ale je to velice jednoduchymi prostredky - hledal jsem rail.
to "h" : Jeste bych si rypnul - netvarte se jako mistr sveta a vse, co neuznavam (nebo neznam?) je sr*cka.
Zatim jste neuvedl moc argumentu - jediny, ktery me zaujal, je ochrana dat - ze lze vykrast cizi praci.
Pro zobrazeni vyrobku nebo rozlozeni mistnosti v dome nebo planovaneho sidliste nebo silnice nepotrebuju extra shadery, osvetleni, udalosti atd. atd.
PS: Já vím o co vám jde, chcete aby někdo za vás udělal kvalitní render a open formát a vy ho mohli zadarmo-nepřímo využívat :-) dobrý sci-fi, i kdyby to klaplo tak stejně nebudete mít oné editory jak jsem už zmínil a historie se bude opakovat, jako s HTML jako s SVG atd.
Presne tak. Jedine co potrebujeme, je kvalitni a podporovany (open) format, nic dalsiho. Nevim, co to presne znamena "zadarmo-neprimo vyuzivat", ale jestli je tim myslena moznost tvorby open source programu, ktere tento format podporuji, tak co je na tom spatneho? Viz ODT.
O editorech se asi nema cenu bavit, tech uz dnes existuje v oblasti open source i close source mnoho, od pomerne jednoduchych projektiku, pres Blender az po profi CAD/CAM. Nejde jen o editory, ale i spoustu dalsich filtru, preprocesoru atd.
Za koho mluvíte ? ("co potřebujem") podle mého skromného názoru nepotřebujem, no každopádně se na mě klidně vyserte a zeptejte se na názor ohledně skutečné (ne)potřebnosti tohoto suprformátu lidí z oboru, projektantů, tvůrců her, zeměměřičů atd. atd. a zeptejte se jich taky jaký je jejich názor na VRML, pak tyto názory kdyžtak připlácněte pod článěk, alepoň bude trocha humoru už jinak nic.
PS: Samozřejmě VÍM že se tohle dotazování ani zveřejnění názorů KONKRÉTNÍCH LIDÍ S KONKRÉTNÍMI ZKUŠENOSTMI A POTŘEBAMI nestane.
Ne nenastane, protoze i kdyby nakrasne nastalo, tak se stejne ozvete, ze to nebyla ta prava skupina lidi. V diskusi jsem napsal KONKRETNI potreby KONKRETNICH lidi. Jedna se o spojeni 3D skeneru Minolta Vivid V 700 a obrabeciho softu zalozeneho na SurfCAMu. Dale potreby jedne firmy ohledne uschovy 3D modelu - potrebuji zrusit velky sklad s realnymi modely, bo se v tom spatne hleda :-) Co potrebujete vy, to samozrejme netusim, ale jestli to neni format pro vas, taky ok.
Takové účelové "připady"...proboha to smrdí jako argumentace ulhána :-)) a víte co je nejlepší ? je úplně šumák co mi tu řeknete, objektivní názorový přehled nebude, VRML bude mrtvý dál a každý si dál bude používat "ty svoje" formáty a tak to má být a tak to je.
No, pristup k 3D skeneru ma u nas (CR) pomerne malo lidi, takze vim, o cem mluvim (http://www.elektrorevue.cz/clanky/03013/index.htm) a s jakymi pozadavky se na me lidi z prumyslu, ale i z takovych zajimavych oboru, jako je archeologie, obraceli. Kdyz to reknu na rovinu - me by dnesni situace vlastne mohla vyhovovat, protoze (kdybych se do teto oblasti grafiky znovu vratil), bych mel vic kseftu. Ale ono vas to vlastne - podle posledni reakce "je uplne sumak, co mi tu reknete" - vubec nezajima, coz je v diskusi opravdu zajimavy nazor.
"Tento skener byl prvn�m dostupn�m typem �ady Vivid. Jedn� se o za��zen�, kter� lze pou��t jak p�i digitalizaci v upraven� m�stnosti, tak pro pr�ci v ter�nu, kdy skener pracuje samostatn� bez pou�it� �idic�ho po��ta�e. Ob� mo�nosti pr�ce ze skenerem jsme vyzkou�eli v praxi, podrobn�j�� popis je uveden v "
aha...ja nerozumet po vasem...to si asi opravdu my neporozumet.
Hmm, vidim, ze redakce "elektroniky" ma zase rozhasene nastaveni webu (i proto je dobre publikovat na Rootu :-), kde je to technicky vyresene dobre i pro ne-IE-and-win prohlizece). Samozrejme si staci v prohlizeci prepnout kodovani na Windows-1250, ale meli by to opravit, takhle je to ostuda.
protoze posilaji spatne http hlavicku, proto browser nezvladne autodetekci. dalsi oblast, kde by prechod na unikod vyresil spoustu problemu, jak je videt.
To je možný, jenom říkám co sem musel nastavit aby se to zobrazilo jak má.
PS: On by nějaký problém vzniknul určitě i s unikodem, třeba by ve fontu nebyly znaky co tam být mají, unicode fontů co mají přítomny všechny znaky a jiné patvary dle standardu je setsakra málo několik desítek kilo entit i ve vektorech dá nějaký ty mega :-)
Na tom se urcite shodneme. Taky pouzivam napriklad pouze "orezane" fonty DejaVu, i kdyz jsou nabizeny i ve variante s cinstinou apod. (tim nerikam, ze DejaVu obsahuje vsechny znaky, ale maka se na tom). Zatim jsem vystacil s Latin 2 a jednou jsem se dokopal k precteni textu v azbuce (abych nakonec zjistil, co vsechno clovek od zakladky zapomene :-)
Pane Tisnovsky, viditelne s nim ztracite cas.
Jedine, v cem ma -h- pravdu je, ze VRML je mrtvy . Doufam, ze tatim. Myslim, ze je to skoda, protoze je opravdu jednoduse pouzitelny.
Chtelo by to vic pouziti na webu a lepsi export z programu - protoze modelovaci programy ze vseho udelaji IndexedFaceSet.
To už si raději pro export nadefinuju vlastní formát, ten půjde tímpádem kdykoliv v budoucnu naimplementovat třeba na 256bit procesoru a windows 50000.
PS: Pan tišnovský přichází o čas především s VRML, ale kašlete na můj názor já jsem jen obyčejný blbec.
PPS: Ohledně nedokonalostí VRML a prohlížečů - ono by to chtělo spíš úplně jiný řádově lepší formát a řádově lepší prohlížeče, takové jako chameleonské aby se jednou tvářili jako manuál a jednou zase jako prostředí hry nebo CAD programu :-)))) MEGALOL.
ja vim, kde o VRML najit rozumne informace (vcetne standardu), ale pan "h" operoval tim, ze o VRML nic na CZ wikipedii neni (ale ani o jim preferovanem 3ds). Coz vsak neni zadna tragedie, mozna oba clanky do wiki vrazim, az bude vic chuti.
V 3ds se mozna vymenuji modely postavicek do her ale sotva tovarnich dilu na kterych je 3d vymodelovane i seriove cislo. V techto odvetvich je skutecne standard VRML a nekolik desitek let stare programy ve fortranu. (At se pan h vzteka jak chce. :)
Jo, ochrana dat ... toho maji vsichni plnou hubu jak akutne potrebuji chranit data ktera ukazuji uzivateli. Jo, proti BFU ti proprietarni format pomuze, ale vazne si myslis ze ti bude k necemu platny kdyz se do ziskavani tech dat pusti konkurencni firma ? Pokud ten tvuj vyrobek bude tak prevratny a super, tak si ho patentuj nebo ty data nepust z ruky v zadnem formatu. Taky je dobry napad pro tu prezentaci pouzit jiny model vyrobku nez pro vyrobu - kdyz to osekas, nejen ze jim bude mene platne to ukrast, navic to bude mensi takze prezentace pobezi rychleji.
Krome toho, softrenderer v Jave ... napsal jste si vlastni ? Strasna sranda co, vazne by vam ten cas firma platila kdyby prohlizece umeli VRML ? Jo on neni vlastni, proste jste si neco koupili (nebo stahli z webu ?) ... no tak to si dotycny muze koupit to same. Nebo ten softrenderer stahnout od vas i s modelem vyrobku, konecne kdyz to prohlizec musel stahnout aby ten vyrobek zobrazil tak uz to stejne ma na disku.
Pozor - VRML 1.0 je víceméně zastaralý formát. Jeho nástupcem je, nebo měl být, VRML 2.0, na který pak navázal X3D, což je vlastně VRML 2.0 zapsaný ve XML.
Bohužel ale VRML 2.0 se moc nepovedl (tedy aspoň podle mne ne), je zbytečně složitý, zejména koncept skriptování a prototypů je totální horor a jeho implementace je velmi náročná (mimo jiné potřebujete kompletní JavaScriptový engine) - možná i to byla jedna z příčin, proč se neprosadil. :-(
Specialne webovskym prohlizecum strasne vadi, ze by na VRML potrebovali kompletni JavaScriptovy engine ... teda alespon doufam ze ty pluginy jde napsat tak aby pouzili engine prohlizece.