játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5448
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2520

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [22]
Asylum - Törzstag | 5448 hsz       Online status #108392   2009.04.05 10:26 GMT+1 óra  
Csak épp konkrétan nem a texturát akarod nagyitani hanem messzebbre akarsz látni...
Ha távcsőről van szó. Ha nem arról akkor oké. Ezért irtam kétféle megoldást.

És nyilván egy távcsöhöz nem kell 1280x1024 ben renderelni igy 6odannyiba kerül mint egy cubemap -.-
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #108386   2009.04.05 09:53 GMT+1 óra  
Jah egy apróság, nem a lineáris interpoláció a legszebb megoldás, ha ráraksz valami megfelelő hatvány cuccot (ami gyors, akkor szépen lencseszerű lesz az egész).

Edit : nincs a melóhelyi gépemen rendermonkey, na majd ha hazamegyek melóból. Utálom a hétvégézést.

Ezt a hozzászólást sirpalee módosította (2009.04.05 10:02 GMT+1 óra, ---)
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #108385   2009.04.05 09:50 GMT+1 óra  
koszi szepen
majd at kell butykolni, hogy mindez 3d-s modellre ervenyesuljon, de az mar nem lesz nehez ugygondolom (remelem)

Ezt a hozzászólást xanat módosította (2009.04.05 10:07 GMT+1 óra, ---)
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #108384   2009.04.05 09:46 GMT+1 óra  
Kell egy textúraként a mögötte lévő kép amit nagyítani akarsz, aztán kell tudni kell hol van a távcső közepe.

És kirajzolod az egész képernyőt megint, annyi változtatással, hogy átmegy rajta egy olyan shader, ami tudja, hol van a távcső közepe

cbuffer vs_cb : register (b0)
{
float2 kozep; // tavcso kozepe
float meret; // tavcso merete uv spaceben
float nagyitas; // nagyitas mérete
float kor_meret; // tavcso szélének a mérete
float4 kor_szin;
}

Texture2D txBackground : register (t0);
SamplerState txSampler : register (s0);

struct PS_INPUT{
float4 Position : SV_POSITION;
float2 UV : TEXCOORD0;
};

float4 nagyit(PS_INPUT in) : SV_TARGET
{
const float2 diff = kozep - in.UV;
const float length = length(diff);
if(length < meret)
{
return txDiffuse.SampleLevel(txSampler, kozep + diff * nagyitas,0)
}
if (length < meret + kor_meret)
{
return kor_szin
}
return txDiffuse.SampleLevel(txSampler, in.UV,0)
}

valami ilyesmi, most fejből írtam, 4 óra alvás, és 10 óra max maya konverziós problémavadászat után. Szal nem garancia. Ja meg ez dx10-es módon van írva, szal írd át dx9-esre, de a lényeg szerintem látszódik. Vagy majd ha nem 2 napos vizihulla állapotban leszek, akkor átnézem a kódod msn-en.

Asylum : 2szer a scenet nem szerencsés kirajzolni szerintem, az elég durván lassú lesz, főleg xna alatt .
raytraceisten és übermedic
   
Asylum - Törzstag | 5448 hsz       Online status #108383   2009.04.05 09:34 GMT+1 óra  
egyik lehetöség: átküldöd a shadernek a képet lencse nélkül, és a texturakoordinátákat ugy offseteled a lencsén, hogy pont a kellö kép jelenjen meg a kellö méretben (ez nagyitástol függöen pixeles lehet).

másik lehetöség: csinálsz egy másik kamerát aminek vagy a fov-ja más vagy közelebb van, és az az által renderelt képet feszited a lencsére.

Google egyébként: lens shader vagy distortion shader
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
xanat - Tag | 489 hsz       Online status #108379   2009.04.05 08:18 GMT+1 óra  
nos, en egy fegyver tavcsovenek a nagyitos lencsejet szeretnem megcsinalni shaderrel. keszitettem is egy "szep" kis rajzot is

van ra valami otlet? vagy hogy keressek erre ra? mert az nem nyert, h zoom shader
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Asylum - Törzstag | 5448 hsz       Online status #108378   2009.04.05 07:05 GMT+1 óra  
Szerintem ilyesmire gondolt mint az nvidia fx composer vagy a rendermonkey.
Mondjuk nekem még egyiket sem sikerült megtanulnom használni...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #108375   2009.04.05 05:36 GMT+1 óra  
A DirectX sdk-ban találsz egy fxc nevű progit, az fordít bytekódot a shaderből, viszont jobb közvetlenül a legújabb d3d-vel lefordítani az egészet. (tehát közvetlen a text alapú shader kódból fordít neked a device egyet, vagy újabban a d3dcompiler osztály)
raytraceisten és übermedic
   
Bukta - Tag | 308 hsz       Online status #108374   2009.04.05 05:27 GMT+1 óra  
Hy
valaki pls írja le nekem h milyen fordítóprogramok vannak a shader nyelvekhez pl a HLSL-hez, mert én nem találtam.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
sirpalee - Tag | 1282 hsz       Online status #102814   2009.01.17 12:21 GMT+1 óra  
Implementált már valaki egy Kelemen/Szirmay-Kalos BRDF-et, Shlick féle Freshnel közelítéssel? És ha igen, van hozzá renferencia képetek? (beledobtam egy shaderembe és most azt nézegetjük jól csináltam-e meg, csak alig van hozzá ref kép)

