Talk:Texture mapping

message: The article needs a serious rewriting. There is a deep confusion between the parametrization problem and the texturing one. The code is by far unnecessary and probably make everithing less clear. I will probably remove it and rewrite some stuff in the next days. ALoopingIcon 09:15, 7 February 2006 (UTC)
thread_title:  Texture mapping vs parametrization 

message: At the moment, this incomplete sentence is in the article & I can't figure out what it was supposed to say: "Before Descent and Duke Nukem 3D, successfully used portal rendering and arbitrary orientation of the walls."  Can anyone fix?  Elf | Talk 05:02, 26 April 2006 (UTC)
thread_title: Incomplete sentence

message: I removed this: 
It makes no sense for me. →AzaToth 03:23, 28 April 2006 (UTC)
replies: text: I added  because I think that's the reality. →AzaToth 16:04, 28 April 2006 (UTC)

text: Is anyone actively working on this article? It really is one of the most important computer graphics related topics, yet it currently is in a pretty pitiful state. I'd like to pitch in, but there's so much to do, I'm not too sure where to start. How about we brainstorm an article overview, and hand out the sections? In any case, I'll see what I can do. Nezbie 04:16, 2 May 2006 (UTC)
thread_title:  What??? 

message: I've rewritten the lead, trying to preserve the same information... though it still feels disorganized to me. I'm not even sure what to do with the "history" section... probably remove it. It appears to be trying (badly) to describe the Bresenham algorithm, but also at the same time the difference between affine and perspective-correct texture mapping (with some strange confusion between the two... why keep mentioning "fractions"?). I'm thinking the section should be removed and just replaced with more description of those two things. (I'll think about it, maybe do that edit in a few minutes.) I've also noticed that the texture filtering, bilinear interpolation, and nearest neighbor interpolation articles seem to be pretty bad as well. - Rainwarrior 20:18, 1 July 2006 (UTC)
replies: text: Okay, I've finished rewriting the information that was there. I think it needs some organization, but at least it's more accurate now, I hope. There are some details I don't have, like I don't know exactly when perspective correct cards hit the market (I said "recently". I hate being so vague.); there's actually no article on affine or perspective correct texture mapping. This would probably be a good addition to this article (I wouldn't suggest making a new article for it) as its own section, perhaps. - Rainwarrior 20:36, 1 July 2006 (UTC)
thread_title:  Some rewriting July 1, 2006 

message: I have not looked at your (plural) age, but you seem not to have lived in the times when home computers needed software for texture mapping. I guess everybody is happy that these times are away and even JAVA on a mobile phone uses OpenGL (you tell me if it does). The reason for this section is, that wikipedia is full of games (articles about~) out of that time. These authors have an even lower grasp of how linear and perspective correct texture mapping have been intermixed then you. I understand that the paragraph maybe too hard to understand without pics, so who cares about DooM, Quake, or descent anyway?  Arnero 17:17, 14 April 2007 (UTC)
replies: text: I don't understand what you're talking about with regard to this article. Are you saying you'd like to see references to Doom and Quake in there? (There's one reference to Michael Abrash's discussion of perspective correct textures in Quake) I'm not sure exactly when perspective correct texturing appeared in games, but it was at least as early as that. The practice is much older than when it appeared in games, of course. I don't think OpenGL is really directly related to perspective correct textures; it's just an interface to the hardware (or software) which may or may not have that kind of texturing. Yes, a picture would be good to explain perspective correct textures. - Rainwarrior 17:42, 14 April 2007 (UTC)
thread_title:  Software renderer 

