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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | [1] > 2 <
Geri - Törzstag | 2186 hsz       Online status #175354   2012.02.26 22:37 GMT+1 óra  
minden pixelre ki kell lőnöd egy sugarat, te tóni


   
ddbwo - Tag | 1625 hsz       Online status #175353   2012.02.26 22:35 GMT+1 óra  
Egyetlen ray-sphere teszt lefut 0.00 másodperc alatt.
Okos matek: x*0.00 = 0 ---> Végtelen teszt azonnal.


---

A messzi tárgyakról ugrott be hirtelen. Ahogy elképzelem a kamera lencsét, a sugarak vektora szétfelé áll, mint egy sörét. De mi történik, ha valami pont olyan helyen van, ami két ray közé esik?

Gyors fejszimuláció alapján: Nem lesz a képen, sem sehol a jelenetben nem lesz hatása!!!
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Geri - Törzstag | 2186 hsz       Online status #175352   2012.02.26 22:34 GMT+1 óra  
ddbwo: ha kicsi és részletes dolgokat akarsz - jellemzően akkor, ha 0 és 1 helyek közé töltöd be az összes geometriát, a float percizitása kevés lehet. floattal szmötyizhet minden. ha cpus realtime ray tracert akarsz, akkor viszont felejtsd el a doublet, és oldd meg a problémát trükkökkel.

   
sirpalee - Tag | 1282 hsz       Online status #175351   2012.02.26 22:27 GMT+1 óra  
Nagyon ritkán van rá csak szükség, főleg akkor, ha a kamera és az objektumok messze vannak az origótól (ez kombinálva a nagy objektumokkal). Akkor pl a sugár egyszerűen átmehet az objektumokon stb. Nekünk volt hasonló problémánk pár rendernél, és ott azzal megoldódott, hogy az intersection teszteket double-ben végeztük. Persze nem mindenhol, csak ahol kellett
raytraceisten és übermedic
   
ddbwo - Tag | 1625 hsz       Online status #175350   2012.02.26 22:16 GMT+1 óra  
Hát ja. Végűlis logikus. Elvégre double.
Mikor és hol van szükség dupla pontosságra? Eddig még nem használtam double-t sehol...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Geri - Törzstag | 2186 hsz       Online status #175348   2012.02.26 22:10 GMT+1 óra  
float elég.

double: ha az FPU a szűk keresztmetszet, akár több mint 2x-es sebességkiesést is jelenthet.

   
ddbwo - Tag | 1625 hsz       Online status #175347   2012.02.26 22:05 GMT+1 óra  
Mekkora pontosságot érdemes tartani a számokkal? Szükséges lehet a double vagy elég a float is? Mekkora sebesség kiesést jelenthet a double?
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Joderida - Tag | 55 hsz       Online status #171688   2011.12.31 13:20 GMT+1 óra  
Asylum vagy Pretender:
Olyan kérdésem lenne, több dokumentációban olvastam, hogy a függvényt 2x hívják meg, az egyiket a nearplane-re, a másikt a farplane-re, a kérdésem az, hogy miért teszik ezt, ha egyszer az eyepos-ből ki lehet következtetni a sugár egyik pontját a másikat meg mondjuk a nearplane-ből.
Még egy kérdésem lenne, lookat-el csinálom a kamerámat, kell-e valamire figyelnem a sugárkövetéssel, collusion detection-el kapcsolatban. Köszönöm előre is a válaszokat.
gluUnproject-ről van szó(nekem saját függvény):
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=279647

ui.: Elviekben sikerült megírnom a sugérkövetéses függvényem, de később tudom csak tesztelni, s BUÉK mindenkinek.