EDIT : sikerült megtalálni a bugot, kemény 4-5 óra után , legközelebb nem jövök be szombaton unalomból a munkahelyemre mert ittragadok.

Ezt a hozzászólást sirpalee módosította (2009.01.17 14:11 GMT+1 óra, ---)
raytraceisten és übermedic
   
Joga - Törzstag | 1791 hsz       Online status #102802   2009.01.17 04:26 GMT+1 óra  
Idézet
dvorgaz :
Idézet
Joga :
Ha shader-ezés megy, akkor 3. koordinátával megadod 0.0nak fenn, 1.0.nak lenn, és az alapján számolsz átmenetet shaderben


Mármint textúra koordinátáknál 3-nak?
Amúgy én is valami ilyesmin gondolkodtam, csak én a vertexcolorba pakoltam volna

Akár..
Sőt, ott még azt is megcsinálhatod, hogy az RGB értékeket textúrákkal felelteted meg

Szal, amikor kirajzolod, akkor a shader megkapja az x, y texkoordinátát, fogja, veszi a színt a 3 textúrából és RGB értékek alapján összeblendeli
persze, 2 textúránál ugyanez, csak ott a B értéket nem használod

Egyszerűen fogod, összeszorzod az R értéket a fűből vett mintával, a G értéket a kőböl vett mintával, és összeadod, így csak jól kell megadni a színeket

Szerk.: Csinálhatod úgyis, hogy csinálsz egy textúrát, és ebből az x textúrából az utolsó tárolja, hogy mily módon kevered a textúrákat, ez pl heightmapnál lehet jó inkább, szvsz

Ezt a hozzászólást Joga módosította (2009.01.17 06:29 GMT+1 óra, ---)
(ಠ ›ಠ) Stewie!

   
sirpalee - Tag | 1282 hsz       Online status #102800   2009.01.17 04:05 GMT+1 óra  
Miért nem próbálsz meg kettős textúra keverést csinálni? Egyrészt magasság alapján, másrészt pedig meredekség alapján. Pl tudod hogy ami 50 foknál meredekebb az szikla már.
raytraceisten és übermedic
   
dvorgaz - Törzstag | 575 hsz       Online status #102799   2009.01.17 04:02 GMT+1 óra  
Idézet
Joga :
Ha shader-ezés megy, akkor 3. koordinátával megadod 0.0nak fenn, 1.0.nak lenn, és az alapján számolsz átmenetet shaderben


Mármint textúra koordinátáknál 3-nak?
Amúgy én is valami ilyesmin gondolkodtam, csak én a vertexcolorba pakoltam volna

Egyébként megjegyezném, hogy a meredek falrésznek, illetve a többi sík füves résznek tökmás textúrakoordinátái vannak, mivel máshogy vannak rávetítve és más textúrát is használnak. Amit xanat linkelt az pont nem jó, mivel az egy sima heightmapes terep, amin a meredek részeknél szétnyúlik a textúra.

ui: ja és heightmapnél nem lehet kiszögelléseket csinálni
   
xanat - Tag | 489 hsz       Online status #102798   2009.01.17 03:55 GMT+1 óra  
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Joga - Törzstag | 1791 hsz       Online status #102797   2009.01.17 03:54 GMT+1 óra  
Ha shader-ezés megy, akkor 3. koordinátával megadod 0.0nak fenn, 1.0.nak lenn, és az alapján számolsz átmenetet shaderben
//nemtom mennyire jó ölet, most ez jutott eszembe

Szerk.: xanat hozzászólásáról jut is eszembe, Énis multitextúrára gondolok
(ಠ ›ಠ) Stewie!

   
dvorgaz - Törzstag | 575 hsz       Online status #102796   2009.01.17 03:38 GMT+1 óra  
Van ötletetek hogy lehetne megoldani a következőt?

Adott egy terep, ami egy tetszőleges mesh, van rajta egy domb, aminek van egy meredek oldala. A képen bejelöltem, hogy melyik felületre hogy van rávetítve a textúra, pl. a meredek falon vízszintesen van vetítve így nem mósódik el rajta mint pl. heightmapes terepnél. A lapos részeken legyen mondjuk fű, a meredek falon szikla textúra.
http://ilab.hu/jf/datas/users/756-ezthogy.jpg

Na most a kérdésem, hogy hogyan lehetne a sötétszürkével jelölt részen átblendelni fűből szikla textúrába?
Arra van ötletem, hogy számolom ki a "meredek" poligon árnyalásánál, hogy milyen textúrával kell blendelni, viszont nem tudom, hogy mi alapján történjen a blendelés. Nyílván a pixelnek a poligon alsó(felső) szélétől vett távolság függvényében kellene blendelni, de fogalmam sincs, hogy ezt hogy lehetne kiszámítani.
   
