OpenGL sichtweite



  • hi folks!

    habe das bluebook und die FAQ durchgesehen, aber nirgends was dazu gefunden,
    also hoffe ich dass ihr mir weiterhelfen koennt...

    ich habe mal wieder an meinem heightmap-generator programmiert, und ihn auch zum laufen bekommen. problem ist jetzt dass, wenn ich die landschaft weg vom bildschirm schiebe, sie recht schnell verschwindet... also ab einer bestimmten entfernung werden die dahinter liegenden polys einfach nicht mehr gezeichnet.

    ich zeichne die ganze landschaft im koordinatensystem zwischen beispielsweise -128.0f bis 127.0f in X und Y. bei Z muesste ich so in etwa bei -15.0f oder so liegen.....

    also, kann ich da jetzt was einstellen dass die sichtweite einfach groesser ist, oder muss ich auf jeden fall meine welt runterskalieren?
    gibt es da generelle regeln, was die positionierung in floats angeht?
    und sonst noch irgendwelche tips bezueglich dieser thematik?

    danke im voraus,

    --loki 🙂

    /EDIT: typo



  • gluPerspective, der letzte Parameter



  • ah, danke... werde das mal ausprobieren...

    aber generell duerfte ja ein groesseres zFar an der performance fressen, oder?

    was mich ein wenig verwirrt ist, dass ich ja rein theorethisch meine komplette welt zwischen z.B. -1024 bis +1023 haben kann, oder zwischen -1 und + 1 (und ich denke mal der einzige unterschied waere, dass ich mit der kamera naeher ran muesste)...
    aber mir ist nicht ganz bewusst was da dann unterschiedlich ankommt. ist die performance unterschiedlich, und was ist mit der genauigkeit der float-positionen? und gibt es dann unterschiede im aussehen der texturen?

    vielleicht muss ich das einfach mal austesten, aber vielleicht kann mir das ja auch einer erklaeren... 🙂



  • Naja kannste dir ja ausrechnen, wenn deine Koordinaten den Gültigkeitsbereich des floats überschreiten wird es lustige Nebeneffekte geben. Entweder nutzt du double oder skalierst deine Szenerie runter (was ich vorziehen würde). Wegen Sichtweite und Performance: Die Sichtweite ist nicht unbedingt ausschlaggebend, eher wie viel Geometrie-Daten du in jedem Frame zum Treiber schickst. Darum sollte ein Culling Algorithmus erstmal das Primärziel sein (Mindestens Frustum Culling, optimalerweise mit in einem Octree oder einer ähnlichen "Hilfsstruktur" organisierten Geometrie Daten). Die Sichtweite kann man dann später immernoch anpassen und das Ende des sichtbaren Bereichs z.B. mit Nebeleffekten vertuschen.
    (edit)
    Fast, vergessen: Wegen Grössenordnung der Szene (-1024<->1024 oder -1<->1):
    Hier spielt die float Genauigkeit natürlich eine Rolle. Je kleiner desto ungenauer, wegen Rundungsdifferenzen etc. Ausserdem musst du dann die Near-Plane sehr klein einstellen was ebenfalls Nebeneffekte aus den selben Gründen mit sich bringt. Musst halt ein bissel rumprobieren bis du das optimale Verhältnis gefunden hast. (Ich knobel gerade selber an diesen Problemen, entwickle grad eine kleine 3D Engine für einen Space Shooter)



  • Wegen Grössenordnung der Szene (-1024<->1024 oder -1<->1):
    Je kleiner desto ungenauer

    das stimmt nur bedingt.
    fliesskomma-zahlen sind nahe 0 am dichtesten. genauer gesagt haben floats zwischen -1..+1 negative exponenten, alle anderen positive.
    vergroessert man den wertebereich also ueber -1..+1 hinaus gewinnt man maximal 1 bit praezision - naemlich das vorzeichenbit des exponent.


Anmelden zum Antworten