Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Ventor

Strony: 1 2 3 [4]
46
Matematyka i fizyka / Odp: Obwody plam
« dnia: Luty 01, 2008, 08:06:57 »
Jedyne słuszne rozwiązanie to algorytm floodfill lub polska nazawa "pożar prerii". Trzeba go trochę zmodyfikować, żeby nie kolorował plamy a każdy napotkany kolor inny niż kolor plamy oznaczał jako jej obwód.

Filtr jest wolny bo trzeba przelatywać całą bitmapę, a szukanie konturu, o którym pisał Steel_Eagle nie sprawdzi się jeżeli plamy będą miały dziury.

//Edit
http://willow.wsb.edu.pl/~pgaj/instrukcje/instr_grafika_kontury.pdf

47
OpenGL / Odp: Możliwy problem z normalnymi
« dnia: Styczeń 26, 2008, 17:53:02 »
Nie wszystkie trójkąty są tak samo poukładane, widać to na wireframe. Poukładaj wszystkie w tą samą stronę, to wtedy solid+flat będzie wyglądał tak jak chcesz. Dzieje się tak bo prawdopodobnie (w DX na pewno) normalna pierwszego wierzchołka traktowana jest jak normalna trójkąta. Niektóre pary trójkątów mają pierwszy wierzchołek wspólny i wtedy mają one jeden odcień, a niektóre nie i wtedy są różne odcienie.

48
Gry / Odp: Polskie firmy zajmujące się tworzeniem gier
« dnia: Styczeń 11, 2008, 19:43:44 »
Cytat: Esidar
Akurat w naszej firmie pracują zdalnie programiści. Ale jest ich mało i dostają zadania na 1-2 dni pracy z minimalną ilością materiałów.
No trochę przesadziłeś, najdłuższy projekt jaki dla Was robiłem trwał prawie rok, a najwięcej materiałów to prawie 30GB. Zapomniałeś też dodać, że praca w CDPLC nie polega na tym samym co praca w CDPRED. Pracując kilka lat nad jedną grą nie potrzeba przesyłać takich ilości materiałów jak pracując nad kilkoma grami w miesiącu.

Mimo wszystko jednak nie wyobrażam sobie pracy zdalnej jako programista np w CDPR. W tej chwili nie muszę się dogadywać z innymi programistami, bo jestem jedynym przy danym projekcie, ale trzeba się dogadywać w sprawie grafik, instalatorów, dźwięków, filmów itp. i to już zajmuje trochę czasu i czasem jest męczące. Ja nie potrafię równocześnie pracować i rozmawiać o szczegółach tej pracy, a że zdalnie trudniej wytłumaczyć co się ma na myśli to bym siedział i gadał na gg zamiast pracować.

Kiedyś pracowałem w innej firmie zajmującej się programowaniem, choć nie gamedev-em, i muszę powiedzieć, że 15 minut rzeczowej rozmowy może dać więcej niż cały dzień gadania przez telefon czy gg.

49
Językoznawstwo / Odp: C/C++ kontra Pascal/Delphi
« dnia: Styczeń 09, 2008, 21:37:03 »
To wszystko zależy co dla kogo jest czytelne, bo ja np nie nawidzę C++ głównie z powodu {}. Kod przez te nawiasy staje się dla mnie bardzo nieczytelny! Jak go przeglądam to musze się wpatrywać w którą stronę jest nawias odwrócony i czy to w ogóle nawias, a begin/end z pięciu metrów widzę. ... a tak w ogóle to najczytelniejszy i najlepszy jest asm :P

50
Językoznawstwo / Odp: C++ && Assembler
« dnia: Styczeń 04, 2008, 09:29:27 »
Nie jest prawdą to, iż kod w assemblerze będzie się pisało wolniej. Czy też to, iż sam asm jest trudniejszy, w ogóle.
Jest prawdą. Chyba, ze ktos pisze od lat i ma tysiac f-kcji/makr. Lubie assembler, to wlasciwie moj pierwszy 'powazny' jezyk, przez lata bylem zwolennikiem podejscia 100% asm i pisalem w nim programy po kilkadziesiat tysiecy linii, ale nie chcialbym juz do tego wracac :)
Wszystko zależy od indywidualnych upodobań, bo ja też zawsze byłem zwolennikiem 100% asm, nadal jestem i cały czas piszę w asm. Oprócz tego jak potrzebuje coś szybko zrobić (przeważnie do pracy) to piszę w Delphi, za to nie mogę patrzeć na C++. Nie lubię tego języka, jest dla mnie zupełnie nieczytelny. OOP w wielu przypadkach to przerost formy nad treścią, choć są też odwrotne sytuacje, ale zawsze mogę improwizować i tworzyć pseudo OOP w asmie. Z góry zakładam, że nikt nie będzie modyfikował ani pewnie nawet oglądał mojego kodu, więc wystarczy, że jest zrozumiały dla mnie.