xanat - Tag | 489 hsz       Online status #100672   2008.12.15 10:27 GMT+1 óra  
koszi a valaszokat. valoszinuleg ez az arnyekos modszer lesz, ugyis szukseg lesz ra.. akkor addig nem bantom
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #100671   2008.12.15 09:33 GMT+1 óra  
Idézet
xanat :
na nemtudom hol kerdezzem... shaderhez tartozik, de megse... szoval naggyabol mukodik a normal map, van szinezett fenyunk + ambient. az lenne a kerdesem, ami a kepen is jol latszik... mitol lehet az "arnyekos oldal" is megvilagitva?

itt a kep

Szerk.: lassan kinovom a gepemet, 200nal lentebb ritkan megy az fps, es meg csak 20 hordo van leteve, normalmap + feny, szal semmi extra.. hmm.



Az gondolom nem kiugró geometria, egy egyszerű megoldás (én mental ray-ben használom) : Elsőnek csekkold hogy a geometriai normal meg-e van világítva, és ha igen csak akkor rakj rá normal mapot (persze csinálj valami interpolációt a 2 között, hogy ne legyen éles határvonal).

Amúgy a legbiztosabb ha önárnyékot tud vetni a fényed minden objektumra és akkor eltűnik minden ilyen gond (pl egy egyszerű shadow map is megteszi).
raytraceisten és übermedic
   
Asylum - Törzstag | 5448 hsz       Online status #100666   2008.12.15 06:38 GMT+1 óra  
például azért mert a széleken általában furán állnak a normálok (hadd legyek analizis kocka: nincs egy környezete amiböl ki lehetne számolni a normált).
De majd az okosok megmonnyák h igyvan-e
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
xanat - Tag | 489 hsz       Online status #100658   2008.12.15 05:29 GMT+1 óra  
na nemtudom hol kerdezzem... shaderhez tartozik, de megse... szoval naggyabol mukodik a normal map, van szinezett fenyunk + ambient. az lenne a kerdesem, ami a kepen is jol latszik... mitol lehet az "arnyekos oldal" is megvilagitva?

itt a kep

Szerk.: lassan kinovom a gepemet, 200nal lentebb ritkan megy az fps, es meg csak 20 hordo van leteve, normalmap + feny, szal semmi extra.. hmm.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
xanat - Tag | 489 hsz       Online status #100600   2008.12.14 07:32 GMT+1 óra  
nah, mostmar muxik, bar nem eleg latvanyos, lehet majd egy masik shadert kell csinalni, nemtudom... nem elegge latszik a normal map rajta, nagyon kis gyenge...

Itt egy kep
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Asylum - Törzstag | 5448 hsz       Online status #100598   2008.12.14 07:04 GMT+1 óra  
például az hogy nem generáltattad le a tangenst teret.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
xanat - Tag | 489 hsz       Online status #100594   2008.12.14 06:14 GMT+1 óra  
jajj nemtudom merjek-e itt ilyet kerdezni, de megprobalom, hatha nem lesz leharapva a fejem.
erdekes kis dolog tortenik ezt a shadert hasznalva:

Kód:
float4x4 world : World;
float4x4 viewInverse : ViewInverse;
float4x4 worldViewProj : WorldViewProjection;

float3 LightDir1 = {1,1,1};
float4 ambientColor : Ambient = { 0.5f, 0.5f, 0.5f, 1.0f };

texture DiffuseTexture
<
    string TextureType = "2D";
    string UIName = "diffuse";
    string ResourceName = "";
>;

sampler DiffuseTextureSampler = sampler_state {
  Texture = <DiffuseTexture>; MinFilter=linear; MagFilter=linear; MipFilter=linear; };

texture NormalTexture
<
    string TextureType = "2D";
    string UIName = "normal";
    string ResourceName = "";
>;

sampler NormalTextureSampler = sampler_state {
  Texture = <NormalTexture>; MinFilter=linear; MagFilter=linear; MipFilter=linear; };


struct VS_INPUT
{
float3 Position : POSITION0;
float3 Normal : NORMAL0;
float3 Tangent : TANGENT0;
float2 TexCoord : TEXCOORD0;
};

struct VS_OUTPUT
{
float4 Position : POSITION0;
float2 TexCoord : TEXCOORD0;
float3 Data1 : TEXCOORD1;
};


VS_OUTPUT VsNormals(VS_INPUT In)
{
VS_OUTPUT output;
float4 pos = float4(In.Position, 1);

float3x3 tangentSpace;
tangentSpace[0] = mul(In.Tangent, world);
tangentSpace[1] = mul(cross(In.Tangent, In.Normal), world);
tangentSpace[2] = mul(In.Normal, world);
float3 tangentLightDirection = mul(tangentSpace, LightDir1);

output.Position = mul(pos, worldViewProj);
output.TexCoord = In.TexCoord;
output.Data1 = normalize(tangentLightDirection);

return output;
}

float4 PsNormals(VS_OUTPUT In) : COLOR0
{
float4 outColor = tex2D(DiffuseTextureSampler, In.TexCoord);
float3 normal = 2*tex2D(NormalTextureSampler, In.TexCoord) - 1.0;
float diffuse = saturate(dot(normal, In.Data1));

return outColor * (ambientColor + diffuse);
}

technique Normal
{
pass Pass1
{   
        VertexShader = compile vs_2_0 VsNormals();
PixelShader = compile ps_2_0 PsNormals();
}
}


