Autor Wątek: [c++] Opengl opakowany w obiekty, czy warto?  (Przeczytany 39899 razy)

Offline Xirdus

  • Redaktor

# Czerwiec 15, 2014, 13:12:40
Może i widziałeś, a ja pisałem w tych językach. Samo używanie drzewa DOM jest zorientowane obiektowo, powiedz jak można pisać w JS nie posługując się DOM, no chyba że używasz czegoś z rodzaju nodejs, ale i tam wszystko kreci sie wokół obiektów. Co do javy to wszem można pisać strukturalnie ale nikt tego nie robi.
Same obiekty to nie jest jeszcze obiektowość. Chodzi jeszcze o enkapsulację, polimorfizm i brak stanu globalnego. Popraw mnie jeśli się mylę, ale DOM to chyba jeden wielki stan globalny?

Co do programowania strukturalnego, to chciałbym żeby ludzie z niego częściej korzystali, bo obecnie nie występuje niemal nigdy. Najpopularniejszym paradygmatem jest niestety programowanie bezmyślne - na zasadzie "no przecież działa".

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline lethern

  • Użytkownik

# Czerwiec 15, 2014, 15:34:24
"W javie nikt nie pisze strukturalnie"
@Q
jeżeli dla Ciebie różnica między programowaniem strukturalnym a obiektowym polega na tym, w pseudokodzie:
Object obj = new Object();
obj.setX(50);
obj.setY(20);
obj.setLasers(true);
obj.setParent(owner);
scene.add(obj);
Struct st = malloc(..);
st.x= 50;
st.y= 20;
st.lasers= true;
st.parent= owner;
add_to_scene(scene, obj);
No to sorry... i c no difference
« Ostatnia zmiana: Czerwiec 15, 2014, 17:16:16 wysłana przez lethern »

Offline Xirdus

  • Redaktor

# Czerwiec 15, 2014, 17:26:02
@lethern: ani jeden ani drugi przykład nie pokazuje programowania strukturalnego.

Offline Q

  • Użytkownik

# Czerwiec 15, 2014, 18:35:39
To zaczyna przypominać dyskusje czy lepiej jest pisać obiektowo czy strukturalnie.
lethern różnica między strukturą a obiektem jest taka że obiekt może mieć metody i w ogóle może więcej niż jakakolwiek struktura. Osobiście nie używam struktur(tylko sporadycznie) bo nie wiem czy czasami w danej strukturze nie będę potrzebował metody która coś tam będzie robić.
Cytuj
Same obiekty to nie jest jeszcze obiektowość.
Wychodze z założenia że jak coś ma pióra, chodzi i gdacze to jest to kura.
Co do hermetyzacji to można zastosować w JS funkcje anonimowe i przestrzenie nazw.
JS jest prosty jak budowa cepa :)

Z tego co się orientuje to w javie opengl ma obiektową naturę. (z tego co podejrzałem w kodzie, nigdy nie pisałem openg w javie i mogę się mylić) Więc jak ktoś będzie chciał pobawić się opengl w javie to i tak otrze sie o obiekty i tego nie przeskoczy.

Offline koirat

  • Użytkownik


Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 15, 2014, 19:31:06
@lethern: ani jeden ani drugi przykład nie pokazuje programowania strukturalnego.
Yep. Wbrew podobieństwu nazewniczemu, programowanie strukturalne ma niewiele wspólnego ze struct-urami. Już lepiej byłoby mówić o programowaniu imperatywnym, bo wtedy przynajmniej łatwo byłoby zauważyć, że każdy programujący w C++/Javie/JS/C#/Pythonie/Ruby/Perlu/etc. pisze "strukturalnie".

Offline Xender

  • Użytkownik

# Czerwiec 15, 2014, 19:47:21
Już lepiej byłoby mówić o programowaniu imperatywnym, bo wtedy przynajmniej łatwo byłoby zauważyć, że każdy programujący w C++/Javie/JS/C#/Pythonie/Ruby/Perlu/etc. pisze "strukturalnie".
Przez te cudzysłowy już nie idzie Cię zrozumieć w tym zdaniu...
Programowanie strukturalne ze structami nie ma nic wspólnego (jest ortogonalnym konceptem).
Jest natomiast dobudowaniem na bazie programowania imperatywnego ograniczeń skonstruowanych tak, żeby kiepscy programiści mogli pisać "czytelny" kod (dobrze umieszczone goto, którego programowanie strukturalne zakazuje w całości, potrafi być czytelniejsze niż dodatkowe warunki w pętlach. Wczesny return tym bardziej).

Więc generalnie racze mało kto pisze w tych językach strukturalnie.

A struct'ów ani obiektów w nich w sumie też używać nie trzeba, można jechać z luźnymi zmiennymi (przynajmniej do pewnego poziomu skomplikowania programu). Więc jeśli te cudzysłowy miały wskazywać na niepoprawne znaczenie to też nie rozumiem...

Offline ArekBal

  • Użytkownik

