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!

Negative Texture Coordinaten in positive umwandeln

  • 1
  • 2

Werbeanzeige

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

11

14.07.2021, 19:39

Zitat von »Key-Real«

bringe bitte ein Codebeispiel

Ich beherrsche diese Sprache nicht. Mein letzter Post war doch sehr eindeutig. Du hattest es fast richtig. Du sollst nur die Berechnung von floor(...) aus dem Pro-Pixel-Code rausziehen, weil es Quatsch ist, das immer wieder neu zu berechnen (ändert sich ja nicht). Und dann sollst du bei der Differenz die Terme vertauschen. Probiere das aus, dann sollte es funktionieren. Vorausgesetzt der Rest deines Codes ist korrekt - den werde ich mir jetzt aber nicht anschauen.
David Scherfgens Website | Konzentrationstest Polizei

Jonathan

Community-Fossil

Beiträge: 3 820

  • Private Nachricht senden

12

15.07.2021, 00:57

Zitat von »David Scherfgen«


Komplett normalisieren kann man vor dem Interpolieren nicht, das stimmt. Es ging hier ja auch nur darum, dass man negative Koordinaten loswird. Und das kann man schon machen, so wie ich es beschrieben habe. Du verschiebst damit quasi das komplette Dreieck in den Texturkoordinaten gerade so weit, dass kein Vertex mehr ins Negative ragt. Dann spart man sich das vermutlich teure x - floor(x) pro Pixel, weil man schon weiß, dass die Koordinaten nie negativ sein können.


Hm. Offensichtlich wird hier ja eine "getPixelclip(texture,tx,ty);" Funktion verwendet, die dann anscheinend positive Integer erwartet (sonst würde er/sie in den Zeilen darüber ja nicht runden). Ich finde es aber immer noch irgendwie abstrus, dass eine solche Funktion kein Problem mit Werten hat, die zur einen Seite aus dem validen Intervall ragen, aber Werte die zur anderen Seite herausragen kategorisch ablehnt. Insbesondere da beide Fälle mathematisch exakt gleich behandelt werden (da die floor-Funktion passend definiert ist).

Es wäre also eigentlich der richtige Ansatz, die entsprechende Funktion vernünftig zu implementieren, so dass man auf der Aufruferseite keine Sonderfälle mehr behandeln muss. Wenn sie aber aus einem anderen Framework stammt mag das ggf. nicht möglich sein. ist ja scheinbar eh eine eher edukative Aufgabe, die nicht auf Performance optimiert ist.
Lieber dumm fragen, als dumm bleiben!

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

13

15.07.2021, 07:05

Hmm, ja. Ich hatte jetzt bei der Umrechnung von Texturkoordinaten in Pixelkoordinaten an Modulo gedacht. Das funktioniert ja (ohne Anpassungen) nur mit positiven Zahlen korrekt. Ist aber vermutlich langsamer als floor.
David Scherfgens Website | Konzentrationstest Polizei

Key-Real

Frischling

  • »Key-Real« ist der Autor dieses Themas

Beiträge: 9

  • Private Nachricht senden

14

15.07.2021, 11:25

die von mir gepostete Funktion leuft korrekt wenn die Texturkoordinaten sich im Bereich von 0..1 befinden.

getPixel ist für Testzwecke in der Clip Variante

hier sind die Texturcoordinaten im Bereich -1..+1



sehe ich etwas falsch?

vor dem rastarezieren, pro Poly:

Quellcode

 
1
2
3
4
5
6

float minU=poly.v[0].tu;  // v ist vertex in poly
for (int x:=1; x=poly.numVertex-1; x++) {
  minU=min(minU,poly.v[x].tu);    // tu ist texture U Koordinate von dem Vertex
}

int minUfloor=floor(minU);    // ergibt immer -1 (wenn U im negativen ist)

und das gleiche für V....


im mainloop:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13

if (z>ZBuffer[offset]){
  float invW=1 / w;

  float u1=u-minUfloor;
  flaot v1=v-minVfloor;
  int tx:=round((u1*invW)*(texture.width-1));   
  int ty:=round((v1*invW)*(texture.height-1));

  int color=getPixel(texture,tx,ty);

  draw(color);  // als Platzhalter
  ZBuffer[offset]=z;
}


hoffentlich habe ich das korrekt in C übersetzt
die Variableninitializeirungen sind nur für Demonstrationszwecke. mir ist klar, dass man in einem innerloop sowas nicht macht

ist der code richtig? funkt nämlich nicht

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Key-Real« (15.07.2021, 11:40)

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

15

15.07.2021, 15:32

Du musst jetzt natürlich noch gucken, dass du u/v-Koordinaten, die größer sind als 1, wieder von 0 anfangen lässt ("repeat").
Ich dachte, dass deine getPixel das schon macht, aber scheinbar nicht.

Dann mach den Kram mit minU und minUfloor mal wieder raus und ersetze stattdessen deine Zeilen 4 und 5 durch:

Quellcode

 
1
2

float u1 = u - floor(u);
float v1 = u - floor(v);
David Scherfgens Website | Konzentrationstest Polizei

Key-Real

Frischling

  • »Key-Real« ist der Autor dieses Themas

Beiträge: 9

  • Private Nachricht senden

16

16.07.2021, 08:57

Langsam glaube ich, mein Model ist nicht gans richtig.

Kann das aber nicht Prüfen, da ich keine Ahnung von Blender/3DS/Maya habe :(

Aber danke für die Hilfe!

Wenn ich sicher bin, dass ich ein Model gefunden habe wo die Texturkoordinaten korrekt negativ sind, greife ich auf deine Lösung zurück

Werbeanzeige

  • 1
  • 2

Ähnliche Themen