Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Okt 19, 2018 14:28

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 09:24 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
@Tak2004: Werbung? Da solltest Du auf Deiner Projektseite machen. Hier ist Werbung eindeutig eine Themaverfehlung.

Du scheinst zu verkennen, was wir hier brauchen. Was Leute brauchen und was sie wollen, ist häufig ein großer Unterschied. Diese Website hat nicht das Ziel, die Neuankömmlinge mit High-Tech-Software zu versorgen. Wir haben hier das Ziel, sie soweit zu bringen, dass sie eine Ahnung davon kriegen, wie man das selber machen kann. Wir haben kein Technologieproblem, wir haben ein Erklärungsproblem.

Und insofern ist Dein obiger Ansatz unbrauchbar, denn es handelt sich um eine Zwangsbeglückung. Das was ich bis hier gesagt habe waren bloße Fakten.

Was ich jetzt sage, ist nur meine eigene Meinung: ich HASSE Zwangsbeglückung. Eine Ahnung, wie man gute Software schreiben kann, kriege ich nicht davon, dass man mir ein bereits perfektes Ding um die Ohren schlägt (damit weckt man bloss meinen Widerspruchsgeist, und davon habe ich eine Menge). Im Gegegnteil, das legt mich fest. Leute, die was lernen wollen, sollen mehrere Möglichkeiten zu sehen kriegen und auch mehrere Möglichkeiten ausprobieren können. Aber Anfangs sind sie froh, wenn sie mal mitkriegen, wo oben und unten ist. In diesem Zustand brauchen sie etwas, was sie auch verstehen können.

Und da ist eine ausgefeilte Software kontraproduktiv. Lernen ist ein Prozess. Das Einfachere kommt zuerst, und dann kann man das Kompliziertere verdauen. Daher finde ich es gut, wenn die Software, die wir brauchen, so klein und einfach wie möglich ist. Aber auch das ist nur meine Meinung.



EDIT: Weil das jetzt alles so ablehnend klingt, muss ich jetzt noch etwas nachschießen:

Vielleicht erinnerst Du Dich, dass Du mir mal eine Anwendung mit zwei Windows-Fenstern unter die Nase gehalten hast. Damals hast Du mir etwas beigebracht, und sagen wir mal, ich glaube, daraus ist auch etwas Brauchbares geworden. Das, was Du mir damals gezeigt hast, war ein bloßer Codeschnipsel, aber er war der Grundstein für einen gewaltigen Lernprozess. Damals warst Du für mich ein guter Lehrer, denn Du hast mir einen Weg gezeigt, und keine endgültige Lösung. Jedem Lehrer sollte bewußt sein, dass die Lösung von der er im Augenblick überzeugt ist, sich innerhalb kurzer Zeit in Luft auflösen kann. Was Du jetzt weißt und was Du vor zwei Jahren gewußt hast, unterscheidet sich das nicht ein wenig? Und jedesmal warst Du fest überzeugt den Stein der Weisen in der Hand zu halten. Aber ist das wirklich so? Und was wirst Du in zwei weiteren Jahren wissen? Wie unterscheidet sich OpenGL jetzt von dem OpenGl vor 10 Jahren? Sind wir mit einer fixen Lösung daher gut bedient?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 11:27 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Materialien: Okay. Ich muss zugeben ich habe damit angefangen und Shader in den Raum geworfen. Wie sich gezeigt hat war das ein Fehler. Denn dadurch wurde die Disskusion in eine andere Bahn gelenkt und wird aktuell zweigleisig geführt. Und das kann nur in einem Chaos enden. Und ich möchte nicht, dass die Diskussion das gleiche Schicksal erleidet wie das was allen anderen Community Projekten zu Teil wurde!

