Multitexturing and decals?
I just read through this thread where these techniques were recommended for texture variations/skids etc - http://www.polycount.com/forum/showthread.php?p=729964
Could someone please explain what they both mean?
Also, if these are more next gen techniques, what techniques would be used in say a PSOne or DS game? Which are comparable to the engine I'm working on, a browser based software renderer.
Some racing games on both consoles have a surprising amount of texture variety and AO etc (for example RR4 on the PS1, and Sega Racing on the DS) - given their absolutely tiny amount of RAM.
What kind of techniques could be used to cram a track full of AO, plus handle skidmarks etc on a lo-fi engine (or bullet holes etc), without using a plethora of textures?
Or even something like Burnout 3 on the PS2, seeing as the PS2 has 32 megs of RAM plus only what, 4 megs of VRAM? It absolutely amazes me just how much texture variety each track has, with the road itself being packed with AO, plus skidmarks etc. To my eyes it's mostly unique UV space, with very clever use of RAM, and possibly lower res textures than they appear. But now I've heard multitexturing decals mentioned, maybe not
Cheers,
RumbleSushi
Could someone please explain what they both mean?
Also, if these are more next gen techniques, what techniques would be used in say a PSOne or DS game? Which are comparable to the engine I'm working on, a browser based software renderer.
Some racing games on both consoles have a surprising amount of texture variety and AO etc (for example RR4 on the PS1, and Sega Racing on the DS) - given their absolutely tiny amount of RAM.
What kind of techniques could be used to cram a track full of AO, plus handle skidmarks etc on a lo-fi engine (or bullet holes etc), without using a plethora of textures?
Or even something like Burnout 3 on the PS2, seeing as the PS2 has 32 megs of RAM plus only what, 4 megs of VRAM? It absolutely amazes me just how much texture variety each track has, with the road itself being packed with AO, plus skidmarks etc. To my eyes it's mostly unique UV space, with very clever use of RAM, and possibly lower res textures than they appear. But now I've heard multitexturing decals mentioned, maybe not
Cheers,
RumbleSushi
Replies
A few thoughts and ideas on this:
The trick is to use a 2nd UV channel for all objects together in 1 layout so that each UV shell has its unique UV space in that channel. This allows you to mark and place unique details on this map.
so with skid marks I would do something like this:
for decals just a quad on the surface, only complicated stuff like shadows and alike I would address with a 2nd uv channel and composite rendering as it eats more processing power (on flash and alike low platforms).
Another trick and this is more a performance thing is to use LOD textures and models to get a better stream and constant good frame rate - that way you can spend more objects without really sacrificing performance.
Judging purely from the words, that's pretty much what I guessed, but I just wanted a confirmation/explanation
I have to admit though, I didn't know that before, that dynamically added textures were just a plane overlayed with textures drawn on. Makes sense of course, and they probably have a slight depth bias to prevent z fighting.
I've experimented with drawing on walls etc, but just used unique UV space.
I could well use the decal method, the only thing is, because there's no 1 bit alpha in flash, you'd just have to use a transparent texture, which renders slower, but could still be worth it.
I wondered how it was done before, say bullet holes on an obviously tiled wall etc. I just assumed that each polygon that was the lucky recipient of a bullet would be assigned a unique tile piece of the same texture that could then be drawn on, rather than a plane stuck on top.
I've also implemented LOD textures and models, but I'm conservative with the textures, so as not to increase draw calls and RAM usage, which can end up having a negative impact on performance.
I have to admit it surprises me that they would use a multi pass render for something like shadow maps/AO with a blend mode, because that is slow, and of course the unique AO/shadow map is still going to use some RAM. I guess the RAM saving is worth it for a lot of hardware, rather than wasting RAM on lots of baked textures.
What do you think would be the method used on something like the PSOne or DS or N64? On machines like that, both rendering juice AND ram is extremely precious. It seems like lots of baked textures would be far too much for their tiny amount of ram, but also a multipass render would have too big a hit on rendering performance.
Last job I worked with a really good one who knew the Wii fixed-function graphics system really well, so we were able to do some really cool things that weren't readily apparent, simply because it took an unconventional thought process to figure out how best to approach things.
One way to reduce the cost for floating mesh decals is to disable Z-write and/or Z-read. As long as you know the order the meshes are being drawn, those surfaces don't need to spend the time querying the z-buffer.
Also, depending on the hardware, multitexture can be done all in one pass. It's not always a slowdown to use.
As you can imagine, many things are very limited.
I render per polygon, but those polygons can be rendered in batches, all in 1 draw call for example if all the polygons in the render list share the same texture.
Doing multipass rendering with a blend mode would be far too slow in my engine (unless it was literally the odd polygon here and there, but doing that for say most of a track would cripple the performance).
What kind of clever things did you do on the Wii Eric?
I hear ya about the memory limits. Have to be creative! And really dissect the competition.