Sorry your browser is not supported!

Actually internally each polygon is then represented as a submesh. I agree that I cannot think of any particular reason to do this for each individual triangle as it would indeed be wasteful however (and what kind of weird model would really need per-face textures? OK if it has a few that are shared among many faces, in that case all triangles sharing the same texture should be grouped into individual submeshes to limit the overhead of texture binding as TheComet suggests).

What I'm saying is, maybe the X-file format supports per-face texture assignments, but DirectX itself will hate you for it, because every time the texture changes you're changing the render state, that is, introducing another "pass".

So if your 200 polygon model has 200 different textures on it, it will take 200 passes to render it.

What is the point of that?

lets say you have a level with lots of polys.
You want to render it.
There are many textures in a level.
To render it you need to transfer vertices to the gpu, indices to the gpu and then render it.
When you render it yoo can tell direct x what polys you want to render.
So you would bind texture1 and tehn tell it to render some polys with it, then you bind texture2 and tell it render some more polys.


If you have 200 separate meshes you have to transfer vertices for each mesh, that's 200 transfers -> slow down. That's why instances where invented - if you have many meshes which are the same you transfer vertices and indices only once and render it many times.

So one mesh, many textures is very useful for rendering levels.
When you have moving objects then you of course need separate meshes for that.

But when you have many small meshes it's faster to combine them on the cpu and then render them as one big object (one vertexdata nad one indexdata transfer) because every time you issue a transfer you are stalling gpu.

One example:
a) 100 objects, each 10 polys
b) 1 object -> 1000 polys

b will render faster. In both cases you render the same amount of polys but in first case you tell gpu 10 times to prepare for receiving vertices and indices -> slow down

There is no "submesh" concept in directx, only vertex and index buffers. You use DrawIndexedPrimitiveUp to render polys. You tell directx from which index to start render and at which index to end render

That sounds unlikely to me. Can you provide a reference?

Ok I was confused and then thought I wasnt, now I am again lol! I didnt realise bind was an actual term here, I assumed(yet again) it was meant in the literal sense ie like uv mapping all those textures internally as 1 - I didnt raise this last night as I took comets word that dbp uses limbs instead of submesh, yeah ok I already checked this but i was super tired when reading and just super confused myself. I have to learn to put the keyboard down once in a while. So by "bind" - is this a texture draw call?

Clearly am back to being confused, no surprises there! Part of me is thinking I wont get answers unless I get into direct x dev kit..which would mean not finding the limit for

certain for quite some time as it doesnt look easy at 1st look.

What I meant by submesh is that when you check out model editing package forums/tutorials the term is used a lot. I have also seen it referenced as subset but they tend to avoid this as subset term is used elsewhere. So when you follow instructions in tutorials the end result of what they refer to as submesh in dbp is multitexturing a mesh without using additional texture stages. ie faces per texture.

In terms of 200 poly and 200 textures - I dont believe anyone here was actually going to do that but merely use it as an example to get the message across? I certainly wasnt, am looking at a small number per zone of my goal test project. My real "need" in looking into this is down to batching smaller numbers of objects at LOD1 then combine 4*this number of objects at LOD2 and 4* this amount at LOD3. This coupled with the need to only load mesh data as few times as possible. Attached image is a rough layout of the lod levels where the surrounding 9 tiles where the spehere is centered at LOD1 would be hidden and individual objects used(LOD0). It works fine in tests with many tree placeholders on 1 diffuse atlas for all lod levels in the test, allowing for indivdual tree meshes across the board but loading indivdual textures in this manner would take forever. And of course then there is combining them for each LOD level.

Now I can do the tests with just the diffuse using "submeshes" but the second texture stage onwards would all have to be atlas`s again without being able to utilise a second grouping of "submeshes". Obviously I will still be using atlas`s to some degree but as 1 zone at lod 2 contains 4*lod 1 objects combined, switching textures per zone is only going to work if I can preprocess the media. I can live with no submeshes at texture stage 2 but it will limit how close to the camera i can make Lod changes as the second texture stage uvs would not be as good quality as first texture stage.

ok I havent explained this very well, hence why I opened the thread to specifically deal with submehes so as to a)find a useful way to produce the media and b)find out what the limitations of submeshes are. Dealing with the x format solved a) to some degree, so now Im focusing on b) - I can live with what I have so far - and may have to - all depends on what the limitation here is. If I had not lost my HDD`s I would upload the test project for sure, but I can`t and I am still rewriting it, in fact I stopped rewriting it when i saw the comments on how we can fix dbp thread so as to check this out so that should it prove useful I wouldnt have to do a second rewrite. So why am I mentioning this? So nobody asks me lol as this is best you might get in terms of an explanation from me!!

