Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Maverick

Frischling

Beiträge: 14

Wohnort: Paderborn

Beruf: IT Fachinformatiker ANW

  • Private Nachricht senden

21

19.04.2003, 16:51

Seit wann muss man Levels Compeliren, das muss man bei UT auch nur, um den BSP zu erzeugen, aber ich denke du meinst etwas anderes. Es geht um die NPC’s und alles was mit AI zu tun hat, man muss so was nicht zwangsläufig mit einem Script Realisieren. Mann kann auch vorgefertigten C++ code verwenden und z.B. ein PlugIn für einen Actor entwickeln, dass alle AI Grundlagen enthält, so kann man sich auch eine Basies schaffen. Im UT Script system gibt es etwas ähnliches. Die Mischung macht es halt. Aber man muss schon ein sehr gutes, und durchdachtes PlugIn system haben, um von einem PlugIn in dem Script erben zu können. Wenn man beides will.

Schaut euch mal den thread an, geht aber auch nur um allgemeine dinge.
http://www.zfx.info/DisplayThread.php?TID=7271&Start=0

mfg

Maverick

Jumping Jack

Treue Seele

Beiträge: 142

Wohnort: Hamburg

Beruf: Schüler

  • Private Nachricht senden

22

19.04.2003, 20:07

@Maverick:
wie meinst du das mit dem SceneGraphen und den anderen Techniken?
Meinst du, dass man NUR einen SceneGraphen verwenden sollte?
Ich kombiniere SceneGraph mit den anderen Techniken wie Portale, ROAM usw.

Maverick

Frischling

Beiträge: 14

Wohnort: Paderborn

Beruf: IT Fachinformatiker ANW

  • Private Nachricht senden

23

19.04.2003, 20:45

Klar kann man das machen, aber es macht keinen sinn mehr, ein statisches GeoMappig ist westendlich schneller, seit einführig der Shader sind Polygone quasi egal geworden. geb den ganzen einfach 3 LOD stufen und fertig. Portale in einem Graphen einzubinden ist ein bissel wie doppelt gemoppelt, die Nodes werden ja schon gecullt, wozu dann noch die Portale?

mfg

Maverick

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

24

19.04.2003, 21:37

@Maverick:
Also ich würde mir das mit Octrees/BSPs/Portalen wie folgt vorstellen: Man würde dafür ein PlugIn schreiben, was man ganz an den Anfang des Szenengraphen setzt. Es prüft dann, ob das Objekt bzw. der Octree-/BSP-Node überhaupt sichtbar sein kann. Falls nicht, liefert das PlugIn beispielsweise false zurück. Das soll dann heißen, dass die Durchwanderung des Szenengraphen gestoppt werden kann.

Ein PlugIn (ich nenne das jetzt Modifikator) sähe so aus:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class Modificator
{
protected:
    char* pName; // Name des Modifikators
    float Quality; // Qualitätsfaktor (muss nicht für alle Mod's gelten)
    bool Bypass; // true, wenn der Modifikator übergangen werden soll

public:
    // Diese Methode führt die eigentliche Arbeit an einem Objekt aus.
    void Work(Object& obj);

    // Liefert eine Flag-Kombination, die besagt, welche Daten
    // der Modifikator als Eingabe benötigt.
    // Z.B. sowas wie VERTICES | MATRIX, wenn der Modifikator
    // die Vertizes des Objekts und die Transformationsmatrix benötigt.
    dword GetInput();

    // Liefert die Flag-Kombination für die Daten, die vom Modifikator
    // verändert wird.
    dword GetOutput();

    GetName, GetQuality, SetQuality,...
};


Dann sähe die Object-Klasse ungefähr so aus:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
class Object
{
protected:
    // Das ist die Liste der Modifikatoren des Objekts
    vector<Modificator*> Modificators;

    // Position, Geschwindigkeit, Achsen, Winkelgeschwindigkeit
    // und Transformationsmatrix
    Vector3D Position, Velocity, Axis[3];
    float AngularVelocity[3];
    Matrix4x4 Matrix;

    // Vertex- und Indexdaten
    PDIRECT3DVERTEXBUFFER9 pVB;
    PDIRECT3DINDEXBUFFER9 pIB;

    // Attributdaten (Einzelteile des Objekts mit verschiedenen
    // Render-Einstellungen)
    struct Attribute
    {
        // D3DX-Effekt dieses Attributs, auch Shader möglich!
        LPD3DXEFFECT pEffect;

        dword StartIndex;
        dword NumPrimitives;
        D3DPRIMITIVETYPE PrimitiveType;
    };

    vector<Attribute> Attributes;

public:
    void RenderGraph();
    void AttachModificator(Modificator* m);
    Modificator* FindModificator(char* pName);
    void DeleteModificator(char* pName);
    ...

