Java-Gaming.org Hi !
 Featured games (83) games approved by the League of Dukes Games in Showcase (521) Games in Android Showcase (127) games submitted by our members Games in WIP (589) 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 2723 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
 « 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
 « 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
 « 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
 « 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 Ninja

Medals: 55

 « 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
 « 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

You cannot reply to this message, because it is very, very old.

 Add your game by posting it in the WIP section, or publish it in Showcase. The first screenshot will be displayed as a thumbnail.
 xFryIx (58 views) 2014-11-13 12:34:49 digdugdiggy (37 views) 2014-11-12 21:11:50 digdugdiggy (30 views) 2014-11-12 21:10:15 digdugdiggy (26 views) 2014-11-12 21:09:33 kovacsa (48 views) 2014-11-07 19:57:14 TehJavaDev (51 views) 2014-11-03 22:04:50 BurntPizza (51 views) 2014-11-03 18:54:52 moogie (66 views) 2014-11-03 06:22:04 CopyableCougar4 (65 views) 2014-11-01 23:36:41 DarkCart (151 views) 2014-11-01 14:51:03
 theagentd 29x basil_ 27x BurntPizza 23x princec 17x Spasi 17x pitbuller 15x HeroesGraveDev 14x Riven 14x KevinWorkman 13x SHC 11x Grunnt 10x kpars 10x gouessej 10x Nate 9x kevglass 9x Longarmx 9x
 Understanding relations between setOrigin, setScale and setPosition in libGdx2014-10-09 22:35:00Definite guide to supporting multiple device resolutions on Android (2014)2014-10-02 22:36:02List of Learning Resources2014-08-16 10:40:00List of Learning Resources2014-08-05 19:33:27Resources for WIP games2014-08-01 16:20:17Resources for WIP games2014-08-01 16:19:50List of Learning Resources2014-07-31 16:29:50List of Learning Resources2014-07-31 16:26:06
 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