Ezt a hozzászólást Joderida módosította (2012.01.02 18:46 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #171373   2011.12.25 14:42 GMT+1 óra  
lehet, hogy így nem jó, de:
vagy ha a kamerát a {0,0,0}-nak tekinted (azaz viewSpace), akkor a következőképpen is megkaphatod a far plane-beli viewSpace pozíciót (részlet a shaderemből)
Kód:
float3 eyeToScreen = float3(Position.x * tanHalfFOV * aspect, Position.y * tanHalfFOV, 1);
float3 viewSpacePos = normalize(eyeToScreen) * farPlane;

ha pedig worldSpace kell, akkor
Kód:
float3 eyeToScreen = float3(Position.x * tanHalfFOV * aspect, Position.y * tanHalfFOV, 1);
EyeRay = mul(eyeToScreen, invView);

Kód:
float4 position;
position.xyz = eyePosition + normalize(EyeRay) * farPlane;
position.w = 1.0f;

De lehet hogy nem.. Deferred shadingnél működik, azzal a különbséggel, hogy nekem nem a farPlane kell, hanem egy adott Depth

De persze az is teljesen jó, amit Asylum írt

   
Asylum - Törzstag | 5440 hsz       Online status #171371   2011.12.25 13:43 GMT+1 óra  
Feltételezve, hogy a user az (x, y) eleme [0, w] x [0, h] pontra kattintott ezt elöször át kell raknod a [-1, 1] x [-1, 1] tartományba, majd beszorzod a viewproj mátrix inverzével (ezután is kell perspective division!). Így kapsz egy world space beli pontot, ez lesz az egyenesed egyik pontja, a másik meg az eyepos nyilván.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joderida - Tag | 55 hsz       Online status #171370   2011.12.25 12:20 GMT+1 óra  
Sziasztok, lehet nem jó helyre írok. Mindössze csak egy kérdésem lenne. Opengl ES 1.0-ban fejlesztek egy játékot és a kérdésem az lenne, hogy sugárkövetéssel szeretném megoldani az egyes objektumok kiválasztását. A matematikai "alapokat" innen megnéztem http://dea.unideb.hu/dea/bitstream/2437/2376/1/Diplomamunka_Berkes_Balazs.pdf .

A kérdésem csupán annyi, hogy egy egyenest meghatározhat 2 pont. Ezt a két pontot úgy kapom, hogy egyik a kamerám(xyz), a másik, ha jól értelmezem az a pont amit a felhasználó ad meg(xyz), amelyet a vetítési síkon "kattint be".
Kell még-e valamit csinálnom ezzel a megadott ponttal, vagy ez a bevitt pont megegyezik a "vetítési síkon való pixellel"(lehet nem érthető, a fentebb linkelt pdf-ben a 4. ábrán a vetési síkon beszínezett pixelre értem).

Azt tudom, hogy az android a bal felső sarokból számolja az xy értékeket, és az opengl a bal alsóból, tehát ezt majd meg kell cserélnem, esetleg kell még valamire figyelnem, illetve helyes a feltételezésem fentebb?
Köszönöm előre is a segítséget, Kellemes ünnepeket, Boldog Karácsonyt mindenkinek.

   
Yodafon - Tag | 8 hsz       Online status #160907   2011.08.24 20:00 GMT+1 óra  
Valaki le tudná írni hogy mi a különbség az Torrance-Sparrow és a Cook-Torrance árnyalások között? Én azt vettem ki hogy a C-T a Beckmann eloszlást használja míg a T-S a Gauss féle normál eloszlást. Valamint a G, D és F azaz Fresnel kifejezésekre is szeretnék kérni egy pici leírást ha kérhetném. A G-nél azaz a "Geometrical Attenuation Factor"-nál olyat tudtam kihámozni, hogy azért kell a 3 kifejezés közül a minimumot venni mert az jár a legkevesebb energiaveszteséggel. Ezt jól értelmeztem? Illetve a D a mikrofelületeknek a milyét határozza meg? Ja és a C-T paper-ben olvastam hogy a színkomponenset egy egészen egyedi módon határozza meg. Ezt valaki el tudná magyarázni?

Köszönöm

   
DMG - Szerkesztő | 3172 hsz       Online status #160045   2011.08.18 21:20 GMT+1 óra  
-----------------------------------------
Dont Listen to the Naysayers
   
gaborlabor - Moderátor | 4449 hsz       Online status #160013   2011.08.18 16:13 GMT+1 óra  
molgab87 - Tag | 51 hsz       Online status #158362   2011.08.04 07:25 GMT+1 óra  
Hogy választod ki a következō sample irányt?

   
Asylum - Törzstag | 5440 hsz       Online status #158361   2011.08.04 07:20 GMT+1 óra  
Sztem valami mas lesz a problema, mert nem kene ilyen sotet legyen a gomb.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
molgab87 - Tag | 51 hsz       Online status #158360   2011.08.04 07:14 GMT+1 óra  
Furák picit a szinek, gamma korrigálsz rendesen? Persze lehet a legfelülre rakott nagy paca éget ki mindent...

Amúgy nem kimondottan arra a csalásra gondoltam, rakjuk egy baromi erős fény felülre, amit veszett egyszerū samplezni

   
Asylum - Törzstag | 5440 hsz       Online status #158349   2011.08.03 23:23 GMT+1 óra  
Második nekifutás.
Elöl nincs fal, valszeg azért fekete a gömb innensö oldala (mondjuk a többi is fekete, no mindegy). 120 sample, 4 szálon (néhány perc).

C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
DMG - Szerkesztő | 3172 hsz       Online status #158249   2011.08.03 15:12 GMT+1 óra  
Mi is saját szerver parkkal dolgozunk nem is kicsivel, de a mi esetünkben életképtelen(nek látjuk) mert több rendszer több terület, mindenki mindent azonnal akar, és minden létező erőforrást, meg úgy egyébként is a működésük jellege miatt szerencsésebb ha nem egy nagy erőforrásból táplálkoznak, hanem rendesen szétszeparált rendszereken dolgoznak, de persze látjuk azért értelmét, teszem azt fejlesztői oldalon nálunk azért lenne értelme, de ott meg megvannak az erőforrások, új beruházás ki van zárva. Na de hosszú lenne ezt ecsetelnem, lényeg, hogy mi arra amire ránk akarják sózni (csak mert ez a divat) nem látjuk életképesnek, persze nem feltétlen a technológia, hanem sokkal inkább az egyes osztályok üzletágak mentalitása miatt..
-----------------------------------------
Dont Listen to the Naysayers
   
Parallax - Tag | 574 hsz       Online status #158248   2011.08.03 15:05 GMT+1 óra  
(
Idézet
DMG :
de szerintem maga a cloud az, ami életképtelen a játékiparban, de még a többi IT szektorban sem látjuk értelmét a kollégákkal.


coderun

Jelentem felhőt használjuk már élesben, szóval van értelme, csak saját szerverparkkal nem a nagy tesónál.
)

   
syam - Törzstag | 1491 hsz       Online status #158195   2011.08.03 09:36 GMT+1 óra  
Ha megnézitek az SSAO eléggé pontatlan -.-

A közeljövő szerintem a hibrid renderelőké: az "elsődleges sugarakat" lehet helyettesíteni inkrementális rendereléssel az átlátszóság, tükröződés és árnyék pedig raycast / raytrace.
A GI pedig fake :3
alias aalberik
   
molgab87 - Tag | 51 hsz       Online status #158190   2011.08.03 08:05 GMT+1 óra  
Idézet
Asylum :
De ez nagyrészt SSAO ha jól látom.



Meg normális türköződés, stb...

Majd ha lesz animált mesh stb... Ez így eddig statikus geometria

   
Asylum - Törzstag | 5440 hsz       Online status #158181   2011.08.03 00:24 GMT+1 óra  
De ez nagyrészt SSAO ha jól látom.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1280 hsz       Online status #158178   2011.08.02 22:45 GMT+1 óra  
Ez tán realtime:
se
   
molgab87 - Tag | 51 hsz       Online status #158176   2011.08.02 22:26 GMT+1 óra  
Majd , egyelöre elvan a feladvánnyal

   
DMG - Szerkesztő | 3172 hsz       Online status #158163   2011.08.02 20:49 GMT+1 óra  
Idézet
molgab87 :
Nem lassú az, csak ésszel kell használni



Hát ez relatív, de kifejtheted ha már ez egy ilyen topic.
-----------------------------------------
Dont Listen to the Naysayers
   
molgab87 - Tag | 51 hsz       Online status #158157   2011.08.02 20:32 GMT+1 óra  
Nem lassú az, csak ésszel kell használni

   
DMG - Szerkesztő | 3172 hsz       Online status #158137   2011.08.02 19:09 GMT+1 óra  
real time amúgy Cloudban már megy, de szerintem maga a cloud az, ami életképtelen a játékiparban, de még a többi IT szektorban sem látjuk értelmét a kollégákkal.

http://www.youtube.com/watch?v=UGwk28tYJbA

http://www.youtube.com/watch?v=XVZDH15TRro&feature=related
-----------------------------------------
Dont Listen to the Naysayers
   
Asylum - Törzstag | 5440 hsz       Online status #158124   2011.08.02 18:24 GMT+1 óra  
Idézet
Pretender :
miért, mi az a sötét paca ott?



A padló szeme

@4Bit:

A szabály nagyon egyszerü: minél lassabban kirajzolni a képet
Ha a path tracingre gondolsz, akkor gyakorlatilag egy monte carlo módszer (integrál közelitése kvadratúrával); egy iterációs lépés egy kép (sample), de minden sample-ben random irányba pattognak a fotonok.

Baromi lassan konvergál.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #158121   2011.08.02 15:52 GMT+1 óra  
Nem hiszem, hogy ezt a közeljövőben használnád
nálam 1-2 fps-el futott eddig amit próbáltam (bár tény, hogy nincs erős cpum, és cpun ment). Ez még egyelőre nem egy realtime dolog... (de az lesz valószínűleg)

Valósághű fénykezelést lehet vele szimulálni, akárcsak a valóságban, itt is "fénysugarak" pattognak ide-oda, változik a tulajdonságuk, stb.

   
4Bit - Tag | 548 hsz       Online status #158119   2011.08.02 15:26 GMT+1 óra  
Mivel közeljövőbeli fejlesztéseim során (lehet) hogy én is használni fogom, meg szeretném kérdezni, hogy ennek mi lenne a szabálya, min alapszik?

Azt látom már hogy mi lenne a lényege, valamilyen fénykezelés áll a dologban, (tükröződés, visszaverődés, stb.) csak azt nem tudom még, hogy ennek hol lehet hasznát venni.
Köszönöm.
Úgy álljunk meg az életben, akár a sziklaszírt a tengerben; ne engedjük, hogy a szüntelen hullámverés megingasson bennünket.
   
molgab87 - Tag | 51 hsz       Online status #158104   2011.08.02 13:01 GMT+1 óra  
Idézet
DMG :
Viszont vagy az ablak kicsi, vagy a parapet magasság nagy.

Az a paca engem is érdekelne, mi vet árnyékot ott és hogyan?



Jézusom, azthittem egyértelmü... Gyorsan mozgó gömb...

Najó nem szemetelem tovább a topicot , legközelebb akkor ha valami real time cuccom lesz

   
DMG - Szerkesztő | 3172 hsz       Online status #158102   2011.08.02 12:57 GMT+1 óra  
Viszont vagy az ablak kicsi, vagy a parapet magasság nagy.

Az a paca engem is érdekelne, mi vet árnyékot ott és hogyan?
-----------------------------------------
Dont Listen to the Naysayers
   
molgab87 - Tag | 51 hsz       Online status #158101   2011.08.02 12:56 GMT+1 óra  


OBJECTI0N!!

   
Asylum - Törzstag | 5440 hsz       Online status #158098   2011.08.02 12:08 GMT+1 óra  
Nem tudom, de feltünöen egyszinüek a képeid, csak nem ez a "csalás"?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #158097   2011.08.02 11:42 GMT+1 óra  
miért, mi az a sötét paca ott?

   
molgab87 - Tag | 51 hsz       Online status #158095   2011.08.02 11:38 GMT+1 óra  


Egy baromi egyszerü dologgal minden máris sokkalta látványosabb lesz

   
Asylum - Törzstag | 5440 hsz       Online status #158094   2011.08.02 11:36 GMT+1 óra  
Én a viewproj mátrix inverzével beszorzom, majd perspective division és voilá.

Kód:
// i megy 0-tol Height-ig, j 0-tól Width-ig
// -> [-1, 1]x[1,-1] (dx)
tmp.y = (((float)i / (float)Height) - 0.5f) * -2.0f;
tmp.x = (((float)j / (float)Width) - 0.5f) * 2.0f;
tmp.z = 0;
tmp.w = 1;

D3DXVec4Transform(&pos, &tmp, &invvp);
pos /= pos.w;

r.Direction.x = pos.x - r.Origin.x;
r.Direction.y = pos.y - r.Origin.y;
r.Direction.z = pos.z - r.Origin.z;

NORMALIZE(r.Direction, r.Direction);


Clippinget viszont kézzel kell elvégezni (near/far plane között van-e stb.)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #158093   2011.08.02 11:20 GMT+1 óra  
Idézet
Wolfee :
nem, hanem hogy ha a kamerát nem egy fix ponttal adom meg, hanem egy ponttal, egy lookattel, egy up és right iránnyal, akkor hogyan lehet kiszámolni a sugár irányát



Ezt írtam le 5 hsz-szel lejjebb :]
alias aalberik
   
