Feature Request

[Mirror]

hello again people. I have been dealing with irrlicht for 2-3 weeks now and i'm very enthusiastic about it.

Here are some features which IMHO would be nice too see in future versions of it : ( though i don't know if it would be nice since im still a new guy around, to make such a request )

1.) mesh LOD

2.) support for bigger than 256x256 terrains ( 4096x4096 would be a nice limit )

3.) support or making it default to read terrains from .raw 16bit heightmap data files ( smaller than .bmp and thus faster loading and less disk space consumed ). Size either as option in the function ( i.e. loadTerrain("blabla.raw",1024, 512) or by default as quadratic ( 1024x1024 )

4.) some kind of detail map for parallax mapping in terrains. I will explain my self : it would be nice and add some "detail" to the terrain in the form of parallax mapping. in the same way as we use a detail map to have a higher detail in the textures, we could use one for having higher visual detail in the heightmap. ( repeated in the same way as detail map ).

5.) support for loading .utx files ? ( dunno if it is legit )

[bitplane]

Welcome to the community

1.) I made a simple mesh reducer, but the performance is really bad and it looked pretty ugly. We don't support a LOD-enabled file format or mesh buffers yet. There are several workarounds available, but if you have ideas how to integrate this to the engine then this is the right place for open discussion

2.) The terrain node would need to be rewritten for this, though it may be possible with the current terrain once we support 32-bit index lists (possibly as early as Irrlicht 1.5?)

3.) Isn't there already a raw loader for heightmaps? I haven't used it myself but I've seen the code in CTerrainSceneNode.cpp

4.) You can do this already, it's just a case of writing a shader like in the shaders tutorial and setting as the terrain's material.

5.) If you decide to write one of these and submit it, there's a good chance it will be included in the engine. If this is beyond your current skill level, try to link to as much information about the format as possible, someone else is likely to pick it up eventually

[hybrid]

1) Which kind of mesh LOD do you think of? I played with predefined meshes of different detail. The scene node simply checked the distance from camera and displayed the mesh the user registered for this range. Simple, effective, and ugly (due to popping). I'll add it to either the core library or the custom scene node collection.
But there are much better techniques available, many are just for specific nodes like the already exsiting terrain LOD, though.
2) Well, max size of the terrain is 129x129 if you want to rule out all problems. But you can also use the terrain mesh, which loads arbitrary heightmaps, but does not offer LOD support.
3) The RAW loader is not nicely exposed to the user, I changed some things in the terrain node to make it easier. Still cleaning up that stuff (as it also contains the terrain flip to make the terrain properly textured).
4) Problem is once more that Irrlicht materials cannot be combined, and the shaders cannot be adapted to different textures, such that one has to use another shader which accesses texture 3 instead.
5) Hell, what's utx?

[Mirror]

a) about mesh LOD, my idea is about using a file format with pre-built meshes as hybrid said. it would be much faster i think than calculating in real time
b)i was speaking about unreal engine 2 format. ( i know it's complicated )
http://udn.epicgames.com/Two/UnrealEngine2Runtime.html

unreal engine 2 editor and runtime is available for free from epic games
try out unreal editor, it's a very powerful one. you can also try to load the sample map from the unrealengine2runtime.

download link : http://udn.epicgames.com/Two/UnrealEngi ... 62002.html

my skill is not as good as making an irrlicht "runtime" / loader for unrealengine2 format but if someone is interested i can find links.

hybrid, the popping effect that you noticed with predefined lod-ed meshes will not occur if LOD distances are well defined. each lod lvl distance must be double than it's previous. for example if you set lod0=2000 lod 2 must be 4000, lod3=8000 and so on ( of course this won't help the reducing of polys so much, unless you use large fardistance ). i suppose a general lod-ing algorithm for meshes that would also be effective performance wise, is something complicated. for example, it's not possible to reduce a cube to something lower. there are some limits, which if changed will affect the

c)i'd vote for making .raw format the default format for heightmaps. it will be better performance wise. just 2 bytes for each heightmap, no headers, no complicated storage information, easy to code reader, less disk space, easy to view and edit in any image editor

hybrid, please think about my idea about combining materials, i think you got the point what i mean, this would lead to superb terrains ( since the detail map would be used to "detail" in 3D the terrain. in this way a 256x256 terrain would look just like having a much larger one, but infact without using so many triangles.

[Dorth]

What the? Are you mad? In this day and age, how many maps are you planning to create on what kind of machines so that a bmp causes a problem? The header IS the good part! Depth, rows and columns. Ever heard of separation of data and functionality? Well then, don't bring the data in the code, thank you very much (I am not against supporting .raw for heightmap by far, just not making it default. And why would one needs to be priviliged over another one anyway? That'S just limiting options)

[Mirror]

What the? Are you mad? In this day and age, how many maps are you planning to create on what kind of machines so that a bmp causes a problem? The header IS the good part! Depth, rows and columns. Ever heard of separation of data and functionality? Well then, don't bring the data in the code, thank you very much (I am not against supporting .raw for heightmap by far, just not making it default. And why would one needs to be priviliged over another one anyway? That'S just limiting options)