message: According to the article, Doom has to have walls perfectly vertical and floors perfectly flat because it uses affine texture mapping. The way I understand it, Doom uses a raycasting algorithm that has nothing to do with the scanline / polygon methods referred to in the article. Also, I've played Doom and seen screenshots and it doesn't seem to have any of the artifacts of affine texture mapping. So is this caption correct? 136.176.8.18 15:05, 4 September 2007 (UTC)
replies: text: The caption is correct, and hopefully explained why Doom doesn't have affine artifacts (maybe it's inadequate); It's only half affine. For a horizontal surface if the perspective correction is done only on the vertical and then a horizontal span is rendered in an affine way; because a screen-horizontal span of pixels on a world-horizontal surface all has the same depth there is no difference between affine and texture correct for that single span (so affine is used). Vice versa for the vertical surfaces, which are rendered in vertical spans (and note that wall textures are stored by column to facilitate this). Secondly, while Doom does do a little raycasting, most of the work is done by a BSP tree (unlike in Wolfenstein). Yes, there are other reasons why the walls/floor had to be axis aligned, but affine texture mapping is the major one (big performance boost because it's the inner-inner loop of the rendering process). - Rainwarrior 16:31, 4 September 2007 (UTC)
replies: text: it's not correct to say doom used to have exact horrizontal walls because of affine texturemapping. Doom used raycasting for rendering and this technique uses a bitmap-format for levels, that's why you just have horrizontal walls and no ramps. btw. that's the reason for the doors opening by sliding.  —Preceding unsigned comment added by 84.177.10.8 (talk) 02:00, 15 September 2007 (UTC)
replies: text: As I said, there are multiple reasons for aligning walls and floors to axes, but the ability to use affine texturing to render the vertical or horizontal spans is definitely something that benefits from this choice. Raycasting isn't something that is technically limited to axis-aligned objects (and the BSP tree really helps speed it up), and it doesn't comprise the bulk of the computation in the Doom engine. The bitmap format used for the walls and floors was specifically chosen to facilitate the rendering of vertical and horizontal spans; axis-alignment is the reason for the format, not the other way around. - Rainwarrior 02:59, 15 September 2007 (UTC)

text: BSP trees are not a rendering method, raycasting is the method it uses, and because of the assumptions it makes and the way maps are stored, the walls are all vertical. It doesn't use polygons the way modern games do, so I didn't think that affine mapping as described by the article and the picture made any sense when applied to Doom, a much older game with a completely different rendering algorithm. 136.176.19.42 03:27, 3 October 2007 (UTC)
replies: text: Whether you're rendering a triangle or a span, the same problems with perspective apply to textures. Doom avoids the expense of perspective correction by using axis-aligned spans. Doom was right in the middle of the period of time where the difference between affine and perspective correct texture mapping really mattered (i.e. there wasn't hardware ready to do it for you), and I think it is a very appropriate example. I didn't write the caption on the image though, maybe the word "scanline" is misleading, since it never really renders an entire scanline; I'll change it to use the word "span", which is more in line with existing literature on doom, and the source itself. - Rainwarrior 04:12, 3 October 2007 (UTC)

text: Doom doesn't use raycasting for rendering. Wolfenstein3D used raycasting but Doom didn't. Doom renders walls in order from front to back from the BSP. Leem02 (talk) 08:53, 8 September 2018 (UTC)
thread_title:  Affine mapping in Doom? 

message: The article currently links to itself (1st sentence, "surface texture"). It should either be removed or a real page only about textures should be created.
--78.56.57.236 (talk) 19:10, 22 February 2008 (UTC)
thread_title:  Link to the same page! 

message: My math skills are rusty, but doesn't the complicated equation simplify to interpolate(u)/interpolate(z)? Surely there is a less convoluted way to express this in the text than the given equation?--Henke37 (talk) 19:12, 20 July 2014 (UTC)
thread_title:  Perspective correct math simplification 

