ZDimitor. maybe you have clue. using your gile(s) exporter and loading it to IRR while running DirectX everything works fine. running the same MY3D using OPENGL, I experience the following strange problem. whenever the camera focuses a MY3D-gile(s)-lightmapped-object, all GUI elements (2D pics, fonts etc.) turn black. as soon as the camera gets out of the focus of these MY3D-objects all GUI elements turn back to normal. as I said, the problem arises only, when using OPENGL. it is not an issue for DIRECTX. any idea ?
wolfsb, berlin
Do you wants to include My3DTools in Irrlicht 0.9 ?
vermeer: it seems you did have a chance to try out Murphy's OBJ2MIM tools. So far, I haven't seen an official release (not even on his web site), which is fine, because it is Murphy's decision whether or not or when he is going to make this tools available to the general public. but unless I haven't tried it out I can not really vote for or against .... so, to decide if it suits, we should have a possibility to work with it.
wolfsb, berlin
True, in someway....But the man is moving from one town for another, he got his PC fried or something, and forgot even his developing 3d card in the other town....got by car in a very stormy day even....I bet he can't do more than he does
That is: He WILL put the very last version up, and if all things play against him, the earth skins, and his pc get bruned with all his coding inside...I have a 100x100 working last betatest version...
Indeed, he's delaying it also as he wanted to make (and the version I have already makes it, just that I think he wants to polish a very tiny thing) it so really easy for the user, that the user didnt have to type in DOS window :
OBJ2MIM whatever the obj with the texture.obj whatever the obj with lightmap also in channel 1.obj
...plus the desired settings, if any wished.
But instead, just shift clicking, as is a windows like aplication now+ a dos command line for those prefering to type it
I am doing other project, a huge level, non irrlicht (I have enough demands to not go and use Irrlicht till 2030 , lol...XD ..I just like helping this engine, so OS based, and so free..and for the great comunity ) ...and...I used his MIM tools as a perfect visor of the level, as he made me a viewer (the irrlicht dll) , so I just put my 2 objs with mtl and texture, run the thingy, and load the mim file in the viewer: This is GREAT for an artist. I go tweaking the objs as I like, change UVs in the lightmap one, or in the other, independently (what i cannot change is the mesh(vertex, triangulation, smoothing), which is allways just a copy with differnt tga asigned
) And as is OBJ, I can handle it with a load of free and purchased tools I have...I know you are eager to try it...
Ehm...But you bet , the mimtools will b eup there, he's worked such a LOAD to not upload it...
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
2wolfsb:
Read how to fix it here
http://irrlicht.sourceforge.net/phpBB2/ ... c&start=30
BTW:
I told about subject with niko and he agreed to do it in next release!!!
Read how to fix it here
http://irrlicht.sourceforge.net/phpBB2/ ... c&start=30
BTW:
I told about subject with niko and he agreed to do it in next release!!!
is good thing....
I think MIM should be adopted, too...
..
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
The problem with using the .x format, is that it's material format is different than IrrLicht's materials. It would be hard to write an .x importer which parses the materials in the .x file and is capable to set the appropiate IrrLicht material types.
If we had a common .irr format animated, and with all the IrrLicht material types, I tihnk it would be much better. I don't know if you can access all the bone information for an animated mesh inside IrrLicht code, and if you can't, the engine would be extended to allow that. Then, to have all the file formats supported, it would just be a matter of writing an application in IrrLicht (the standard Mesh Viewer would fit) with all the mesh loaders manually attached, which loads a mesh in any of the formats that IrrLicht currently has support for (both offial and user-made loaders), and writes a file in the .irr format. Apart from this method, which wouldn't add any advantages, as the materials problem would still be in, thre would be a bounch of exporters for different modellers. For example, would be cool if the current exporters for .my3d would export to .irr, and all of the octools and that stuff.
For the .irr format, I would vote for an XML-based format.
If we had a common .irr format animated, and with all the IrrLicht material types, I tihnk it would be much better. I don't know if you can access all the bone information for an animated mesh inside IrrLicht code, and if you can't, the engine would be extended to allow that. Then, to have all the file formats supported, it would just be a matter of writing an application in IrrLicht (the standard Mesh Viewer would fit) with all the mesh loaders manually attached, which loads a mesh in any of the formats that IrrLicht currently has support for (both offial and user-made loaders), and writes a file in the .irr format. Apart from this method, which wouldn't add any advantages, as the materials problem would still be in, thre would be a bounch of exporters for different modellers. For example, would be cool if the current exporters for .my3d would export to .irr, and all of the octools and that stuff
.For the .irr format, I would vote for an XML-based format.
"The problem with using the .x format, is that it's material format is different than IrrLicht's materials. It would be hard to write an .x importer which parses the materials in the .x file and is capable to set the appropiate IrrLicht material types. "
Is there really a need of complex materials and multitexturing for characters animation? I never use that in those...I can understand it for terrain...
For characters, only "need" that I see , maybe normal maps, but for that there could be already md5, carrying that info....
BTW, if there were a convertor of x --->irr or whatever, ok then, but in the practice the converters tend to not get done...seen sadly in other engines....
Is there really a need of complex materials and multitexturing for characters animation? I never use that in those...I can understand it for terrain...
For characters, only "need" that I see , maybe normal maps, but for that there could be already md5, carrying that info....
BTW, if there were a convertor of x --->irr or whatever, ok then, but in the practice the converters tend to not get done...seen sadly in other engines....
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
I'm glad to hear my3d will be included in Irrlicht. Loaders are generally small (not too much bloat to include in the prebuilt lib), and as far as I'm concerned it's really almost a matter of the more the merrier.
I thought I'd throw in my two cents on the subject of a "native" Irrlicht format, the problems associated with importing into Irrlicht, etc.
MIM is, in fact, my attempt at an XML-based ".Irr" format. Murphy's Irrlicht Mesh. MIM has converters from a number of file formats (including OBJ, which is supported by many packages). You mentioned having a way to get from OCTTools -- getting from OCT to MIM isn't very hard -- my OCT2OBJ and then OBJ2MIM. I could throw together an OCT2MIM pretty quickly if anyone really cared.
The problem with materials (which you mention) -- and animation too -- is that any modeler's features and any other format's features don't necessarily map exactly to stock Irrlicht features (or even proposed Irrlicht features). There's nothing to do about this besides adding features to Irrlicht, but that gets to a point of ridiculousness. That's why for MIM, I simply tried to make it as Irrlicht-ish as possible, leaving the decisions about how to map features completely up to the conversion or export process (and, thus, hopefully up to the artists). In short, the concept is that if Irrlicht can do it -- MIM can do it. Whether it can actually be done should be a function the exporters and converters and not of the file format itself. For the most part, I think I've met this goal.
As for X -> Irr... I could do an X to MIM easily enough (you may remember I started one but ditched it because it wasn't particularly useful), but I don't think there's currently much of a point unless animation is carried through, and nobody has yet proposed a real solution to the animation problem (different kinds of animation, differences in the bone animation system used by different formats/modelers/engines). I mean... it'd be easy enough to just have MIM's animation exactly the same as X's (or any random bone animated format's) animation. This would make conversion from an animated X to MIM simple (you could then manipulate the materials and such exactly as you would with any other MIM). But from other animated formats to MIM... not as simple at all. Is that really a good idea? Maybe it would serve to get the job done, but it just doesn't strike me as great. Jedive, you likened the .Irr concept to .B3D. In general... aren't B3D animations done with Blitz-specific tools? Fine, I could implement an Irrlicht-specific animation system. Who's going to write the character animator tool? The solution I think I would lean towards (agree? disagree?) if I actually felt pressure to get animation working in MIM is to pick a tool (probably Blender or Anim8or) and implement a generic-ish animation system for Irrlicht that would be compatible with it, and then write an exporter or converter for that. If it can then be made to work with other formats -- great. But I doubt I would write the converters/exporters for it.
I've said this all in reference to MIM, but it's true of any format.
But on top of all this... I'm just not convinced that a "file format" exactly is the right solution for the types of things people (myself included) seem to want done in an Irrlicht file format. I think having a really good binding to a scripting language or something is actually the way to go. Instead of having a file with a fixed format, an ".Irr" file would just be a script (in Python or JavaScript or maybe even C#) which built the Irrlicht objects at runtime just exactly how you want them. I think this would provide far more control and flexibility than would be practical to provide with a fixed format.
I thought I'd throw in my two cents on the subject of a "native" Irrlicht format, the problems associated with importing into Irrlicht, etc.
Converting bone based animation between formats isn't easy. Not all bone based animation works exactly the same. In order to support conversion from multiple formats, you'd actually have quite a bit of code to write, including probably having a "generic" bone based system in Irrlicht, which there isn't yet. There's some more info on this in the first post of the MIM thread.Jedive wrote:The problem with using the .x format, is that it's material format is different than IrrLicht's materials. It would be hard to write an .x importer which parses the materials in the .x file and is capable to set the appropiate IrrLicht material types.
If we had a common .irr format animated, and with all the IrrLicht material types, I tihnk it would be much better. I don't know if you can access all the bone information for an animated mesh inside IrrLicht code, and if you can't, the engine would be extended to allow that. Then, to have all the file formats supported, it would just be a matter of writing an application in IrrLicht (the standard Mesh Viewer would fit) with all the mesh loaders manually attached, which loads a mesh in any of the formats that IrrLicht currently has support for (both offial and user-made loaders), and writes a file in the .irr format. Apart from this method, which wouldn't add any advantages, as the materials problem would still be in, thre would be a bounch of exporters for different modellers. For example, would be cool if the current exporters for .my3d would export to .irr, and all of the octools and that stuff
For the .irr format, I would vote for an XML-based format.
MIM is, in fact, my attempt at an XML-based ".Irr" format. Murphy's Irrlicht Mesh. MIM has converters from a number of file formats (including OBJ, which is supported by many packages). You mentioned having a way to get from OCTTools -- getting from OCT to MIM isn't very hard -- my OCT2OBJ and then OBJ2MIM. I could throw together an OCT2MIM pretty quickly if anyone really cared.
The problem with materials (which you mention) -- and animation too -- is that any modeler's features and any other format's features don't necessarily map exactly to stock Irrlicht features (or even proposed Irrlicht features). There's nothing to do about this besides adding features to Irrlicht, but that gets to a point of ridiculousness. That's why for MIM, I simply tried to make it as Irrlicht-ish as possible, leaving the decisions about how to map features completely up to the conversion or export process (and, thus, hopefully up to the artists). In short, the concept is that if Irrlicht can do it -- MIM can do it. Whether it can actually be done should be a function the exporters and converters and not of the file format itself. For the most part, I think I've met this goal.
Yeah, Vermeer, I agree. Mostly what you'd want on a character would be bumpmapping, which is supported by MIM. It's also possible you'd want a custom material type for a ghost or a character made of energy or something. Since MIM doesn't actually have material types (just ways to set up Irrlicht mesh buffers), this is also often possible without modifying the MIM format or loader at all -- you just need to alter the exporter (or the MIM itself) to use your custom material's ID instead of one of the built in ones and include the required data.vermeer wrote: Is there really a need of complex materials and multitexturing for characters animation? I never use that in those...I can understand it for terrain...
For characters, only "need" that I see , maybe normal maps, but for that there could be already md5, carrying that info....
BTW, if there were a convertor of x --->irr or whatever, ok then, but in the practice the converters tend to not get done...seen sadly in other engines....
As for X -> Irr... I could do an X to MIM easily enough (you may remember I started one but ditched it because it wasn't particularly useful), but I don't think there's currently much of a point unless animation is carried through, and nobody has yet proposed a real solution to the animation problem (different kinds of animation, differences in the bone animation system used by different formats/modelers/engines). I mean... it'd be easy enough to just have MIM's animation exactly the same as X's (or any random bone animated format's) animation. This would make conversion from an animated X to MIM simple (you could then manipulate the materials and such exactly as you would with any other MIM). But from other animated formats to MIM... not as simple at all. Is that really a good idea? Maybe it would serve to get the job done, but it just doesn't strike me as great. Jedive, you likened the .Irr concept to .B3D. In general... aren't B3D animations done with Blitz-specific tools? Fine, I could implement an Irrlicht-specific animation system. Who's going to write the character animator tool? The solution I think I would lean towards (agree? disagree?) if I actually felt pressure to get animation working in MIM is to pick a tool (probably Blender or Anim8or) and implement a generic-ish animation system for Irrlicht that would be compatible with it, and then write an exporter or converter for that. If it can then be made to work with other formats -- great. But I doubt I would write the converters/exporters for it.
I've said this all in reference to MIM, but it's true of any format.
But on top of all this... I'm just not convinced that a "file format" exactly is the right solution for the types of things people (myself included) seem to want done in an Irrlicht file format. I think having a really good binding to a scripting language or something is actually the way to go. Instead of having a file with a fixed format, an ".Irr" file would just be a script (in Python or JavaScript or maybe even C#) which built the Irrlicht objects at runtime just exactly how you want them. I think this would provide far more control and flexibility than would be practical to provide with a fixed format.
I think it would still be important to get other tools to export to my3d then. 3dmax was first, then giles, it would be interesting if someone could write a python exporter for blender, or ac3d or any other 3d app that allows you to place lights.
on the other hand, Zdimitor just announced he'll be including My3dSaver with his next release, which converts and loads bsp,lmts,my3d-separate lightmaps and 3ds into My3d. So why not extend its support to MIM and even Csm loader and Dmf loader? then it would really become an all-around tool; the only thing would be getting you guys in contact: Zdimitor, Murphy, Jox, Mohaps and Ilbuzzo.
blender support would rock
and I think Murphy's progress on that regard would contibute a lot.
on the other hand, Zdimitor just announced he'll be including My3dSaver with his next release, which converts and loads bsp,lmts,my3d-separate lightmaps and 3ds into My3d. So why not extend its support to MIM and even Csm loader and Dmf loader? then it would really become an all-around tool; the only thing would be getting you guys in contact: Zdimitor, Murphy, Jox, Mohaps and Ilbuzzo.
blender support would rock
and I think Murphy's progress on that regard would contibute a lot." 3dmax was first, then giles,"
Giles was supported since a while with th eOBJ+obj by mimtools.Mohaps made a loader too, and I even think Murphy made one. Though Obj+obj for me its better as being only-artist, don't like my full name put in the files I export, thing done when you save/export anything with giles...I can easily remove from objs, at least, they'r ascii. besides, being an univrsal format like OBJ, I still can edit a lot the giles output of the two channels, materials etc. With a gls file, I can do nothing else than just load directly.If u think that's enough...that's not in 3d. There's allways a situation when u need the flexibility. Have been my profession, I know this sadly too well...
Reason why I keep liking specially the Blender in oct tools, and obj in mim's aproach that Murphy made. besides that he also made fsrad free radiosity lightmapper work in linux, and load directly its format in irrlicht.
" it would be interesting if someone could write a python exporter for blender, or ac3d or any other 3d app that allows you to place lights. "
the loading of lights and stuff that u say (btw, 3ds does not support shared uVs, neithe rcounts higher of 65,000, or longer than 8 letters material names(old dos limit )) is since long supported by OCT Blender python plugin also made by murphy.
ac3d is comercial. I'd se it more sensible use Blender or Anim8or for building the scene.
I *know* linux users have ben pretty able to handle well Anim8or in linux Wine.
So , wether My3d or MIM or both, for ease of setting up an scene, maybe Anim8or has the best quicker learning curve.
As a difference with blender, it at least supports a real autosmoothng normals shading value.
The UI is very similar to what non-blender users are used to handle. And newbies get the hang of it in no time. Is easier than radiant or any of those.
Just no deal of export animation for it. No OS, no enough specs for it, I was told by someone quite expert in the matter...
Anim8or would be a free and easy as it can be to deal scene builder, with th eadvantage of being already familiar to some, and having the main aproach of...being easy to handle.
Blender anyways, keep having the advantage of being fully multi platform, but if Linux people report to be ok with wine...
or support both. Just i see it much more closed Anim8or...though the an8 files are ascii and supposedly easy to parse...(the only-one coder works in nvidia)
I personally see quicker to learn than Blender.
But for animation I keep recomending blender, for the fact of it export to x, md2, md3, md5, and has joint pinning, not in Anim8or yet.
But we speak bout scenery building, so forget this last paragraph.
is not a bad idea to use Anim8or for level basic first arranging. My only fear is...linux users may have probs there. And with Blender, I have a feeling too many users don't even care to open it, fearing the UI and learning curve.
Mainly, both are good ideas. You loose a bit excluding one, but both are free to use coemrcially or not, so , good to go, each.
Just that...well, that's exactly what already Murphy did with octools(blender plugin, oct viewer, oct loader, fsrad modification, oct2obj (for obj freaks like me)) long ago...
and the mim tools are already supporting max, giles, maya, lightwave, xsi, blender, allways levels with texture, smoothing normals, etc, lightmaps.And pretty anyother application: tgas, render to texture, and obj are that universal. And this has been done since long ago in Murphy's development... times when my3d was Max centric only.
As an artist, I already had my experiences on editing and reading the xml file that is *.mim, and it's really convenient that the artist can change stuff at will even after exported.
Dunno...
Imho there's no harm in including both in engine.As other loaders.
Giles was supported since a while with th eOBJ+obj by mimtools.Mohaps made a loader too, and I even think Murphy made one. Though Obj+obj for me its better as being only-artist, don't like my full name put in the files I export, thing done when you save/export anything with giles...I can easily remove from objs, at least, they'r ascii. besides, being an univrsal format like OBJ, I still can edit a lot the giles output of the two channels, materials etc. With a gls file, I can do nothing else than just load directly.If u think that's enough...that's not in 3d. There's allways a situation when u need the flexibility. Have been my profession, I know this sadly too well...
Reason why I keep liking specially the Blender in oct tools, and obj in mim's aproach that Murphy made. besides that he also made fsrad free radiosity lightmapper work in linux, and load directly its format in irrlicht.
" it would be interesting if someone could write a python exporter for blender, or ac3d or any other 3d app that allows you to place lights. "
the loading of lights and stuff that u say (btw, 3ds does not support shared uVs, neithe rcounts higher of 65,000, or longer than 8 letters material names(old dos limit )) is since long supported by OCT Blender python plugin also made by murphy.
ac3d is comercial. I'd se it more sensible use Blender or Anim8or for building the scene.
I *know* linux users have ben pretty able to handle well Anim8or in linux Wine.
So , wether My3d or MIM or both, for ease of setting up an scene, maybe Anim8or has the best quicker learning curve.
As a difference with blender, it at least supports a real autosmoothng normals shading value.
The UI is very similar to what non-blender users are used to handle. And newbies get the hang of it in no time. Is easier than radiant or any of those.
Just no deal of export animation for it. No OS, no enough specs for it, I was told by someone quite expert in the matter...
Anim8or would be a free and easy as it can be to deal scene builder, with th eadvantage of being already familiar to some, and having the main aproach of...being easy to handle.
Blender anyways, keep having the advantage of being fully multi platform, but if Linux people report to be ok with wine...
or support both. Just i see it much more closed Anim8or...though the an8 files are ascii and supposedly easy to parse...(the only-one coder works in nvidia)
I personally see quicker to learn than Blender.
But for animation I keep recomending blender, for the fact of it export to x, md2, md3, md5, and has joint pinning, not in Anim8or yet.
But we speak bout scenery building, so forget this last paragraph.
is not a bad idea to use Anim8or for level basic first arranging. My only fear is...linux users may have probs there. And with Blender, I have a feeling too many users don't even care to open it, fearing the UI and learning curve.
Mainly, both are good ideas. You loose a bit excluding one, but both are free to use coemrcially or not, so , good to go, each.
Just that...well, that's exactly what already Murphy did with octools(blender plugin, oct viewer, oct loader, fsrad modification, oct2obj (for obj freaks like me)) long ago...
and the mim tools are already supporting max, giles, maya, lightwave, xsi, blender, allways levels with texture, smoothing normals, etc, lightmaps.And pretty anyother application: tgas, render to texture, and obj are that universal. And this has been done since long ago in Murphy's development... times when my3d was Max centric only.
As an artist, I already had my experiences on editing and reading the xml file that is *.mim, and it's really convenient that the artist can change stuff at will even after exported.
Dunno...
Imho there's no harm in including both in engine.As other loaders.
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
I had forgotten about Vermeer's valuable contribs!!! 
I agree with you that anim8or may be a bit easier to learn than blender, but blender is nowadays a full 3d package and very feature rich, and as you said, completely multi plattform. Once you get the feeling of how blender works there's no stopping you from learning new things in it. Anim8or may be used as a modeler to export to 3ds and then load models into blender for texturing-lighting-rendering. Anyway, blender's import capabilities cover a very wide range of formats.
I'd say blender all the way tio.(community-wise speaking)
I agree with you that anim8or may be a bit easier to learn than blender, but blender is nowadays a full 3d package and very feature rich, and as you said, completely multi plattform. Once you get the feeling of how blender works there's no stopping you from learning new things in it. Anim8or may be used as a modeler to export to 3ds and then load models into blender for texturing-lighting-rendering. Anyway, blender's import capabilities cover a very wide range of formats.
I'd say blender all the way tio.(community-wise speaking)
"I had forgotten about Vermeer's valuable contribs!!! Embarassed Embarassed"
haha, lol...
"I agree with you that anim8or may be a bit easier to learn than blender, but blender is nowadays a full 3d package and very feature rich,"
yup, more powerful as a matter of fact...
" and as you said, completely multi plattform. Once you get the feeling of how blender works there's no stopping you from learning new things in it. Anim8or may be used as a modeler to export to 3ds and then load models into blender for texturing-lighting-rendering. Anyway, blender's import capabilities cover a very wide range of formats."
Yep, indeed, 3ds, obj, wings, md2... a lot.
"I'd say blender all the way tio.(community-wise speaking) Very Happy"
yes, I'd say that one, too... After all is pretty well documented (available online for free also) to overcome the possible difficulty in learning (though depends on the person) , and is truely multi platform...
...compadre
haha, lol...
"I agree with you that anim8or may be a bit easier to learn than blender, but blender is nowadays a full 3d package and very feature rich,"
yup, more powerful as a matter of fact...
" and as you said, completely multi plattform. Once you get the feeling of how blender works there's no stopping you from learning new things in it. Anim8or may be used as a modeler to export to 3ds and then load models into blender for texturing-lighting-rendering. Anyway, blender's import capabilities cover a very wide range of formats."
Yep, indeed, 3ds, obj, wings, md2... a lot.
"I'd say blender all the way tio.(community-wise speaking) Very Happy"
yes, I'd say that one, too... After all is pretty well documented (available online for free also) to overcome the possible difficulty in learning (though depends on the person) , and is truely multi platform...
...compadre
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
Actually it's a not good idea to use text (ascii) format in game (not in level design) just because of they about 5-6 times bigger (much more time in loading) than the same geometry in binary format.vermeer wrote:Though Obj+obj for me its better as being only-artist, don't like my full name put in the files I export, thing done when you save/export anything with giles...I can easily remove from objs, at least, they'r ascii
yup, that's true, but the obj is temp format for editing by the artist.The tool is called OBJ2MIM, MIM is also ascii (XML) but Murphy said while developing the format he rpefered to keep ascii for quick development but that he could turn it to binary at certain point....
During editing proccess by the artist, yep it comes very handy when a format is ascii....U can then modify with text editors, even do a ""replace all" in wordpad...done it often with OBJs...poser comunity users are used to this.
During editing proccess by the artist, yep it comes very handy when a format is ascii....U can then modify with text editors, even do a ""replace all" in wordpad...done it often with OBJs...poser comunity users are used to this.
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com