normal map-et hasznalja szepen, csak ha kozeledek fele, akkor villog a kicsike...
nyilvan valami tok trivialis hiba, v. van valami, ami elkerulte a figyelmemet nemtudom....
elore is koszi!
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
AmidaBucu - Tag | 281 hsz       Online status #98853   2008.11.10 13:07 GMT+1 óra  
Köszi a linket
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5448 hsz       Online status #98835   2008.11.10 11:00 GMT+1 óra  
szerintam ott arról van szó, hogy egy második kamerát raksz le ami kb ugy viselkedik mint a komplex számoknál a konjugált...szal a viz sikjára tükrözöd a saját kamerádat és az úgy renderel egy texturába. Régebben ezt megcsináltam xna ban de a shader már nincs meg (a kamera osztály még igen).
Csak arra kell vigyázni, hogy ami a viz alatt van azt ne rajzolja és gondolom erre gondoltál te is, hogy oda be kell rakni egy vágósíkot; asszem valamelyik riemer xna tutorban van erről szo.

http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series4/Reflection_map.php

szerk.: még keresem h hogy lehet ezt nem xna ban megcsinálni.

ogl: http://forum.beyond3d.com/archive/index.php/t-12316.html
dx: http://www.gamedev.net/community/forums/topic.asp?topic_id=402381
mdx: http://www.mdxinfo.com/resources/hlslclipplanes.php

jajj