Co do szybkości działania to dobrze zoptymalizowany kod w asm jest szybszy, ale po pierwsze komu się chce optymalizować, a po drugie ile taka optymalizacja pomoże? W większości przypadków nie ma to sensu, choć są sytuacje, w których warto optymalizować.
Całkiem niedawno pisałem procedurę (do mojego projektu wszechczasów ;)) kopiującą vertexy z bufora w pamięci do DX-owego vertex bufora. Problem polegał na tym, że format vertexa w buforze pamięci ma wszystko co tylko można sobie wymyślić, a ten DXowy tylko to co jest potrzebne do renderowania. Musiałem więc napisać coś co szybko mi skopiuje tylko niektóre dane (określone flagami). Wymyśliłem że taką procedurę najlepiej wygenerować i tak też zrobiłem - jedna instrukacja (movsd lub add esi,4) na jedno pole struktury. Później jeszcze zoptymalizowałem - jeżeli kilka kolejnych pól nie ma być kopiowanych to załatwiane jest to jedną instrukcją. Rozwiązanie to jest nieporównywalnie szybsze np do zwykłego sprawdzania flag, gdzie potrzebowałbym 3-4 instrukcje na jedno pole struktury. ... o C++ nie wspomnę :P


Nie da się ukryć, że programowanie w asm może zająć więcej czasu, ale na to, jak już wspomniał yarpen, duży wpływ ma ilość gotowych funkcji, makr, bibliotek itp. Mi przez lata trochę się już tego nazbierało i cały czas dopisuję. Najbardziej lubię jak do pracy robię coś co później mi się przyda, bo mi za to płacą  ;D

Jeżeli ktoś ma zamiar pisać w asm polecam flat assemblera, jest na prawdę dobry, szybki, ma wbudowany edytor, jest darmowy również na użytek komercyjny, cały czas rozbudowywany, obsługuje 64bitowe instrukcje i w ogóle jest naj ;)

51
Inne / Odp: Programowanie na procesory wielordzeniowe
« dnia: Grudzień 16, 2007, 10:17:07 »
Gdzie te rejestry zapisuje, pewnie w Cache L2 u Intela, a w AMD w L3. W AMD do tego poziomu ma dostep kazdy rdzen.

Procesor (czyli też system) nie ma możliwość zapisywania do cache, po prostu nie ma takich instrukcji. System zapisuje rejestry do pamięci, pewnie na jakiś stos i jak się uda to przy ponownym przełączeniu na to zadanie, zapisane dane będą jeszcze w cache, ale wydaje mi się to mało prawdopodobne.
Co ciekawe procesory od 286 w górę obsługują sprzętowo przełączanie zadań, ale nie zapisują np rejestrów koprocesora, więc winda nie korzysta z tego i robi wszystko programowo.

52
DirectX / Odp: HLSL/Cg'owy varying...?
« dnia: Listopad 28, 2007, 08:35:42 »
Że tak zapytam,: a jak wyobrażacie sobie przesłanie czegoś z vertex shadera do pixel shadera bez interpolacji, można by teoretycznie (chociaż z tego co wiem w opengl jeszcze nie ma czegoś takiego) przesłać bez interpolacji coś z geometry shadera do pixel shadera.
Musiałbyś chyba dla każego wierzchołka trójkąta wysyłać (np jako TEXCOORD) tą samą wartość, wtedy interpolacja daje takie same wartości dla każdego pixela.