This is why i cant find anything then! I had been exasperated when searching msdn looking for submesh and subset! A lot of the time google has not been a good freind XD
So as things stand I will give this more thought now things that I thought were clear cut have been jumbled up once again! I would really appreciate it if we could do our best to stick to known facts(well ok, I to am guilty here) rather than folk saying this is the case then using words like "think", "not sure" at some point afterwards. This is all very very interesting and fun and I do appreciate all the comments and info regardless

Edit Note to self turn wordwrap off in notepad before copying and posting!!

@Brendy Boy
You're talking about uploading vertex and index data to the GPU, I'm talking about why anyone would use per-face textures.

Uploading textures to the GPU is way slower than uploading a few vertices, especially when you can instance the same mesh multiple times.

I would if I could find any concentrated information about how data is given to the GPU, but it's all scattered around in hundreds of tutorials.

Would you agree that if I had an object with 200 faces and 200 textures (one for each face), and each set of 3 vertices making up a single face all have their own independent texture coordinates, every time I render a face the render state changes?

Because that's basically what Brendy Boy is saying.

no, it's a state change. Draw call is when you actualy render the mesh.
Setting matrices, textures, shaders are state changes. The more state changes the slower the game runs. I think i read somewhere that texture state changes and vertexdata uploading to the gpu are the most expensive state changes.

Each draw call can use only one texture in each layer so if you want to render 10 polys where first 5 use one texture and next 5 second texture you would use 2 draw calls


here's something about draw calls

Actually textures are stored in the VRAM (on the graphics card) most of the time, meaning you don't have to transfer more than an identifier (like a pointer) and some information about what resource register to bind it to. It can be assumed that the graphics driver does a bit more work behind the scenes, but that is essentially all it should "need" to do.
In the same manner, vertex data is also stored in VRAM and won't be continuously "uploaded" to the GPU in anticipation of a rendering operation unless the VRAM is full and you have to do memory swapping (in which case yes, it would obviously be very slow).

A submesh is just some notion of a smaller part of a larger mesh and was used to describe the fact that your mesh data would have to be split up into several draw calls (one per "submesh") in order to draw different parts of the same mesh with different textures.



You can only bind textures to the shader pipeline between draw calls. As such, if you want to have a unique texture (at the same stage) for each triangle in a mesh you would have to split up its vertex data and do 200 separate draw calls, or you wouldn't be able to change the bound texture. This is a hard fact in DX11, I cannot imagine an earlier version would be less restrictive about it.


@James H: Care to elaborate a bit more on your problem? It isn't impossible it can be solved in a different way than what you might have planned.

Rudolpho It will take me some time to put into words and pics, my biggest problem in life in general is being able to communicate my thoughts. May be day or so as I have real life stuff going on atm, but I will, thanks this aside I have now gotten far to interested in the limits to simply drop it now XD I just have to know!

Brendy boy - your trying to break my brain right?!! LOL I cant pretend I fully understand the info from the link and the batch batch batch pdf referenced in the link but I do understand to a small degree some of it(certainly makes some sense with some bf4 issues I have). Will have to go through this many times before I can identify what I dont understand. I cant remember where I saw the term "texture" draw call but looks like it was misinformation as Ive been under the impression it was a seperate thing when coupled with the fact statistic(5) in dbp is detailed as a primitive draw call(why would lee call it that specifically?), thinking along the lines I must add them together possibly.

I think one of the biggest issues here for me is when it comes to the "p" in dbp they needed to add another "p" for psychic!!

@Rudolpho
Thanks for making that clear.

when you render something in directx you call a method called "DrawIndexedPrimitiveUp", probably because of that word primitive

@James: Ah, yes no hurry for me, take your time


DirectX refers to faces as "primitives" so this usually means to draw connected vertices in a triangle fashion, but a primitive can also be other shapes like lines or quads.

@Brendy boy, TheComet and Rudolpho

Thanks for clarifying the submesh/draw calls/render state issue. I'll put that to the test some time to see what effect it has. It hadn't occurred to me that there was a draw call problem there at all.

Thanks for the explanations, more things starting to make sense now
I will review all material here again and again until I`m happy I have a good grasp of it all. Thanks to all

Rudolpho - have done an explanation in odt and pdf in a rar file attached, 7 of the 9 pages are code which you don`t have to look at but its there in case it helps, if you dont have pdf viewer then you can open the odt file in Word.