Ezt a hozzászólást Asylum módosította (2008.11.10 11:31 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #98834   2008.11.10 10:53 GMT+1 óra  
Hello! Szeretnék vizet renderelni, de nem jöttem rá, hogy kell kivágni egy általam meghatározott planeval a tér valameik részét. pedig ez nagyon kellene. Az SDK-s doksiban csak a front és back clipping planerol van szó (nézeti mátrixnál).
Ami tönkremehet, az tönkre is megy!!!
   
Attila - Tag | 2 hsz       Online status #97660   2008.10.28 05:40 GMT+1 óra  
Sziasztok!

Ne haragudjatok, hogy ide írok, de nem találtam jobb topic-ot!

Olyan 3D-s grafikust/programozót keresek, aki egy C++-ban írt programhoz 3D-s megjelenítéseket tudna nekem csinálni (fizetés ellenébe!!!).
Többek közt egy berendezés valós idejű megjelenítése lenne, mozgásokkal, a kamera szögének és pozíciójának megváltoztatása és zoom-olás.

Ha érdekel a dolog, akkor bővebb információt is tudok adni.
attila_nagy@hotmail.com

   
syam - Törzstag | 1491 hsz       Online status #97634   2008.10.28 02:28 GMT+1 óra  
egyértelmü, h a raytraceré a jövő
az inkr. képszintézis elérte a fejlődése csucsát, lassan már az egész folyamat programozható, de pl. az árnyékokra, tükröződésre (vagyis 2 poligon közötti viszony érzékeltetésére ) még mindig nincs kompromisszummentes megoldás és valószínű nem is lesz, mivel maga a technológia nem erre lett kitalálva (az megint más kérdés, h meg lehet vele csinálni)
az megint más kérdés, h mindezt gpuval v cpuval fogjuk-e megvalósítani (bár most ugy tűnik, h a cpu áll jobban)
alias aalberik
   
newversion - Tag | 197 hsz       Online status #97596   2008.10.27 13:34 GMT+1 óra  
a raszterizálás is logaritmikus, hála a LOD-nak meg a különbözö térfeloszto algoritmusoknak
ebböl a szempontbol a raytracingnek nincsen elönye

viszon nagy a hátrány abban hogy a raytracinghez véletlen elérésü memoria kell, szemben a raszterizálás stream szerü feldolgozásával
mostanában egy memoria müvelet ezer orajeles latencyt generál és ez csak rosszabb lesz
ehhez hozzájön az hogy mostanában ugrik fel a felbontás 1920*1080-ra késöbb 4000*2000-re
és mint tudjuk a raytracing lineáris a felbontással
szal a raytracing a szopo ágon van, abszolut nem arra megy az ipar, csak a PR-t nyomják
   
nadam - Törzstag | 364 hsz       Online status #97592   2008.10.27 12:54 GMT+1 óra  
Geri:
Szerintem is valószínűleg itt a nyakunkon a ray-tracing, ha másért nem, akkor azért, mert ahogy említetted ugyanolyan minőség eléréséhez egyszerűbb és tisztább kód is elég (nem kell annyit trükközni).
Meg ahogy látom az a tendencia, hogy a GPU-n párhuzamos processzorok vannak, amikkel a programozó azt csinál amit akar. Szóval lassan elég komoly vas áll rendelkezésre a raytracinghez.
   
Geri - Törzstag | 2188 hsz       Online status #97591   2008.10.27 12:44 GMT+1 óra  
A polygonok számának növekedésére a gépigény logaritmikusan reagál. Szerintem ez már önmagában is elég nagy előny, ha a többi négyszázat nem is vesszük.

nadam: igen, igaz. De a jövő a ray tracing, nem pedig egy kínlódásból összetoldozott-foltozott raszterizer arhitektúra, aminek a fenntartási és fejlesztési költségei az egekben, effektizálhatósága a shaderek nélkül gyakorlatilag nulla, etc. Felesleges tovább toldozni foldozni ezt az összedőlő, kivénhedt, kifáradt, elavult arhitektúrát, amikor van nagyságrendekkel ésszerűbb is.

   
nadam - Törzstag | 364 hsz       Online status #97590   2008.10.27 12:43 GMT+1 óra  
Idézet
Geri :
A radiosity és a global illumination is elkészül a raytracer algoritmusok lefutása során



A sima ray-tracing az nem 'global illumination' algoritmus, mert nem számol az indirekt fényforrásokkal.

A sima raytracing algoritmus az csak annyi, hogy a szemből elindítunk egy sugarat, onnan shadow sugarat a fényforráshoz és onnan rekurzívan tükröződés sugarat vagy 2-3-szor.
Ez már nem olyan vészes, ezt már lassan elbírja a mai vagy a közeljövő hardvere. De ebbe nincsenek benne a felületekről egymásra sugárzott indirekt fények: egy pixel színét végülis elvileg az egész scene befolyásolja, hiszen a pixel mindenfelől megvilágítódik.
A photon mapping az már tudja ezt, de ahhoz irtózatos számítási kapacitás kell. Mondjuk a foton mapping alapja is a sugárkövetés, szóval lehet, hogy csak terminológiai a vita, és te tág értelemben vett ray tracingről beszélsz, amibe azt is beleérted.

Egyébként egy nagyon jót olvastam valahol, asszem az NVidia honlapján, ahol egy real time ray tracing demójukról volt szó. Valahogy így hangzott:

-A háromszögrajzolós raszterizálás gyors, de trükközni kell, hogy élethű legyen.
-A raytracing élethű, de trükközni kell, hogy gyors legyen.

Ez nagyon igaz.
   
newversion - Tag | 197 hsz       Online status #97589   2008.10.27 11:26 GMT+1 óra  
semmi elönye nincs a raytracingnek
   
Geri - Törzstag | 2188 hsz       Online status #97585   2008.10.27 10:36 GMT+1 óra  
A radiosity és a global illumination is elkészül a raytracer algoritmusok lefutása során, de ha írtál ray tracert, mint mondtad, akkor ezzel nyilvánvalóan tisztában vagy. A ray tracing önmagában forradalmasítaná az egész grafikai megjelenítést, minőségileg több százszoros ugrást jelentene a jelenlegi elavult raszter alapú megjelenéshez képest, előbb viszont ki kell futnia a raszteres grafikának. Ez az elkövetkezendő években fog megtörténni.
Természetesen a jelenlegi opengl és d3d fejlesztések ezzel nem értéktelenednek el, csak hosszú távon (tehát azoknak, akik nem arra gondolnak, hogy 4-5 éven belül kihoznak egy gamet opengl-el, hanem méghosszabb távon) a raszteres grafika már egyáltalán nem alternatíva egy egyénileg kialakított ray tracerhez képest.

   
nadam - Törzstag | 364 hsz       Online status #97553   2008.10.27 04:31 GMT+1 óra  
A raytracinggel az a helyzet, hogy mehetne már most is ha nagyon akarna, de inkább az a kérdés, hogy minek? Tükröződést és árnyékokat a hagyományos raszterizációval is csinálnak (environment mapping, shadow mapping).
Az igazán élethű megjelenítéshez (radiosity neadjisten global illumination) meg a ray tracing _önmagában_ édeskevés.

Szóval szerintem a raytracing önmagában nem hozna áttörést. Ettől függetlenül ha a nagymennyiségű általános párhuzamos processzorok lesznek a nyerők (most hogy shadernek hívjuk őket, vagy CPU magnak az mindegy), akkor elterjedhet a ray-tracing, mert szerintem sokkal egyszerűbb a programozása. (Egy egyszerű semi-real-time ray-tracert még 2000-ben összedobtam, pedig nem voltam valami nagy 3D szakértő. Természetesen közel nem volt tudásban, teljesítményben és komplexitásban sem egy mai 3D engine-hez.)

A nagy áttörés a real-time photon mapping lenne, de szerintem ezt csalások és trükközések nélkül még jó ideig nem fogja bírni a hardver. Sőt, nagyméretű scenekre (tájak, stb...) elég reménytelnnek tűnik szerintem.

Ezt a hozzászólást nadam módosította (2008.10.27 04:45 GMT+1 óra, ---)
   
newversion - Tag | 197 hsz       Online status #97545   2008.10.27 02:40 GMT+1 óra  
nem kell benyalni a pr dumát, nem régi hir hogy csak 40 magot birtak belerakni
ugyanaz mint a cell, programozhatatlan fostömeg
mire ebböl az asztalon lesz valami lesz 10 ezer shaderem,

raytracing engine álom még 10 évig, most jön a voxel korszak
   
Asylum - Törzstag | 5448 hsz       Online status #97542   2008.10.26 20:14 GMT+1 óra  
az egy dolog, hogy van ilyen proci de szerintem nem otthoni használatra...ekkora teljesitményt talán a nasa tud kihasználni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1291 hsz       Online status #97541   2008.10.26 18:11 GMT+1 óra  
Ríltime-szoftveres-raytracer-engine: here we go? Jó is lenne, ha ekkorákat ugrana az ipar néha, de gyanítom, hogy nem lesz ez ripsz-ropsz az asztalomon (amúgy nem szerverekben lesz ez?).
   
Geri - Törzstag | 2188 hsz       Online status #97539   2008.10.26 17:12 GMT+1 óra  
Az Intel Larrabee kódnevű processzor számításokat végző ALU (arithmetic logic unit = aritmetikai logikai egység) tömböt tartalmaz gyorsítótárakkal és memóriavezérlővel. Justin Rattner, az Intel főtechnológusa (CT)) szerint az ALU tömb teraflopsebességgel dolgozza fel az adatokat. A TFLOPS teljesítményű processzort az Intel a tervek szerint 2010-ben bocsátja ki, de már 2009-ben bemutatja. Mindezeket Rattner az InformationWeek weboldalnak adott interjúban mondta el.
Az Intel Tera-Scale kezdeményezés első inkarnációja egy 80 magos teraflops kutatási lapka, amely 65 nm-es technológiával készül, és 80 magot tartalmaz, amelyeket az Intel „cserepeknek” hív. Ezeket a 4 GHz-es órajellel működő nagyon egyszerű magokat 10x8 2D háló hálózatba szervezték. Minden egyes cserép egy feldolgozó gépet (PE) tartalmaz, amely különleges határfelületen keresztül egy ötkapus útválasztóhoz csatlakozik. A 80 magos lapka a VLIW (very long instruction word = nagyon hosszú utasítás-szó) mikroarchitektúrán alapul, amely (architektúraszinten) nagyon hasonlít a legújabb ATI R600 kódnevű GPU (grafikus feldolgozó egység) feldolgozó gépéhez.

