I'd like to add fbx support.

JoshM · Post by **JoshM** » Mon May 04, 2009 2:17 pm

I think that it would be a great addition to the irrlicht engine. I have linked the autodesk fbx sdk into the visual studio 2009 project, and I initially tried to just read all of the data into the .x reader data structures, and have all of the rest of the work done for me, but I've determined that would be a terrible design decision, so I'm starting from scratch again.

One of the initial problems that I had was due to the fact that I hadn't studied how the data structures work. I'll probably have some questions through out the project which I'm hoping to get done hopefully late this week, or early next week. One thing that I'm wondering is what kind of support that I can receive for testing and integration into linux, and mac computers. I'm kind of new to open source development, so I'm not sure if I would be expected to implement it for all platforms. I don't have a mac, so it would be hard for me to add and test support for it.

Can anyone give me tips for a good way to really get started on this project, as far as learning the data structures, and the flow of the program? Like I said, I'm kind of new to open source programming, and I'm not new to programming, but I'm kind of new to pretty large projects. Thanks in advance for any help.

I hope that this is the correct part of the forum to post this.

Thanks.

JoshM

rooly · Post by **rooly** » Tue May 05, 2009 3:14 am

the beauty of open source is that you only do what you want to do. if someone else needs it to do something else, they have the option of asking you to do it for them, or doing it themself.

point is, just document well and you should be fine, if you make it windows-only, someone will probably eventually port it if you don't

hybrid · Post by **hybrid** » Tue May 05, 2009 6:56 am

If you only include headers from irrlicht, the sources should be pretty portable already. Get some ideas from the other file loaders and everything will be fine. It's more important to get the code straight and simple, in order to make it easy to use it in the engine or elsewhere.

JoshM · Post by **JoshM** » Tue May 05, 2009 6:37 pm

ok thanks guys that helps. I'll probably have more questions as the project proceeds and I'll post them in this thread. Especially near the end when I'll be linking stuff and making relative paths for the libs for the autodesk sdk and such.

Thanks.

JoshM

JoshM · Post by **JoshM** » Wed May 20, 2009 5:35 pm

I haven't been able to work on the project for the last week and a half because my computer had a bad mother board. I'm back and working on it again. I have a question about texture layers that I hope that someone can answer.

It looks like there are 3 types of texture layers supported in the irrlicht engine. One is specified by S3DVertex which is a standard mesh with texture coordinates. The next is S3DVertex2TCoords which includes a layer for light maps. The final one is S3DVertexTangents which supports a normal map. Am I thinking about this the right way? Can there be more than 2 texture layers? I'm still trying to learn the layout of the engine and will probably have more questions eventually..

I found this by looking at the CMeshBuffer.h file.

Thanks.

JoshM

hybrid · Post by **hybrid** » Wed May 20, 2009 5:46 pm

Texture layers are not really bound to the vertex types. We have 4 texture layers in the standard Irrlicht configuration. Those textures can be used whatever the material wants to do with it. The elements of the vertices are sometimes required to render a special effect, but e.g. you can also lightmap without a second set of texcoords. The actual render behavior is set in the material type and the other SMaterial elements.

JoshM · Post by **JoshM** » Wed May 20, 2009 6:19 pm

ok that really helps

Josh

JoshM · Post by **JoshM** » Thu May 21, 2009 5:55 pm

One thing that I'm looking into is how to best link the fbx sdk libs into the engine. There are many different configurations of libs, and all together they take about 1 GB of space. With this size it is unreasonable to add them to the project to be downloadable with the general downloadable irrlicht engine. I'm currently just going to add the 2008 visual studio lib to a folder. What is the best way to handle linking 3rd party libs that are very large?

Once I get to a point where I'm ready to check in the code, can I have someone that really knows the irrlicht engine well to do a code review? I didn't check out the project in svn so I might need help actually checking it in as well.

hybrid · Post by **hybrid** » Thu May 21, 2009 9:11 pm

