hit.u1, hit.u2

hit.x/y/z and hit.u/v returns the world coordinates so when a model is not world centered and/or rotated the hit.u/v values after a trace make no sense to me.

How can I calculate the real texture coordinates after a c_trace hit a rotated/moved model?

The values for hit.v.u1 / hit.v.v1 I do not understand as well.

hit.v is a standard DirectX vertex in the format defined in atypes.h. DirectX uses a 0..1 texture coordinate range, while hit.u1,v1 contain texture coordinates in pixels. All this has nothing to do with "World coordinates".

OK - thats fine.
But it doesn't answer my question at all.

My main problem is that I do not know how to determine the correct pixels.

detailed description:

I c_trace from the mouspointer to a facing (90°) model and get the right coordinates with the hit-values.
Then I rotate the model and the resulting pixel coordinates of the models textures are "wrong".
So the returning hit-values seem to be related to the models/faces angles/position.
Maybe there is a "secret trick" to calculate the proper coordinates (I please want to know) or it is simply still a bug.




(hit.x/y/z should be -32/32/0 - but this can be calculated)
(hit.u1/v1 should definitly be 0/0)

Also hit and target vector are always the same.

When you rotate an entity, of course you'll get different UV coordinates of the hit point. XYZ are normally also different.

So I admit I do not understand what you do not understand.

Sorry but I have to switch to german (native language)...

Was ich benötige ist das Pixel(x/y) der Textur eines Modelles.
Die Textur dreht sich mit den Modell mit.
Also habe ich (in o.g. Beispiel) Pixel 0/0 der Textur an der oberen linken Ecke des Modelles.

Dieses bekomme ich auch über hit.u1/v1 zurück, wenn ich auf die linke obere Ecke des Modelles trace (und das Modell pan/tilt/roll/x/y/z = 0/0/0/0/0/0 orientiert ist)

Drehe ich nun das Modell (und mit sich die Textur) und ich trace auf die linke obere Ecke des Modelles bekomme ich nicht 0/0 für hit.u1/v1, sondern einen für mich nicht erkennbaren Wert.

Wenn ich jedoch z.B. auf eine Textur zeichnen möchte, kann ich bei gedrehten Modellen nicht die Textur-Pixelkoordinaten ermitteln.

Möglicherweise verstehe ich den Sinn von hit.u1/v1 nicht - dann erklären Sie bitte, was die Werte repräsentieren und wozu ich sie verwenden kann.
Zudem würde ich mich über einen Hinweis zur Lösung meines Problemes (seit Januar2008) freuen.

ich glaube, er will die Texturkoordinate haben. Das Problem hatte ich auch mal.

Mein Vorhaben war, auf die Textur an der Aufschlagsfläche eine Wunde zu zeichnen. Zu einer Zeit, bevor das decal-System rauskam.

Das bedeutet, wenn ich auf eine Fläche trace, bekomme ich den Aufschlagsvector in den Weltkoordinaten. Die Koordinaten x y auf der Textur sollten dann aber immer, unabhängig von der Ausrichtung der Entity, das gleiche Ergebnis liefern.

Beispiel:
Ich treffe auf das Polyon xyz der getroffenen Entity. Der Rückgabewert ist der Vector xyz. Ich lasse an diesem Vector Blut per Partikel ausströhmen. Und zwar auch noch nachdem sich die Entity weiter bewegt. Dazu speichere ich z.B. den nächsten Vertexpunkt ab und berechne diesen immer wieder neu.

Auf die Texturposition, über die das Trefferpolygon liegt, möchte ich einen Blutfleck zeichnen. Koordinaten X / Y. Egal wie sich die Entity bewegt - die Koordinaten für Textur, über die das Teffer-Polygon platziert ist - bleiben immer gleich.

Das ist richtig: Die Texturkoordinaten sind gleich, wenn Sie auf die gleiche Stelle der Textur tracen. Sie bleiben jedoch nicht gleich, wenn Sie in die gleiche Richtung tracen und das Modell drehen, da Sie dann ja andere Textur-Stellen treffen.