Flash: Meiner Meinung nach geht es nicht darum irgend jemandem etwas zu vermitteln. Das wird in dem VBO Tutorial schon echt gut gemacht. Sondern mir persönlich geht es darum einem die Arbeit zu erleichtern. Ich für meinen Teil kann sehr gut mit Pointern umgehen und habe "ein Herz für Pointerkonstruktionen". Aber wenn ich es vermeiden kann, dann tue ich es auch. Vernünftig gekappselt hilft es ungemein Fehler bereits im Keim zu ersticken. Aktuell benutze ich selber nahezu ausschließlich den Imediate Mode. Das aber nicht weil mir Hintergrundwissen fehlen würde. Sondern aus Bequemlichkeit. Und wenn man dann bedenkt, dass ein Anfänger auch erst noch das System dahinter verstehen muss, dann ist es vermutlich gleich ganz vorbei. Dann schwenkt man wieder auf das Bekannte zurück. Allerdings selbst jetzt würde es in sehr vielen Fällen etwas bringen auf VBOs zu setzen.

glInterleavedArray: Okay. Also die Funktion würde ich persönlich auch nur selten empfehlen. Meiner Meinung nach lohnt es sich immer die passenden gl*Pointer Funktionen per Hand aufzurufen. Alleine, wenn man 2 unterschiedliche Texturkoordinaten benötigt kommt man da kaum umher dies per Hand zu erledigen. Die Bestandteile der Vertices in einzelne Streams zu zerhacken hat vermutlich auch nur dann richtige Vorteile, wenn man die Streams auch seperat von der Platte laden möchte. Oder kommt die Grafikkarte damit besser klar? (ernst gemeinte Frage) Die Vertexdaten liegen ja dann direkt nacheinander und wenn man nur diese benutzen würde, dann könnten Cachemechanismen besser greifen. Wäre zu mindest bei der CPU so. Nur bei der GPU weiß ich nicht ob diese nur einen Vertexcache hat oder auch so einen generellen Datencache wie die CPU?

SceneGraph/Materialmanagement: Solch ein System ist in jedem Fall wahnsinnig flexibel, schnell und hat so einige Vorteile die in einem komplexem Spiel zum Tragen kommen und dort auch benötigt werden. Das steht vollkommen außer Frage. Allerdings kann ich Traude da nur zustimmen. Für Anfänger ist das wohl nur dann brauchbar, wenn sie auch vor haben ein ähnlich komplexes 3D Spiel zu programmieren. Sonst nützt es ja doch nichts, wenn man ein kompliziertes System gegen ein Zweites austauscht. Damit würde man doch erreichen, dass die Leute an einigen Stellen so gar nichts mehr mit OpenGL zu tun haben und dadurch entfremdet würden. Zu mal man da bitte auch bedenken solltest, dass nicht jeder das Gleiche vor hat.

Ich denke die Lösung die man anstreben sollte ist etwas was einen die Arbeit mit VertexBufferObject, FramebufferObjects und Shadern etc. erleichtert. Also, dass man etwas auf die Beine stellt wodurch man sehr einfach ein VBO erstellen kann. Wenn man in dieses VBO dann auch noch Modeldaten einlesen könnte wäre die Handhabung für den Entwickler wirklich sehr komfortable. Wenn man dort noch mehr Verwaltung braucht, dann kann man die immer noch selber drumherum bauen. Und aktuell würde ich auch nur ein Thema (VBOs) betrachten wollen. Sonst siehe erster Absatz.

Man sollte auf gar keinen Fall ein System anstreben was alles kann. Es ist nicht möglich ein System auf die Beine zu stellen was allen hilft und alle zufreiden stellen wird. Das liegt nicht in der Natur der Menschen! Nicht ohne Grund gibt es windows, mac und 20 verschiendene Linux Distributionen. Und genau aus dem Grund wird es nicht möglich sein etwas auf die Beine zu stellen was jedem zusagt. Wenn jeder jetzt darauf erpicht ist seine Ideen mit Biegen und Brechen durchzusetzen, dann wird sich die ganze Sache kein Stück bewegen und es wird, wie alle vorherigen Comunity Projekte, scheitern. Dazu muss man nicht mal Hellseher sein. Und da sollte man mal genau überlegen wozu es eigentlich gedacht ist? Meiner Auffassung nach um Einsteigern den Einstieg zu erleichtern. Und entsprechend sollte man auch seine Prioritäten setzen. Wenn man meint man braucht fortschrittlichere Lösungen, dann ist das das Recht eines jedem Einzelnen. Allerdings wenn die Ideen dann keinen Anklang finden bitte ich doch jeden (mich eingeschlossen) auf das eigentliche Ziel Rücksicht zu nehmen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 12:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Einverstanden, wir konzentrieren uns hier nur auf die VBOs im Hauptspeicher. Wenn die Sache mit dem Loader das Projekt gefährdet, nehme ich davon Abstand. :wink:

