I'm trying to make a level rendering system using a single mesh for the map geometry. I'd planned on using vertices' W coordinate as a texture ID and then passing multiple textures to the shader using device->SetTexture. I got this far before I realized that you can't index a sampler array using a variable, which I'm very upset about as it invalidates my entire plan unless I want to make a massive mess of elseifs... is there some better way to do this? A 3D texture would work on the shader side of things, but it'd be harder to set up in my C++ backend. I just want a way to put multiple textures on one mesh, determining which texture to draw using data from the vertices. Because they're tiled, I can't just bake them all into one texture either. I wish there was a way to convert an array of sampler2D's into one sampler3D, but I'm sure there isn't... any other ideas?

I'm using C++ with DX9. No FX, just shaders and SetShaderConstantF and such.

I guess I could use a texture atlas with manual tiling, but I really would prefer to use separate textures if possible. I kinda think that if I'm willing to take the time to make a texture atlas generator, I might as well just make a 3D texture generator instead, since then I could use the W coordinate like I originally wanted. Though I did just test a massive switch case and technically that works, but only with up to 16 samplers, which probably won't be enough for an entire map.

That's true, I hadn't thought of frustum culling. The main reason I wanted it to be one mesh is because the collision response is easier to calculate that way and it's also easier to export from 3dsmax in one piece rather than several. Cutting it into one mesh per triangle would be ridiculous, and I'm not really sure what would be a good intermediate step. I mean, technically I could make all maps using an additive scheme like the interiors in the Elder Scrolls games, using nothing but single-texture single-mesh objects all put together into a world... but I'd planned on using Valve Hammer Editor, which I'm very used to, exporting to DXF, opening them in 3dsmax and exporting to my format, then texturing them in an in-engine tool with special W coordinate stuff. It sounded great until I hit this obstacle...

EDIT: to restate-- I'm not sure where to divide a mesh up if I were to do so-- dividing it based on texture wouldn't help with culling, but dividing it based on culling wouldn't help me texture. Technically I could divide it based on culling and then use a texture atlas, but that's actually quite a bit of work...

My collision engine does allow for a mesh to have a separate triangle list for collision, but it's still 1 physobject per mesh. I pretty much code everything from scratch except DirectX and Windows, so I don't use third party libraries. It's just an Ellipsoid/Polygon intersection test, I don't have Poly-Poly collision yet and when I do it'll probably be convex polygons only. For now, though, the map file has one mesh that's already fairly low poly, and I've been using the same mesh for rendering and collision because of the fact that it's a hammer map exported into my format.

Technically if I were to take your suggestion of using a single mesh for collision and several for rendering, I would just have to give the collision mesh a nonrenderable mesh and set its physics mesh to the one I had been using, then fill the scene with a lot of non-physics objects set up for culling. Still, though, I'll have to figure out what criteria to cull based on-- I mean, I don't have any sort of area portal system and I'd rather not manually separate them in 3dsmax... though technically that is an option. Another idea though-- I did manage to get a W-based texture selector working using a massive switch case, but it only supports up to 16 textures because of the SM3 sampler limit. However, if I were to chunk the map into a bunch of culled pieces, it'd be easy to have less than 16 textures per chunk at least.

So to summarize, I'm thinking I could turn off rendering on my big one-piece non-textured map file, split it into a bunch of non-physical pieces, multitexture each of the pieces separately, then draw the pieces separately using frustum culling. Technically though if I make a few changes to the collision response I don't even need the one-piece physics object and I can just make the chunks physical as well. Do you see any problems with the switch-based per-chunk multitexture idea? Is swapping out a bunch of samplers per pixel shader painfully slow or something? It sounds like it would work to me, but that massive switch case does make me feel a little nautious

I did look into BSP's and such, but my main weakness is writing an editor for something rather than actually writing the system itself. My engine is very strangely coded and even the "easy to implement" things like bullet or lua would require far more work than usual to make them play nice with my system. I won't go into detail, but I have a very polymorphic exe that loads different scenes (including editors) depending on the "map file" you load. And the map file is not just geometry and entities-- it's basically an entire program, and may or may not have GUI's, physics objects, shaders, textures, etc., all potentially embedded inside them. I also have my own compiled scripting language specifically for creating these map files.

I guess my wacky interface wouldn't really be too much of a roadblock for implementing a third party tool if I really needed to, but I really just prefer making it myself because I can understand fully how it works. If anything in my engine is slow, I want it to be my fault and my fault only. I don't take the beaten path with coding, and I never have... I really don't know why. However, this doesn't apply with editors, and I'd much rather figure out a way to texture an exported hammer map than make my own new map editor. I suppose an additive mesh system suits the engine better the way it's built anyway-- the main reason I want multitex is because I want to be able to use hammer's excellent brush toolset, and the easiest way I can find to render it is using multiple textures.

I guess it's just time to give up on hammer and use static mesh pieces to build maps, that seems like it is still the best alternative to hammer and multitex.