HomeForumsWhat's newResources 
 
 
Saturn Texture Coordinate Test
RockinB - Jul 1, 2005

 < Prev  1  2  3  Next> 

  M3d10n Jul 19, 2005
Whoa! You offically broke the Sonic R saturn environment map monopoly! Could you sum up the trickery? AFAIK, SonicR's title and loading screen were actually rendered by a software renderer (it becomes apparent if you run Sonic R in an HW accelerated emulator like GiriGiri hack: the enviroment mapped stuff stays at fixed resolution, in another VPD2 layer).

 RockinB Jul 20, 2005
This texture mapping stuff could be used for all sprite based console systems, like Saturn, SEGA CD, 32x, GP32 and a lot other.

The code currently uses some Saturn libs for mapping, but with some optimizations, this will be obsolete.

So if I work a little more on this, we could see it on other consoles, too.


  
	
	

		
		

			Originally posted by M3d10n+Wed, 2005-07-20 @ 03:50 AM-->
QUOTE(M3d10n @ Wed, 2005-07-20 @ 03:50 AM)
Whoa! You offically broke the Sonic R saturn environment map monopoly![/b]



Yeah, but I'm not sure if the effect in Sonic R can be called environment mapping. It's not view dependent. It seems to be plane mapping, I offer cylinder and sphere mapping, too. And there is a very buggy version of view dependent sphere mapping included.


  
	
	

		
		

			Originally posted by M3d10n@Wed, 2005-07-20 @ 03:50 AM



Could you sum up the trickery?


Well, I started with implementing a function which resamples a rectangular texture from texture coordinates of another texture, which form a convex quad. This is what the demo#1 is about.

Then I made a small framework to map the vertices of a polygon (the fast method) onto an intermediate surface(plane, cylinder, sphere) and finally convert them to texture coordinates. So I could map textures and generate new textures which then replace old textures in VRAM and are displayed by the Saturn VDP1.

The texture coordinates must form a convex quad to get correct result, so there are problematic mappings, like a quad that's mappen onto the pole of a sphere. So I implemented the mapping of each texel instead of the polygon vertices only. This takes a lot more time, but the display is no approximation anymore. I would wish to detect problematic textures and generate those with this slow method.

QUOTE(M3d10n @ Sun, 2005-07-24 @ 03:01 PM)
I think a few (very few) Saturn games might have used such method for a few models, but using some sort of pre-processing tool, never in real time.

[post=137180]Quoted post[/post]

[/b]



Actually I think a lot of games used the "Texture slice" function of 3DEditor's tool "Texture List", which performs very similar operation as precomputation.

The Sonic-R effect is done in real-time, but as mentioned in the posts before, it's probably rendered by software only.

QUOTE(Omni @ Thu, 2005-07-28 @ 03:47 AM)
2. I can comprehend the idea of resampling a 2D quad or convex polygon from a source texture and creating a new rectangular texture for mapping. Have I understood that correctly? Also, why must the distorted quad be convex?

[post=137410]Quoted post[/post]

[/b]



It's due to the resmapling algorithm. You won't see a glitch or anything when a convex quad transforms into a concave quad in demo one, but the generated texture image is not correct. Just like when you want to display concave quads with VDP1. See Charles MacDonalds example, it's explained in a manual, too.


  
	
	

		
		

			Originally posted by Omni@Thu, 2005-07-28 @ 03:47 AM



3. I barely understand what you mean by a mapping method such as sphere or cylinder.




[post=137410]Quoted post[/post]


It's the method of texture mapping using an intermediate surface. Such an intermediate surface is a plane, a cylinder or a sphere and you can easily imagine how it looks like when a texture is applied to them.

The faces of the 3D object are just projected onto the intermediate surface and the face gets the part of the texture that is mapped on the intermediate surface in that region.

The mapping:

point in 3D space -> point on intermediate surface -> texture coordinate

Projecting the faces on the intermediate surface can be done in two ways:

* project 4 vertices of a face

(fast, but approximated)

* project each texel of a face

(slow, but accurate)


  
	
	

		
		

			Originally posted by Omni@Thu, 2005-07-28 @ 03:47 AM



Do I need to read more about ...texture coordinates?




[post=137410]Quoted post[/post]


Use keywords like "texture mapping" "inverse mapping" "intermediate surface"

QUOTE(Omni @ Thu, 2005-07-28 @ 12:58 PM)
Awesomeness! Okay...a few more questions, if you don't mind.

1. I can understand the idea of using the sphere to correspond to texture coordinates...but...I can't really imagine how that works with a cylinder. Much less a plane... [plane means "flat surface", right?] ...Is this something I will figure out as soon as I research texture coordinates?

[post=137424]Quoted post[/post]

[/b]



Putting a texture on a plane - a rectangular shape - is the simplest method. The 3D object is projected onto it. But unlike the projection to screen - which is perspective projection - , it uses orthographic projection, which is much simplier (only take one dimension and discarda the other, in my case).

The only difference between cylinder and sphere mapping is the computation of the vertical texture coordinate, which involves trigonometric in case of sphere and which is just as simple as plane mapping for cylinder.


  
	
	

		
		

			Originally posted by Omni@Thu, 2005-07-28 @ 12:58 PM



2. How exaclty are you sampling the texture data?




[post=137424]Quoted post[/post]


The texels are sampled using nearest neighbor. That's a decision which I think is appropriate for runtime on Saturn, but bilinear interpolation of texels could be done in a PC tool.


  
	
	

		
		

			Originally posted by Omni@Thu, 2005-07-28 @ 12:58 PM



For the first demo and the rectangle source quad, that seems pretty simple...I think. I guess you'd retrieve the rectangle data copy it into a second buffer, 4somehow, but I'm not sure how -- I thought you guys were still working on DMA image access and linescrolling? Is there another way to transfer image data?




[post=137424]Quoted post[/post]


In demo#1, there are two sprites in VRAM: the original texture and the texture which is resampled from the quad inside the other texture. In fact, there is a 2nd copy of the original texture in work RAM, as it is in all other demos.

The linescroll enables the display of "continuous address" bitmaps using VDP2 scrolls. It's slightly faster than using VDP1 sprites and it's the only way to display 24bpp images. In either case, sprite or linescroll, the data is transfered using DMA.

QUOTE(Omni @ Fri, 2005-08-05 @ 12:51 PM)
Question:  can this be used for the same type of reflection mappy-kind of stuff that's seen on the cars in Gran Turismo 1 & 2
[post=137941]Quoted post[/post]

[/b]



That's the idea.

BTW: you can apply multiple textures on Saturn, too.

If anyone is interested to make a demo, I'd give him my texture mapping stuff.