loading very large maps

[juliusctw]

viva Hybrid

[vitek]

Would it be possible for you to integrate the method addTerrainSceneNodeRAW, too? It's nice to have the ability to use 16 bit raw heightmaps

Someone should just make a derived IImageLoader that supports raw files. It is pretty easy to do, and everyone can use it without having to modify the Irrlicht sources.

On a related note, I've often wondered why the addTerrainSceneNode functions weren't reduced to a single function that took a video::IImage. It would allow loading terrain from any IImage source, even an in-memory buffer.

Travis

[hybrid]

I think there had been such a proposal some time ago. But the problem with raw images is that you must set the dimensions somewhere as there is no meta information in raw images. But the interfaces do not allow for such things.

[Spintz]

The new IrrSpintz, I really need to release a version with all my changes, supports VertexBuffers and 3d and cube textures, cube texture rendertargets, for very nice dynamic environment reflections, alpha loader support with IImage( I'll look into updating the addterrainnode function to be a single call with options ) and a lot more. I'm still cleaning up a lot of the stuff I've implemented new, and am even thinking of adding a quaternion camera class.

I was thinking about implementing a ROAM terrain algorithm scene node, but am thinking of going back to a RangerMk2 style terrain node.

I need to clean up the CImageLoaderRAW, and the cube and 3d texture support. Not as much time is going to IrrSpintz at this moment tho, because I'm releasing a game( I'll provide an installer demo of the game in a couple of days, OpenGL and DirectX are supported, but I don't have a Linux machine to test and build on at the moment, so no clue how good or bad it works in Linux ).

Hybrid, if you'd like, I can take speciifc changes I've made and apply them to an SVN Irrlicht revision and provide the changed files, if you need anything from IrrSpintz.

[hybrid]

Sorry, I think I mixed up the loadHeightMapRAW and the ImageLoaderRAWAlphaMap. The latter has a very problematic interface (as I mentioned), the former is probably just a little messy due to the overall interface as vitek said. So in the end both things should be merged and provide just a single method for all possibilities.

@spintz: I'll check the extensions of IrrSpintz and send you some ideas and requirements. Interesting points are: IIndexBuffer, Renderstates, VBOs, additional materials. An easier integration will be possible for particle extensions and spot lights.

[Xaron]

Thank you all! This sounds very promising! I'd love to see the particle extensions in the Irrlicht engine, too.

Regards - Xaron

[Spintz]

ImageLoaderRAW should not be combined with addTerrainSceneNode. It's used to load RAW format data for multiuple purposes( like for doing texture splats with RAW alpha data ).

[hybrid]

Yes, but if you have a generic raw loader (maybe even not converting to 32bit, but keeping the original depth using new color formats) you could just pass this IImage to the terrain generator. Although the raw loader in the terrain is not really complex it would be redundant.

[Spintz]

ImageLoaderRAW is a RAW loader, I'm confused.

[hybrid]

The raw loader that I've seen loads one color component with arbitray bitwidth, chops it to 1 byte, puts it into alpha and makes the other components white. Probably not what a "generic loader" is thought to be. I'd prefer new RAW color formats, such that it can be applied in any depth to any layer.

[Spintz]

That's just cause I only care about 8bit RAW data at the moment, the loader is not used for terrain node at the moment, but I think I see your other points. If you are loading 32 bit raw data, how do you store it?

[Spintz]

Maybe some new RAW color formats, like ECF_A32, ECF_A16, etc. which would require changes to the IImage to handle these formats also.

[hybrid]

Yes, that's what I thought. I think ECF_X8, _X16, and _X32 would be the ones to choose, maxbe _X1 also. I'd rather choose _X as this one component image could be used for color layers and even luminance etc. It might also require to add some getters and setters to define which channels are in the image, i.e. use the 8 bits for alpha channel in your loader.
Access to the contents can be given via getPixel() for 8bit and 32bit, but 16bit is a little odd, there's no default conversion to 32bit.

[Spintz]

I just remembered two other things.

• The problem with using them as textures, is you have to make the texture loaders aware of these new formats. That's why the current RAW loader in IrrSpintz only reads 8 bit raw data, and then creates data in the format ECF_A8R8G8B8. It sets the A8 to the raw value, and R8G8B8 to 0xFFFFFF.
• Also, to explain more about why the terrain changes occurred which made the issue with 16/32 bit indices come about. The original terrain code used separate mesh buffers for each patch. This is bad, because without Vertex Buffers, the vertex data for each patch has to be uploaded to the video card, as well as the index data( which doesn't matter so much, since it's always changing anyways ). This worst part is the number of different calls, it's always better to stream large chunks of data in, then to have lots of little chunks. So I redid the code, so it was a single large meshBuffer for all patches. All patches now share the same vertices, it's just the indices that change every frame, and they are again, 1 large set of indices, not indicies for each patch. If Vertex Buffer support was added, I would put back the terrain code to use individual vertex buffers for each patch, which could be done without 32 bit index support. Honestly, the VertexBuffer patch is easier, because the IIndexBuffer change for having both 16 and 32 bit indices changes many more things, mesh loaders, video drivers, etc.

Oh, and Hybrid, I only make the changes in IrrSpintz to DX9 and OpenGL, DX8 would be easy, most of the changes are supported. However, I haven't touched the SOFTWARE2 driver, and I've actually removed the original SOFTWARE driver.