im not saying that it causes a problem as of now. what im saying is that in midterm and longterm everyone will use .raw format. why ? take this scenario. at some point irrlicht will be able to support large terrain heightmaps like for example 8192x8192. that in .raw format would be 128MB. in .bmp that would be 192MB. that means +64MB of data. secondly, in loading time terms, if this big raw would take 6seconds to load, the .bmp would take 9 seconds. Those 3 seconds are important in my opinion, because at some point there comes the production phase, when optimization is important. as irrlicht is supposed to be a lightweight engine, i don't see why it shouldn't have as default the best ( in opinion ) file format as default. yes, it's good to have alot of options, but this adds more code and will eventually result in a bloated irrlicht engine. Options are good, but if there is a by far a better choice, why should the rest of them be present ?
let me put it in another way :
why not ?
in which aspect is .bmp better than .raw ? speed ? disk space ? performance ? the only thing that could be considered as a pro for .bmp is that it has the dimensions in the file, but that's not something that outweights the benefits of .raw file format IMO.

--

- some other feature which would be interesting in my opinion would be a 'degradation of light intensity'. just like as in irrklang the sound become more and more dim the further one is from the source, in the same way, light should be degrading as one moves further from the light point.

[hybrid]

BMP is just like RAW, but with an additional header. If you read in the bmp and reinterpret the data you see in your image you'll get the same results. BMP also exists in 1-32bit depth, so you can adjust to the bit depth you need for the height precision. But RAW is often used in GIS applications, hence we'll support it somehow.
Light degradation (officially named attenuation) is supported since Irrlicht 1.4, you simply set the attenuation in the SLight structure. Before you had to change the radius of the light.

[Dorth]

Mirror, it would NOT increase by 64 mb. A raw IS a bmp with header truncated. THAT'S ALL! anyway, some would rather use a png for the lightweight since it's also a lossless format. or tga. I've seen many loaders, many preference. You're only attempting to limit the engine, the choices and options, that's back-coding, not future-coding. If you like meat, and think people that eat sandwiches are eating bread and salad for nothing, fine for you. But other still might want their sandwiches. I DO NOT want to hardcode the size of the map. I DO NOT want to create another script data for the map to say it. It's more work for the designers/coders. The kind of size you're talking, only new machines support it and trust me, it doesn't take 9 seconds to load a bmp. With proper loading placement, the loading isn't seeable by the player. On top of that, how many heightmaps do you plan to have concurrently? I'd say if they are that size, 9 at the very most at the worst case. There is NO benefit to choose your option. End.

[christianclavet]

Here my features request for Christmas:

- Occlusion culling
- Supporting an image format that is HDR (Up to 128bit) (possible formats: OpenEXR, HDR) OpenEXR is under a BSD licence. Check more details here ( http://www.openexr.com/ )
- An Heigtmaps that support those HDR files and would be bigger than 129,129 (or 257,257?)
- Streaming support for loaders?

[hybrid]

128bit heightmaps? I don't think that's necessary. The size limit is disturbing, we know that. But tiles managers are available.
Streaming support? You mean web loaders, or background loading?

[BlindSide]

- Streaming support for loaders?

Read "Make mesh loaders thread safe"

[hybrid]

Yeah that was my second guess, cause it would allow for background loading...

[Mirror]

yes he didn't mean 128 bit heightmaps that would be larger than the universe

( 16bit is more than enough - 65535x65535 )

merry-xmas to all! cheers!

[hybrid]

The resolution is only important for the height values, the heightmaps can already be as large as you want (well, most images are usually <16384x16384). The thing is that raw images do support 8, 16, and 32 bit depth. Maybe there are even 64bit float formats found, don't know what typical GIS applications need. But Irrlicht will support larger terrains sometimes, and Irrlicht will support floating point textures sometimes. And all image types should be supported as heightmaps then. So even 128bit might be possible at some point.

[christianclavet]

HI, The Depth should be used for 128bit are RGBA, so 32 bits PER channel. Open EXR is used on Adobe Photoshop, and some HDR rendering capable applications.

Having up to 32bit heightmap would allow for more level details on the ground.

I don't know if anybody would this for up 128bit (incredible details on the ground, we could see the Ants holes!). Most would surely use 16 and 32 bits greyscale picture. But having the EXR format implemented, we could also have other element with HDR rendering. (I remember that we could use a color mode that is HDR(if the display support it))

For the background loading, it is that. Would have to have a flag like: isLoaded() to know if the mesh or IRRfile is completely loaded. Another thing could be interesting - IsPercentLoaded() or isBytesLoaded() and isTotalBytes() .(That could allow developper to update a gui displaying the amount of level is loaded while, the player is waiting, and could display some little animation instead of blocking the process and waiting the complete load of everything.

With this, we could know of how much is loaded. The scene rendering would check the isLoaded() flag to see if it can render it. So there will not be a problem because, it's checking the meshbuffer and it still not yet completed and would surely cause a crash. Also, using, this we could load parts of level WHILE it's being played, have NO loading time (after loading the first part, thats for sure)

The one thing this method show, is that it could be simple and the standard code will not be affected (Only new fucntions added but old code shouldnt need to use them).

There would be major modification of the IRRlicht code. (All loaders (Meshes, Pictures, Scenes), would need to have this implemented so it really work. So surely a "stream loader class" will have to be defined that could load arbitrary data in the backgound with theses status on them, and update all loader to use class to retrieve the data. Unless you can overide the data loading function with the new class.

In theory, I think I could be right. But in practice, my skills are really not up to this. Do you think this method is good and possible to implement (someday in a future version?) Anyway. It is still my wish that I see something like that in the future...

By the I was also meaning by streaming, that: Can it be possible to have and URL instead of the file name? With the background loading implemented, we could have a level updated LIVE from an URL, instead of copying the level files copied in the HD. So some developper could write very little applications that have their levels loaded from their servers. But for this I think we need a library for network. But it could be interesting to have a way to "hook" the to the file loading...