53
Programowanie grafiki / Odp: Animacja na kościach
« dnia: Listopad 20, 2007, 09:42:24 »
Cytuj
Cytuj
Pytanie, po co Ci tyle kości? Kilkadziesiąt??? Nie wiem, może profesjonalne modele tyle mają i każdy drobny mięsień to osobna kość, żeby mógł się napinać, ale mnie się wydaje że do odwzorowania rąk, nóg, głowy, stóp, dłoni itp. spokojnie wystarczy limit np. 32 kości.
Nie wystarczy. Przykładowo, bohater ma dwie dłonie, dłoń ma pięć palców, a każdy z nich składa się z trzech segmentów i w efekcie mamy 30 kości na same palce dłoni (tak to wyglądało na przykład w Doom'ie 3).
32 kości to mało właśnie np na dłonie. Nie robię konkretnie żadnej postaci, która miałaby akurat tyle kości, ale nie chaiałbym wprowadzać tak drastycznych ograniczeń. Jak przyjdzie mi kiedyś robić ośmiornicę ;D 8 kości * 8 ramion to już 64, a 8 na jedno ramię to trochę mało.


54
Programowanie grafiki / Odp: CCW lub CW
« dnia: Listopad 20, 2007, 02:16:29 »
Cytuj
Cytuj
[...]Twierdzisz, że trzeba sprawdzić znak tej normalnej. Pomijając fakt że normalna nie ma znaku[..]
Cytuj
[...]w tym momencie wracasz do punktu wyjścia bo zależnie w jakiej kolejności rozpatrzysz te punkty otrzymasz normalną skierowana w jedną lub druga stronę[...]

To w końcu normalna ma znak, czy nie? Bo raz tworzysz od nowa matematykę, a raz wracasz do starych sprawdzonych teorii. Gwoli przypomnienia - normalna to wektor i ma nawet 3 znaki, po jednym wzdłuż każdej z osi.

Najpierw chcesz sprawdzać znak normalnej, a później jeszcze dodajesz, że wektor ma trzy znaki. Ja nigdzie nie napisałem, że wektor ma znak, bo nie ma, a tym bardziej nie ma trzech znaków! Współrzędne wektora mogą mieć znak, ale nie sam wektor, a to jest różnica między "starą sprawdzoną teorią" a "tworzeniem nowej matematyki". Zastanów się więc jeszcze raz kto tworzy nową matematykę.

Jak tak czytam co piszesz, to zastanawiam się czy w ogóle wiesz na czym polega problem? Opowiadasz o przekształcaniu sześcianu bliżej nieokreślonymi funkcjami F1...F5, ale przecież szecian to tylko przykład. Co zrobisz jak dostaniesz postać składającą się z 5000 trójkątów z nieprawidłową kolejnością wierzchołków. Wymyślisz funkcje F1...F4999? Poza tym Twój algorytm jest niedopracowany, innaczej działa dla sześcianu, inaczej dla pierscienia, a dla innych brył musisz "ostro pomyśleć".

Cytuj
Tam dostajesz w wyniku czworokąty i trójkąty o ile z drugimi nie ma problemu to pierwsze trzeba jakoś podzielic na dwa trójkąty i ustalić kolejność ich wierzchołków, przecież grafika do tego nie zaprzęgniesz.
... no grafika nie zatrudnię i miliona funkcji tez nie wymyślę. Po prostu podzielę każdy czworokąt [1,2,3,4] na dwa trójkąty [1,2,3] i [1,3,4]. Oba trójkąty będą widoczne z tej samej strony co czworokąt, a czworokąt będzie wygenerowany prawidłowo, bo
Cytuj
CSG powinno wiedzieć po której stronie wygenerowanej powierzchni jest wypełnienia, a po której wolna przestrzeń


55
Programowanie grafiki / Odp: CCW lub CW
« dnia: Listopad 19, 2007, 09:25:11 »
Zacytuję Krzyśka K.: "androny prawisz".

Sposób o którym mówisz:
Cytuj
Jest prosta metoda na liczenie CW i CCW. Mając 3 wierzchołki trójkąta w losowej kolejności czyli jakieś v0,v1,v2 wystarczy policzyć corss product v2v0 i v1v0 (znormalizować)
to nic innego jak obliczanie normalnej trójkąta. Twierdzisz, że trzeba sprawdzić znak tej normalnej. Pomijając fakt że normalna nie ma znaku i tak się mylisz, bo wyobraź sobie sześcian w lokalnym układzie współrzędnych (czyli tak jak chciałeś) i rozpatrz sciankę przednią i tylną. Twój algorytm potrakuje je identycznie, bo "patrzy" na nie z tej samej strony. Właśnie dlatego w okreslaniu CW/CCW ważne jest położenie obserwatora. Nie mów mi czasem o równaniach płaszczyzny i wyciąganiu z niej normalnej, bo z matematycznego punktu widzenia płaszczyzna nie jest widoczna tylko z jednej strony. Możesz sobie liczyć normalną tej płaszczyzny np na podstawie trzech punktów i w tym momencie wracasz do punktu wyjścia bo zależnie w jakiej kolejności rozpatrzysz te punkty otrzymasz normalną skierowana w jedną lub druga stronę.

To czy trójkąt jest CW czy CCW zależy od grafika i jeżeli on coś pomieszał to musi to naprawić, bo nie ma algorytmu, który to naprawi. Można wymyślić algorytm zbliżony do ręcznego naprawiania przez grafika i prawdopodobnie w większości przypadków wystarczający. Obracasz cały obiekt tak, żeby rozpatrywany trójkąt był prostopadły do kierunku patrzenia, puszczasz promień w jego kierunku od obserwatora i liczysz ile trójkątów przetnie zanim do niego trafi. Jeżeli po drodze ilość trójkątów była przysta to rozpatrywany trójkąt będzie widoczny (front face), a jeżeli nieparzysta to back face. I tak po kolei każdy trójkąt sprawdzasz. Nie sprawdzi się to np w przypadku skyboxa, który widoczny jest od wewnątrz, lub otwartych brył.

56
Programowanie grafiki / Odp: Animacja na kościach
« dnia: Listopad 18, 2007, 22:17:44 »
Przy takiej liczbie macierzy albo zbuntuje się driver, albo całe przetwarzanie wierzchołków po cichu przeniesie się na CPU zmienić swoją wizję świata. ;)
Driver raczej się nie zbuntuje, ale z przeniesieniem na CPU to całkiem możliwe.