# Czerwiec 15, 2014, 21:22:21
Cytuj
bo wtedy przynajmniej łatwo byłoby zauważyć, że każdy programujący w C++/Javie/JS/C#/Pythonie/Ruby/Perlu/etc. pisze "strukturalnie".
Nie każdy i nie wszystko.

Załamuje mnie gdy ludzie poniżej 20 lat są adwokatami programowania strukturalnego, a Fortrana na oczy nie widzieli. Ja mam 30 lat, a się nie odważę...

Wracając do tematu i utopii
pt. Face Object.
Daruj sobie Q. Obiektowość obiektowością, ale po ch.. ci  taki face...
Cytuj
Vertex f1(position, color, texpos, normal);
...
Face face(f1, f2, f3);
geo.add(face);
Nawet w blenderze "face"y mogły być trójkątem lub quadem(co zresztą komplikowało sporo)...

Wierzchołki w buforze są zazwyczaj DZIELONE tzn. zawsze gdy budujesz poligon(wielobok) czy dowolną bryłę zawsze się starasz dzielić wierzchołki zamiast je dublować, potem jakbyś sie przyjrzał na kompletny lepszy model to... Rozłożenie wierzchołków w takim meshu jest naprawdę z d... np. a) przy triangle strip z konieczności się dubluje wierzchołki ale oszczędność wraca gdzieś indziej, b) gdy potrzeba dodatkowej normalnej dla jednego z trójkątów przylegających do wierzchołka to znowu się robi sieczka... powodzenia w dodawaniu faceów w podany przez ciebie sposób. :)

 Nie jest głupie wybieranie trójkątów, czy innych faceów z mesha, przyszłego bufora. To jest często potrzebne(np. triangle picking).  Ale przy dodawaniu nie będzie to wyglądać tak różowo jak w twojej utopii.
W praktyce dodasz wierzchołki, ew. indeksy, wskażesz metodę rysowania i voila mesh gotowy. jak jakiś program będzie chciał być mądrzejszy(a to niekoniecznie się przykłada na lepsze rozwiązanie) to ci wypluje kilka takich części gdzie każda się inaczej rysuje.

Spróbuj dodać okrąg twoją metodą... będzie to baaardzo nieefektywne dodanie. :)

Z resztą użyjmy dodawanie okręgu jako przykładu...
Taki okrąg można przechować na kilka sposobów... z tych ważniejszych: najbardziej generyczny to będzie bufor wierzchołków + bufor indeksów(wtedy możemy przechowywać nie tylko okręgi w naszym buforze... ale mamy dzielenie wierzchołków... i bufor indeksów). Najbardziej optymalny to Triangle Fan(ale rysowanie tym czegoś innego niż wachlarze, czy okręgi to koszmar).

Proponuje tą obiektowość upchać gdzieś indziej(ja tak robię). I np. miej metody importujące całe meshe, buduj meshe(te generyczne ;P) z figur geometrycznych.

Reasumując...
Będzisz chciał mieć metodę pobierającą konkretny trójkąt czy iterującą po trójkątach mesha/submesha... ale te trójkąty nie przekładają się na ilość wierzchołków w meshu/submeshu...

No... chyba nie pozostawiłem żadnych wątpliwości
THE END
« Ostatnia zmiana: Czerwiec 15, 2014, 22:52:50 wysłana przez ArekBal »

Offline Q

  • Użytkownik

# Czerwiec 16, 2014, 01:58:30
Ja dam Ci inny przykład, załóżmy że mamy kilka domów na ulicy, każdy przylega do siebie ścianą.
Nie jest potrzebne wyświetlanie przylegających ścian. W moim modelu łatwo jest pozbyć się jakiegoś face-a bez ingerencje w reszte geometrii, wystarczy:
geo.deleteFace(121);  // 121 to index jakiegoś face-a
Co wiecej łatwo jest sprawdzić które face do siebie przylegają(bo beda miały wspólne wierzchołki).

Owszem ilość wierzchołków jest duża ale zyskujemy bardzo prostą w modyfikacji geometrie.
W podanym przeze mnie wyżej modelu pozbycie sie niewidocznych ścian nie tylko zmniejszy ilość wierzchołków ale także nie trzeba bedzie tego oteksturowywać, czyli mniej obliczeń dla shadera fragmentów i bufora głębokości.

Offline Xirdus

  • Redaktor

# Czerwiec 16, 2014, 02:14:44
Jeśli niczego nie spartoliłeś to fragment shader i tak by się nie odpalił. Takie randomowe usuwanie face'ów ma jedną poważną wadę - bufory OGL-a muszą być ciągłymi blokami pamięci, a modyfikacja gdzieś w środku wymaga przesunięcia wszystkich dalszych elementów - operacja dość kosztowna. Oczywiście można zrobić swap z ostatnim elementem i pop_back, ale uniemożliwia to stosowanie triangle stripów.

Offline Q

  • Użytkownik