Ist dann die Vorgangsweise nicht schon klar? Flash wollte weiter oben ein Beispiel für das SDK. Das bedeuted, mit SDL ein VBO Objekt zu zeichnen, möglichst mit einer Textur dazu . Also etwas Neues für das EasySDL. Wenns geht alles in einer Unit. Was uns dafür fehlt ist ein einfacher Wrapper fürs VBO.

Halt ich hab noch was vergessen: Wir haben doch ganz sicher irgendwo eine Software, die prüft, ob VBO's überhaupt zur Verfügung stehen. So etwas brauchen wir auch.
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 13:09 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich glaube durch die Erläuterungen das Thema besser verstanden zu haben. Ich glaube, dass eine "glVBO" im Stile der "glBitmap" durchaus die angesprochene Hilfe bieten kann, die Lossy sich wünscht.

Allerdings sehe ich diese Lib nicht als *.pas sondern, um die Idee von Traude aufzugreifen, als Schnittstellenbeschreibung für die Benutzung von VBOs. Wieso? Nun, ich programmiere seit längerem mit Java und in der Community gibts noch C++ und vielleicht nocht andere. Wenn wir eine solche Schnittstelle definieren, dann kann man diverse (Sprachabhängige) Implementationen anbieten. Was ich begrüßen würde. Für die Delphier wäre es kein Nachteil. Ihre Version währe quasi die Referenzimplementation.

Die Idee des Modellloaders ist wiederum gar nicht so abwegig. Jedenfalls nach meinem bisherigen Verständnis. Kurz zur Erklärung: Wenn man Lossys glBitmap ansieht, dann gibt es dort die Texturklassen, welche die Texturen als Objekte abbilden und Funktionen zur manipulation bereitstellen. Etwas vergleichbares wird es auch in der glVBO geben. Also eine "Modell"-Klasse. Aber was muss sie den abbilden können? Ein Feld mit Zahlen? Bestimmt nicht. Mehrere Zahlenfelder die jeweils verschiedene Bedeutungen haben (Positionen, Texturkoordinaten, etc.)? Schon eher. Aber was bildet dann diese Klasse ab? Etwas was man durch den Begriff "Mesh" oder "Modell" beschreiben kann.

Soweit ist es also nicht hergeholt mit dem Modell loader.

Und mein Vorschlag der Wissensvermittlung (Den hab ich in den Raum geworfen hatte, weil ich dachte ihr seht da ein Problem) kann dann immer noch umgesetzt werden - aber anhand der neuen Lib.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 13:22 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
(Ich sitze gerade unter ganz ungünstigen bedingungen, bombardiert von schlechter Musik und inmitten von nem haufen komischer leute, also verzeiht mir, wenn das jetzt etwas wirr wird)

Also, so wie ich das sehe, wird das jetzt im ersten Schritt eine glVBO. Lossy hat dafür ja schon eine art Grundstein gelegt, der wie mir scheint garkein so schlechter anfang ist.

Wir brauchen eine Art Lernprozess.
Wir haben (dann) eine einfache(!) Unit für VBOs.

Wie wäre es, wenn derjenige, der letzendlich die einfache Version der glVBO bzw den Grundstein dafür in ein Tutorial verfasst? Das könnte man dann einem Einsteiger als ein Übergangstutorial vom Einsteigerstoff, mit einer einfachen Lib, zum "Hardcore" Stoff mit Pointergeschiebe den sie dann für eigene Partikelsysteme oder Engines nutzen können.

Gruß Lord Horazont
*flucht ergreif*

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 14:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Flash schrieb:
Zitat:
ich programmiere seit längerem mit Java und in der Community gibts noch C++ und vielleicht nocht andere. Wenn wir eine solche Schnittstelle definieren, dann kann man diverse (Sprachabhängige) Implementationen anbieten.

Ja. Wir sind schon lange multilingual.

@Lord Horazont: auch ja.

