Irrlicht Engine

My guess: Sampling itself should be same cost. Uploading texture needs more data, so that is slower. Creating mipmaps can be slower (but also only done once). Needing less texture switches (assuming you also use other blocks of same texture) will be cheaper.

The hard part: Avoiding texture-bleeding ...

Sorry, was a bit too tired yesterday to think about it. Also I'm using shadow maps, but haven't coded them myself, so take everything I say with a grain of salt.

In theory near/far wouldn't matter as light is infinite far away and you just want all shadows. In reality we have to struggle with the ...

Hm, do you still have an older version? With Irrlicht trunk rendertargets have functions to set/get the depthmap. Don't remember how Irrlicht 1.8 did it.

Ah yes - covering exactly how much you need is a bit tricky. But having a bit more won't hurt much.

I'm probably missing something. But Irrlicht matrix has the function buildProjectionMatrixOrthoLH which allows you to set the near and far plane and width/height. The world-view transformation is the same as for other cameras.

I sometimes use multi-texture render targets. Yeah... more memory. Thought those also have their troubles, especially in Irrlicht which doesn't allow masking per texture so far (so mixing fixed function materials with shaders is nearly impossible for that case as fixed function materials always ...

Sorry, need a bit more details to understand what exactly you are trying. Are you trying to pad the image so it keeps the original size but has some invisible alpha part? (I do something like that here: https://github.com/mzeilfelder/irr-playground-micha/blob/master/image_scaling_padding.cpp)
There ...

Nice, will it be open source?

You can call void IVideoDriver::removeHardwareBuffer(const scene::IMeshBuffer* mb). Thought worth it doing a quick calculation how much memory geometry really needs, might be unnecessary. Mostly it's the textures which take up memory.

If you don't render they won't be uploaded. IMesh/IMeshBuffer have a function setHardwareMappingHint. When using EHM_NEVER it will send the data over the bus each frame. Which can make sense for animated meshes which are changed each frame on CPU or very small meshes. Which seems to be even default ...

Thanks, the shadows look good. I don't think the camera is orthographic after loading the roads still get smaller in the back. Looks either like very wide fov or maybe some messed up viewport.

Yeah - as long as the polygons-crossed count is ok it might work. Maybe transparency messing with the stencil count, not sure. But glad to see you have something which works for you :-)

OK, just had time for a quick look now. And I think the problem is that drawStencilShadowVolume doesn't do what I thought it would do. When I proposed that in last thread I assumed it would simply write the triangles to the stencil-buffer, but that doesn't seem to be the case. I realize now that ...

Stencil shadows can be tricky. First - experiment with the settings - especially zfail vs zpass in this case. Also in 1.8 directional light didn't work with shadows - only point lights.

Do you get the error also in the Example 08 Special effects? And which driver?

edit: I missed the transparent ...

The simpler solution are likely the stencil buffers I mentioned. Thought you still didn't tell us what the issues with the blob shadow solution had been.