ViewFrustum-culling ungenau?

Manuel

Hi,
sind die Funktionen, die im 2. Band von Stefan Zerbst verwendet werden alle korrekt? Ich habe hier gerade "Game programming gems" vor mir liegen und da gibt es einige Unterschiede: z.B.
Normalize:
Zerbst:

D3DVECTOR Engine::Normalize(D3DVECTOR *vector)
{
float temp;
temp=this->VSum(*vector);

(*vector).x /= temp;
(*vector).y /= temp;
(*vector).z /= temp;

return (*vector);
}

GPG:

D3DVECTOR Engine::Normalize(D3DVECTOR *vector)
{
float temp;
temp=this->VSum(*vector);
temp=1.0f / temp;

(*vector).x /= temp;
(*vector).y /= temp;
(*vector).z /= temp;

return (*vector);
}

... welche Funktion ist nun richtig?
Das ganze soll aber nur auf das Problem hin hinauslaufen, dass ich bei meinem Terrain die Culling-Funktionen aus Stefans Buch verwende und selbst wenn nichts von der Landschaft auf dem Bildschirm ist, immer noch ca. 20000 Polygone gerendert werden?
Kennt ihr bessere ViewFrustum-culling Funktionen?

Danke im Voraus

M.T.

Stefan Zerbst

Hi,

einen Vektor zu normalisieren bedeutet, jede Komponente durch seine Länge zu teilen. Eine Optimierung dabei kann es sein, wenn man zunächst 1/temp berechnet (wenn temp die Länge ist) so wie es in der Gems Variante ist. Dann müsste man aber die einzelnen Komponenten mit temp multiplizieren, und nicht dividieren.

Schneller ist das immer dann, wenn die CPU schneller multiplizieren als dividieren kann. Bist Du sicher, dass das im GPG so drinsteht?

Was das Culling angeht. Dort hast Du definitiv etwas falsch berechnet. Am besten wäre es, wenn Du auch mal die Bounding Boxen die Du cullst renderst. Eventuell sind diese falsch berechnet.

Ciao,
Stefan

TomasRiker

Ich weiß nicht, was das "VSum" heißen soll.
Aber folgende Funktion ist garantiert richtig:

D3DVECTOR Engine::Normalize(D3DVECTOR& vVector)
{
    float fInvLength = 1.0f / sqrtf(vVector.x * vVector.x +
                                    vVector.y * vVector.y +
                                    vVector.z * vVector.z);
    return D3DVECTOR(vVector.x * fInvLength,
                     vVector.y * fInvLength,
                     vVector.z * fInvLength);
}

Diese Methode verändert den Vektor nicht, sondern liefert einen neuen Vektor zurück. Die beiden, die Du angegeben hast, verändern auch den Originalvektor. Falls das erwünscht sein sollte, dann so:

D3DVECTOR Engine::Normalize(D3DVECTOR& vVector)
{
    float fInvLength = 1.0f / sqrtf(vVector.x * vVector.x +
                                    vVector.y * vVector.y +
                                    vVector.z * vVector.z);
    vVector.x *= fInvLength;
    vVector.y *= fInvLength;
    vVector.z *= fInvLength;

    return vVector;
}

Aber das dürfte eigentlich nicht viel mit View-Frustum-Culling zu tun haben!

Manuel

Das mit dem Normalize könnt ihr selbst nachlesen - GPG Seite 426.

@Stefan: ich hab den Fehler jetzt gerade gefunden . Bei meiner Engine gibt es kein Intersect -> das zweite Punktprodukt muss gelöscht werden, deswegen die zu vielen Polygone.

@TomasRiker: Das VSum soll im Deutschen VBetrag heißen, mir ist nur keine bessere Übersetzung eingefallen.

M.T.

Stefan Zerbst

Hi,

wer sagt denn dass immer alles richtig ist was in Büchern steht?

Ciao,
Stefan

VBetrag would be VMagnitude ...

Manuel

Danke, ich werds umändern ...

M.T.