4. nicht sichbar = nicht existiert ?

nicht sichbar = nicht existiert ?

  • F

    hallo

    unzwar:
    folgendes:
    zum anfang meines artikels werde ich in den bauch geboxt
    ...naja ich weiss, so fangen die meisten artikel an...aber gut..

    die frage:

    verbraucht ein objekt, dass nicht sichtbar ist (zb auf den koordinaten 100/0/101 liegt) so viel performance wie ein nicht existierendes objekt?

    bsp:
    1.

    translatef(100,1,-101);
drawquad();

    ist 2. viel schneller oder nur minimal?

    ps: john swartzwelder geht ab 😉

    0
  • N

    Fachmann schrieb:

    verbraucht ein objekt, dass nicht sichtbar ist (zb auf den koordinaten 100/0/101 liegt) so viel performance wie ein nicht existierendes objekt?

    Ich finde schon das die Industrie Compiler entwickeln sollte die weniger verbrauchen. 👍

    0
  • F

    wiie jetzt?

    0
  • L

    ich hab mal gelesen das grafikkarten nicht sichtbare stellen nicht rendern ...

    daraus interpretiere ich aber nur eins:

    der cpu wird denoch "belastet" da er ja der grafikkarte sagen muss rendere das... ausser es ist im selben vertexbuffer was aber wiederum sehr selten ist (ne map mit nur 8 texturen, das gibts doch nur bei CS (dust) *G*)
    und was ist wenn grad zufällig ganzhinten im sichtfeld angefangen wird ist ja sichtbar steht ja "noch" nix davor.

    eine funktion die entscheidet ob objekte sichtbar sind kostet vllt viel resourcen in ego-shootern dürfte sich das aber 100%ig bezahlt machen - man sollte aber die models nicht vergessen zu rendern sonst gibts den effeckt wie ich ihn bei RavenShield kenne uzw das leute die von der seite in einen gang rein rennen mit einmal in der mitte stehen - sehr blöde.

    bei anderen spielen sollte so eine funktion auch mer fps bringen und is vllt einfacher zu realisieren (rennspiel - was hinter mir ist seh ich nicht -> nicht rendern ausser ... oder strategie spiele von oben sieht man ja nur nen ausschnitt -> maximal so un so viel drumherum rendern [maximal grösse von objekten un so])

    0
  • T

    LinkeT schrieb:

    ich hab mal gelesen das grafikkarten nicht sichtbare stellen nicht rendern ...

    daraus interpretiere ich aber nur eins:

    der cpu wird denoch "belastet" da er ja der grafikkarte sagen muss rendere das... ausser es ist im selben vertexbuffer was aber wiederum sehr selten ist (ne map mit nur 8 texturen, das gibts doch nur bei CS (dust) *G*)
    und was ist wenn grad zufällig ganzhinten im sichtfeld angefangen wird ist ja sichtbar steht ja "noch" nix davor.

    eine funktion die entscheidet ob objekte sichtbar sind kostet vllt viel resourcen in ego-shootern dürfte sich das aber 100%ig bezahlt machen - man sollte aber die models nicht vergessen zu rendern sonst gibts den effeckt wie ich ihn bei RavenShield kenne uzw das leute die von der seite in einen gang rein rennen mit einmal in der mitte stehen - sehr blöde.

    bei anderen spielen sollte so eine funktion auch mer fps bringen und is vllt einfacher zu realisieren (rennspiel - was hinter mir ist seh ich nicht -> nicht rendern ausser ... oder strategie spiele von oben sieht man ja nur nen ausschnitt -> maximal so un so viel drumherum rendern [maximal grösse von objekten un so])

    ????

    Deine Frage lässt sich nicht so leicht beantworten. Es gibt mehrere Arten von "nicht sichtbar", z.B. Geometrie außerhalb des View Frustums, gecullte Geometrie oder Geometrie, die durch andere verdeckt wird. Schau dir einfach mal die D3D Fixed Function Pipeline an, dann siehste an welcher Stelle welche Art von "unsichtbarkeit" relevant wird.
    Als Faustregel kann man sagen: Alle Daten die du zu GraKa schickst, werden einen Aufwand erzeugen (selbst wenn dein Vertex bereits in der Clipping Stage verworfen wird, wird es auf den meisten GraKas zuvor durch die ModelToProject Transformation sowie VertexFog/Lighting Stage gewandert sein).

    0
  • L

    this->that schrieb:

    LinkeT schrieb:

    ich hab mal gelesen das grafikkarten nicht sichtbare stellen nicht rendern ...

    daraus interpretiere ich aber nur eins:

    der cpu wird denoch "belastet" da er ja der grafikkarte sagen muss rendere das... ausser es ist im selben vertexbuffer was aber wiederum sehr selten ist (ne map mit nur 8 texturen, das gibts doch nur bei CS (dust) *G*)
    und was ist wenn grad zufällig ganzhinten im sichtfeld angefangen wird ist ja sichtbar steht ja "noch" nix davor.

    eine funktion die entscheidet ob objekte sichtbar sind kostet vllt viel resourcen in ego-shootern dürfte sich das aber 100%ig bezahlt machen - man sollte aber die models nicht vergessen zu rendern sonst gibts den effeckt wie ich ihn bei RavenShield kenne uzw das leute die von der seite in einen gang rein rennen mit einmal in der mitte stehen - sehr blöde.

    bei anderen spielen sollte so eine funktion auch mer fps bringen und is vllt einfacher zu realisieren (rennspiel - was hinter mir ist seh ich nicht -> nicht rendern ausser ... oder strategie spiele von oben sieht man ja nur nen ausschnitt -> maximal so un so viel drumherum rendern [maximal grösse von objekten un so])

    ????

    Deine Frage lässt sich nicht so leicht beantworten. Es gibt mehrere Arten von "nicht sichtbar", z.B. Geometrie außerhalb des View Frustums, gecullte Geometrie oder Geometrie, die durch andere verdeckt wird. Schau dir einfach mal die D3D Fixed Function Pipeline an, dann siehste an welcher Stelle welche Art von "unsichtbarkeit" relevant wird.
    Als Faustregel kann man sagen: Alle Daten die du zu GraKa schickst, werden einen Aufwand erzeugen (selbst wenn dein Vertex bereits in der Clipping Stage verworfen wird, wird es auf den meisten GraKas zuvor durch die ModelToProject Transformation sowie VertexFog/Lighting Stage gewandert sein).

    die D3D Fixed Function Pipeline hab ich mir (noch) nicht angeschaut ... aber wenn das sooooo ist lohnt sich eine fuktion die nur sichtbare objkte rendet alle mal

    0
  • C

    Die Graka kann in den meissten Fällen erst entscheiden ob das Objekt sichtbar ist, wenn dieses schon transformiert und projeziert wurde. Diesen Aufwand sollte man vermeiden indem man vorher testet welche Daten überhaupt an die Graka gesendet werden sollen. Dafür gibts viele Ansätze, die gängigsten sind wohl "Octree" und "BSP". Kommt aber wiederum sehr auf den Anwendungsfall an, also musst schon ein Paar Stündchen investieren um da durchzublicken 🙂

    0
  • R
    Mod

    Es gibt keine globale immer gueltige performance tips. am besten ist es, wenn man performance probleme hat dann zu profilen und die problemstellen zu beheben, statt im voraus aufgrund von vermutungen zu optimieren.

    0
  • F

    thx an alle!

    also schlussfolgere ich mal, 8 punkte zu setzen, wie ich hier erfahren habe, indem ich nach

    Octree" und "BSP"

    gegoogelt habe:

    Du hast ne Landschaft oder irgendwas grösseres. Nun machst du 8 Punkte auf dieser Landschaft und schaust nur welche der 8 Punkte in deinem Sichtfeld liegen. Den 8 Punkten sind wiederrum Objekte zugeordnet. Und so kannst du einfach schaun, ob eine grössere Menge Objekte nicht im Sichtfeld liegt. Das ist schneller als zu überprüfen ob jedes Objekt nicht zu sehen ist

    das problem kann man natürlich in viele spezielle probleme gliedern, deswegen auch
    was rapso geschrieben hat. aber das obrige war mein problem. dass objekte, die verdeckt werden bei mir auch gerendert werden werden, hat den grund dass sich eigentlich noch nicht so viel aufwand wegen sowas "kleinem" lohnt

    also thx nochmal^^

    0
  • C

    Auch die Leistung moderner Grafikkarten bricht schnell ein, je mehr Polys und Shader-Spielchen an die Graka gehen. Irgendeine Form von Optimierung ist da eigentlich immer erforderlich, sobald du über den rotierenden Würfel hinaus willst.

    0
  • R
    Mod

    Cpp_Junky schrieb:

    Auch die Leistung moderner Grafikkarten bricht schnell ein, je mehr Polys und Shader-Spielchen an die Graka gehen. Irgendeine Form von Optimierung ist da eigentlich immer erforderlich, sobald du über den rotierenden Würfel hinaus willst.

    nicht irgendeine, sondern die richtige optimierung, sonst machst du es nur noch schlimmer. Graphik ist nicht nur Polygon und shader abhängig.

    0
  • J

    Kann man nicht generell sagen, dass Frustum-Culling sinnvoll ist? Gibt es Situationen (abseits vom drehenden Würfel und solchen Spielereien) in denen es tatsächlich besser ist einfach alles zu rendern, egal ob sichtbar oder nicht?

    0
  • L

    teste es doch einfach 😃 man könnte ja mal nen polygon benchmark machen *G* hat wer lust zu coden;)

    0
  • R
    Mod

    Jester schrieb:

    Kann man nicht generell sagen, dass Frustum-Culling sinnvoll ist? Gibt es Situationen (abseits vom drehenden Würfel und solchen Spielereien) in denen es tatsächlich besser ist einfach alles zu rendern, egal ob sichtbar oder nicht?

    ja, es waere wenig sinnvoll einzelne objekte die aus einzelnen polygonen bestehen mittels frustumculling zu verwerfen, da es weniger kostet einfach alle zu zeichnen wenn eines potentiel sichtbar ist, anwendung: Particlesystem.

    0

  • Jester schrieb:

    Kann man nicht generell sagen, dass Frustum-Culling sinnvoll ist? Gibt es Situationen (abseits vom drehenden Würfel und solchen Spielereien) in denen es tatsächlich besser ist einfach alles zu rendern, egal ob sichtbar oder nicht?

    Nein, kann man nicht. Man kann aber sagen, das es immer dann besser ist, wenn t(Culling Test) + P(Culling Test sagt sichtbar) * t(alles Zeichnen) < t(alles Zeichnen). Oder aber die Guete ist proportional zu t(Culling Test) + P(Culling Test sagt sichtbar) * t(alles Zeichnen), wobei kein Culling ein Sonderfall ist mit t(Culling Test)= 0 und P(Culling Test sagt sichtbar)= 1.

    Gruß, TGGC (\-/ has leading)

    0
Anmelden zum Antworten