I'm still trying to get an overall grasp of CS, so it's possible that I've done something absurd. However, I'm pretty much lost.

For testing an experience purposes, I've added a mesh (a simple block with brick texture) to the "terrain" example. At first it didn't show at all, until I did some experimentation with the custom renderloop and various shaders (after reading the parallax example). At this point, it all works perfectly, except I can't scale (or tile) the texture that is on the mesh.

Here's a (possibly) pertinent snippet of the world xml:

...
     <shader><file>/shader/std_lighting.xml</file></shader>
     <shader><file>/shader/parallax/parallax.xml</file></shader>
  </shaders>

  <materials>
    <material name="Brick">
      <texture>box</texture>
      <shadervar name="tex normal" type="texture">boxn</shadervar>    
         <shader type="terrain_base">ambient</shader>     
         <shader type="terrain_splat">parallax</shader>
      <shadervar name="texture scale" type="vector2">16,16</shadervar>
    </material> 
....

The end result (when I put in the mesh and relight the scene) is a correctly positioned box, with the correct texture on each side, but the "texture scale" line doesn't do anything regardless of what numbers I feed it. From experimenting with the same line on the materials used for the terrain, obviously the shader is functional, just not for this mesh.

Does the vector2 scaling and the shader set conflict?  Is there a better method to achieve the same goal?

Speaking of shaders, the documentation is pretty scarce. I would be willing to write it, except I don't understand it myself yet. What would be nice is a "documentaton trade" where folks can agree to document the stuff they understand in exchange for someone else documenting something that they want to understand. Probably too complex...

When I compare the two, I see that the Python version is using the Software Renderer, while the C version is using OpenGL. I hadn't thought to look through the code to find differences. Regardless, after changing this, I can see a significant improvement in rendering speed. In fact, I can't really tell the difference. There are other oddities. For instance, the camera doesn't move as quickly, and the sprite looks about 1/10 the scale. However, these are likely to be similar changes in the Python code from the original.

You definitely hit the nail on the head. Thank you for the helpful response!

I've been looking for a good 3Dengine for Python scripting. Did a little jig with Panda3D, but it doesn't support Blender imports yet, so I moved on. Looking around, the best choice seemed to be CrystalSpace, but there was very little information available. Regardless, I've had enough failed engines that I wasn't afraid to try one more. Besides, it has mirrors! You can't go wrong with mirrors.

So first, I looked for a binary so I could use it as a Python module. Nope. Bummer. Oh well, I had some experience with Ming and Msys. I'd compiled other 3d engines in the past. No problem. Well... after much frustration, 9 straight hours later, it was compiled correctly. I could probably write a really good article concerning all the things to doublecheck when you are compiling. I must have hit them all. Order of installation (first the libraries, THEN the ./configure) is critical, but after 6 hours or so, I wasn't thinking straight anymore.

Regardless, it works. I tried out the sample applications (walktest) and whistled happily. Next, I moved to the Python scripts and hit the next wall. I'm using a Windows machine, so settting the PATH for Python to find _cspace.pyd was very important. Eventually, I got the right combo. TADA... it sorta works now. Since I was interested in the "Pure Python" approach, I quickly moved to the second set of tutorials. Which don't appear functional. Perhaps a bug in the latest snapshot? Anyway, tutorial 0 does nothing. Tutorial 1 blips a quick blank window then disappears. I went in to the file and turned the script's debugging on, and added some more debug statements. The progarm breaks at the line "if not csInitializer.OpenApplication (object_reg):".  I put additional debug statements both before and after the statement to confirm this. The program just ends on this line.

So finally, Tutorial 2. It works. It works! I cheer! Then I go compare it to the same tutorial (simple2) in the main CS directory. It's slower than molasses! I expected the top-level Python code to slow down the program somewhat, but this isn't acceptable. By estimation, it runs at about 1/10 framerate. Such a simple program is visibly choppy on the screen. I don't want to imagine what it would do with a full-fledged game. I shake my head sadly. Either I'm doing something wrong, as evidenced by Tutorial 1's breakdown. Or, it just isn't meant to be. Or, perhaps it's just a problem in the current snapshot?

Does anyone have any advice or are other folks' experience with Python similar? If not, anyone have any luck with any of the other Python3d engines? It's not that I hate C. It's just once I switched to Python, I never want to go back.