[B3D] Darstellung langsam bei ~1600 Triangles
Übersicht
BlitzBasic Beginners-Corner
|
hecticSieger des IS Talentwettbewerb 2006Betreff: [B3D] Darstellung langsam bei ~1600 Triangles |
 Mi, Jan 18, 2006 2:09Antworten mit Zitat 
|
|---|---|---|
| Hi, habe noch ein Problem. Habe eine 2D-Landschaft per AddVertex/AddTriangle in B3D erstellt. Die Kamera zeigt mit 90° auf dieses Mesh. Nun wird aber die gesammte Darstellung bereits ab etwa 1600 Triangles langsam (beim P4 2.8GHz mit 1GB RAM). Auch dann wenn keine Triangles mehr sichtbar (mit der Kamera aus dem Bereich Raus geflogen) dargestellt werden. Habe follgendes schon ausprobiert: CameraRange auf minimale Eingrenzung (min,max) und CamerProjMode auf 2. Keines der beiden hat Besserung erbracht. Erst wenn ich richtig weit weg zu Seite fliege wird's wieder ganz normal schnell. Gibt es eine Möglichkeit es zu beschleunigen? Die Triangles sind willkürlich positioniert auf der X und Y -Ebene. Es kann also nicht eine art RectOverlap für ShowEntity bzw HideEntity gemacht werden. | ||
|
Jan_Ehemaliger Admin |
Mi, Jan 18, 2006 8:48 Antworten mit Zitat
|
|---|---|---|
| wieviele Surfaces | ||
| between angels and insects | ||
|
Markus2 |
Mi, Jan 18, 2006 13:15 Antworten mit Zitat
|
|---|---|---|
|
vieleicht benutzt du auch CameraPick oder LinePick ???
Wenn ja nur dann benutzen wenn du es brauchst . Normal solltest du über 16000 Polys problemlos darstellen können . |
||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Mi, Jan 18, 2006 16:50 Antworten mit Zitat
|
|---|---|---|
|
@Jan, es sind zwei Surfaces die aber immer zusammen erstellt werden. Also eine für die Textur und eine nicht sichtbare für die Kollision. Dieses doppelgemoppel kommt vielleicht etwas Spanisch vor, ist aber notwendig da eine Kollision mit EntityRadius nicht auf ein Polygon der 90° zu einem steht erkannt wird. Also zwei Surfaces über die gesammte Map.
@Markus2, kein (Camera/Line)Pick verwendet. Habe allerdings festgestellt, daß es eventuell an den Surfaces liegen kann. Überlege mir, ob eine Surfacebereiche-Einteilung hilfreich sein kann. Also jeder Map-Teilabschnitt bekommt ein eigenes Surface und nicht ein Surface für die gesammte Map. |
||
|
|
Jan_Ehemaliger Admin |
Mi, Jan 18, 2006 16:53 Antworten mit Zitat
|
|---|---|---|
|
hm,
1 Surface für die Ganze Map hätte ich aber empfohlen naja, 4 Surfaces sind sicherlcih auch cnith schelcht, hast du vielleicht transparenz an, oder erstellst es jeden frame wieder? muss das Kollisionsmodell genausoviele Polys haben, wie das orginale? |
||
| between angels and insects | ||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Mi, Jan 18, 2006 17:11 Antworten mit Zitat
|
|---|---|---|
|
Also die Surfaces werden nur erstellt wenn eine Map geladen wird. Keine Transparenz. Es wird soweit es geht an Polygonen gespart. Deshalb auch per AddTriangle und kein Terrain oder was anderes. Das ganze soll 'dynamisch' sein, damit man per Editor eigene Levels erstellen kann.
Habe folgendes mal ausprobiert: Per Tastendruck wird immer wieder ein neuer Level geladen, ohne die vorherigen Polygone zu löschen (FreeEntity), um das Resourcenproblem besser zu verdeutlichen. Zwei Levels sind bisher vorhanden. Beide haben in etwa die gleiche Anzahl an Polygonen. Das eine hat aber ganz weit (bis zum Levelende = Rand) noch jeweils zwei Polygone. Wenn ich diese Map dreimal übereinander lade, wird das Spiel auch an den Stellen wo keine mehr sichtbar auf dem Bildschirm sind, recht langsam. Die andere Map wo sich nur Polygone im Zentrum befinden, bleibt das Spiel so lange schnell bis wieder Polygone auf dem Bildschirm auch dargestellt werden. Ich gehe davon aus, daß die Grafikkarte bei der ersten Map immer mit rendert, da sich Polygone im Sichtbereich aufhalten könnten. Werde mal heute Abend ein Mehr-Surface-Level erstellen um es mal auszutesten. Hoffe das es dann schneller funzt. |
||
|
|
Markus2 |
Mi, Jan 18, 2006 19:25 Antworten mit Zitat
|
|---|---|---|
|
eine simple Zeitmessung in diversen Abschnitten
könnte dir bestimmt auch weiter helfen . t=millisecs() ... debuglog millisecs()-t |
||
BIG BUG |
Mi, Jan 18, 2006 21:08 Antworten mit Zitat
|
|
|---|---|---|
|
Die Erscheinungsgröße der Polygone ist auch sehr wichtig, da diese ja von der Grafikkarte ausgefüllt werden müssen. Ein Polygon welches nur 30x30 Pixel dargestellt wird, kann um ein Vielfaches schneller gezeichnet werden, als eines das zb. 300x300 Pixel einnimmt.
Überschneidungen von Polygonen sind also zu vermeiden und das mehrfache Übereinanderlegen von bildschirmnahen Polygonen bremst das System ziemlich aus... Mehrere Maps testweise übereinanderzulegen führt daher nicht unbedingt zu realistischen Ergebnissen. |
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Mi, Jan 18, 2006 21:41 Antworten mit Zitat
|
|---|---|---|
|
@BIG BUG, das übereinander legen der Polygone war nur zu testzwecken. Da ich das Spiel so programmieren möchte das man nicht grad ein HiEnd-Rechner zum spielen benötigt. Dieses habe ich aber auch so erleutert. Im Spiel selber werden sich keine Polygone überschneiden. Es werden sogar 'Sparmassnahmen' beim erzeugen der Polygone getroffen. Beinahe Bildschirmausfüllung müß denoch sein, da mit den Polygonen eine 2D-Map gezeichnet wird, welches ein Tunnelsystem wiedergeben soll.
@Markus2, ein Frameunabhängiges programmieren wird sowieso gemacht. Es geht ja nicht ohne, wenn man schöne Resultate bringen will. 100 Frames/Sekunde machen nun mal mehr Spaß als 40 Frames/Sekunde, auch wenn das Spielgeschehen gleich schnell ist... Hat denn keiner ein Lösungsvorschlag? |
||
|
|
Markus2 |
Do, Jan 19, 2006 1:14 Antworten mit Zitat
|
|---|---|---|
|
Das solltest du einbauen um zu sehen was viel Zeit braucht
quasi wie ne Stopuhr nur für Funktionen . Also mehrmals benutzen und die Werte als Kommentar eintragen . |
||
Übersicht
BlitzBasic Beginners-Corner
Powered by phpBB © 2001 - 2006, phpBB Group