Die Kombination zwischen Flash und Lord Horazont hört sich für mich an wie ein Nehe-Tutorial. Die ganz Sache ist eigentlich ein Tutorial, aber man kann auch die Software in mehreren Programmiersprachen dazu haben. Klingt eigentlich ganz gut, oder?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 14:37 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2523
Wohnort: Berlin
Programmiersprache: C/C++, C#
Stimmt schon also gehts weiter mit den VBO.
Abstrakte Klassen für VBO und FBO hab ich in Karmarama in benutzung.
Hier mal der Code, vom VBO, um mal eine Mögliche Umsetzung zu zeigen.
Code:
  1. //abstract Mesh class
  2. struct TKar_Face
  3. {
  4.         unsigned int Start;
  5.         unsigned int Count;
  6. };
  7.  
  8. class TKar_Mesh
  9. {
  10.         protected:
  11.                 vector<TKar_Face> Faces;
  12.         public:
  13.                 bool UseColor;
  14.                 bool UseNormal;
  15.                 bool UseTexCoord;
  16.                 bool UseIndex;
  17.  
  18.                 virtual void SetVerticeList(void* List,unsigned int Size)=0;
  19.                 virtual void SetNormalList(void* List,unsigned int Size)=0;
  20.                 virtual void SetColorList(void* List,unsigned int Size)=0;
  21.                 virtual void SetTexCoordList(void* List,unsigned int Size)=0;
  22.                 virtual void SetIndexList(void* List,unsigned int Size)=0;
  23.                 virtual void SetFaceList(TKar_Face* List,unsigned int Size)=0;
  24.                 virtual void AddVertex(float x,float y,float z)=0;
  25.                 virtual void AddColor(float r,float g,float b)=0;
  26.                 virtual void AddNormal(float x,float y,float z)=0;
  27.                 virtual void AddTexCoord(float u,float v)=0;
  28.                 virtual void AddIndex(unsigned int ind)=0;
  29.                 virtual void AddFace(unsigned int Start,unsigned int Count)=0;
  30.                 virtual void Generate()=0;
  31.                 virtual void Draw(unsigned int Face)=0;
  32. };
  33.  
  34. //OpenGL implementation
  35. struct TKar_Vertex{float x,y,z;};
  36. struct TKar_Normal{float x,y,z;};
  37. struct TKar_TexCoord{float u,v;};
  38. struct TKar_VertexColor{float r,g,b;};
  39. typedef unsigned int TKar_Index;
  40.  
  41. template <class T> class TKar_GraphicBufferOGL
  42. {
  43.         protected:
  44.                 T* Data;
  45.                 unsigned int Count;
  46.                 unsigned int ReservedElements;
  47.                 unsigned int VBOID;
  48.                 unsigned int BufferType;
  49.                 unsigned int BufferDataType;
  50.                 bool ExternalList;
  51.         public:
  52.                 TKar_GraphicBufferOGL();
  53.                 bool Generate(unsigned int ABufferType,unsigned int ABufferDataType);
  54.                 void AddElement(const T AElement);
  55.                 void Clean();
  56.                 void Bind();
  57.                 void Unbind();
  58.                 unsigned int GetLen();
  59.                 T* Get(unsigned int Index);
  60. };
  61.  
  62. class TKar_MeshOGL:public TKar_Mesh
  63. {
  64.         protected:
  65.                 vector<TKar_GraphicBufferOGL<TKar_Index>> IndexBuffers;
  66.                 TKar_GraphicBufferOGL<TKar_Vertex>        VertexBuffer;
  67.                 TKar_GraphicBufferOGL<TKar_Normal>        NormalBuffer;
  68.                 TKar_GraphicBufferOGL<TKar_VertexColor>   ColorBuffer;
  69.                 TKar_GraphicBufferOGL<TKar_TexCoord>      TexCoordBuffer;
  70.                 TKar_GraphicBufferOGL<TKar_Index> IndexBuffer;
  71.         public:
  72.                 void SetVerticeList(void* List,unsigned int Size);
  73.                 void SetNormalList(void* List,unsigned int Size);
  74.                 void SetColorList(void* List,unsigned int Size);
  75.                 void SetTexCoordList(void* List,unsigned int Size);
  76.                 void SetIndexList(void* List,unsigned int Size);
  77.                 void SetFaceList(TKar_Face* List,unsigned int Size);
  78.                 void AddVertex(float x,float y,float z);
  79.                 void AddColor(float r,float g,float b);
  80.                 void AddNormal(float x,float y,float z);
  81.                 void AddTexCoord(float u,float v);
  82.                 void AddIndex(unsigned int ind);
  83.                 void AddFace(unsigned int Start,unsigned int Count);
  84.                 void Generate();
  85.                 void Draw(unsigned int Face);
  86. };
  87.  
  88. //how to use
  89.         TKar_Mesh* Mesh=Context->GenerateMesh(FileName);
  90.         if (Data->VertexCount>0)
  91.                 Mesh->SetVerticeList(Data->Vertice,Data->VertexCount*sizeof(TKar_ModelVertex));
  92.         if (Data->NormalCount>0)
  93.         {
  94.                 Mesh->UseNormal=true;
  95.                 Mesh->SetNormalList(Data->Normals,Data->NormalCount*sizeof(TKar_ModelNormal));
  96.         }
  97.         if (Data->ColorCount>0)
  98.         {
  99.                 Mesh->UseColor=true;
  100.                 Mesh->SetColorList(Data->Colors,Data->ColorCount*sizeof(TKar_ModelVertexColor));
  101.         }
  102.         if (Data->IndexCount>0)
  103.         {
  104.                 Mesh->UseIndex=true;
  105.                 Mesh->SetIndexList(Data->Indices,Data->IndexCount*sizeof(TKar_ModelIndex));
  106.         }
  107.         if (Data->TexCoordCount>0)
  108.         {
  109.                 Mesh->UseTexCoord=true;
  110.                 Mesh->SetTexCoordList(Data->TexCoords,Data->TexCoordCount*sizeof(TKar_ModelTexCoord));
  111.         }
  112.         for (unsigned int i=0;i<Data->FaceCount;i++)
  113.                 Mesh->AddFace(Data->Faces[i].Start,Data->Faces[i].Count);
  114.         Mesh->Generate();
  115.  
  116. //draw
  117.                 for (int i=0;i<Mesh->Faces.size();i++)
  118.                         Mesh->Draw(i);