message: Perhaps the article would be better split into 3 ? (I've tried to re-arrange into sections that would 'map' onto them)
* Texture Map: - the resource used in texture mapping;details- formats, memory ordering, mipmaps, how they are used as resources in APIs. also link to 'tile maps'/character-map graphics. Use in GPGPU to approximate 1D,2D, 3D functions through lookup. 'used in multiple layers by materials.'. The article Texture atlas and possibly texture compression (both stub class) could be merged here. render-to-texture
* Texture mapping: the overall idea, used in 3d modelling & rendering; including assignment ('mappings' e.g. cylindrical,projection, UV unwrap, tiling, mirroring). mention control by vertices. Relation to a Material. also History of.  Rendermapping/baking. UV painting. The existing article UV mapping is quite close to what this should be, I would suggest merging this split with that.
* Texture mapped rendering: the history & technicalities of software & hardware texture mappers. history: flightsims, CAD,SGI, games,modern GPU. affine,perspective-correct, forward (saturn)/backward; doom-like limited axes. surface caching. Overview of modern shader pipeline. 
As I make this suggestion, I'm reminded how I often run into 'notability guidelines'. However smaller articles are IMO more manageable (the wording and ordering of a large article can become incoherent) and they flow better through more precise links - improving discoverability, and increasing wikipedias' value as an AI resource.
Fmadd (talk) 12:26, 4 June 2016 (UTC)
thread_title:  split the article? 

message: Posting here at Fmadd's suggestion. Prefacing this with an "I'm new, please forgive my mistakes and provide some guidance" in case I do this wrong.
the following patent: https://www.google.com/patents/US6002738  describes a method and apparatus to perform both tomographic reconstructions and volume rendering using texture mapping within the same device. Essentially, the invention interprets tomographic data from something like a CT scan and processes and displays the resulting information using texture mapping techniques and hardware. Quote "The mathematical and algorithmic similarity of volume rendering and backprojection, when reformulated in terms of texture mapping and accumulation, is significant. It means that a single high performance computer graphics and imaging computer can be used to both render and reconstruct volumes at rates of 100 to 1000 times faster than CPU based techniques. Additionally, a high performance computer graphics and imaging computer is an order of magnitude less expensive than a conventional CT system."
I also have access to one of the authors of the following document:http://dl.acm.org/citation.cfm?id=134071 which describes shadows and lighting effects using texture mapping.
I believe I can also obtain physical copies of the SIGGRAPH proceedings from 1991 through 1999  at least, which I can use to add additional citations to multiple pages on the computer graphics pages. Ignus3 (talk) 19:31, 13 June 2016 (UTC)
replies: text: interesting. in the 1995-2000 era prior to shaders various techniques appeared trying to leverage texture-mapping hardware 'for other purposes', I suppose what you're talking about here would easily justify a new section, "applications of texture mapping hardware"/ "variations" ... not sure exactly how. Maybe what you're talking about even deserves its own article (which will have links to tomography, texture mapping, and volume rendering), or a section in another article like 'volume rendering' . IMO , add the info .. see how it goes.. (When I read your references, I was also hoping you'd have good suggestions for increasing the citations for a load of *uncited* information that I've brain dumped here whilst restructuring the article)Fmadd (talk) 20:32, 13 June 2016 (UTC)
replies: text:  Hi fmadd, the above actually was my attempt to do just that, I'm pretty unschooled in the technology of 3D graphics, so I've been mostly going off of word association. I had also been staring at the screen so long my vision was going loopy, so I posted the info here first :)  as to your suggestion regarding the tomographic reconstruction using texture mapping, I think that info might fit best in a discussion of CT or CAT scan machines (or the tech thereof) as it is referencing a device that uses a single processor for what was, up until that time, two processes. I also did a ton of copy editing of this page as that's something I feel more confident with than computer graphics tech.Ignus3 (talk) 22:49, 14 June 2016 (UTC)
thread_title:  Information related to hardware implementations of texture mapping and rasterization 

message: The subsection does not define what exactly is baking. Maybe somebody can help with that.  — Preceding unsigned comment added by 148.225.71.160 (talk) 19:41, 29 March 2017 (UTC)
replies: text: Texture baking is described in this section. Jarble (talk) 19:41, 29 December 2020 (UTC)
thread_title:  Baking 

message: FTFA: Doom engine renders vertical and horizontal spans with affine texture mapping, and is therefore unable to draw ramped floors or slanted walls.
Unless you know precisely how the engine works, this is very misleading. The texture mapping in Doom is only affine in the directions orthogonal to the viewing direction, which is also the only direction where it makes no difference.
Also, while this explains why the use of affine mapping in this direction doesn't affect the result, it doesn't explain why it cannot render slanted floors and walls, this is due to other engine limitations. Tomb Raider for example could render slanted floors, although both its floors (even flat ones) and walls were affected by the display problem caused by affine texture mapping.  — Preceding unsigned comment added by 77.61.180.106 (talk) 00:13, 12 December 2021 (UTC)
thread_title:  Doom caption misleading