Java-Gaming.org Hi !
 Featured games (91) games approved by the League of Dukes Games in Showcase (757) Games in Android Showcase (229) games submitted by our members Games in WIP (844) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 3D perspective correct texture mapping  (Read 9200 times) 0 Members and 1 Guest are viewing this topic.
lcass
 « Posted 2013-11-20 21:59:19 »

Hello. Im looking for help with an algorithm on 3D Affine perspective correct texture mapping. This is basically rasterizing a 2d image in 3d space orthagonally.
EgonOlsen
 « Reply #1 - Posted 2013-11-20 22:32:19 »

You have either affine or perspective correct texture mapping. What is "affine perspective correct" supposed to be?

lcass
 « Reply #2 - Posted 2013-11-21 07:51:49 »

Ooop sorry I meant perspective correct
Roquen

JGO Kernel

Medals: 517

 « Reply #3 - Posted 2013-11-21 07:54:02 »

Use hardware.
EgonOlsen
 « Reply #4 - Posted 2013-11-21 09:07:35 »

Ooop sorry I meant perspective correct
It's not much different from affine texture mapping, where you interpolate u/v linear along the edges and for each scan line. The problem here is that u and v are linear in 3d, but not in screen space. By doing it that way, you'll get this Playstation 1-wobble-effect in the textures.
However, what is linear in screen space is "anything" divided by z. So instead of interpolating u and v, you interpolate u/z and v/z. To get the proper texture coordinates from this, you have to know the current z. z itself is again not linear in screen space. But 1/z is, so you interpolate three values: u/z, v/z and 1/z. To get u and v for each pixel, you simply divide u/z and v/z by 1/z...which is rather costly to be done per pixel. You can do a little optimzation here by doing this all 8/16/32/whatever... pixels only and do a linear interpolation between these correct values.

If done well, it's pretty fast: http://www.jpct.net/quapplet/

Roquen

JGO Kernel

Medals: 517

 « Reply #5 - Posted 2013-11-21 10:40:26 »

There's always the quadratic approximation which works in a fair number of situations and the error is easy to calculate so you can decide to sub-divide or use a different routine.  But I wouldn't bother, CPUs are much faster then when software rendering was required and the latency (in cycles) has also decreased.  But then again I wouldn't write a software renderer today either.
Roquen

JGO Kernel

Medals: 517

 « Reply #6 - Posted 2013-11-21 11:22:24 »

Oh and an easy and reasonable thing to do is be correct every Nth pixel (do the divide) and lerp the coordinates for the pixels between.  Quake did this at every 4th pixel if memory serves.
EgonOlsen
 « Reply #7 - Posted 2013-11-21 11:26:19 »

Oh and an easy and reasonable thing to do is be correct every Nth pixel (do the divide) and lerp the coordinates for the pixels between.  Quake did this at every 4th pixel if memory serves.
That's what i wrote. Quake did it every 16 pixels btw.

Roquen

JGO Kernel

Medals: 517

 « Reply #8 - Posted 2013-11-21 13:25:09 »

You did indeed.
lcass
 « Reply #9 - Posted 2013-11-21 15:37:34 »

Ooop sorry I meant perspective correct
It's not much different from affine texture mapping, where you interpolate u/v linear along the edges and for each scan line. The problem here is that u and v are linear in 3d, but not in screen space. By doing it that way, you'll get this Playstation 1-wobble-effect in the textures.
However, what is linear in screen space is "anything" divided by z. So instead of interpolating u and v, you interpolate u/z and v/z. To get the proper texture coordinates from this, you have to know the current z. z itself is again not linear in screen space. But 1/z is, so you interpolate three values: u/z, v/z and 1/z. To get u and v for each pixel, you simply divide u/z and v/z by 1/z...which is rather costly to be done per pixel. You can do a little optimzation here by doing this all 8/16/32/whatever... pixels only and do a linear interpolation between these correct values.

If done well, it's pretty fast: http://www.jpct.net/quapplet/
Are the U and V the coordinates of the pixel on the screen or are they the vector coordinates? . An example would really help .
EgonOlsen
 « Reply #10 - Posted 2013-11-21 17:54:44 »

Neither. u and v are the texture coordinates. Each vertex has x,y,z to define the point in space and u,v to define the texture coordinates.

lcass
 « Reply #11 - Posted 2013-11-21 18:10:32 »

sorry I dont quite understand what u and v are then. Are they just temporary coordinates?
cylab

JGO Kernel

Medals: 180

 « Reply #12 - Posted 2013-11-21 18:51:37 »

The letters "U" and "V" denote the axes of the 2D texture[note 1] because "X", "Y" and "Z" are already used to denote the axes of the 3D object in model space.

Source: Texture Mapping Mania

Mathias - I Know What [you] Did Last Summer!
lcass
 « Reply #13 - Posted 2013-11-22 08:19:29 »

Ahh I understand U and v now.
Roquen

JGO Kernel

Medals: 517

 « Reply #14 - Posted 2013-11-22 08:39:05 »

As an aside I'd suggest not wasting your time writing a software rasterizer.  It's too big a time commitment vs. the useful learning (approaching none) you'll get from it.  Do something else.
Pages: [1]
 ignore  |  Print

 EgonOlsen (76 views) 2018-06-10 19:43:48 EgonOlsen (56 views) 2018-06-10 19:43:44 EgonOlsen (76 views) 2018-06-10 19:43:20 DesertCoockie (258 views) 2018-05-13 18:23:11 nelsongames (156 views) 2018-04-24 18:15:36 nelsongames (155 views) 2018-04-24 18:14:32 ivj94 (896 views) 2018-03-24 14:47:39 ivj94 (160 views) 2018-03-24 14:46:31 ivj94 (809 views) 2018-03-24 14:43:53 Solater (173 views) 2018-03-17 05:04:08
 Java Gaming Resourcesby philfrei2017-12-05 19:38:37Java Gaming Resourcesby philfrei2017-12-05 19:37:39Java Gaming Resourcesby philfrei2017-12-05 19:36:10Java Gaming Resourcesby philfrei2017-12-05 19:33:10List of Learning Resourcesby elect2017-03-13 14:05:44List of Learning Resourcesby elect2017-03-13 14:04:45SF/X Librariesby philfrei2017-03-02 08:45:19SF/X Librariesby philfrei2017-03-02 08:44:05
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org