prim.hu

Ennyit a szar processzorokról... Vagy inkább az egész, dedikált gpu, és shader alapú arhitektúráról...

megj: A hír régi. A processzort 2 napja bemutatták. Hamarosan indul a tömeggyártás.

megj2: a Larrabee 6 magja elegendő a F.E.A.R. nevű számítógépes játék röccenéstelen megjelenítéséhez 3 ghz-n. Na, ilyen magból van 80 a prociban.

megj3: a gpu centrikus fejlesztéseket folytató emberek írhatnak mindent újra.

megj4: A larrabee x86-os processzor. A core2duo helyére berakva még a windows is elindul rajta, hisz egy általános célú egység.

megj5: A processzor 90w-nál kevesebbet fogyaszt.

megj6: A nem használt magok órajelét a proci lehúzza, minimaliálva a fogyasztást.

   
TPG - Tag | 3402 hsz       Online status #97532   2008.10.26 14:44 GMT+1 óra  
Idézet
newversion :
nemtom, mindenki maga érzi hogy melyik a jobb
most a gépemben van 1600 unified shader, olyan hogy VS nem is létezik már csak a régi szarokban
na most ha most ir valaki valamit az jo esetben 2 év mulva kész lesz , hát arra lesz vagy 10 ezer shader a gpu-kban, meg lesz egy csökevény 8 magos proci
aki ezek tudatában a cpu-val grafikázik az sikeres nem lehet


Kinek mi a célhardver, speciel én úgy tervezem a rendszeremet hogy az 5-7 évre visszamenőleg kompatibilis legyen. Unified shaderes kártyánál valószínű már tényleg nem jelent olyan sebességcsökkenést a VTF, de spec. én két kezemen meg tudom számolni hányszor használtam tesztelésre ilyen kártyát. (A jó öreg Gef6800 meg még klasszikus felépítésű.) És azt sem tart sokáig megszámolnom hogy a környezetemben hány ilyen kártya van. Másrészt meg mi hobbiból toljuk, nem célunk a következő GPU generációk lelkének kitiprása.
Reality is almost always wrong. - House

   
newversion - Tag | 197 hsz       Online status #97531   2008.10.26 14:32 GMT+1 óra  
nemtom, mindenki maga érzi hogy melyik a jobb
most a gépemben van 1600 unified shader, olyan hogy VS nem is létezik már csak a régi szarokban
na most ha most ir valaki valamit az jo esetben 2 év mulva kész lesz , hát arra lesz vagy 10 ezer shader a gpu-kban, meg lesz egy csökevény 8 magos proci
aki ezek tudatában a cpu-val grafikázik az sikeres nem lehet
   
TPG - Tag | 3402 hsz       Online status #97527   2008.10.26 14:02 GMT+1 óra  
Idézet
newversion :
"VTF csak SM3-tól van ráadásul csak 32bites lebegőpontos textúrából (1 vagy 4 csatorna lehetséges). És ez mellett a dolog nem is gyors, eleve a VS nem erre van kitalálva, lassabban éri el a textúrát mint a PS másrészt az ilyen lebegőpontos textúrák mintavételezése marha lassú amúgy is és nagy adatforgalmat generál. Miért nem csinálod úgy hogy egy patch-et használsz de azt dinamikus VB-ben? Szükség esetén lock és CPU-ból lehet frissíteni az egészet mondjuk egy külön szálban így még akadályt sem jelent a dolog. Renderelési tempóban a dinamikus VB rosszabb a statikusnál, de talán az egyik legjobb megoldás mind tempó szempontjából, mind szükséges vas szempontjából. "