Wolfee - Törzstag | 1336 hsz       Online status #158091   2011.08.02 11:15 GMT+1 óra  
nem, hanem hogy ha a kamerát nem egy fix ponttal adom meg, hanem egy ponttal, egy lookattel, egy up és right iránnyal, akkor hogyan lehet kiszámolni a sugár irányát
FZoli jóváhagyásával XD

   
molgab87 - Tag | 51 hsz       Online status #158087   2011.08.02 10:21 GMT+1 óra  
Úgy néz ki

   
syam - Törzstag | 1491 hsz       Online status #158086   2011.08.02 10:15 GMT+1 óra  
Idézet
Wolfee :
www.fsz.bme.hu/~szirmay/grafika/bmeray.ppt

ebből a 17es diára voltam kíváncsi. mostmár mindenki fogalmazza meg magának a kérdést



A kérdés akkor hogyan működik a FirstIntersect függvény? :]
alias aalberik
   
Wolfee - Törzstag | 1336 hsz       Online status #158084   2011.08.02 09:49 GMT+1 óra  
www.fsz.bme.hu/~szirmay/grafika/bmeray.ppt

ebből a 17es diára voltam kíváncsi. mostmár mindenki fogalmazza meg magának a kérdést
FZoli jóváhagyásával XD

   
syam - Törzstag | 1491 hsz       Online status #158083   2011.08.02 09:41 GMT+1 óra  
Idézet
Wolfee :
Akkor én kérdezek:
Eddig egy fix pontban volt a kamerám, viszont ha jól tudom, három vektorral szokás megadni a kamerát, és az alapján számolni. szóval a kérdésem, hogy ha van egy XYZ vertexem, egy CxCyCz kamera pozícióm, egy LxLyLz lookat vektorom és egy UxUyUz "felfele", akkor hogyan tudom eldönteni, hogy az SxSy koordinátában látszik-e az adott vertex?