    GetModificatorList, GetXXX...
};


Was hältst Du von diesem Ansatz? Ist natürlich nur ein grober Entwurf.

Maverick

Frischling

Beiträge: 14

Wohnort: Paderborn

Beruf: IT Fachinformatiker ANW

  • Private Nachricht senden

25

19.04.2003, 23:47

Man merkt dir an, das du ein s.g. Emotionsgeprägter Coder bist. Ich werde morgen dazu mal was posten, wenn ich die zeit finde. Das ganze Thema ist natürlich etwas komplexer.

mfg

Maverick

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

26

20.04.2003, 00:14

Aha :) Und was bist Du für ein Coder?

Jumping Jack

Treue Seele

Beiträge: 142

Wohnort: Hamburg

Beruf: Schüler

  • Private Nachricht senden

27

20.04.2003, 12:57

Maverick, was verstehst du denn unter nodes?

Wenn ich das richtig verstanden habe funktioniert ein SceneGraph so:

Jedes Objekt hat eine Bounding Box, manche sind sehr groß und manche nur ganz klein.
Nun wird getestet welche BBox von einer größeren BBox umschlossen wird.
Das Model mit der kleineren Box wird nun dem Model mit der umschließenden Box untergeordnet, so dass insgesamt ein Baum entsteht.
Das sieht dann ungefähr so aus:

Quellcode

1
2
3
4
5
6
7
Terrain
+-- Haus1
|    +-- Modell1
|    +-- Modell2
|        +-- Waffe
+-- Haus2
     +-- Modell1


Wenn man nun Cullt kann man sich rechenzeit sparen, da man, wenn man ein Objekt testet und es nicht sichtbar ist, sofort weiß, dass seine Childnodes auch nicht sichtbar sind.

Allerdings kann es hier doch sein, dass ein modell im haus nicht sichtbar ist. das kann man dann mit hilfe von portalen oder nem bsp baum prüfen.

oder habe ich da was falsch verstanden?

Maverick

Frischling

Beiträge: 14

Wohnort: Paderborn

Beruf: IT Fachinformatiker ANW

  • Private Nachricht senden

28

20.04.2003, 16:45

Ein Node ist eine Punkt, mit Ausrichtung im 3D Raum (Quaternion). Sorry habe i.m. wenig Zeit. Ich Poste bald mal was dazu.

mfg

Maverick

Patrick

Alter Hase

  • »Patrick« ist der Autor dieses Themas

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

29

20.04.2003, 20:48

@Maverick
Du sagst BSP und ROAM sind veraltet, gibbet denn was besseres und schnelleres ???

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

30

20.04.2003, 21:01

Bei modernen Grafikkarten ist es meistens so, dass die Füllrate alles begrenzt, also die Anzahl der gezeichneten Pixel.
Roaming zielt darauf ab, die Anzahl der Vertizes zu verringern, also die Landschaft in der Ferne weniger detailliert zu machen. Dadurch verringert sich aber nicht die Anzahl der zu zeichnenden Pixel.
Von daher ist es wohl nicht mehr nötig, den Prozessor all diese Detailstufenrechnungen anstellen zu lassen, weil man keine Zeit mehr spart, sondern es eher noch langsamer macht.
Bei statischen Terrains mit vielleicht ein paar Detailstufen passt man sich daher wohl der heutigen Hardware besser an.

Beim BSP-Tree ist es ähnlich. Die Grafikkarte schmeißt die Dreiecke, die außerhalb des View-Frustums liegen, sowieso schon raus, bevor sie gezeichnet werden (Clipping, Culling). Der BSP-Tree kann also die Anzahl der zu zeichnenden Pixel nicht verringern.
Occlusion-Culling, wie es bei Portalen zum Einsatz kommt, ist besser geeignet, denn es reduziert wirklich die Anzahl der Pixel. Durch die Portale werden nämlich viele Dreiecke gecullt, die von einem anderen Objekt verdeckt werden und beim Zeichnen nachher nicht sichtbar wären - das wären dann verschwendete Pixel.

Das alles gilt natürlich nur für solche Hardware, wo die Füllrate der Flaschenhals ist. Wenn die Karte sich mit der Transformation von Vertizes oder mit deren Beleuchtung schwertut, sollte man anders verfahren.

BSP-Trees und Octrees kommen aber noch sehr häufig bei der Kollisionserkennung zum Einsatz. Z.B. bei einem großen Raumschiff: Es wird dann in kleinere Stückchen unterteilt, die jeweils von einer Bounding-Box umgeben werden. Bei der Kollisionserkennung testet man dann erst die Kollision mit diesen Bounding-Boxes, und erst danach mit den darin enthaltenen Dreiecken.

Werbeanzeige