32 bit indicies patch for the 1.2v...

[buhatkj]

the primary reason to use 32bit indices is for larger terrains right?? however, many people are concerned about the performance hit. so if as hybrid says the better method is to use multiple meshbuffers for the terrain, then that's what we should focus on to fix the issue with terrain. high-end terrain renderers frequently use terrains made up of "patches".
so what we do is somebody implement a better terrain node, that builds a series of <128x128 patches to represent larger terrains, then renders them translated properly relative to each other.

this discussion of 32bit vs 16bit is counter-productive. each has advantages and disadvantages. i think the answer lies in between.

[Eternl Knight]

I actually agree - discussing 16 bit vs 32 bit indices is redundant. They are simply an "implementation" issue. What needs to be discussed is features & bugs.

Now whether you classify terrains larger than 255x255 as a feature or a bug is irrelevant. What IS relevant is that it is a limitation an engine claiming terrain support cannot really abide by.

There are two solutions to the issue. One of them is to leave things as they are in terms of vertex/triangle counts (i.e. leave 16 bit indices as they are) and to change the terrain classes to split up the geometry in such a way as to make them work within this limitation. This has the (IMO, dubious) advantage of keeping the "rendering level" of code the same.

The other solution involves moving to 32 bit indices (whether keeping 16 bit around or not is irrelevant to this discussion, so I will not address it). This has the advantage that it will work for larger terrains (up to an unrenderable number of triangles!), but hybrid posits that this will create issues with the uploading of data. Which is true because Irrlicht uploads the data for the geometry EVERY FRAME.

For an engine using hardware acceleration (right up to GLSL fragment shader support!) - this is relatively backwards. One of the first things you do to speed up hardware support is to upload vertex & index buffers to the card and reuse them frame-to-frame. I think people would be pleasantly surprised at the speed-up they get from this feature alone (should it be implemented). After which, the argument for/against 32bit indices becomes almost irrelevant.

--EK

[vermeer]

curious. I spoke about this...years ago, here. I was speaking about the matter of...if you export a more than 65,000 (aprox.) tris mesh, be it whatever , dx 8.0 3d package exporters would tell you no way, to export such large mesh. But using dx 8.1 exporters, was possible.Sombody answered d 8.1 had support for 32 bit index. And then came the talk about that in Irrlicht...That irrlicht nx had a patch for that..
If I remember well.

[itx]

dazedandconfused 257x257 terrain also not working, so only 127x127 available (and yes of course 256x256)

Run calc.exe 257*257=? , undrstand now?

[Spintz]

For a LONG time, IrrSpintz has had variable 16 / 32 bit indices. On top of this, IrrSpintz has had Vertex/Index buffer support for just as long. I've still not heard any valid arguments on why these aren't good enough implementations....

Splitting terrains with more than 65536 indices into multiple draw calls is SLOWER, than using a single terrain with 32 bit indices. Because vertex buffers are not being used, with each draw vertices will have to be re-passed to the video card with every draw call.

To sum it up, Vertex/Index buffers are the only viable solution to this problem. 16/32 bit indices are just a bonus.

[iZOTOPE]

i've used the patch, and made a huge 1024*1024 heigh map, and i've made a demo with it, i still got 200fps in 800*600, with the detail map 100%, the terrain is huge(the program rendered it in 0.000 seconds, all map), i also want to make it seamless, so if anybody can help me with suggestions on good seamless(but not repetitive) world please help

[rogerborg]

The complete pipeline will only become slower due to 32bit buffers.

How much slower?

[hybrid]

I measured 10-20% due to too large mesh buffers. See http://irrlicht.sourceforge.net/phpBB2/ ... 9&start=30

[Spintz]

I measured 10-20% due to too large mesh buffers. See http://irrlicht.sourceforge.net/phpBB2/ ... 9&start=30

What about while using vertex/index buffers? I'd put a lot of money on the percent increase for optimal mesh buffer size being a lot smaller once vertex buffers are enabled.

Also, those results are for OpenGL only, if i remember your post correctly. What about DirectX?

[hybrid]

I'm pretty sure that there's still some benefit because the NVidia and ATI papers had all these suggestions for apps with and without VBOs. So there should still be a noticable difference.
For DirectX I have the problems that the values are often much higher than those of OpenGL. Basically because DirectX does not support any higher value than the Caps number, while OpenGL supports every possible value - only slower in many cases. So OpenGL figures out some optimal value for the internal render pipeline, while DirectX only gives the maximal amount possible. I simply don't know how to find a different, optimal value.

The lack of VBOs for Irrlicht is bad. We all know this. But there are more things to do for the S3DVertex and SMeshBuffer family of structures in Irrlicht. Even changing a bit of it will introduce more problems with all those methods which are already ignoring some possibilities right now. So I'm still unsure how the final architecture for those structures should be - and that's why I still search for a solution which fixes all problems. And my current spare time does not allow for more than fixing smaller problems.

[Saturn]

So I'm still unsure how the final architecture for those structures should be - and that's why I still search for a solution which fixes all problems. And my current spare time does not allow for more than fixing smaller problems.

So open a discussion on this! Describe, as best as possible, the requirements for a viable solution to be integrated into Irrlicht. If there is a chance to get it included into Irrlicht, then I am sure, many people will review the problem and propose something sensible and even work on it.
I know I will. The reason I'm not, and perhaps others too, are not working on it right now, is the uncertainty on whether it gets included or not. I'm not going to work on such a huge project unless I'm sure, that the work will get rewarded with inclusion into core irrlicht.

So an API-Proposal, peer-reviewed by all the forum users and the team, is something to work with.

Question is, how does such a proposal look like? I'm all for abandoning E_VERTEX_TYPE madness alltogether, but I understand that not all do, and I am willing to help to get VBOs into irrlicht nevertheless. But I am only participating, if we can establish a clear goal and a clear path to it.

[Spintz]

I would gladly work on this. I think what you're getting at is the need for Irrlicht to have flexible vertex formats? We should get rid of S3DVertex2TCoords and S3DVertexTangents and have an S3DVertex which is capable of representing all possible vertex layouts/formats.

I'll admit, I meant to work on this a while ago, however, I swear I have A.D.D., and I branched off into work on many other things. Once I clean up some things, ( DDS Loader, X Loader fixes, 3D/Volume textures ) I will put work into a flexible format vertex for IrrSpintz. I would just model it exactly after the DX FVF. As far as I know, OpenGL has no kind of vertex format enumerations, correct? You just have to construct the vertex format using glEnableClientState calls.

[hybrid]

Well, at least we should investigate what would be possible with the current setup and what would be necessary to change to the advanced types. Since Irrlicht will keep a simple API the addition of those enhanced vertex types will only be made if it's either quite simple to use, or if they can be used alternatively to the old ones. So my hopes are to get a proper architecture based on interfaces for 3d vertices, mesh buffers and index buffers (and what else would be necessary).