Irrlicht - how to create a scene from custom scene format?

[hybrid]

Well, meshbuffer organization needs a little experience with 3d graphics, hence I told you about it. But explaining getters and setters seems a little far out. So yes, using setTexture will set a texture, while getTexture returns the texture previously set. Moreover, the tutorials cover such things - that's why I alsways suggest to go through the tutorials first

[karx11erx]

hybrid,

I don't need the API explained (again) to me, no worries, and I won't ask for that. I need info on what to do where, and when.

As I said, my first step is to render static geometry. The question is how to organize that. I know enough about OpenGL to understand that a mesh buffer containing arbitrary data cannot just be loaded to the graphics driver as a whole.

You can load up vertex and texture coordinates, colors and indices in array fashion. But you cannot load textures to the (OpenGL) driver in a similar fashion (in a vector). You can only tell OpenGL "this is the current texture", and that will be used for all subsequently rendered textured polys.

That's why I am asking about mesh and mesh buffer organization. Of course I can load all my triangles to some mesh buffers (at least one mesh buffer per texture, I suppose), put them in a mesh and tell Irrlicht to render it. But is that the proper way to do it? I mean, there's a lot of completely disconnected and spatially separated triangles with the same texture in a Descent level. I wonder how the octree will cope with that, if all these triangles are in a single mesh buffer. So maybe I should create one mesh buffer per face, trusting the renderer will put all those together that are visible and have the same texture?

Actually most current Descent levels aren't very complex. We're speaking about 100 or less different textures and max. 5000 quads.

[radiant]

Hi, i think u re trying to reinvent the weell...
(if i missunderstood your question im sorry)

u want to make a descent -like game right... u usually wont be manually drawing triangles(in most cases anyway) what u would do is... making 3D models in a 3d modeling sw... like 3dstudio max or blender, then u can export what u do there to a format that the irrlicht engine can display..(.3ds, .dae, .obj, .x, etc...)

once u have the models u want to display u have to put then in your scene... like in example one, thats the most basic layout for a 3d app in irrlicht

in a more complex app.. u wont be loading just one model, u would be loading many more, including terrain maybe a player character, etc... instead of using a static camera u could use a FPS camera... its all in the tutorials, u just need to put it together...

Tutorial 1: setting up the window and displaying a mesh
Tutorial 2: Displaying a map Q3 Map(this would be your world)
Tutorial 4: Movement how to use events and event response
Tutorial 5: GUI, adding menus to the game.
Tutorial 7: How to do collision detection(add gravity, picking, etc)
Tutorial 8: Special Efects lights, fire efects, etc.

Now in order to find out exactly what u re doin... read the api the class/metods names are pretty much self explanatory thou...

I hope this post helps u.

[Saturn]

In order to understand how irrlicht ticks, I recommend to step through a ISceneManager::drawAll call with the debugger. This really is helpful to understand the inner workings of irrlicht and it isn't hard to understand. Irrlicht is extremely simple.

5000 quads are not worth mentioning these days. The quads are meaningless. More important are the ~ 100 textures and prevention of overdraw. An octree won't help much, but also probably won't be needed. The octree in irrlicht doesn't guarantee a specific order in that geometry is drawn, for everything else it is meaningless, as the GPU will clip geom not in the camera frustum efficiently and early so that this geom will have no negative performance impact.

In this scenario only negative performance impact I can see is that faces are drawn in back to front order instead of front to back. But if this is indeed a problem, it can be solved later on and you shouldn't worry about it now.

[karx11erx]

radiant,

Looks like you only read the last few posts here. I am not gonna repeat myself here, just so much: In a first step, I simply want Irrlicht to render a standard Descent 2 mine. The level loader is in the D2X-XL code, all I need to know is how to feed the scene manager with the mine geometry. So I simply need to throw the level's triangles and lights at the renderer.

hybrid,

I have tried my best to optimize the D2X-XL renderer, but it still isn't as fast as one would expect, probably due to the many state changes required by using many different textures. Opaque geometry is rendered front to back, with a depth only pass first. Transparency is of course rendered back to front in a subsequent pass. So triangle Z pos is the main sorting criterion, not textures, resulting in many possible texture changes. If texture changes cause significant slowdown of the rendering, visibility culling ahead of the driver should be helpful to reduce texture state changes.

Another problem might be posed by huge faces which can occur in Descent levels. I am thinking about adding code that will split such triangles in sufficiently small ones.

What does the octree do then?

I really wonder how well Irrlicht will fare with the many light sources a typical Descent level has (the first level of the Descent 2 main campaign has over 130, a significant amount of which is destructible).