The first place for such extensions is irrExt. But we won't place such large libs in any version of irrExt or Irrlicht. Moreover, we have to be really careful with licensing etc. But adding the code in disabled state, and allow the user to reenable and recompile this loader could be possible.
Once you have something running you can submit it to either the Irrlicht or the irrExt patch tracker. Then we'll review the code anyway.

BlindSide · Post by **BlindSide** » Fri May 22, 2009 8:38 am

I for one don't think it's necessary to link the FBX sdks. There is a fully working FBX exporter for Blender (Supports animations etc) and it doesn't need to reference any libs.

I am personally looking forward to FBX support in Irrlicht as it has been hailed as "the new X" but I fail to see the point of including the Autodesk SDK.

May I suggest perhaps you study the python code for the Blender exporter here: http://wiki.blender.org/index.php/Exten ... rt/FBX-xna

Coupled with a close look at the current ASCII .X mesh importer in Irrlicht (Which I believe structurely is a fairly similar format, so some of the parsing code should be reusable.) , I think you can have a working importer in a fairly short amount of time.

JoshM · Post by **JoshM** » Fri May 22, 2009 2:55 pm

Sounds like it might be a good alternative I'll look into it.

JoshM

JoshM · Post by **JoshM** » Fri May 22, 2009 5:20 pm

The issue is that it seems that autodesk seems to occasionally change the fbx format, and with the fbx sdk, with any changes that are made, most likely, all that you would need to do is change from one lib file to another. Wouldn't it be better to use the autodesk sdk for this reason? If I were to make a reader, then I would probably do that in a separate project and link that in as a lib anyways. I have no idea what is taking so much space in the autodesk libs. It's like a bunch of dlls with sizes between 30 MB and 70 MB for many different configurations. There are some issues that might need upkeeping if I implement my own importer. What do you guys think about the issues at hand?

My hope is to write something that is as usable as possible, and that I can pass off to you guys so that if any changes are needed then you guys can fix it as necessary and add new components as necessary as well. I'm not entirely sure what to do, but do you think that it would be worth my time to make my own fbx importer package with more of an open source gnu license that other people can update and use freely? I really don't know how long that would take and of course time is an issue. I don't want it to be a lifelong project.

When I link in the autodesk sdk I get some compiling errors and a ton of linker errors, so it's kind of important to decide if I'm not going to use the autodesk sdk before wasting a bunch of time with that kind of stuff. I think that the linker errors are due to the fact that the autodesk sdk is compiled in C, but I'm not sure.

JoshM

FuzzYspo0N · Post by **FuzzYspo0N** » Fri May 22, 2009 5:58 pm

linking the sdk makes absolutely no sense.. Blindside knows what he talking about

The reader is fine, when formats change, you update the reader to read the version and act accordingly.

Think about 300 lines of code, no extra overhead VS
GIGS?? not even worth considering

The reader is a simple and smooth way to handle it, you just handle the versions according to the version number in the header. The lucky thing about the other mesh formats is that they all have been around for so long nobody changes them.

FBX is awesome, and the updates are moving formats forward, the "upkeep" wouldnt necessarily be solely up to you. Thats the point of a community, and FBX internal loader would be awesome.

JoshM · Post by **JoshM** » Fri May 22, 2009 6:16 pm

Ok, I'll take the advice, and try and implement a reader. I'm probably going to do it as a smaller different project. I'll probably have more questions soon, and thanks for sticking with me on this.

JoshM

JoshM · Post by **JoshM** » Sun May 24, 2009 5:35 pm

ok, so I've been looking at that python script, and I have learned a lot, but I'm having a major problem that I'm hoping that some of you guys will have good advice on. A lot of the data is written in binary, and I'm having a heck of a time trying to decipher stuff like big endian or little endian, and precision for the floats and doubles and such. Also the format is a little confusing on some parts. . I think that once I am able to read the binary in so that the data is plainly visible to me, then it might be a downhill battle from there. That's what I'm hoping.

Can some of you guys give me tips on how best to read the data and account for that kind of stuff. I've spent a few hours on this particular issue and thought that I would ask you guys for tips.

Thanks

JoshM