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

[hybrid]

I'm also sorry for this misunderstanding, but as it seems I wasn't the only one to get it wrong I'm glad that it's solved now

[rogerborg]

I agree that we should admit that the problem is with everyone else.

[MasterGod]

And I think it would really make sense to stop this discussion here and become more productive again. We had enough of such discussions lately. Concentrating on more important stuff would help. Might even give some time to work on the docs

My bad

P.S
After reading it all it seems nobody (except hybrid) understood karx11erx. He didn't mean to insult anyone, just to state his opinion about the docs.

Well, it's pretty interesting to see how people react in different situations == Why I love forums

Edit:
By the way karx11erx, I'll be very interested to know your opinion about the docs I'm going to write for my engine after what you've written there so don't disappear on me!!
(Also that would prove how much truth / frustration you had in your saying)

[Acki]

it seems nobody (except hybrid) understood karx11erx. He didn't mean to insult anyone, just to state his opinion about the docs.i

I ran in this trap, too !!!
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=26248

[MasterGod]

it seems nobody (except hybrid) understood karx11erx. He didn't mean to insult anyone, just to state his opinion about the docs.i

I ran in this trap, too !!!
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=26248

Yeah I remember that

It seems no one can criticize the docs

[hybrid]

Well, everyone should enhance the docs. I know that criticizing is much easier than working on it, but is usually doesn't help that much. Since documentation is - almost by definition - never finished, there's not much sense it telling us that the docs have to be enhanced. So better use the time you'd invest to post such information to enhance the docs and post patches.

[Acki]

well, and so we get in this circle again, and again...

just to be clear:
I need the doc to learn something...
now the part I want to learn is missing something...
as far as I wanted it to learn I don't know about it...
so how could I enhance something I have no knowledge of ???

on the other side the developers know what they did there...
they do some comments like "//! this function does something fancy."...
so why can't the add paramter/return value explanations, too ???
it would take less than a minute to add it...

If I did this at work I'll be crucified by the people who have to work with my functions, because they'll have to phone/meet me every time they miss an ecplanation and they're not sure what this things are for...

please don't get me wrong again...
I don't want to start this discussion again and I don't want to blame anyone !!!
that's just my opinion and I know I shouldn't post this, because it will probably start this all again...
but I'll now hit the submit button, take it or leave it...

[MasterGod]

So better use the time you'd invest to post such information to enhance the docs and post patches.

I did -_-...
http://irrlicht.sourceforge.net/phpBB2/ ... p?p=151893

Please don't tell me you need a test case for that too

[hybrid]

In fact I needed one, but as it seems it's indeed override instead of overwrite. However, that's probably a problem with Niko and me speaking German natively, and we have the same word for it...

[karx11erx]

Master,

you're right on the spot.

My opinion on the docs is that there should be a document introducing each concept in the engine from a general point of view and then relate that to the concrete implementation. Kind of top down doc design.

Kind of "you have a renderer which works on scenes consisting of scene nodes built from meshes" or so (just an example).

Then explain "scene", "scene node", "mesh", first in an abstract way, making any relationships and hierarchies clear, and finally write about the underlying implementation. Add some example code lines how to code this.

Finally, you can get into details, like handling of different mesh types (objects, animations, transparency) etc.

Just take my example: From the naming I'd have thought that a mesh buffer collects meshes, but it's the other way round. Go figure how hard it is to get around such premises when trying to understand some tutorial code all own your own. Such misconceptions can be massively in the way of understand what some code is doing.

[karx11erx]

Well it's going to be more than a few lines of code...

And you won't have to dig through loads of code. Just look at source/irrlicht/C3DSMeshFileLoader.cpp which is how 3DS models are loaded. From that you should be able to see fairly clearly how you could about doing it yourself.

I looked into this now. There's way to much happening there, particularly in regard to handling the 3ds format.

What I need is some simple information.

First of all, how to handle static geometry consisting of an arbitrary number of triangles (i.e. 3 vertices consisting of a vector (float*3), a uv vector (float*2), a color (float*4), and a texture). As far as I have understood, all triangles with the same material (can go into one mesh buffer). Just how? And what is a material? Just the texture? Color also?

So I am having a few mesh buffers. These go into a mesh, right? For me that mesh would be the entire level geometry.

How do I connect that mesh to a scene node?

Can I expect any help on this by people who know all that already, or can I dig through the Irrlicht source code for weeks in the hope to finally get all pieces together?

[hybrid]

Well, 3ds is a very complex format, hence the loader is also pretty complex. The STL loader is far simpler, so you might want to look into it.
You create a new meshbuffer and add S3DVertex elements to it, which hold all the necessary information for a single point in 3d space. The faces are built from the indices also contained in the meshbuffer. Irrlicht uses clockwise winding, so add 3 indices per triangle in such a way that the vertices are visited clock-wise when looking at the front face of the triangle.
Every IMesh has a method to add meshbuffers, so do that with a newly created SMesh. This SMesh can be put into an IMeshSceneNode with the proper method from the scene manager.

[karx11erx]

Thanks.

I have derived some code what I found in the STL loader, which is pretty straight forward.

The next two questions are:

What is the proper organization for all faces of the level's geometry? Should I create one mesh buffer per texture used in the level, even if the faces are far away from each other, and trust the octree builder to properly deal with it?

How do I insert textures in mesh buffers? The SMaterial class seems to have a texture handle, but it logically does not expect it to be set at class instantiation.

[hybrid]

Well, at some point you should consider looking into the API. It will tell you about the setTexture methods...
The organization depends on what you want to do with the buffers, and which performance you want to achieve. It could be that the octree has some advantage if you break up your mesh into smaller parts, but IIRC it simply uses a collection of faces from all meshbuffers. However, your gfx card could prefer to get a decent amount of data in each buffer, but also not too many. Depending on your card this number will be somewhere between 2000 and 65000 (often on the lower end...). Moreover, if you can reuse parts of your mesh it's necessary to have those parts in a separate buffer.

[karx11erx]

I have seen the setTexture() method, but the API says nothing about when to use it.

It also says nothing about how to organize meshes in a good and efficient way so that the renderer would work as fast as possible. Currently I am creating a mesh buffer for each geometry quad, and that's probably not the best solution.

And so on, and so on.

I said it already, there is no documentation explaining how all the parts of the Irrlicht engine work together.

Unfortunately, I don't need a black box renderer, I need to understand how it works.