"Weltkoordinaten" bezieht sich auf ein globales 3D-Koordinatensystem. Da Texturkoordinaten zweidimensional und lokal sind, gibt es hier keine "Weltkoordinaten".

Die hit.u1/v1 Koordinaten geben die getroffene Texturstelle wieder. Sie werden z.B. von der Engine verwendet, um per ent_decal auf die Textur an der getroffenen Stelle ein Decal zu zeichnen. Sie können auch selbst per pixel_to_bmap an der getroffenen Stelle etwas auf die Textur zeichnen. Wie die Entity dabei gedreht ist, sollte egal sein.

Zum Zeitpunkt, als ich diese Frage formulierte, gab es noch nicht die Rückgabewerte der Texturkoordinaten. Darum war eine Veränderung der Textur an der ensprechenden, getroffenen Polygonstelle nicht ohne größere Workarounds möglich.

Jetzt liefert die trace-Funktion zusätzlich noch die Textur-Koordinaten zurück, die man bei Bedarf abspeichern kann.


Wenn ich die Bilder anschaue, dann stellen die Koordinaten xyz den Treffer-Vektor dar.
Und u1 und v1 vermutlich die Textur Position X und Y.

Nehme ich an, daß das getroffende Polygon die Textur (bitmap) von X=0 bis X=100 und y=0 bis y=100 abdeckt, also 100*100 Pixel - dann müsste ich (egal, wie ich die Entity drehe und platziere) bei tracen derselben Stelle haargenau wieder die gleichen Werte für u und für v bekommen.

In den dargestellten Bildern bekomme ich aber andere Koordinaten ... obwohl die gleich Position am Modell getroffen wird.

Wenn ich das richtig verstanden habe, dann hat der Anwender zwar sein Modell um 15 Grad geneigt, aber er zielt auf haargenau die gleiche Stelle??

... und noch was...
auch wenn ich auf ein anderes Polygon trace, dieses aber deckungsgleich an der Stelle des ersten Polygons auf der Textur liegt - müssten die UV-Koordinaten identisch sein.

Bei einem Differenzergebnis von über 211 Pixeln heißt das, daß der Anwender ein anderes Polygon traced, das an einer anderen Stelle auf die TExtur gelagert wurde.

Jetzt kommen wir der Sache schon näher!

Wie ich festgestellt habe, funktioniert dies eben nicht:

(siehe Bilder oben)

Hier trace ich in beiden Fällen auf exakt die gleiche Position des Modells (linke obere Ecke (mit Texturpixelkoordinate 0/0)), bekomme aber bei dem gedrehten Modell eine verschobene? Texturposition.

Damit Sie es auch bequem sehen können, hier das zugehörige Testprogramm: u1v1.zip (50kb)

Das Programm läd ein einfach texturiertes Modell auf welches ein extra Vertix (Textur roter Punkt) gesetzt ist.
Das Programm tracet permanent von der Camera (0,0,100) auf den Vertix und zeigt hit.u1/hit.v1 an.

Diese sollten immer gleich sein - sollten...

Mit der Maus können Sie das Modell drehen.


Das Ergebnis:

Ich habe schon ne Weile nix mehr gemacht... aber bekommst Du das gleiche Ergebnis auch, wenn Du beim Tracen "use_polygon" verwendest?
Kann das wechselnde Ergebnis mit der "Strahldicke" zu tun haben?

So etwas gab es mal zu Zeiten von der A5 und A6, bis eben die polygongenaue Abfrage kam.

Ohne USE_POLGON triffst du einfach nur die Bounding Box und die rotiert bekanntlich nicht mit. Dein roter Punkt hat mit dem Treffer nix zu tun.

Setz doch einfach eine Zielentity auf die Trefferstelle dann siehst du wo das Problem ist.

