Quality issues

[CuteAlien]

Ok - next thing you can try: set the geometry as static so it's not uploaded to the card each frame. You can do that per meshbuffer with
IMeshBuffer::setHardwareMappingHint (see: http://irrlicht.sourceforge.net/docu/cl ... uffer.html)
You should set it to irr::scene::EHM_STATIC

[dban]

I'm already doing this...

Code: Select all

    for (unsigned int i=0; i<mesh->getMeshBufferCount(); i++) {
        mesh->getMeshBuffer(i)->setHardwareMappingHint(EHM_STATIC);
    }
 

and/or

Code: Select all

 
    mesh->setHardwareMappingHint(EHM_STATIC);
 

In the meantime I have removed some of the materials from the shelves - instead of three I only have one (no textures). And the results are better.




Btw, how can I have smoother lines for the shelves? I have antialiasing set to true, but no improvement.

I've been also playing with the lights - ambient, point, directional, no lights and I got different results. Not sure yet how to set the lights for the entire scene in the best possible way, but probably the Managed Light tutorial will help...

I'm going to upload my project hoping that someone more experienced will take a look and give me some hints.

Thanks & best regards,
Dumi.

[hendu]

Those shelves are just six boxes - 6*12 = 72 verts. 300 is a lot still if their geometry looks like that.

[dban]

It's not that simple:

And it's not necessarily about that. I don't wanna be forced to use really simple objects. 3000 vertices is a lot, but 300 seems like a reasonable number.

[dban]

Anyway, I have uploaded my project here - http://dako.ro/irrlicht/library.zip. The code is all in one place, main.cpp, no other classes created yet since I am just trying to asses Irrlicht. There are 4 types of shelves in the project - 3000 verts/3 materials (colors), 3000 verts/1 material, 300 verts/3 materials and 300 verts/1 material.

I've tried many things so far, but the results are not consistent. Batching works for many 300 vertices objects, but doesn't work for 3000 vertices ones. Octree doesn't help at all. I got some improvements when changing the culling for shelves to EAC_FRUSTUM_BOX, when reducing the number of materials (colors) of the shelves and when playing with the lights.

I didn't think that I would encounter so many issues from the start. For me this part seemed straightforward, there are so many 3d games with levels much more complicated. What will happen when I'll put the books on the shelves, when I'll write the title of the books, when I'll write on the shelf the number of copies for a particular book right under that book?

I don't expect the work to be done by somebody else, as you can see from this thread I'm constantly reading and learning and trying, but any ideas would probably help me progress faster.

Thanks & best regards,
Dumi.

[hybrid]

When counting visible vertices per shelf (even back/front together) I'd say that 300 is more than enough. I usually didn't find more than 60-80, even with quite bad placement and subdivisions. Anyway, 300 might be working. If you place books there, you shouldn't model each book separately. And even more important: Don't use rendered text to write the title, but use textures.
If your card does not support anti-aliasing in windowed apps, you have to try full-screen.
EHM_STATIC does not work for meshes under 500 vertices by default. If you want to try it with very small meshes you have to set a scene parameter or call a function to reduce this threshold. Octree also works only for huge meshes (>20000 polygons)

[CuteAlien]

Oh wow, that's also something I didn't notice before. After some searching I found it: IVideoDriver::setMinHardwareBufferVertexCount allows changing the number. Guess we should document this ... we even set EHM_STATIC for all our geometry created in the geometrycreator which is usually way below 500 vertices.

I didn't find out anything about octrees only working for > 20000 polygons and it would also suprise me as I'm pretty certain I've used it with smaller meshes succesful in the past (but maybe it got changed). What I do know is that I got best settings by recompiling Irrlicht with some other defines which are used in octree (and no, I don't know why those are defines instead of variables). I used:

Code: Select all

 
#define OCTREE_USE_HARDWARE true
#define OCTREE_USE_VISIBILITY true
#define OCTREE_BOX_BASED false
 

instead of the usual

Code: Select all

 
#define OCTREE_USE_HARDWARE false
#define OCTREE_USE_VISIBILITY true
#define OCTREE_BOX_BASED true
 

and especially not using OCTREE_BOX_BASED had improved speed a lot in my test-case. (I've never changed defaults because I only had one test-case, didn't write the code and I'm confused about the usage of defines for this anyway).

[hybrid]

With default settings, the effect for small meshes will be neglectable, hence my rule of thumb is to use octrees only for huge meshes, which is something larger than a few thousand polys at least. Should work with all sizes, though, but might introduce more overhead than advantages.
Using the hardware define will use EHM_STATIC for the newly created octree meshes as well, which should be significantly faster on most current hardware. And it uses defines because it was introduced by burnings, which means that not a single cycle should be wasted

[Tedi]

I have the same problem. I am looking the answer 6 months now....