Hi,
I have a question concerning mesh loading. I'm currently seeing about the possiblity of converting a previous WWII tank game that I wrote (two or so years back) to using Irrlicht (some screenies available at http://korps.sourceforge.net/images/) and was a bit interested at looking at Irrlicht because of its C# bindings & large community.
As I was skimming around in the code in the C++ API section, in the IMesh and similar classes, I was curious to find that there is no model vertex group information from the model files being stored into the mesh objects. This is quite problematic in my case, as the group information (namely the group name) was being used as an ID lookup into a database table to determine which armor plate a shell had hit (since various parts of the model had different thicknesses in armor, a group was being used to identify these various parts).
My question, is there a way, somewhat like implementing a concrete IMesh/IMeshLoader class (modified from the original loaders), to extract this group information from the model file?
Thanks for any input,
JB
Mesh Loading
Hello hybrid,
The tanks were originally done in .3ds format, and using MS3D can be converted into other formats as well. I was doing some testing tonight using .ms3d format.
The tanks themselves aren't animated - just static meshes at the moment - but it would make sense to have some animated things in the future (such as hatches flipping open - easily able to be done by the 3d modeler).
I would like to use Irrlicht if at all possible, because the biggest thing that has me going for you guys in the .irr format, which allows me to really actually build a model as a scene node, and then just instantiate that over and over again as needed.
Plus before, I wrote my own integrated "engine", so to speak, and I really don't want to recreate the wheel if I don't have to.
If I can't get group information, though, then the whole basics of the system will not work, as in this instance the individual polygons do have meaning. I can drop the model down as an attachment if you'd like.
Any input is appreciated.
The tanks were originally done in .3ds format, and using MS3D can be converted into other formats as well. I was doing some testing tonight using .ms3d format.
The tanks themselves aren't animated - just static meshes at the moment - but it would make sense to have some animated things in the future (such as hatches flipping open - easily able to be done by the 3d modeler).
I would like to use Irrlicht if at all possible, because the biggest thing that has me going for you guys in the .irr format, which allows me to really actually build a model as a scene node, and then just instantiate that over and over again as needed.
Plus before, I wrote my own integrated "engine", so to speak, and I really don't want to recreate the wheel if I don't have to.
If I can't get group information, though, then the whole basics of the system will not work, as in this instance the individual polygons do have meaning. I can drop the model down as an attachment if you'd like.
Any input is appreciated.
Maybe I'm not being clear as to what I'm trying to accomplish here...
I have several model files (which are essentially a decomposed full model that will be built in a scene graph modeler and reassembled so that each functional node can rotate and have points in which can be transformed to the absolute world coordinates as to know where to initialize shells when the guns fire, etc) and would like to support a higher methodology of doing collision detection so that I know which vertex group (as build in any modeling program) contained the triangle that was hit by another object.
As this image shows, there are multiple groupings per one (usually static) mesh object:
I would like to keep things simple and not have to decompose each group into its own mesh, and closer examination of the code did not show the IMeshBuffer object array as being related to groups (although I wish it were).
My only real solution that I can honestly see at this point is to implement the IMesh, IMeshBuffer, and IMeshReader interfaces and write my own as to support this grouping concept.
My question is, am I going about this wrong, is there an easier way, or does Irrlicht simply not handle vertex groups so that it can be a "little bit of everything to everybody" (being able to read from multiple formats with not full support for any single one)?
I have several model files (which are essentially a decomposed full model that will be built in a scene graph modeler and reassembled so that each functional node can rotate and have points in which can be transformed to the absolute world coordinates as to know where to initialize shells when the guns fire, etc) and would like to support a higher methodology of doing collision detection so that I know which vertex group (as build in any modeling program) contained the triangle that was hit by another object.
As this image shows, there are multiple groupings per one (usually static) mesh object:
I would like to keep things simple and not have to decompose each group into its own mesh, and closer examination of the code did not show the IMeshBuffer object array as being related to groups (although I wish it were).
My only real solution that I can honestly see at this point is to implement the IMesh, IMeshBuffer, and IMeshReader interfaces and write my own as to support this grouping concept.
My question is, am I going about this wrong, is there an easier way, or does Irrlicht simply not handle vertex groups so that it can be a "little bit of everything to everybody" (being able to read from multiple formats with not full support for any single one)?
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
A meshbuffer is some kind of a group, with the mesh being all groups belonging together. Finally, a scene node is just one instance of a mesh (when talking about meshes, there are other scene nodes, but that's not relevant here).
Since the 3ds loader does not support groups it simply puts all geometry using the same material into one meshbuffer. Hence you'd lose all information about groups. But if you can export the mesh into another format, e.g. ms3d or b3d, the group information (as long as it still exists in those formats) will be preserved into separate meshbuffers.
There's one problem with this: Since meshbuffers are not named you can only identify them by position (n-th buffer of the mesh), but this position might change when the mesh loader implementation is changed (not very likely once Irrlicht 1.5 is out, because we just updated both loaders). But you should keep that in mind.
Another question is how to get the meshbuffer from collision checking. I don't know if that's easily possible. A working alternative would be to use a simple skeleton and attach hitboxes to the joints. But I guess there are also other possibilities...
Since the 3ds loader does not support groups it simply puts all geometry using the same material into one meshbuffer. Hence you'd lose all information about groups. But if you can export the mesh into another format, e.g. ms3d or b3d, the group information (as long as it still exists in those formats) will be preserved into separate meshbuffers.
There's one problem with this: Since meshbuffers are not named you can only identify them by position (n-th buffer of the mesh), but this position might change when the mesh loader implementation is changed (not very likely once Irrlicht 1.5 is out, because we just updated both loaders). But you should keep that in mind.
Another question is how to get the meshbuffer from collision checking. I don't know if that's easily possible. A working alternative would be to use a simple skeleton and attach hitboxes to the joints. But I guess there are also other possibilities...
JB >> I would say creating your own custom scene node would be the best way to go. Since you are using static meshes it wont be too difficult. Most difficult part would be probably to create your own loader ...for loading your mesh from file (3ds or other).
Like that you would have complete control over everything. Different groupings, collision detection even some simple animations like turning of wheels or opening hatches.
Irrlicht is really versatile in this respect and once I figured out how custom scene nodes works it became one of the most entertaining parts of engine.
Core of each custom scene node is render() function in which you have to present your node to engine in some form which allow engine to render it.
Look at Custom scene node example from examples direstory as a place to start. Then look at ISceneNode, IMeshSceneNode, IMesh and IMeshBuffer interfaces. You may find some inspiration also in SMesh and SMeshBuffer.
Like that you would have complete control over everything. Different groupings, collision detection even some simple animations like turning of wheels or opening hatches.
Irrlicht is really versatile in this respect and once I figured out how custom scene nodes works it became one of the most entertaining parts of engine.
Core of each custom scene node is render() function in which you have to present your node to engine in some form which allow engine to render it.
Look at Custom scene node example from examples direstory as a place to start. Then look at ISceneNode, IMeshSceneNode, IMesh and IMeshBuffer interfaces. You may find some inspiration also in SMesh and SMeshBuffer.
Perhaps, this is the way to go, with writing a custom loader... On the flip side...
It might just be the better idea to just model each group as its own mesh... This idea might prove better in the long run since I had always imagined the ability to "blow up" a tank, in which case each mesh would be capable of interacting as its own object (say in a physics engine such as newton or ageia) and would add a nice awesome feature.
In that regards, I wouldn't necessarily have to write my own mesh loader, just use the existing tools.
Which leads me onto my next idea - is it possible to load a scene object (an .irr file) and then make multiple copies of such, easily?
The idea was always to model these complicated tanks into using a scene graph hierarchy, and then be able to do rotations, etc, via simply being able to edit the transforms directly into the scene graph instead of trying to build some complicated methodology to controlling such an object.
It might just be the better idea to just model each group as its own mesh... This idea might prove better in the long run since I had always imagined the ability to "blow up" a tank, in which case each mesh would be capable of interacting as its own object (say in a physics engine such as newton or ageia) and would add a nice awesome feature.
In that regards, I wouldn't necessarily have to write my own mesh loader, just use the existing tools.
Which leads me onto my next idea - is it possible to load a scene object (an .irr file) and then make multiple copies of such, easily?
The idea was always to model these complicated tanks into using a scene graph hierarchy, and then be able to do rotations, etc, via simply being able to edit the transforms directly into the scene graph instead of trying to build some complicated methodology to controlling such an object.
Yes i think that the irrlicht as it is supports youridea.
Exporting every tank part as seperate meshes, would make blow up the tank easy.
In irrlicht you could have a invisible node in the middle, and all other parts are children to this. The problem is then mixing animated parts like hatch, and static parts. But that is only matter of having a good Tank class to represent these possible type of child nodes.
You could also just animate the parts by rotation when these are individual parts. Moving the pivot point on the model should handle this.
Exporting every tank part as seperate meshes, would make blow up the tank easy.
In irrlicht you could have a invisible node in the middle, and all other parts are children to this. The problem is then mixing animated parts like hatch, and static parts. But that is only matter of having a good Tank class to represent these possible type of child nodes.
You could also just animate the parts by rotation when these are individual parts. Moving the pivot point on the model should handle this.
I also have the problem seperating objects out of one mesh file. Im using b3d and I know that this file format is seperating different nodes, like I need it. But I also need every node from the b3d file to a seperate IAnimatedMeshSceneNode, so that I can give each mesh node a seperate material, shader, physic collision and so on. So I created a b3d file with two objects (a cube and a plane) and loaded this file. But as hybrid says:
the meshbuffer count dont fits with my number of nodes. But this would be the answer, to have one meshbuffer for each b3d node. So my question is, is the meshbuffer limited to an amount of vertices ???But if you can export the mesh into another format, e.g. ms3d or b3d, the group information (as long as it still exists in those formats) will be preserved into separate meshbuffers.
But think of a map (a game level), for example I want to create one which contains about 5 different materials for shaders and even for the physics engine. Than I also have 5 different b3d files !! And thats not cool, and even not when it is possible to put everything in one b3d file. You also have to think that for a game level map you also need some more information, not only the materials. For example Im planning to make a racing game, so I need also information about where the start/finish is. I thought that could be done by creating a pivot or something at the required position... So at least it will be alot more than 5 files for each map... and I dont think you would do it like that 
This is why games companies use their own file formats... nothing in the public domain caters for the needs of each individual game...
To be fair you don't need to store all that information in the b3d file. The start finish line could be marked out in IrrEdit in various ways and putting your 5 different models together could be done in IrrEdit too so that you don't have to align them in your code.
To be fair you don't need to store all that information in the b3d file. The start finish line could be marked out in IrrEdit in various ways and putting your 5 different models together could be done in IrrEdit too so that you don't have to align them in your code.
Mh sorry but I dont understand what you really mean.JP wrote:To be fair you don't need to store all that information in the b3d file. The start finish line could be marked out in IrrEdit in various ways and putting your 5 different models together could be done in IrrEdit too so that you don't have to align them in your code.
You say, that I can put all my 5 different models together in IrrEdit, beside the way that I dont use IrrEdit, Im standing before the same problem. Because I dont want to bring the models together before loading them into irrlicht, I want to seperate them after loading into irrlicht. And why not putting all informations for a map together in one file when it is capable of doing?
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
That's why using a scen format is a good idea. Mesh formats are storing single meshes. Making them work like a scene is...complicated if not worse. The .irr format is an extensible file format, hence using it would make some things easier. You can also use a custom .xml file format or other things, but separating your models, your scene, and your game logic properties is probably a good idea.
Just imagine you want to allow your game users add their own cars. I guess it wouldn't be too easy to let them define the physics in some special way, with specific, expensive tools you use. But having some properties added by (some, not necessarily irrEdit) editor would make this scenario at least somewhat more likely.
Just imagine you want to allow your game users add their own cars. I guess it wouldn't be too easy to let them define the physics in some special way, with specific, expensive tools you use. But having some properties added by (some, not necessarily irrEdit) editor would make this scenario at least somewhat more likely.
I didnt thought that it would be so hard to understand, or even to reproduce my problems. But to make it clearer I will explain it again:
1. Im creating a racing game
2. You know I need to create car models and levels (maps)
call it what you want, a cource to drive
3. I dont want to put all my models like cars, levels whatever in one file!!!
4. that means cars and levels will be in seperate b3d files
5. So lets talk only about the levels, for example this one:
I create the cource (asphalt street) and the environment (grass) in a 3d tool, then I open it into giles and light up the whole scene, than I store this whole map as one b3d file. But when I load this file with irrlicht I dont want ONE IAnimatedMeshSceneNode for the whole map, but I want one IAnimatedMeshSceneNode for the asphlat and one scenenode for the grass environment. So that I can add different materials and shaders to the asphalt than the grass environment. Another thing is that the cars should drive less good on the grass ground than on asphalt street. But this can only be done by knowing the collision between the cars and the grass environment or the street.
6. There will be more than a grass and a asphalt material !
7. And I dont want each ground type from a level in a seperate b3d file.
So I dont think it is uncommon to put all level information into one file.
sorry for misunderstanding?!
1. Im creating a racing game
2. You know I need to create car models and levels (maps)
call it what you want, a cource to drive
3. I dont want to put all my models like cars, levels whatever in one file!!!
4. that means cars and levels will be in seperate b3d files
5. So lets talk only about the levels, for example this one:
I create the cource (asphalt street) and the environment (grass) in a 3d tool, then I open it into giles and light up the whole scene, than I store this whole map as one b3d file. But when I load this file with irrlicht I dont want ONE IAnimatedMeshSceneNode for the whole map, but I want one IAnimatedMeshSceneNode for the asphlat and one scenenode for the grass environment. So that I can add different materials and shaders to the asphalt than the grass environment. Another thing is that the cars should drive less good on the grass ground than on asphalt street. But this can only be done by knowing the collision between the cars and the grass environment or the street.
6. There will be more than a grass and a asphalt material !
7. And I dont want each ground type from a level in a seperate b3d file.
So I dont think it is uncommon to put all level information into one file.
Not relevant to my project. But if it will be some day: noone has to buy giles, using the b3d format is still open to everyone. The custom properties I need to specify which ground type is grass and which is asphalt will be defined in the nodes name in b3d file.hybrid wrote: Just imagine you want to allow your game users add their own cars.
sorry for misunderstanding?!