Ladet Euch doch einfach das Testprogramm runter und schaut es Euch an (hier noch mal der link).
@tobias: der rote Punkt ist ein opt. Hilfspunkt für den Vertex der als trace-Ziel dient.
An dem Ergebnis ändert auch ein USE_POLYGON nichts.

Und wenn Ihr gerade dabei seid, würde ich mich über die Lösung freuen - einfach das Testscript ändern und hier posten (scheint ja nur eine Unachtsamkeit von mir zu sein).

Ive been having the same problem!
I wanted the UV coordinates (either pixels or 1 to 0) but the trace function doesn't seem to return the correct values.

I would really appreciate a solution. I am planning on creating a small code to handle bullet fire as actual holes (tranparent) in some entities such as crates to make my games and simulations more realistic.

Sorry for writing in english, I translated your German but I can't write it.

-Mike-

Auch auf die Gefahr hin, daß mein Gedanke dämlich ist:

Das getroffene Polygon ist ja immer ein Dreieck. Somit sollte es möglich sein, alle 3 Vertices und damit deren UVs zu ermitteln. Der Punkt, der tatsächlich auf dem Polygon getroffen wurde, liegt ja entweder genau auf einem der drei Vertices oder halt irgendwo innerhalb des Dreiecks.
Das Dreieck selbst ist immer eine Fläche und kann nicht gekrümmt werden. So könnte man anhand der Position des getroffenen 3D-Punktes im Verhältnis zur Position der anderen 3 Vertices das gesuchte UV-Paar berechnen.

CONTACT-Informationen

...aber wenn es eine Möglichkeit von 3DGS gibt, das Pixel zu ermitteln sollte diese auch funktionieren (da sie in diesem Fall einfacher zu verwenden währe)

I have tested the u1v1.zip. It had many bugs, for instance it must be SCAN_TEXTURE+USE_POLYGON, and you shoot at the very edge of the model so that you will probably miss the model in 50% of the time, and are not testing if you have hit it. But when I fixed all those errors the uv values are still wrong, so I think there is some engine bug.

then hurry up and move it to the bug forum (you are the guy for moving posts as I remember).



lol - the vertix is somewhere in the inner range (far away from the border) of the model - the traces must hit it every time.
The only thing you had to add was the USE_POLYGON, my little friend.

And now please just fix this bug (conitec) it (once again) took too much of my time to attract you to this obvious bug.

I'll look into this and will check if there is a bug.

fyi: I sent it yesterday also to the support to be checked.

thanx

i experience the same problems, when using hit.u1/v1/u2/v2

It seems as if it has problems with rotating (just use a simple model, check the u1 value and one point - remember this point, rotate the model, check u1 and the same point as before ==> wont be the same)

Please check this, u1/v1 is a very important feature for me..

@TechMuc

It's another bug but no moderator moves this post to the bug forum...

I'm basically having similar issues with the UV coordinates. Unfortunately, I can't read german and would like to know if someone here that can read it summarize if the problem can be worked around? We're trying to make a golf game and we need to know what type of material on the terrain the ball hits. We're doing this by looking at the colors in the texture using the UV coordinates. Anyhow, if anyone has any suggestions, that would be superb. Thanks.

This is an old thread, when you look in the bug list you see that this was fixed long ago.

...but it still does not work... *sight*

There was a scaling fix for hit_... in 7.65
So it should work with the next public beta.

Yes, there was a bug when the scale was different to 1, but apart from that I am not aware of any current u/v problem. If I remember right, the level you've uploaded had just the problem that you were hitting not polygons but bounding boxes. When you want UV coordinates, make sure to use polygon mode, otherwise your hit point is not inside the polygon.

If you want, download the latest version, 7.66, here: http://server.conitec.net/down/gstudio_766.exe. If it still does not work with that version, I'll have a look into your code. Please send it to Support then - we'll check what the problem is.

Thanks, we'll check it out.

@jcl: you're right - now it works fine (my fault on testing it)