[hybrid]

Well, since you have 5000 quads with 100 textures there's not much to optimize for the geometry, as already mentioned. You should definitely avoid the octree for it, unless it can significantly reduce the number of active textures. But an optimized algorithm for your lavel layout might help better, maybe some kind of portal culling. Huge quads will always be drawn by the octree, only completely culled tris are skipped.
For many lights you will have to provide your own light manager (rogerborg once provided one, it's in the patch tracker). With proper per-pixel lighting you can adjust the number of usable lights to the actual system, but that also requires proper shaders. Otherwise you have to reduce the number of lights to less than 9 per render call.

[rogerborg]

That light manager will almost certainly have rotted by now, and I'm not entirely convinced that it does what I thought it did even when I wrote it.

[karx11erx]

The engine does some kind of portal culling already. I tried to have it gather all subsequent render calls of quads with the same texture and render them in one batch, but that failed to work, and I couldn't be bothered to investigate this at that time.

[hybrid]

Are you sure that you cannot combine textures to larger ones, in order to reduce the state changes? Would make the texture coords slightly more complex, but since it's just about 5k quads...

[Halifax]

That light manager will almost certainly have rotted by now, and I'm not entirely convinced that it does what I thought it did even when I wrote it.

Well light shifting could always be an alternative. It can be done in the user code, or in the engine, but basically you switch between variances of 8 lights. I usually keep it at switching between 2 groups of 8 lights in sucession, which gives you virtually 16 lights. As you can see this could be applied from 8-128 and more lights if you a smart algorithm is made, although light shifting can be noticed when the FPS drops down.

[MasterGod]

What a great idea Halifax. I really like it and with a smart algorithm even small FPS problem can be worked out.

[Halifax]

I really wonder how well Irrlicht will fare with the many light sources a typical Descent level has (the first level of the Descent 2 main campaign has over 130, a significant amount of which is destructible).

Are all those lights dynamic? Are they all affecting the immediate scene that the user is looking at? Have you ever tried just lightmapping the levels, or deferred shading?

That light count is ridiculous if you are considering have them as dynamic lights.

[rogerborg]

That light manager will almost certainly have rotted by now, and I'm not entirely convinced that it does what I thought it did even when I wrote it.

Well light shifting could always be an alternative. It can be done in the user code, or in the engine, but basically you switch between variances of 8 lights. I usually keep it at switching between 2 groups of 8 lights in sucession, which gives you virtually 16 lights. As you can see this could be applied from 8-128 and more lights if you a smart algorithm is made, although light shifting can be noticed when the FPS drops down.

Can you explain what you mean by "light shifting"? It sounds like you're talking about turning lights on and off on a per-frame basis, which I'd imagine would cause some horrendous flickering.

The light manager patch referenced above (with sample code) turns lights on and off on a per scene-node basis, as they are rendered. There's still a limit of 8 simultaneous lights acting on each mesh as it's rendered, but there's no limit on the number of lights that you can add to the scene. The sample app demonstrates 108 lights acting on 54 mesh nodes.

In the discussion thread I countenanced using the light manager to produce 'local lights', where dynamic lights are turned on and off based on the scene heirarchy, so that they only effect local areas.

[Halifax]

Yes that is exactly what I'm saying, and even said it will cause flickering if the FPS drops lower than 120 FPS, or so. It's really an elementary technique, but I figured that I would just throw it out there.

[karx11erx]

I could reduce the lights per vertex to 8 by preprocessing them and picking only those influencing the vertex most.

Of course you do not see all 130 lights at once. But just consider an intense multiplayer game with a lot of laser bolts flying around. Each bolt emits light, and not just a little. A player can fire 4 bolts at a rate of ... umm ... 4 shots per second. Go figure.

Another example: Currently powerups emit some faint light. An exploding player ship scatters all stuff the player had in close vicinity to where the ship blew up. There can be cases where players carry 100+ powerups. That sums up to a very bright light around the powerups. D'oh.

I have a headlight shader program in the current game engine, and just turning on the headlight already has quite an impact on frame rate, and that's only one light source for per pixel lighting. Now how should that go with 8 simultaneous light sources? *shudder*

For all these reasons, lightmaps are not an option, as I would have to recompute all lightmaps affected by dynamic lights each frame. D2X-XL has an (outdated) lightmap lighting option, but it never worked too well. Or I'd need some extremely fast lightmap calculation code, which I don't have.

I know nothing about deferred lighting except the term right now.

Edit: Know something more about it, not sure whether I'd be too happy using it.