Mi úgy csináljuk, hogy - mivel OGL kompatibilitást is akarunk - hogy az OGL 2 mátrixából kiszámoljuk a látótér / frustum közeli oldalát azaz egy téglalapot és ezt pásztázzuk végig sugarakkal.
Ez a téglalap jelenti ugye a képernyőt vagyis ha 0..1, 0..1 tartományban meg tudod adni a képernyőkoordinátád (ha szükséges egy inverz viewport transzformációt berakhatsz ide) egy bilineáris interpolálással lazán meg tudod adni a világban a kívánt sugarat.
Ha pedig a sugarat ismered akkor a láthatóság már csak a szokásos vizsgálat :3
alias aalberik
   
molgab87 - Tag | 51 hsz       Online status #158079   2011.08.02 08:23 GMT+1 óra  
Nem tudom pontosan mit szeretnél, de ilyen generálnak az adott samplehez egy sugarat és egyszerűen elindítják a jelenetben

Amire te talán gondolsz, nos annak hirtelen nem tudom a hivatalos nevét, de kb annyiról szól, hogy egy gridet építesz a screenre, és megnézed melyik triangle melyik részben van, és építesz ennek megfelelően egy listát, és ezt használod nagyon alap szintű gyorsítóstruktúrának. Ez elég lassú, kényelmetlen és kamerától függően folyton újra kell építeni (egy normális acc struct ezekkel a tulajdonságokkal nem rendelkezik). Ez kombinálhatod half space function-okkal, de az már inkább rasterizáció