azért ne vicceljünk, ne mond hogy a proci gyorsabban olvas texturát mint a vertex shader
a 32 bites fp sem gáz annyira, mert 8 bites loszarra valo, 16 bites lenne az ideál
talán a processzort nem grafikára kéne használni


Én hol írtam olyat hogy a procinak textúrát kellene olvasnia vagy hogy a proci gyorsabban olvas textúrát mint a VS? A magasságadatok szépen letárolódnak egy tömbben a memóban, innen a CPU szépen kikalkulálja a terepet majd egy darab memcpy-val betolja az éppen lockolt dinamikus VB-be. Szépen párhuzamosítható a dolog, a terepkalkulálást SSE-vel gyorsítani lehet, plusz egyéb olyan optimalizációkat is el lehet végezni amiket VTF esetén nem. Ráadásul a szükséges masina sem lesz akkora és még a sebessége is jó lesz. Másrészt a terepkezelés határeset, nem egyértelműen csak grafikai probléma.
Reality is almost always wrong. - House

   
newversion - Tag | 197 hsz       Online status #97519   2008.10.26 13:31 GMT+1 óra  
"VTF csak SM3-tól van ráadásul csak 32bites lebegőpontos textúrából (1 vagy 4 csatorna lehetséges). És ez mellett a dolog nem is gyors, eleve a VS nem erre van kitalálva, lassabban éri el a textúrát mint a PS másrészt az ilyen lebegőpontos textúrák mintavételezése marha lassú amúgy is és nagy adatforgalmat generál. Miért nem csinálod úgy hogy egy patch-et használsz de azt dinamikus VB-ben? Szükség esetén lock és CPU-ból lehet frissíteni az egészet mondjuk egy külön szálban így még akadályt sem jelent a dolog. Renderelési tempóban a dinamikus VB rosszabb a statikusnál, de talán az egyik legjobb megoldás mind tempó szempontjából, mind szükséges vas szempontjából. "

azért ne vicceljünk, ne mond hogy a proci gyorsabban olvas texturát mint a vertex shader
a 32 bites fp sem gáz annyira, mert 8 bites loszarra valo, 16 bites lenne az ideál
talán a processzort nem grafikára kéne használni
   
TPG - Tag | 3402 hsz       Online status #97510   2008.10.26 12:19 GMT+1 óra  
Idézet
dvorgaz :
Azért tetszett ez a VTF-es dolog mert sokkal kisebb a memoriaigénye, viszont most kipróbáltam, és elég lassúnak tűnik.
A statikus VB-vel az a gondom, hogy nagy terepeknél baromi sok memoriát foglalhat, VTF-nél több négyzetkilométernyi terület simán elférne a videokarin.
Ez dinamikus VB ez kellően gyors ahoz, hogy egy nagy terület ugyanazzal a patch-el rajzoljam ki? Mármint úgy, hogy minden alkalommal teljesen átírkálom a vertexeket (szal a nagy területet sok kis patchből)?


A dinamikus VB ugyanannyi helyet foglal mint a statikus, egy a különbség: azzal hogy a VGA-nak megmondod hogy a VB dinamikus az egy olyan helyre fogja azt a memójában pakolni ahol mind a lock-olás mind a módosítás gyorsabban végrehajtható. Cserébe viszont valamivel lassabb lesz a renderelés is, a kompromisszum tökéletes példája. A probléma pedig tökéletes példája az optimalizálás során felmerülő egyik alap kérdésnek: memóriára vagy számításigényre optimalizáljunk-e? A kérdést mindenkinek magának kell megválaszolnia, én spec számításigényre optimalizálnék. Viszont arra a tényre alapozhatunk hogy a távolban lévő dolgok kisebbnek látszanak ebből pedig következik hogy kevesebb is látszik belőlük. Így nem kell egyszerre az egész terepet a videómemóban tárolni, a távoli részeken nyugodtan lehet csökkenteni a részletességet. Másrészt ha feltételezzük hogy nem repülőszimulátorról van szó akkor feltehetjük azt is hogy a szemlélő nem fog nagy tempóval haladni, így meg tudunk spórolni jópár VB frissítést is, elég másodpercenként csak párszor.
Idézet
dvorgaz :
Egyébként meg nem lehet olyat, hogy a magasságértékeket valami tömbbe teszem be a shaderbe, mint pl amikor a fénypozíciókat meg egyéb tetszőleges paramétereket belekötöm? Így nem kéne textúrából olvasni VS-ben; viszont sehol se hallottam, hogy így csinálta valaki, gondolom van valami oka.


