|
0 registered members (),
821
guests, and 2
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Better modeling formate adapt
[Re: Doug]
#78958
06/23/06 20:34
06/23/06 20:34
|
Joined: Jul 2000
Posts: 11,321
Virginia, USA
Dan Silverman
Senior Expert
|
Senior Expert
Joined: Jul 2000
Posts: 11,321
Virginia, USA
|
Doug, FBX is quickly becoming the standard and many, many people are requesting it if their 3D app of choice does not already support it. MAX, MAYA and Modo (the three big "M"s) all have native FBX import/export capabilities. FBX carries with it geometry, materials, textures, lights, cameras, animation, bones, etc. So all your scene data can be exchanged between software apps. Quote:
It looks good but I always worry about "free" tools from for profit companies
Yes, but OBJ, 3DS, X ... all of these are "free" formats made by "for profit" companies, so we end up in the same catch 22 no matter what  .
Quote:
Yes. Also, there are SO MANY different packages that trying to supporting all of them would be foolish.
Neither should Conitec have to support all of them. This is why I did not like the suggesting of supporting COB and IFF to begin with. They are application specific file formats.
Quote:
We try to support the major ones with 3rd party tools, but they get outdated quickly.
Well, I don't think so. No one at Conitec has lifted a finger to support either 3D Studio MAX, Lightwave, Maya or any of the other modeling tools out there. All the plugins for both MAX and Lightwave were developed by people well outside of Conitec. I was even responsible for having the old MAX2MDL plugin updated from MAX 2.5 to both MAX 3 and 4. Someone else updated it for v6 and up of MAX. Greenbriar did the Lightwave plugin.
What support has Conitec actually given for the "major ones"? Hosting the files others have created on your site?
|
|
|
Re: Better modeling formate adapt
[Re: Dan Silverman]
#78961
06/23/06 21:09
06/23/06 21:09
|
Joined: May 2002
Posts: 7,441
ventilator
Senior Expert
|
Senior Expert
Joined: May 2002
Posts: 7,441
|
i hear lots of complaints about fbx too. they didn't try that long. the first complete collada version (with full animation support) is only a few months old. collada has a lot to offer for realtime 3d over fbx. like shader (hlsl, glsl, cg) and material support, physics setups,... if i remember correctly sony originally started the collada project for playstation3 developers. ... maybe conitec could also support the ogre3d format.  just kidding... but they are supposed to have excellent exporters for many tools. (they got free 3dsmax and xsi versions for developing exporters.)
|
|
|
Re: Better modeling formate adapt
[Re: ventilator]
#78962
06/23/06 21:56
06/23/06 21:56
|
Joined: Jul 2000
Posts: 11,321
Virginia, USA
Dan Silverman
Senior Expert
|
Senior Expert
Joined: Jul 2000
Posts: 11,321
Virginia, USA
|
Quote:
they didn't try that long. the first complete collada version (with full animation support) is only a few months old.
Well, let's look at this link for a moment:
http://en.wikipedia.org/wiki/COLLADA
And this quote:
Quote:
COLLADA version 1.4, released in January 2006, supports features such as character skinning and morph targets, rigid body dynamics and shader effects for multiple shading languages including the Cg programming language, GLSL and HLSL.
So, according to Wikipedia, version 1.4 has been out since January ... that is half a year already and this is for v1.4. Since they are on v1.4 then that means that there were previous versions.
According to one source, Collada was announced at SIGGRAPH 2004. This means it has been almost two years. So, as stated, they have been tring for quite some time to make Collada a standard. They may be getting somewhere, but there is still a long way to go, it seems.
|
|
|
Re: Better modeling formate adapt
[Re: Dan Silverman]
#78963
06/24/06 21:33
06/24/06 21:33
|
Joined: Aug 2001
Posts: 2,320
Alberta, Canada
William
Expert
|
Expert
Joined: Aug 2001
Posts: 2,320
Alberta, Canada
|
Quote:
MAX, MAYA and Modo (the three big "M"s) all have native FBX import/export capabilities. FBX carries with it geometry, materials, textures, lights, cameras, animation, bones, etc. So all your scene data can be exchanged between software apps.
Hmm... does this mean I could export an entire scene from Modo-3ds Max(including all objects, their positions/parameters, ect.) at ease? If so, this sounds like a great format. Mabye this would allow a full scene export to WED if implemented("if" = prolly never).
Your right about Conitec not supporting major 3rd party tools, well, at least not from what I seen over the years. Were still waiting for an official scene exporter... and it took a while to even get proper 3ds & OBJ importers/exporters. However, there is still no bones animation import(unless i've been missing something). I don't really buy the excuse that 3ds Max changes to quickly outdating proper exporters. Infact, 3ds Max remains a bit bloated to keep proper support for alot of old plugins. We really only need an official exporter for Max and possibly Modo & Maya.
In the meantime, we'll use Malabars plugins, and thanks a million to them for what they're offering. But it still makes me very un-easy relying on a 3rd party for tools to make good use of the engine. Mabye Conitecs waiting to finish Octree, as that would obviously benifit the performence of model-only levels. But that is performance wise only, these model-only levels can still be built. I really don't know what to think....
|
|
|
Re: Better modeling formate adapt
[Re: William]
#78964
06/24/06 21:41
06/24/06 21:41
|
Joined: Aug 2000
Posts: 7,490
Orange Brat
Senior Expert
|
Senior Expert
Joined: Aug 2000
Posts: 7,490
|
I was basing my package specific plugin suite on the Quest3D model. They supply their own X exporter plugins for most of the major programs(even down to separate version number specific variants in some cases), and also include or tell how to get 3rd party ones like Panda X. http://www.quest3d.com/index.php?id=102My main concern with something like FBX would be having to worry about the different flavors per modeling program and dealing with changes made to each one as the respective programs evolve. Conitec could make changes to proprietary plugins much faster and know exactly what to change and test as the MDL format changes and/or the modeling programs themselves. I'm thinking of this in more of a "big picture" view. Yes, it would be expensive, at first, however having a simplified, "it works everytime no matter what you use" export path would be a great marketing point. It would pay for itself quickly I think.
My User Contributions master list - my initial post links are down but scroll down page to find list to active links
|
|
|
Re: Better modeling formate adapt
[Re: Orange Brat]
#78965
06/24/06 23:02
06/24/06 23:02
|
Joined: Jul 2000
Posts: 11,321
Virginia, USA
Dan Silverman
Senior Expert
|
Senior Expert
Joined: Jul 2000
Posts: 11,321
Virginia, USA
|
Quote:
I don't really buy the excuse that 3ds Max changes to quickly outdating proper exporters. Infact, 3ds Max remains a bit bloated to keep proper support for alot of old plugins.
This is not the case. At least not in the "early days". Plugins for MAX 2 did not work in MAX 3. Plugins created for MAX 3 did not work in MAX 4. However, Discreet did allow for MAX 4 plugins to work in MAX 5. With MAX 6, though, MAX 4 and 5 plugins no longer worked. MAX 6 plugins seem to work in MAX 7 and 8, though. This policy of Discreet (and now Autodesk) has made many people more than upset with them because many of these plugins cost hundreds of dollars and you usually had to buy them all over again simply because you upgraded to the newer version of MAX.
As an example of this, someone had created the original MAX2MDL plugin for MAX 2.5. It would not work in MAX 3 so we had to have it updated (which meant we needed the MAX 3 SDK to do so). Later, when MAX 4 came out we had to do it again. MAX 5 gave us a rest, but someone else handled bringing the plugin over to MAX 6.
MAX is NOT bloated to be backward compatible with old plugins. This is totally not the case. In fact, if you look at the various changes in the SDK for MAX over the years it would seem that Discreet made subtle changes to it mainly to PREVENT older plugins from working in newer versions of MAX. In fact, getting MAX2MDL to work in later versions of MAX was often a change of one or two lines of code to accomidate some SDK change and that was all (and these changes were nothing specific to the exporter, but to getting the plugin to run at all in MAX).
Quote:
My main concern with something like FBX would be having to worry about the different flavors per modeling program and dealing with changes made to each one as the respective programs evolve.
I am not so certain this is a concern. The format will most likely evolve for various reasons, but GameStudio would only need certain things from FBX like geometry, materials and textures, lights, animation, etc. Most likely these things are properly in place already and so they should not change much from here on out though I could well be wrong .
|
|
|
Re: Better modeling formate adapt
[Re: Dan Silverman]
#78966
06/25/06 06:56
06/25/06 06:56
|
Joined: Aug 2000
Posts: 7,490
Orange Brat
Senior Expert
|
Senior Expert
Joined: Aug 2000
Posts: 7,490
|
Quote:
I am not so certain this is a concern. The format will most likely evolve for various reasons, but GameStudio would only need certain things from FBX like geometry, materials and textures, lights, animation, etc. Most likely these things are properly in place already and so they should not change much from here on out though I could well be wrong .
Yeah, most of the essentials are probably already in place. However, future MDL features may fall outside the FBX focus at some point. Using proprietary plugins would insure full compatibility no matter what. Of course, I suppose Conitec could always adapt the MDL format to reflect the latest greatest FBX format and per app. Then, as Doug mentioned(I think)...it comes down to FBX -> MDL conversion. If you're going to go to all that trouble, though why not just dump MDL and directly support FBX or treat it like X format.
I look at it this way...if there's an open source alternative that is BETTER than what we have now and is widely supported or respected, then Conitec should go with it. I think this is true for the rendering, as well. A lot of people seem to crap on the way 3DGS looks and like to dote on Ogre and Irricht(sp?), so why not give serious consideration to using them in the future IF what they offer is BETTER(i.e. faster, more features, etc) than what we have now? If Conitec can't create something superior, in a timely fashion, then adapt it and spend the creative energies elsewhere. I know it's not an issue of dropping it in and moving on, but I would think it would be quicker to do this then create something from scratch.
My User Contributions master list - my initial post links are down but scroll down page to find list to active links
|
|
|
Re: Better modeling formate adapt
[Re: Orange Brat]
#78967
06/25/06 14:44
06/25/06 14:44
|
Joined: Jul 2000
Posts: 11,321
Virginia, USA
Dan Silverman
Senior Expert
|
Senior Expert
Joined: Jul 2000
Posts: 11,321
Virginia, USA
|
Quote:
I would think it would be quicker to do this then create something from scratch.
However, I think this is part of the problem ... that a lot of the basis for GameStudio was NOT (originally) created from scratch. MED was an old Quake Model Editor that was licensed by Conitec and the slowly modified over the years. The original Acknex engine was licensed from ... well ... we know that story. I don't know what lingers on (if anything) from the days of old (apparently there is a new kernel in place in A6 and possibly an even newer one for A7 (???) but is this completely new material? I certainly don't know but old "bugs" and artifacts seem to still be there from days gone by. SED, as we all know, is nothing that was created from scratch by Conitec. WED ... I am not certain what its origins are, to be honest.
Perhaps it would be better if Conitec just simply started from scratch instead of adapting all these things to suite their needs.
|
|
|
|
