32 bit indicies patch for the 1.2v...

[sdi2000]

Ive create an 32 bit index patch.
This patch replace all 16bit calls and change them to 32bit.
U can download this patch at my homepage
http://www.sdi-syndrom.de/dev-delight/irrlicht32.patch


have fun

pls let it flow into the new version of irrlicht

[hybrid]

As previously stated I don't think that you'll have any benefits from a 32bit patch as long as all mesh loaders and generators are fixed to use enough mesh buffers. The complete pipeline will only become slower due to 32bit buffers. Thus, a simple replacement will never be used. The only way would be the index buffer interface which allows to choose from both alternatives.
Just read the suggestions on average buffer sizes sent to the gfx card. Both NVidia and ATI propse to use at most 65000 elements per call, because in most cases the pipeline will otherwise stall until all elements arrived. But to avoid all these complaints about the terrain sizes this patch will come in handy

[itx]

512x512 terrains - its reason for 32bit ;-(

[hybrid]

No, 32bit is one way to overcome the limits. But as said a usually slow one. It's better (but somewhat more complex for the implementer) to use severl mesh buffers.

[Saturn]

Actually the stalling element is not so much 64k+ vertices, but rather the fact, that they are sent to the graphics card each frame anew and are bothersome to address from the GPU this way. Hardware buffers would solve this and 32bit don't make too much sense without those.

Also a patch shouldn't, as hybrid wrote, simply replace all u16 with u32, since their is a performance penalty involved for the case, where 32bit are not needed, which is the majority of cases. So, this patch actually makes performance worse for highly crowded scenes.

So instead of having here a patch for 32bit and a patch for hardware buffers and patches for more vertex formats, an integral concept is needed, that addresses all these issues. There have been a few initiatives, but, yada, yada, yada... I'm sure hybrid can't stand here it anymore.
But it's true. And no one seems to be willing to do anything about this, without some backing from the team.

[hybrid]

I was actively involved in the last discussions about concepts for hardware buffers and these things. But I won't develop the required patches as my current focus is far before those things. But if a convincing concept is implemented I'll integrate it right away (since any problems will have been fixed in discussions and fixes before it is convincing ). Unfortunately, all discussions deceased before any result was found.

[dazedandconfused]

Same old story - aarrgghhh..

No wonder all the noobies get SO confused.

Is there a single working terrain demo anywhere ??

Yet again the same old inconclusive answers keep coming up.

16 bit this, 32 bit that, hack this, patch that, - heeelp !!

Unless anyone wants to argue different, anything above 129x129 heightmap is dead right ??

So many people 'claim' 257x257 works fine for them, and everything is oh so wonderful, but damn I am so confused over the huge amaount of threads, that debate each other.

can one of the 'team' please post a working demo, or a 'no arguement' list of facts and rules on terrains.

Regards

[CodeDog]

TortoiseMerge
The line Index was not found

Got a patch with an index?

[xyzchyx]

Actually, the speed of manipulating 32-bit numbers is no slower than 16-bit unless the non-native integer size is actually narrower than 32-bits. In fact, on some systems, it may even be slower to use a non-native integer size. The only advantage using 16-bit integers gives one is compactness of storage in arrays. There is no practical benefit to using 16-bit integers on 32-bit computers for variables, either local or global, unless there are many of them to store and space is at a premium.

[vitek]

The issue is not _necessarily_ space. Of course 32-bit integers are twice the size of 16-bit integers, so for a mesh with less than 65536 vertices, you use two times the memory for representing the same mesh when you switch to 32-bit indices. This is an issue, but it is not the only issue. The other issue is that you are sending the index buffer to the graphics card every frame. This will be a significant bottleneck.

Lets say you have a mesh with 65535 vertices [just for arguments sake]. To maintain 100fps while rendering that mesh with 32-bit indices, you have to send 25MB of data through the CPU to the GPU every second. It is only 12.5MB for 16-bit indices. With the CPU busy sending vertices to the GPU, you don't get a lot of time for other stuff.

On my machine [which is not a powerhouse], I get 10fps with the D3D9 driver when rendering a 255x255 hill plane mesh and nothing else.

Code: Select all

  scene::IAnimatedMesh* mesh =
    smgr->addHillPlaneMesh("terrain",
                            core::dimension2d<f32>(1.f, 1.f),
                            core::dimension2d<s32>(255, 255),
                            0, .25f,
                            core::dimension2d<f32>(5.f, 5.f));

  ISceneNode* node = smgr->addMeshSceneNode(mesh->getMesh(0));
  node->setMaterialFlag(video::EMF_WIREFRAME, true);
  node->setMaterialFlag(video::EMF_LIGHTING, false);

If you are going to have many vertices, it is best if you don't send them to the GPU every frame. That is why you need both the 32-bit index patch and the vertex buffer patch. Without the vertex buffer patch, the only thing you are going to get is bad performance and more memory usage.

Another suggestion would be to get a different terrain implementation. If the terrain was broken up as a quad tree with each quad as a seperate mesh buffer, you could get much bigger terrains easily. It would be more difficult to implement the geomorphing, but you could easily avoid rendering mesh buffers that aren't visible.

Travis

[Raedwulf]

Actually, the speed of manipulating 32-bit numbers is no slower than 16-bit unless the non-native integer size is actually narrower than 32-bits. In fact, on some systems, it may even be slower to use a non-native integer size. The only advantage using 16-bit integers gives one is compactness of storage in arrays. There is no practical benefit to using 16-bit integers on 32-bit computers for variables, either local or global, unless there are many of them to store and space is at a premium.

xyzchyx, you are referring to the CPU, this is true for the CPU - actually in some cases 32-bit is faster than 16-bit codes. However, its a different case for graphics because as the previous post explains copying 16-bit data is only half the size of 32-bit data....

[xyzchyx]

The issue is not _necessarily_ space. Of course 32-bit integers are twice the size of 16-bit integers, so for a mesh with less than 65536 vertices, you use two times the memory for representing the same mesh when you switch to 32-bit indices. This is an issue, but it is not the only issue. The other issue is that you are sending the index buffer to the graphics card every frame. This will be a significant bottleneck.

Lets say you have a mesh with 65535 vertices [just for arguments sake]. To maintain 100fps while rendering that mesh with 32-bit indices, you have to send 25MB of data through the CPU to the GPU every second. It is only 12.5MB for 16-bit indices. With the CPU busy sending vertices to the GPU, you don't get a lot of time for other stuff.

I'm confused.... first you say that the issue isn't necessarily space, but then you go on to even cite an example where the only reason that it's going to be slower is _BECAUSE_ of the amount of extra space that a large array of 32-bit integers would take up.

[hybrid]

Even if your bandwidth is large enough you can get problems due to lack of input. So in case everythig is switched to 32bit, but you keep your mesh buffers small (i.e. every draw call issued only takes some thousand elements at max) you won't notice the difference. However, bandwidth might become a problem for many average and low-end cards, and the lack of automatic splitting into medium sized mesh buffers would put even more pressure on the pipeline. So I'll put the splitting implementations on my list as it is useful for all index buffer sizes. But still, any implementations for all kinds of buffers are welcome

[sdi2000]

Im very sorry about this thread... ?!?!
It was not my intension to confused some peoples.
I meant no harm by it. =)
If any people want this patch.. use it.

[dazedandconfused]

Hi sdi2000,

No, you absoloutly right !

This is the point, no one can put there finger on a firm answer, and everyone is confused.

Unless someone cane give people a positive answer, than how do we know whats the best thing to do.

I'm still yet to find a single thread in these forums, where someone can grabs their balls, and say 'YES' this is the answer to all our problems.

YES, this will fix all our issues, YES 257x257 heightmaps work, or anything.

But no one can.

I'd like to see a sticky with some answers, telling 'everyone' what officially works, and what doesn't.

I am impressed with irrlicht, but with so many issues, and un-answered questions (other than vague guesses), I would suggest someone, patches this engine and releases it in all it's glory, I'd sure pay for a working version, with more features.

Regards