Das Template macht den Code gerade ein bischen groß, darum hab ich den code einfach mal rausgeschnitten.
Die Abstrakte klasse und OpenGL Implementierung hab ich gemacht, weil meine Engine nicht nur OpenGL benutzt sondern auch für andere Rendersysteme gedacht ist, was in der DGLVBO implementierung zu einer Klasse werden könnte.
Man kann die einzelnen Streamdaten stückchenweise hinzufügen, z.B. wenn man ein Dreieck oder so braucht(dafür hab ich es verwendet, sonnst wäre es garnicht drin). Die Listen sind für das schnelle laden für Modelformate gedacht.
Die UseXXX Flags sind dann beim Generieren notwendig, wenn das VBO erstellt wird.
Beim Draw(i); steht i für das Face des Models, Face wird niergends erwähnt, weil es auch als vector<TKar_GraphicBufferOGL<TKar_Index>> IndexBuffers; implementiert ist, wobei jeder TKar_GraphicBufferOGL<TKar_Index> ein Face repräsentiert.
Wenn man auf ein Mesh mehrere Texturen verwendet, dann kann man vorher die Textur binden und dann das entsprechende face zeichnen.
In meinem Modelformat liegt neben den Daten noch ein array von cardinal und ein array von string[32].
Der stringarray enthält die Textur/Materialnamen und der cardinalarray ist der index auf den stringarray.
Wenn man 3 Texturen hat('1.dds','2.dds','3.dds') und eine faceliste(0,1,0,1,2,1,0,2,...) dann heisst das nichts anderes als dass draw(0) man 1.dds binden sollte und bei draw(1) 2.dds und bei draw(2) 1.dds,... .
Damit ist das VBO vom Textursystem entkoppelt und macht das coden leichter.

Das FBO ist ziemlich verzahnt, da man dieses ja an eine TexturID bindet und daher hängt bei mir noch eine Textur und TexturManager klasse mit dran. Darum finde ich meine Lösung, für FBO, nicht als vorzeigbar.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 16:38 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1965
Programmiersprache: C++
Was haltet ihr erstmal von der Basis?
Also eine Demo für das DGLSDK was direkt die OpenGL-Befehle nimmt?