(half space meg pl ilyen http://www.devmaster.net/codespotlight/show.php?id=17 )

ui : a screenX és screenY jobb elnevezés, csak én gyakran elkövetem azt a hibát, hogy csak samplekban gondolkozom. (méghozzá 5 dimenziósban )

Ezt a hozzászólást molgab87 módosította (2011.08.02 08:41 GMT+1 óra, ---)

   
Wolfee - Törzstag | 1336 hsz       Online status #158076   2011.08.02 07:44 GMT+1 óra  
igen, Sx és Sy mint ScreenX és ScreenY.
Azt hiszem, nem egészen tudom még megfogalmazni a problémámat
FZoli jóváhagyásával XD

   
molgab87 - Tag | 51 hsz       Online status #158070   2011.08.02 01:26 GMT+1 óra  
sx és sy raytraceben a sample x és sample y koordináták... természetesen 0 és 1 között.

vfc felesleges mivel úgyis csak a frustumon belül tracelgetsz

   
Asylum - Törzstag | 5440 hsz       Online status #158069   2011.08.02 01:20 GMT+1 óra  
Sx és Sy mi? Pixel koordináták? Perspektiv vetités (és persp. division) után a [-1, 1] x [1, -1] intervallumban kell lennie.

Ha meg arra gondolsz amikor a vertex a kamera "mögött" van, akkor ugyanezen térben a z koordinátát kell megnézni, hogy a [0, 1] intervallumban van-e (avagy view spaceben a near/far plane között).

Ha az egészet world spaceben akarod akkor pedig view frustum culling.
Ezek jutottak elsöre eszembe.

Ezt a hozzászólást Asylum módosította (2011.08.02 01:25 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Wolfee - Törzstag | 1336 hsz       Online status #158066   2011.08.01 23:36 GMT+1 óra  
Akkor én kérdezek:
Eddig egy fix pontban volt a kamerám, viszont ha jól tudom, három vektorral szokás megadni a kamerát, és az alapján számolni. szóval a kérdésem, hogy ha van egy XYZ vertexem, egy CxCyCz kamera pozícióm, egy LxLyLz lookat vektorom és egy UxUyUz "felfele", akkor hogyan tudom eldönteni, hogy az SxSy koordinátában látszik-e az adott vertex?
FZoli jóváhagyásával XD

   
Bacce - Bacce | 1783 hsz       Online status #157980   2011.08.01 15:34 GMT+1 óra  
Raytrace, raycast, minden ami a témához kapcsolódik.
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
Frissebbek | [1] > 2 <