I need more U/V coords - I think!
Blitz3D Forums/Blitz3D Programming/I need more U/V coords - I think!
| ||
I've been tinkering with a simple tile based environment. Each tile is a separate object and has a base texture and two effects textures for highlighting and suchlike. Each texture is an animtexture so I can select the tile image & two layers of effects for each tile with:EntityTexture this\t_mesh,tile_texture,this\t_texture,0 EntityTexture this\t_mesh,tile_mask_texture,this\t_mask,1 EntityTexture this\t_mesh,tile_decal_texture,this\t_decal,2 This means that each polygon has 3 sets of U/V coords even though they are all nominally set to the same values by me. Under the hood each partial texture requires unique u/v's. Now this all works but having hundreds of separate objects is slow and I'd like to be able to have multiple tiles in a single mesh. This means dropping animtexture and managing the u/v's myself. Not a problem but as far as I know, I can only have 2 sets of u/v coords per vertex - but I need 3. Is there any way around this? |
| ||
| Maybe PositionTexture, RotateTexture and ScaleTexture are enough? You can do this indvidually for each texture, but as I have no clue about what you are trying to achieve, it might not be what you are after... |
| ||
| You may be able to overlay another mesh (and mess with the render order) to simulate more that 2 UV sets. But, as Fredborg says, without knowing more its hard to fathom. |
| ||
| Many polys will share the same 3 textures, but each poly will need to display specific portions of those textures (tiles within a tileset). Currently, each tile is a separate object (mesh) and therefore separate surface. By merging multiple tiles in the same mesh (sharing surfaces) I can get a potentially massive increase in rendering speed. |
| ||
| If you are trying to do what I think you are, you can get away with a single uv set, and Position+ScaleTexture. If you are using quads of some kind, set the vertex uv's to the full range (0.0,0.0 for the upper left hand corner, 1.0,1.0 for the lower right hand corner). Then you should be able to scale and position the textures to display the individual tiles. You may need to load each texture indivdually for each tile, but it won't take up much extra memory, as they will all share the same bitmap data... It may get messy, but it just might work :) |
| ||
| I don't think that will help. I won't be able to pack each 'tile' onto the same surface will I? |
| ||
| Maybe I'm rambling, but can't you generate a bigger mesh and use a larger tile-based texture on it instead? Then you do the tiling in your texture instead of using meshes. |
| ||
| I have been pondering using the idea of a large mesh and tiling the main texture with smaller texture brushes too. But I am wondering if it is possible to change sections of a texture when it is already applied to the mesh. Sort of painting the mesh with a new texture, in small areas using the uv coords. Does anyone know if this is possible. And if it is, does anyone have a small example of how it's done? |
| ||
| I don't want to use a big texture, I have a system up and running but I want to optimise it. It looks like the limit of 2 sets of u\v's is going to prevent me from doing what I want. Any idea why Blitz has this limit? |
| ||
| Because Mark was worried about how much memory >2 user-defined uv sets would use up. Mind you, that was a few years back now, and I doubt whether the extra memory useage would be so problematic now. |
| ||
| REALLY? thats a terrifically trivial reason now! Mark, there can be *no escape for youuuuuu* |
| ||
| I reckon we should go to 8 sets. One for each texture layer. |
| ||
| A third set off u\v's would come in really handy when doing projective shadows on a lightmapped level. So yes, please! |
| ||
| Madjack I fourth that - for Peter's reason. |
| ||
| Yes, it would be nice... perhaps if there are little problems with latest update, this could be added in as a little bonus along with the fixes? :-D |
| ||
| John, can you explain what your mask and decal layers are. If the decals use alpha blending what is the mask for? |
| ||
| Hi, Yeah, its a memory thing. Each set of tex coords takes up 2 floats=8 bytes, so increasing UVs from 2 to 8 would increase the size of each vertex by 48 bytes, which would eat up a considerable amount of vidmem for scenes with complex meshes. Whats really needed is a way for different meshes to have differing numbers of tex coord sets, but this is non-trivial. |
| ||
| If we had DXTC (texture compression) the extra memory overhead would be much less of a worry. Just my 0.0002 drogna. |
| ||
| From Evak: Without Extra UV’s in order to do bad looking multitexture blending you need to add extra geometry and cut it into the existing mesh and UV map the polys separately with multiple transition textures so I’m not sure the saving vid mem really works out in the end. If you want say a brick to grass texture you will need a minimum of: A brick texture A grass texture A corner transition A side transition texture More textures to make it look more natural and less tiled, they all need to be 24bit and similar pixel scale to they align fairly well. That’s a minimum of 4 textures 4/surfaces just for that transition from grass to brick. With other engines that support multiple UV’s you only need: 1 brick texture 1 grass texture Both 24bit And 1 8 bit greyscale mask texture. You can blend multiple textures independently of one another allowing you the most freedom and the mask can be shared with multiple texture combinations, so you may only need one for an entire terrain. So currently that’s 4 surfaces and 4 24 bit textures vs 1 surface 2 24bit textures and 1 8bit texture to get a much cleaner result, and no extra polygons to get the transition to conform to the shape of the area the transition goes to. |
| ||
| skidracer, mask & decal is just my own jargon. The mask layer is set to multiply the decal layer is set to add. I can create all kinds of highlight effects with this setup. Not just straight decals. I'm using animated sequences of colours an patterns to highlight areas for example. But that said, I didn't realise I could use an alpha blended decal. Is that what blend mode 1 is for? Mark, Any chance of going to 3 or 4 sets? Is this just a matter of changing one number and recompiling? Could this be something we choose ourselves when we start up the 3D mode? It seems odd to allow 8 textures but not allow full control over how they are mapped. |
| ||
| Is this a non-starter then? |
| ||
| "With other engines that support multiple UV’s you only need: 1 brick texture 1 grass texture 1 greyscale mask texture" You don't need more than 2 UV's to do that, and you can do it in Blitz. It requires two surfaces, but from what I know of how texture blending works, it would require two surfaces in any language/engine. Each surface has two UV coordinates. So you use one for the texture, and the other for the mask. Put down first surface with no mask. Put down second surface turning on vertex alpha, but not changing vertex alphas, and set alpha texture to first texture layer of second surface. Set blend of texture to alpha I think. Then set second texture unit to multiply the second texture with the alpha texture. If that doesn't work, then you can use an inverse alpha on first layer in second textuee channel and set it to multiply, and then set second texture layer in second surface to the alpha texture and set that to multiply, and then se the second layer to add blend mode, and that will blend them. |
| ||
| I think a couple of more uv coordinate sets would be great! Even if you can always find a workaround, it still would be nice to just have it :) |
| ||
| I don't know. This sounds to me like people being lazy. I mean, I think it is so cool that Blitz even supports two UV sets; most other engines I've used only allow one UV set. More UV sets would be useful certainly, but so would a lot of things. Just look at the feature set of any major 3D art package for plenty of examples of stuff Blitz could be doing. The important question is, do the benefits outweigh the costs? From mark's post it sounds like the costs are significant. |
| ||
| Eh? What has laziness got to do with it? I just want to control the textures I'm using. sswift, perhaps I'm being ignorant but what's this '2 surfaces' business? How do you overlay geometry without getting Z-fighting? |
| ||
| "How do you overlay geometry without getting Z-fighting?" Enable the vertex alpha flag on the surface. Flag 32. Even if you don't have any vertices which have alpha, Blitz will draw the entity last with all the other entities that have transparency. And on the surfaces with transparency compare each pixel against the zbuffer, but not write zbuffer values. When comparing against the zbuffer if the distances are equal, which they will be if two polygons overlap and have their vertices in the exact same locations, the new overwrites the old. As far as I know, Z-Fighting is an issue only when you have seperate entities that can draw in different orders depending on how they get sorted. When you have two surfaces in ane entity, the surfaces are always drawn in the same order, even if one of them has transparency. The first surface added is drawn first. So to do an alpha blended terrain, you'd make an entity that has two surfaces. The first surface would have two textures. The first texture would be your ground texture. The second would be the inverse-alpha texture, where black is where you want the second layer to show through. The second surface which has the exact same polygons as the first, has FX flag 32 enabled. That's the vertex alpha. Texture 1 would be the second ground texture, and texture 2 would be the regular alpha texture. And finally, the second surface would use add blending mode. So it's: Surface 1: Texture 1 multiply 1-Alpha multiply Surface 2: Flag 32, Add Texture 1 multiply Alpha multiply You can also do away with the alpha maps, not use add blend on the second surface, and use vertex alpha changes instead. And as I said, there MIGHT be a way to use a single alpha map only on the second surface, with no alpha map on the first surface. Unfortunately, from what I hear alpha maps aren't supported the same way on all cards. I think if you use them only in the first texture channel then you'll be okay, but I don't know what happens when one multiplies a texture in a second channel with an alpha map in the first channel. Is the alpha map applied to the final alpha of the image? I don't know. But I do know that you couldn't enable the alpha flag on that texture channel cause you need it to multiply with the lower layer if you want any lighting to work. Oh, and I'm not sure if fogging will work with the first method I described with the multiplied alpha maps. The adding of the second layer to the first might mess that up.... Then again... If you set ONLY the first layer to have fogging enabled... It just might work... If the fog is lighter than the texture color... If the fog is black.... Then... The second layer wouldn't get fogged. I think. Vertex alpha I know supports lighting and fogging and all that good stuff. It's just alpha maps I'm not so sure about. |
| ||
| Interesting. Cheers sswift. I'm still hoping for more U\V's though. ;-) |
| ||
| Oh yes. Mark, if you are reading this, in my original post I point out that the vertices must have 3 sets of U\V's internally. Am I wrong? |
| ||
| If you apply three textures to a mesh, all you are doing is using three texture units. That as far as I know, has nothing to do with which set of UV's each texture references. |
| ||
| Yes but in my example, each of those 3 textures has unique U\V coords as each is a small tile from a large tileset (an Animtexture in Blitz). So INTERNALLY those vertices have 3 sets of U\V coords. |
| ||
| I'm a little confused. When you say the vertices "must" have 3 sets of UVs, do you mean that they do currently and Mark simply isn't giving us access to the 3rd set, or that you need a 3rd UV set to accomplish the effect you are after? I would assume the former except your stressing of "internally" indicates you mean the latter. |
| ||
| My polygons currently have 3 textures. Each is actually a small section of a larger texture. As I can select all 3 sections freely then 3 sets of u\v's *must* be in use. Because I'm using animtexture I personally set the u\v's in the 0-1 range to show the whole texture and blitz works out the real u\v's internally. This system only works with each of my tiles being a separate object. But I want to have multiple tiles in the same mesh, sharing the same surface. For this I have to do manually what Blitz does for me, and thus I need access to more than 2 sets of u\v coords. |
| ||
| John, i really think you can do this with scale texture and position texture. Each texture mayb have it's own UV co-ords, but they are layed out the same essentially. |
| ||
| Actually, I think Blitz splits an animtexture into separate texture images when loading it. Assuming that is correct then no, there aren't separate UV sets for each section of an animtexture. Hopefully Mark will confirm or refute. |
| ||
| Ross C, I don't think I can. I need multiple polys in the same surface to show different parts of the same texture. jhocking, If it DOES split the texture up then I'm only using 1 set of U\V's. Doesn't solve my problem though. |
| ||
| Of course it doesn't. I was addressing your question, "Am I wrong?" In particular, it sounds like you're convinced adding support for additional UV sets would be trivial, but mark's post indicates otherwise. |
| ||
| Mark said it would be non-trivial for different meshes to have different numbers of u\v's. It would be trivial to increase the global number. |
| ||
| I'll try and fix up something tonight, see if it's the same :) |
| ||
| True, but he also explained why it would be a bad idea to increase the number of UV sets globally, because of the increased memory usage. While some might argue that the memory cost isn't crippling (and that's debateable,) I would respond that any wasted memory (since, except for the once-in-a-blue-moon situation that you are using all 3 UV sets, the additional memory used is wasted) is bad, especially considering how much of a premium video memory is at already. |
| ||
| And HEY I'm of a different opinion. |
| ||
| Um, so what's your point? That yours is the only opinion which matters? I'm afraid I'm not following you here. ADDITION: Let's cruch the numbers. Let's say you have a level with, oh I don't now, 150,000 polygons. At 8 bytes per polygon, that's an extra 1.2MB from adding just 1 more UV set. And unless you're using the 3rd UV set, that's wasted memory. 1.2MB gone for no reason is a lot, and 150,000 polygons isn't even a huge amount. 2ND ADDITION: Oops, I wasn't even thinking about the fact that the number of vertices is always greater than the number of polygons. It's 8 bytes per vertex, not per polygon. In most cases the number of vertices is twice the number of polygons, so double the wasted memory I calculated. *** I definitely agree that having additional UV sets would be useful. But unless we can have different numbers of UV sets for different meshes, I just don't feel the minor benefits outweigh the costs. |
| ||
| My point is I'd like this feature implemented. I don't see how repeating what 'Mark said' adds to the thread. On a more general point I'm interested in learning how all this stuff works. I THOUGHT that the vertices had 3 sets of U\V's - it transpires that perhaps they don't. |
| ||
| By that reasoning jhocking lets go back down to ONE u\v set. Or not make it controllable at all. Limiting it to 2 sets is an arbitrary (but understandable) decision. It's also a decision made a while ago; specs have increased significantly since then. More to the point, I think having 8 textures and not being able to fully control them is very limiting. I understand that making it variable per mesh is non trivial but it may be possible to set a global variable when you start the graphics mode. Or at compile time. I'm prepared to bet that most people aren't even using two sets, but once you start to make use of multi-texturing then you quickly need 2,3 or even more. Sswift has offered a very practical solution, which is probably the one I will use; but it still seems a shame to add more geometry to do something that the hardware can do in a single pass. I don't think 1.2 meg extra for an 150k polygon scene is very much at all. A couple of large textures could use that much. |
| ||
| "By that reasoning jhocking lets go back down to ONE u\v set. <snip> Limiting it to 2 sets is an arbitrary <snip>" Not at all. In the case of 2 UV sets there are pretty significant benefits going from 1 to 2 UV sets, benefits which outweigh the cost. And as for how many people are using 2 UV sets, bear in mind that the most common lightmapping approach requires separate UVs for the main textures and lightmaps. Thus anyone using lightmapped levels is using 2 UV sets. I didn't quite understand what you meant by "global" however. I took that to mean all meshes will have 3 (or more) UV sets all the time. Your suggestion that one could establish the number of UV sets used when starting the graphics mode or at compile time makes a lot of sense. Make the number of UV sets controllable, just not per mesh. Thus people who don't need additional UV sets aren't saddled with the increased memory consumption, while people who do need additional UV sets have that option. *** "A couple of large textures could use that much." Exactly. That's a couple fewer textures that you can use. Also, I realized I made a mistake and the additional memory usage for a 150,000 polygon mesh would be 2.4MB, not 1.2MB |
| ||
| The ability to globally specify extra sets of UVs at runtime would be useful. Since .B3D already supports it :) |
| ||
| "A couple of large textures could use that much." Exactly. That's a couple fewer textures that you can use. Also, I realized I made a mistake and the additional memory usage for a 150,000 polygon mesh would be 2.4MB, not 1.2MB Very bad reasoning. Larger textures kill performance. |
| ||
| Mark would do well to change the b3d file format and make it so that each mesh can independently hold differing numbers of texture coordinates. This means no waste, and jhocking's argument is completely invalid. Plus using large textures is pretty much a no-no without texture compression. My card chokes on anything bigger than 512x512 and it can handle 2048x2048. So either introduce tex compression or sort out the uv thing, because Blitz projects are slowly moving out of the amateur into the professional as more tools and techniques come to light. |
| ||
| Yes, texture compression would be a god send :) |
| ||
| Mark would do well to change the b3d file format and make it so that each mesh can independently hold differing numbers of texture coordinates. It already does, we 'just' need Blitz to support it. I don't think that setting the number of texture coords as a global option is a good idea, exactly because a B3D file can have anything between 0-8 sets. |
| ||
| I still think going straight to 8 sets makes the most sense. |
| ||
| I guess Mark can just make it support unlimited UV sets, just as it supports unlimited entities. 2 UV sets doesn't neccessarrily means that they have to be used at same time, so endless sets shouldn't be that big problem. |
| ||
| Rob, "large textures" is of course subjective. I think 512x512 textures are large. One 512x512 image is around 800KB, and that's without an alpha channel. As for changing the b3d file format, what Peter said. The b3d file format already does that, that isn't the issue. The issue isn't storing additional UV sets, it's using additional UV sets in real-time. And in case you didn't notice, I eventually figured out and agreed with John. When I thought he meant forcing everyone to be saddled with additional UV sets all the time (and thus the additional memory consumption,) I was against that. But when I realized he meant making the number of UV sets Blitz uses selectable when initializing the graphics mode, well there's no reason to disagree with that. As you said, in that case there's no waste. Indeed, the change wouldn't break any existing code because setting the number of UV sets could be optional. If you don't explicitly define that it'll default to 2 UV sets, what Blitz currently uses. |
| ||
| I very much doubt anyone will use 8 sets of UV co-ords, but if it's selectable, then go for it. |
| ||
| Just the UV coord sets doesn't use much memory. Actually those coords is just a few arrays, and nothing more. It's the texture you assign to the entity, that uses the UV coords to know where on the model the specific parts of a texture is, that uses memory. |
| ||
| ChrML, have you read mark's and my posts? He pointed out exactly how much memory each UV set consumes per vertex, and I calculated that's around 2.4MB for each UV set on a 150,000 polygon model (fairly average for a level.) If you're not using the UV set, that's a lot of memory wasted. Anyway, it turns out to be a relatively moot point. I misunderstood what John was talking about. |
| ||
| Hmm, 2.4MB memory isn't really much when ordinary PC's today have 512MB memory (atleast very few have less than 256MB). But that's not a good enough reason to limit it to 2 sets. I think that should be up to the Blitz programmer :). That's my opinion. |
| ||
| ...and in case we talk about the vidmem (idunno), then 2.4 isn't really much there either (2.4 of 64/128mb). |
| ||
| *tears hair out in frustration* Yes, I agree, it should be up to the programmer. What I was disagreeing with was my erroneous take on John's suggestion, that it NOT be up to the programmer, that we all be forced to use a higher number of UV sets. And if you don't think wasting (remember! if you aren't using the UV set then it's completely wasted memory) 2.4MB out of 64MB on the videocard is a big deal, I'm just at a loss for words. Cripes, nevermind. I don't know why I'm still posting, I realized I don't disagree after all because the suggestion was to make it selectable. |
| ||
| I agree, but I still think it's up to the programmer :). |
| ||
| LoadMesh() should by it self choose the correct number of UV sets, or it will be a mess. |
| ||
| Again, -support for more uv channels -support for texture compression -a case of beer for mark |
| ||
| Hey, texture compression is a good idea. The textures loaded into the memory should be compressed (if possible in the vidram), and decompressed realtime. |
| ||
| Just wondering if there's any progress on this front. I.e planned for a future update, or is this officially not going to happen? (At least for b3d) |
   |