# Czerwiec 16, 2014, 02:18:41
Cytuj
ma jedną poważną wadę - bufory OGL-a muszą być ciągłymi blokami pamięci, a modyfikacja gdzieś w środku wymaga przesunięcia wszystkich dalszych elementów
Miałem na myśli modyfikacje geometri przed dodaniem jej do obiektu a tego do sceny, czyli przed wysłaniem jej do bufora.

Offline lethern

  • Użytkownik

# Czerwiec 16, 2014, 03:28:13
@Xion @Xirdus @Xender Hmm, nikt nie użył w dyskusji zwrotu "programowanie proceduralne", a dopiero teraz zauważyłem że to chyba tak się właściwie nazywa (chyba). Co do komentarzy to ... trudno mi się odnieść, z racji mojej pomyłki w nazwie na starcie ;)
[edit] Na wszelki wypadek dopiszę: chodziło mi o styl pisania C, czy linux (mi się to wprost  kojarzy z określeniem "programowanie strukturalne", sorry)
@Q
Cytuj
lethern różnica między strukturą a obiektem jest taka że obiekt może mieć metody i w ogóle może więcej niż jakakolwiek struktura.
Q, ok, w teorii obiekty są bytami gdzie dane i metody są ściśle powiązane, ale napisałeś to tak jakby struktura nie mogła miec metod.. Tym bardziej dziwi to zdanie, kiedy struktura i klasa naprawdę niewiele się różnią. Nie bede dogryzał, po prostu napiszę że nie rozumiem o co kaman
struct ze_obiektowosc{
   virtual void ze_wirtualna();
};
struct X : public ze_obiektowosc
{
int ze_ja_nie_moge();
};
Cytuj
Więc jak ktoś będzie chciał pobawić się opengl w javie to i tak otrze sie o obiekty i tego nie przeskoczy.
Biorąc pod uwagę powyższe, nadal nie widzę różnicy żeby cały opengl był napisany w strukturach a w classach (obiektach). Obiektowość leży daleko głębiej niż upiep*enie wszystkiego w klasę i udawanie niewiniątka (witam programistów java)
« Ostatnia zmiana: Czerwiec 16, 2014, 05:07:56 wysłana przez lethern »

Offline Q

  • Użytkownik

# Czerwiec 16, 2014, 04:07:48
Cytuj
Obiektowość leży daleko głębiej niż upiep*enie wszystkiego w klasę i udawanie niewiniątka (witam programistów java)
To zabrzmiało tak jakby trzeba było wyznawać całą filozofie obiektowości by korzystać z obiektów.
struct ze_obiektowosc{
   virtual void ze_wirtualna();
};
struct X : public ze_obiektowosc
{
        int ze_ja_nie_moge();
};
Przyznam się że nie wiedziałem że tak można, struktury znam dość słabo.
Cytuj
ale napisałeś to tak jakby struktura nie mogła miec metod
Bo nie wiedziałem że mogą. Jeszcze 5 miesiecy temu nie umiałem c++(właściwie to chciałem się uczyć języka D, ale nikt w nim nie pisze). Przeleciałem przez kilka tutoriali ale nie zagłębiałem się w struktury, bo i po co skoro są klasy.   

Offline Xirdus

  • Redaktor

# Czerwiec 16, 2014, 08:42:27
W C++ słowa class i struct są równoznaczne, różnią się tylko domyślnym specyfikatorem dostępu. Jednak koncepcyjnie struktura i klasa to dwie różne rzeczy służące do czego innego - "poprawna" klasa nie powinna mieć żadnych pól publicznych i wszystko powinno się odbywać za pomocą metod, natomiast "poprawna" struktura powinna mieć wszystkie pola publiczne i żadnych metod. Przy czym para metod get/set powoduje upublicznienie pola klasy - nie jest to dobry design.

Miałem na myśli modyfikacje geometri przed dodaniem jej do obiektu a tego do sceny, czyli przed wysłaniem jej do bufora.
Czyli to o czym mówiłem na początku - po inicjalizacji nie zmieniasz geometrii obiektu, ergo nie potrzeba ci interfejsu do edycja face'ów (tylko dobrej fabryki która od razy zrobi wszystko co trzeba).
« Ostatnia zmiana: Czerwiec 16, 2014, 08:46:18 wysłana przez Xirdus »

Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 16, 2014, 11:29:56
Cytuj
Tym bardziej dziwi to zdanie, kiedy struktura i klasa naprawdę niewiele się różnią.
Tylko w C++. W innych językach, gdzie oba te pojęcia występują (np. C#, D, Swift), różnice są znaczne. Najważniejsza jest taka, że struktury są value types, a klasy reference types.

Cytuj
(witam programistów java)
No tak, gdy programiści Javy korzystają ze wszystkich obiektowych patternów to źle, bo za dużo abstrakcji i SingletonFactoryProxyProviderów. A gdy nie korzystają, traktując klasy raczej jak moduły z logiką i stanem, to jest to "upiep*nie wszystkiego w klasę i udawanie niewiniątka" -_-