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

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

11

16.02.2009, 21:03

Ja, bei mir vllt... Ich hab mit VC++ 2008 und Comeau compiliert.

12

16.02.2009, 21:04

Zitat von »"David_pb"«

Ja, bei mir vllt...

auf was war das jetz die antwort?

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

13

16.02.2009, 21:05

Zitat von »"PCShadow"«

Zitat von »"David_pb"«

Ja, bei mir vllt...

auf was war das jetz die antwort?


Das war die Bestätigung auf:

Zitat


bei dir vllt,

Phil_GDM

Alter Hase

  • »Phil_GDM« ist der Autor dieses Themas

Beiträge: 443

Wohnort: Graz

Beruf: Student-Softwareentwicklung u. Wissensmanagement

  • Private Nachricht senden

14

16.02.2009, 21:10

OK. Das Code-Schnipsel compiliert bei mir auch durch. Nur das ganze Projekt (wo der Octree schon mehrmals verwendet wird) nicht.

Der Fehler scheint irgendwo anders im Code zu liegen oder so.
Naja ich werd mich mal an die Fehlersuche machen.

Jedenfalls vielen Dank an alle.

mfg Philipp

Phil_GDM

Alter Hase

  • »Phil_GDM« ist der Autor dieses Themas

Beiträge: 443

Wohnort: Graz

Beruf: Student-Softwareentwicklung u. Wissensmanagement

  • Private Nachricht senden

15

16.02.2009, 21:16

OMG ich hab den Fehler gefunden:

C-/C++-Quelltext

1
    template <typename TNumeric, typename TNodeData> friend class Octree;


Leider hat er als Fehlerquelle immer die Zeile wo das 3-te Template argument im Octree deklariert war angegeben. Die Fehlermeldungen bei der compilierung von Templates sind leider wirklich nicht immer die gerade aussagekräftigsten.

Naja was solls, jetzt hab ich den Fehler ja gefunden.

mfg Philipp

16

16.02.2009, 21:18

@David_pb: oh, das hat ich irgendwie...nicht gemerkt :oops:

@Phil_GDM: wenn dus hast poste mal, worans lag, zumindestens mich würde das interessieren

Phil_GDM

Alter Hase

  • »Phil_GDM« ist der Autor dieses Themas

Beiträge: 443

Wohnort: Graz

Beruf: Student-Softwareentwicklung u. Wissensmanagement

  • Private Nachricht senden

17

16.02.2009, 21:22

Zitat von »"PCShadow"«


@Phil_GDM: wenn dus hast poste mal, worans lag, zumindestens mich würde das interessieren


Siehe meinen vorherigen Post.

mfg Philipp

18

18.02.2009, 10:14

Ich habe auch mal ein Octree programmiert und mich gegen Typisierung des Inhalts per Template entschieden. Was sagt die Policy denn aus? Alle verwalteten Objekte sollen eine Methode fuer die Bounding Box anbieten. Also waere es durchaus sinnvoll eine Basisklasse fuer alle im Octree verwaltete Typen mit Methode bounds() einzufuehren, die die AABB (ein einfaches Rechteck) zurueckliefert. Das machst du irgendwie schon, aber wrappst das ganze noch um eine Policy mit ganz viel Templates. Da stellt sich die Frage: Warum?
If it were not for laughter, there would be no Tao.

Phil_GDM

Alter Hase

  • »Phil_GDM« ist der Autor dieses Themas

Beiträge: 443

Wohnort: Graz

Beruf: Student-Softwareentwicklung u. Wissensmanagement

  • Private Nachricht senden

19

18.02.2009, 10:51

Zitat von »"knivil"«

Was sagt die Policy denn aus? Alle verwalteten Objekte sollen eine Methode fuer die Bounding Box anbieten.

Nur die Default-Impolementierung sagt das aus!

Indem ich das ganze über solche Policies erledige (welche vom User ja nicht zwangsweise verwendet werden müsen), bleibe ich extrem flexiblel. Denn nun hat der User folgede Möglichkeiten:

1.) Sein Objekt bietet die Methode getAABB und fertig

2.) Er möchte/kann den Typ, den er einsortieren will nicht modifizieren (Klassen aus einer Lib z.B.), dann kann er einfach die Policy für den Typ spezialisieren, welche dann sagt, wie man für den Type die AABB generiert.

Beispiel: Ich sortiere auch Punkte in diesen Octree ein. Ich hab jetzt aber keine Lust, meine Vektor Klasse mit einer Methode getAABB auszustatten da es einfach keinen Sinn ergibt, dass ein Punkt eine BB hat (wobei ich dass noch auf "bounds" ändern werde; getAABB klingt im Vergleich ja schrecklich :roll: ).
Also mache ich folgendes:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
  template <>
  class OctreeAABBPolicy<float, Vec3f>
  {
  public:
        static AxisAlignedBB<float> getAABB(Vec3f const& data)
    {
      return AxisAlignedBB<float>(data, data);
    }
  };

Und schon sind meine Vektoren für den Octree verarbeitbar, ohne das ich an der Vektorklasse etwas ändern musste.

Im wesentlichen also: Es ist keine Ableitung notwendig; Die Klasse kann das interface haben, welches sie bereitstellen will; Man kann die BB für die Einsortierung im Octree unabhängig von der "realen" BB machen z.B.: für die Einsortierung werden 10% größere B-Boxes verwendet (um z.B. Heuristiken für Algorithmen anzunehmen und diese dadurch effizienter zu machen)

mfg Philipp

20

18.02.2009, 11:29

Zitat von »"Phil_GDM"«

bleibe ich extrem flexiblel.

Klingt wie "premature optimisation", habe aber keine Links parat, wo das Problem zuviel zu generalisieren diskutiert wird.

Zitat von »"Phil_GDM"«

Er möchte/kann den Typ, den er einsortieren will nicht modifizieren (Klassen aus einer Lib z.B.), dann kann er einfach die Policy für den Typ spezialisieren, welche dann sagt, wie man für den Type die AABB generiert.

Ok, das ist ein guter Grund.

Aber leider besteht dann noch das Problem, das Objekte mit unterschiedlichen Policies nicht im gleichen Octree verwaltet werden koennen. Falls du es doch moechtest, dann musst du trotzdem eine gemeinsames Interface anbieten und davon ableiten.

Zitat

Man kann die BB für die Einsortierung im Octree unabhängig von der "realen" BB machen z.B.: für die Einsortierung werden 10% größere B-Boxes verwendet

Das haengt von der Verwendung des Octree ab, z.B. bei Kollisionserkennung. Wie findet man seine potentiellen Kollisionspartner, "buttom up" oder "top down". Dabei bewirkt eine 10% groessere Bounding Box in der Regel, dass die Objekte schneller in eine hoehere Ebene rutschen (das Raster hat eine geringere Aufloesung). Und um so mehr Objekte in hoeheren Ebenen sind, desto schlechter die Vorauswahl von moeglichen Kollisionspartnern. Das macht sich dann vor allem bei einer "top down" Suche bemerkbar. Die BoundingBox-Policy als Option zu verwenden, um den Octree an das Problem anzupassen, halte ich fuer nicht sinnvoll.
If it were not for laughter, there would be no Tao.

Werbeanzeige