A shader-ben feltölthető konstansok számának van felső határa, méghozzá ilyen szempont elég alacsony. A szabvány nem köti meg mennyi, csak azt határozza meg hogy mind VS2-nél mind VS3-nál minimum 256 helynek kell lennie, így csak arra lehet építeni hogy ennyit tud az adott VGA (le lehet kérdezni az aktuálisan támogatott értéket, de felesleges, a probléma természete nem olyan hogy így dinamikusan lehessen a megoldást rá alakítgatni).
Reality is almost always wrong. - House

   
dvorgaz - Törzstag | 575 hsz       Online status #97491   2008.10.26 10:25 GMT+1 óra  
Azért tetszett ez a VTF-es dolog mert sokkal kisebb a memoriaigénye, viszont most kipróbáltam, és elég lassúnak tűnik.
A statikus VB-vel az a gondom, hogy nagy terepeknél baromi sok memoriát foglalhat, VTF-nél több négyzetkilométernyi terület simán elférne a videokarin.
Ez dinamikus VB ez kellően gyors ahoz, hogy egy nagy terület ugyanazzal a patch-el rajzoljam ki? Mármint úgy, hogy minden alkalommal teljesen átírkálom a vertexeket (szal a nagy területet sok kis patchből)?
Egyébként meg nem lehet olyat, hogy a magasságértékeket valami tömbbe teszem be a shaderbe, mint pl amikor a fénypozíciókat meg egyéb tetszőleges paramétereket belekötöm? Így nem kéne textúrából olvasni VS-ben; viszont sehol se hallottam, hogy így csinálta valaki, gondolom van valami oka.
   
TPG - Tag | 3402 hsz       Online status #97487   2008.10.26 10:01 GMT+1 óra  
VTF csak SM3-tól van ráadásul csak 32bites lebegőpontos textúrából (1 vagy 4 csatorna lehetséges). És ez mellett a dolog nem is gyors, eleve a VS nem erre van kitalálva, lassabban éri el a textúrát mint a PS másrészt az ilyen lebegőpontos textúrák mintavételezése marha lassú amúgy is és nagy adatforgalmat generál. Miért nem csinálod úgy hogy egy patch-et használsz de azt dinamikus VB-ben? Szükség esetén lock és CPU-ból lehet frissíteni az egészet mondjuk egy külön szálban így még akadályt sem jelent a dolog. Renderelési tempóban a dinamikus VB rosszabb a statikusnál, de talán az egyik legjobb megoldás mind tempó szempontjából, mind szükséges vas szempontjából.
Reality is almost always wrong. - House

   
dvorgaz - Törzstag | 575 hsz       Online status #97482   2008.10.26 07:06 GMT+1 óra  
Helló

Szerintetek mennyivel gyorsabb/lassabb egy terepet úgy renderelni, hogy egyetlen sík patch-nek megfefelő meshem van, és ezt többször rajzolom ki úgy, hogy vertex shaderben állítom át a vertexeit illetve textúrából olvasom be a magasságokat (vertex texture fetching?), szemben a "klasszikus" megoldással (ahol is statikus vertexbufferekben tárolom az egész terepet)?

Annyi előnye biztosan lenne ennek a VTF-nek, hogy a memóriaigény drasztikusan lecsökkenne, hiszen egy 1024-es terep 16bites magasságokkal kb egy 2 megás tömbben elférne, szemben modjuk egy float3-ból álló vertexbuffernél, ami asszem 12 mega + esetleges normálok/textúra koordináták.

Egyébként VS-ből textúra olvasás csak SM 3-tól van?
   
AmidaBucu - Tag | 281 hsz       Online status #96892   2008.10.10 09:46 GMT+1 óra  
Nah sikerült Rossz texfromtumot használtam
De egy másik probléma. Lementem a mélységet a fény szemszögéből vsmhez.
Elmosom, és miután használom ezt a texet a vsm shaderrel a végeredményt csak egy másik texturába nyomhatom bele
Tehát két nagy textúrát kell elpazarolnom egy árnyékhoz, az meg baromi sok vram.
Ti hgy szoktátok?
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #96326   2008.09.24 10:54 GMT+1 óra  
Helloka. Próbáltam vsm-et elővarázsolni (rengeteget kellet olvasni )
Kiprobáltam egy gömbön, hogy mien árnyékot vet, de csak egy hímes tojás effekt lett belőle
Alant a kodom
Kód:
float4 pos;
//kiszámolom a world post

float4 ppos = mul(mul(pos, LV),LP);
ppos /= ppos.w;

/ /ugyenez csak nem world hanem a lámpa VP terében

float2 sTexC;
sTexC.x = 0.5*ppos.x+0.5;
sTexC.y = 1-(0.5*ppos.y+0.5);

float2 m = tex2D(shadowtex, sTexC).xy;
   
float E_x2 = m.y;
float Ex_2 = m.x * m.x;
float var = min(max(E_x2 - Ex_2, 0.0)+0.0008, 1.0);
float m_d = (m.x - ppos.z);
float p = var / (var + m_d * m_d);// na jó bevallom ennek az öt sornak egy picit ctrl-v szaga van :P
       
return p;


Amugy ha valaki tud egy jó valószínűség számításos linket, ahol nem 2000 oldalon keresztül taglalják a taglalni valót, akkor idevele, plz mer csebisev egyenlőtlenséget és a gauss eloszlást nemigazán értem
Ami tönkremehet, az tönkre is megy!!!
   
DMG - Szerkesztő | 3172 hsz       Online status #95754   2008.09.10 02:11 GMT+1 óra  
Na jó de jön a tech 5.
-----------------------------------------
Dont Listen to the Naysayers
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [22]