Słabo z tymi shaderami, myślałem, że da się coś wymyślić. Zastanawiam się teraz czy gdybym miał np kilka animowanych postaci, każda po kilkadziesiąt kości to lepiej załatwić to jednym drawcall-em przesyłając w jednym streamie wierzchołki, a w drugim macierze, czy lepiej renderować każdą osobno i prawdopodobnie dzielić je jeszcze na mniejsze kawałki? Każda postać inna, więc odpadają instancje.

57
Programowanie grafiki / Animacja na kościach
« dnia: Listopad 18, 2007, 16:26:16 »
Jako że blizej mi do Fixed Function niż shaderów, a właśnie chcę się trochę bliżej z nimi zapoznać przyszło mi dogłowy kilka pytań. Nie będę od razu wszystkich zadawał, bo niektóre wynikają z innych, więc część pewnie sama się wyjaśni.

Zacznę od animacji przy użyciu kości. W Fixed Function można zdefiniować 256 macierzy, a każdy wierzchołek morze mieć 3 wagi i 4 indexy do macierzy. Załóżmy, że chciałbym to samo odwzorować za pomocą Vertex Shadera. Problem w tym, że stałych jest 256 (VS 3.0) lub nawet mniej dla starszych wersji. Każda stała to 4 floaty, a na macierz potrzeba 16, więc na 256 stałych można zapisać 64 macierze (kości). Pomijając fakt, że kilka stałych jest potrzebnych np do świteł, jak rozwiązać problem jeżeli potrzebowałbym więcej niż 64 kości?

Przyszło mi do głowy kilka pomysłów. Po pierwsze można wysyłać macierz razem z danymi każdego wierzchołka, ale to oczywiście idiotyczny pomysł. Po drugie VS 3.0 ma dostęp do tekstur i możnaby w takiej teksturze zapisać macierze, ale co ze starszymi shaderami? Można też podzielić mesha na kawałki korzystające z mniejszej ilości kości, ale to rozwiązanie najmniej mi się podoba, bo psuje całą moją wizję świata ;) Istnieje jakieś inne rozwiązanie tego problemu?

58
Programowanie grafiki / Odp: CCW lub CW
« dnia: Listopad 16, 2007, 09:47:30 »
Witam wszystkich po kilku latach ;). Pewnie nikt mnie nie pamięta, ale nic to :P

Czytam ten temat i nie mogę wyjść z podziwu jak bardzo komplikujecie sprawę. Po pierwsze backaface culling wykonywany jest przed rasteryzacją, jak wspomniał orzech. Nie ma innej opcji i każdy kto pisał softwareowy renderer na pewno o tym wie.

Po drugie kolejność wierzchołków ustala grafik (lub program do obróbki). Jeżeli wierzchołki (lub indeksy do nich) nie są ustawione w prawidłowej kolejnośći, to tylko ręcznie można to naprawić. Nie ma algorytmu, który to zrobi, bo np sześcian może być renderowany z zewntrz jako jakiś obiekt albo od środka np jako skybox. W obu tych przypadkach kolejność wierzchołków musi być różna, lub w jednym przypadku trzeba użyć backface a w drugim frontface culling.

Po trzecie nie są potrzebne żadne normalne, ani wierzchołków, ani trójkątów. Obliczenie polega na wymnożeniu dwóch wektorów (cross product) trójkąta, znajdujących się na płaszczyźnie XY. Po wymnożeniu otrzymujemy wektor prostopadły do XY i sprawdzamy tylko znak wspólrzędnej Z tego wektora. Nie pamiętam tylko jaki znak określa CW a jaki CCW.

Po czwarte:
Mam pytanie jak rozpoznać czy vertexy sa ułożone CCW czy CW ?
patrz wyżej

Ok. Z innej beczki Mam model który ma to pomieszane(tzn. część trójkątów które powinny być widoczne nie są widoczne, a część z tych ktore powinny być niewidoczne są widoczne) i jak to teraz poprawić.
Nie da się inaczej niż ręcznie w jakimś edytorze.

Strony: 1 2 3 [4]