I'm a college graduate with a degree in computer science and I've developed software professionally for the last 10 years.  This stuff makes me feel feebleminded.  I've been toying with the game idea since college 10 years ago (C/C++ DirectX/OpenGL) and every time I pick it up I get stuck in a theoretical haze of math or physics and put it away for 6-9 months until I feel froggy again and think, well I'm smarter now!  Well no I'm not!  Anyways, I've been toying with various high level things, and now I've forced myself back to basics, (draw a box and texture it, got it, good!)  Now I'm going to put my sky cube together and I thought, gee, I'll texture my box on the inside the same way I did in my primitive, back to basics project......this is where I got off track.

There seem to be several ways to do each task in xna, and I assume each one has various plusses and minuses and various things are there because "that's the way it was done in the past" and other things are there because "that's the way things are moving with future hardware, etc."  So I thought, well I'll make a ContentProcessor (based somewhat off of TerrainProcessor) to load the image from here ( http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Build_a_skybox ) use my newly aquired texture mapping skillz and texture map at load time then render it as a model instead of as primitives  ( is this right?, which is more efficient?  plusses? minuses?).  So I ran into a fairly minor snag and while looking on the net for a solution I find the Random Chaos skybox example and check it out for good measure (http://xna-uk.net/blogs/randomchaos/archive/2007/10/15/generic-xna-skybox.aspx) and they have a cube model, a texture, and a shader and they use the HLSL texCUBE function to texture map the cube.  So, what's the best way to do the texture mapping in HLSL? in the Draw() method via materials?  at load time in my ContentProcessor?  I'm guessing this is really a cpu vs gpu thing, but is it all trial and error to figure out which is more efficient?  That sounds like a royal pain if so.

I prefer to build the skybox as textures + geometry in a modeling program, and do nothing special in the content pipeline or rendering, other than when to render it and how to treat the depth buffer.

The cool thing with that is that you can build your skybox as a box, or a sphere, or a dome with bits and pieces hanging down -- it doesn't matter. It all gets drawn as the background in the end. Just make sure to set the center of the skybox model to the location of the camera before you render it.

I get that aspect of things, and perhaps I should have made my question more generic...It looks to me like certain things like texturing can be done at load time, draw time, and gpu draw time (i.e. HLSL effect code), my question should have been what are the pros and cons of each and when is each one more applicable...I would think the gpu draw time would be the fastest and most tailored to the task, but the skybox wouldn't need the extra gpu time that say an explosion would, so shouldn't it be done slightly less efficiently in the regular draw code with primatives?  OR, should it be done in the LoadContent and/or Content Pipeline routines so as to gain a little efficiency, i.e. still happening in cpu, but everything is preloaded in memory.  That too raises the question of how much memory is reasonable to have loaded for say an xbox 360 (not to mention cpu mem vs gpu mem).  All of these questions aren't really specific to xna, but are relevant to any 3D app. 

So, back to my skybox ;)  Is a Model of a cube better than indexed primatives (with VertexPositionTexture)?  Is Texturing and drawing with indexed primatives any more/less efficient than a Mesh.Draw() method?  Should Texturing be done via HLSL texture methods like texCUBE, or by using a Material in the Draw code?  What are the preloading benefits/drawbacks when using the Content Pipeline, if any?  Or is it just data structure thing for simplicity?

Thanks for any help.

I think your questions show a bit of confusion how things work "under the hood."

Is a Model of a cube better than indexed primatives (with VertexPositionTexture)?

There is no difference. Internally, a Model is a vertex buffer and an index buffer with indexed primitives.

  Is Texturing and drawing with indexed primatives any more/less efficient than a Mesh.Draw() method?

There is no difference. Internally, the Mesh sorts triangles by materials, and issues one device draw call per material, because it needs to change the bound texture for each face.

  Should Texturing be done via HLSL texture methods like texCUBE, or by using a Material in the Draw code?

Texturing is done by the hardware no matter what. A 2D texture on the BasicEffect material translates to a tex2D() in HLSL function call.

Cube texture look-up is slightly less efficient than 2D texture look-up, because there is a normalizing divide (and a comparison) involved in calculating the actual texture coordinates in the texture unit. Thus, fetching each texel may be a bit slower when using texCUBE than when using tex2D. On the other hand, texturing with tex2D means that you need to re-bind four or five textures each time you draw the sky box (assuming the back face will never be drawn). Re-binding textures and issuing draw calls have fixed overhead. Thus, you may find, when you measure, that on your hardware, texCUBE will be slower on large displays (1920x1080, etc), because the per-pixel cost dominates. Meanwhile, you may find on your hardware that tex2D is slower on small displays (848x480, say), because the set-up cost dominates. Or you may find that there is no difference on an empty scene, but there is a difference on a heavily loaded scene. Or vice versa. It's impossible to tell from just a loose "what if" -- or, more accurately, I can sketch reasons for why either outcome would be true, depending on the specific hardware. Pick a target, and measure.

  What are the preloading benefits/drawbacks when using the Content Pipeline, if any?  Or is it just data structure thing for simplicity?

Once data is loaded into vertex buffers, it's loaded data. How it gets there doesn't matter for rendering. However, from a content creation pipeline point of view, it's always better to let artists (the ones doing the model creation) have as much control as possible, and reduce the number of times they have to call in a programmer to have some change made. That has to do with production efficiency, not rendering efficiency.

Thanks!  The under the hood aspects have been seriously bugging me.  This definitely gets me started.