Danach kann man dann das ganze auch kapseln.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 16:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Das versteh ich jetzt nicht, i0n0s. Meinst Du Taks Beispiel oben? Das sieht eigentlich ganz in Ordnung aus. Aber bei VBOs bin ich sicher nicht der Weisheit letzter Schluß.

Was genau meinst Du mit
Zitat:
Also eine Demo für das DGLSDK was direkt die OpenGL-Befehle nimmt?
?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 17:20 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1965
Programmiersprache: C++
Eine Demo, die mit Hilfe der von OpenGL bereitgestellten Befehle ein VBO erstellt, befühlt und zeichnet.
Dabei sind die von OpenGL bereitgestellten Befehle nicht zu kapseln, sondern direkt an der entsprechend benötigten Stelle zu benutzen.

Halt wie man nen VBO benutzt ohne eine VBO-Klasse zur Verfügung zu haben.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 17:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Wir sprechen die ganze Zeit von einer Kapselung. Genau was Du vorschlägst, wollten wir eigentlich vermeiden. Das kommt jetzt drauf an, was Du für Argumente dafür hast: weils schneller geht - weils durchschaubarer ist ????

Also warum sollten wir Deiner Meinung nach umschwenken?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 17:46 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2523
Wohnort: Berlin
Programmiersprache: C/C++, C#
Ich glaube I0n0s will eine Demo für die Verwendung von VBO haben, an der man sieht wie man VBO normal verwendet.
Das man dann als Entwickler auf die Klassen Kapselung zurück greifen ist dann eine andere Geschichte aber man muss ja wenigstens mal die VBO Befehle in direkter Verwendung zeigen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 17:55 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Tja, dann brauchen wir das Ganze aber doppelt. Ist dann schon eine ganz schön aufgeblasene Sache: in jeder Sprache zweimal.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 19:39 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1965
Programmiersprache: C++
TAK2004 hat geschrieben:
Ich glaube I0n0s will eine Demo für die Verwendung von VBO haben, an der man sieht wie man VBO normal verwendet.
Das man dann als Entwickler auf die Klassen Kapselung zurück greifen ist dann eine andere Geschichte aber man muss ja wenigstens mal die VBO Befehle in direkter Verwendung zeigen.

Genau :)

Die Sachen wie z.B. die Initialisierung von SDL sind im SDK ja auch enthalten, obwohl wir easySDL bereitstellen.
Wir geben an der Stelle den User die Wahl, ob sie einfach die angenehme Kapselung nehmen, oder es selber verstehen und eine eigene Kapselung bauen.

Denkt daran, dass das SDK eigentlich nicht so was wie easySDL enthalten muss. Es ist nur als Komfort für die Demoschreiber zu verstehen bzw. für die ersten Schritte. Wenn der User es so weit geschafft hat, kann er dann seine eigenen Systeme nehmen.
Wir wollen also keinen User dazu bringen, dass er für immer unser System benutzt. Es soll einfach nur so komfortabel und einfach sein, dass er es benutzt, bis er selbst in der Lage ist, so ein System zu schreiben.

Und aktuell sieht es danach aus, dass eure Planung den Umfang für das SDK deutlich überschreiten.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 21:00 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
@Traude: Ich stimme ionos zu. Aber deine befürchtungen sind unbegründet. Eine kleine BeispielVBO Anwendung kann man im SDK bereitstellen ohne, dass man das ständig aktuell halten muss und für andere Sprachen muss es auch nicht sein.
Es geht einfach darum, dass man DGL die Techniken lernen soll. Wir wollen es nicht verschleiern. Wir wollen die Techniken nur für den Anfänger aufbereiten so das er rein findet. Später soll(!) er dann schon seinen Code selber bauen und optimieren. (Wobei Lossys Libs meist auch von Fortgeschrittenen gern genutzt werden. ;) )

Da wir ja ein VBO Tutorial haben, sollte doch auch der passende Code verfügbar sein, oder?

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.040s | 15 Queries | GZIP : On ]