Horde3D

Hi

why are texture resources such as TerrainNodeParams HeightMapRes write-only? I'd like to get a pointer to texture data, so I could use it for i.e. creating a heightfield in PhysX. Now instead I have to create geometry for terrain with Horde3DTerrain::createGeometryResource() and make it trianglemesh shape in physx to do collisions with the terrain, which is not very optimal at all...

And it looks very strange to me that texture-resources are write-only. Why is this?

Giving full read/write access to resource streams is something that is quite high in our priority list. Unfortunately, it is not as trivial as it might seem. The textures are usually in the graphics memory to which you don't have direct access, so data needs to be downloaded again which is not very efficient. Another problem is that mapping a GPU resource can introduce a serious stall by forcing a synchronization between CPU and GPU. If a GPU resource is still referenced in the GPU's command buffer, the CPU has to wait until the GPU has finished. After that, the GPU command buffer is empty and the GPU will idle until the CPU sends out some new commands.

Which raises the question of whether terrain heightmaps should be treated as textures at all?

I realise this was done initially to avoid introducing new resource types, but since these heightmaps are never used as textures, there is no need for them ever to be uploaded to the GPU.

Would it be worth defining a new 'image' resource type (as opposed to 'texture') to be used for images that will only ever be used CPU-side? They can use the same loading routines, just without the upload step, and images could be cheaply read/write, and then allowed to be uploaded into a texture at the programmer's discretion.

_________________
Tristam MacDonald - [swiftcoding]

Good point. Originally we experimented with vertex texture fetching, so the heightmap was used as texture. But we dropped that for compatibility reasons and to have a single code path. The terrain code is doing some heavy preprocessing on the heightmap. It would certainly make sense to store that data on disk. So I think a custom binary format for the terrain would be the best option.


Hmm, instead of having another very similar resource, I would rather introduce some access flags like GPU_READ, CPU_READ, CPU_READ_ONCE, CPU_WRITE etc.