3D Canvas PRO exporter?
by Sam Contapay · in General Game Discussion · 07/28/2003 (8:23 am) · 20 replies
I just came across this program this weekend. I did not have time to download the demo. It looks like a good program. I was debating over writing an exporter for this or AC3D with the help of Tom's G3D SDK :). I kind of like the features and UI available in 3D Canvas PRO of course anyones opinion on either program, or both, would be appreciated.
You can find 3D Canvas PRO at http://www.amabilisplus.com.
You can find 3D Canvas PRO at http://www.amabilisplus.com.
#8
07/28/2003 (3:24 pm)
@Clint yeah it caught my eye thats why I have a hard time between the two. I mean the PRO package for 3D Canvas is only $64 and it seems to have a lot of features. Maybe I should just write an exporter for both, but then I would need to decide on which one to start on first :)
#9
07/28/2003 (7:59 pm)
They both look good... I haven't used either one so I am not much help ;)
#10
07/28/2003 (8:15 pm)
They both look good... I haven't used either one so I am not much help ;) 
#11
There is also work being done on a standalone .3ds format to g3d so you can use any modeller, save to .3ds and then use the exporter to make your art RE friendly.
It doesn't make a lot of sense to spend yet more precious time in supporting win only modelers that have a userbase that can only be labelled as a "niche market", etc.
Don't forget that one of the major plans is bringing RE both to MacOS X and Linux.
Again, in that light, spending yet more scarce community ressources on supporting "non standard" modeling apps looks like time that could have been better spent in making your game, making content for you game, etc.
Don't get me wrong : not ranting, just giving an opinion here :)
I mean, you'll do what you want anyways, right ? (well, I hope so ;))
Also, it looks like 3DCanvas forces you to use DX 9, and the latest versions of other redistributable MS components, which while not that big an issue, is certainly a pain in the b*** for those who like to keep a stable, working environment the way it is, and don't like having to upgrade system software for the heck of it..
Food for thought ? Maybe.
Have a good day
07/29/2003 (9:02 am)
See guys, RE already has support for 2 win only modellers in Max and Milkshape 3D. There is also work being done on a standalone .3ds format to g3d so you can use any modeller, save to .3ds and then use the exporter to make your art RE friendly.
It doesn't make a lot of sense to spend yet more precious time in supporting win only modelers that have a userbase that can only be labelled as a "niche market", etc.
Don't forget that one of the major plans is bringing RE both to MacOS X and Linux.
Again, in that light, spending yet more scarce community ressources on supporting "non standard" modeling apps looks like time that could have been better spent in making your game, making content for you game, etc.
Don't get me wrong : not ranting, just giving an opinion here :)
I mean, you'll do what you want anyways, right ? (well, I hope so ;))
Also, it looks like 3DCanvas forces you to use DX 9, and the latest versions of other redistributable MS components, which while not that big an issue, is certainly a pain in the b*** for those who like to keep a stable, working environment the way it is, and don't like having to upgrade system software for the heck of it..
Food for thought ? Maybe.
Have a good day
#12
The 3DS converter will be portable. That should cover most eventualities. However, using the 3ds converter will be an extra step ... you'll have to export to 3ds then run a command line app. It's not a perfect solution.
Personally, I think the more modellers we support with native exporters the better. It's less work for the modeller. With the G3D SDK it's easyish to write converters since the guts of the file format stuff are done, it's just a matter of feeding the modelling app's representation of the data to the G3D methods (possibly with some tweaking, depending on the app) and calling a save method. A basic converter shouldnt take more then a week, less if the person writing it has written an exporter for that app before. I don't think it's time wasted.
Another note: the 3ds converter won't support animation for quite some time. This is also a big reason to write native exporters.
How can 3DCanvas force you to use DX9 ? Wouldn't that be up to the exporter and engine used ? The .g3d format is very limited (until I rewrite it ;-)..) so I dont see any reason it can force you to use DX9. It can, however, force you to use DX9 in order to run it, but that would be on the artist's computer, not end users.
@Sam,
Please keep me posted on what exporters etc you're working on. The G3D SDK integration with RE will be commencing soon and I'd like to get as much in there as possible.
Tom.
07/29/2003 (11:14 am)
@Nicolas,The 3DS converter will be portable. That should cover most eventualities. However, using the 3ds converter will be an extra step ... you'll have to export to 3ds then run a command line app. It's not a perfect solution.
Personally, I think the more modellers we support with native exporters the better. It's less work for the modeller. With the G3D SDK it's easyish to write converters since the guts of the file format stuff are done, it's just a matter of feeding the modelling app's representation of the data to the G3D methods (possibly with some tweaking, depending on the app) and calling a save method. A basic converter shouldnt take more then a week, less if the person writing it has written an exporter for that app before. I don't think it's time wasted.
Another note: the 3ds converter won't support animation for quite some time. This is also a big reason to write native exporters.
How can 3DCanvas force you to use DX9 ? Wouldn't that be up to the exporter and engine used ? The .g3d format is very limited (until I rewrite it ;-)..) so I dont see any reason it can force you to use DX9. It can, however, force you to use DX9 in order to run it, but that would be on the artist's computer, not end users.
@Sam,
Please keep me posted on what exporters etc you're working on. The G3D SDK integration with RE will be commencing soon and I'd like to get as much in there as possible.
Tom.
#13
Another advantage of having native exporters would be that the engine would be more appealing because of all the support.
Before I knew that a Milkshape exporter was being worked on, I wasn't going to buy the engine. Then once I found out about it, I bought it.
My 2 cents...
07/29/2003 (11:23 am)
I have to agree with Tom. I think the more native exporters there are the better. Plus any of the grunt work done now just means less later. Another advantage of having native exporters would be that the engine would be more appealing because of all the support.
Before I knew that a Milkshape exporter was being worked on, I wasn't going to buy the engine. Then once I found out about it, I bought it.
My 2 cents...
#14
I plan on also knocking up a GUI based tool that will show you the mesh and allow you to do some operations on it (The D3DX lib has some pretty nice simplification functions, etc) and then save out to G3D. However, I won't hold up the release of the command-line tool for this, I'll release the simple command line tool when it is ready (hopefully tonight or tomorrow at the latest).
In theory one should be able to save a DirectX file in many different modelers (Maya (using the exporter in the DirectX SDK Extras), AC3D, etc) and use this tool to convert the .X to .G3D. However, I do agree that native modeling exporters are best, when available, if only to eliminate the extra step for artists.
And in response to Nicolas, I think a big part of why there is a lot of Windows modeler support is that is what most people using RE are using. I'm not opposed to more support for Linux and Mac tools, but since I personally use a Windows based modeler, that is what I care about most and where I'll put my efforts as far as exporters go. I'm sure sooner or later Linux and Mac users will pick up the slack for export tools over there (though this might not happen until RE is actually running on those platforms). Tom's SDK makes the G3D creation process very painless.
07/29/2003 (12:00 pm)
I'm about 95% done with the DirectX .X File to G3D conversion program. Right now it consists of a static library that takes a pointer to the D3DXMesh and dumps it to a G3D file and a simple command-line tool that wraps the library functionality. There is one bug remaining when dealing with meshes that have multiple materials... once I nail that down I'll post a link to the binary & code for the converter. I plan on also knocking up a GUI based tool that will show you the mesh and allow you to do some operations on it (The D3DX lib has some pretty nice simplification functions, etc) and then save out to G3D. However, I won't hold up the release of the command-line tool for this, I'll release the simple command line tool when it is ready (hopefully tonight or tomorrow at the latest).
In theory one should be able to save a DirectX file in many different modelers (Maya (using the exporter in the DirectX SDK Extras), AC3D, etc) and use this tool to convert the .X to .G3D. However, I do agree that native modeling exporters are best, when available, if only to eliminate the extra step for artists.
And in response to Nicolas, I think a big part of why there is a lot of Windows modeler support is that is what most people using RE are using. I'm not opposed to more support for Linux and Mac tools, but since I personally use a Windows based modeler, that is what I care about most and where I'll put my efforts as far as exporters go. I'm sure sooner or later Linux and Mac users will pick up the slack for export tools over there (though this might not happen until RE is actually running on those platforms). Tom's SDK makes the G3D creation process very painless.
#15
What could eventually worry me with supporting all sorts of more or less obscure modelers is the possibility to have plenty of "kinda working" exporters, but none with the level of support only present in the Max one atm.
While having a full blown .3ds to .g3d, while not being an ideal solution, is certainly the one that guarantees getting artwork to work fine in RE, whatever app you're using, as the important point here is not what features the modeller has, but which ones are compatible with the .g3d format.
I don't quite agree that because the .3ds to .g3d won't support animation for some time is a good reason to work on native exporters : to make them handle animation is going to also take a lot of work, if not as much as supporting animations in the standalone exporter, no ?
That said, as I think I hinted at in my first post, people can and certainly will do what they want, and I do not want to discourage anyone from doing so.
Just wanted to chime in with the flipside of that particular point, being that the time spent on supporting multiple modellers part of the way, or all the way could be spent on making the standalone one fully featured, robust, and user friendly as possible.
Both approaches have their pros and cons.
edit : some missing words
07/29/2003 (12:22 pm)
No, I meant to say that it needs DX9 installed to work well, according to the FAQs on the site. Sorry for the confusion...What could eventually worry me with supporting all sorts of more or less obscure modelers is the possibility to have plenty of "kinda working" exporters, but none with the level of support only present in the Max one atm.
While having a full blown .3ds to .g3d, while not being an ideal solution, is certainly the one that guarantees getting artwork to work fine in RE, whatever app you're using, as the important point here is not what features the modeller has, but which ones are compatible with the .g3d format.
I don't quite agree that because the .3ds to .g3d won't support animation for some time is a good reason to work on native exporters : to make them handle animation is going to also take a lot of work, if not as much as supporting animations in the standalone exporter, no ?
That said, as I think I hinted at in my first post, people can and certainly will do what they want, and I do not want to discourage anyone from doing so.
Just wanted to chime in with the flipside of that particular point, being that the time spent on supporting multiple modellers part of the way, or all the way could be spent on making the standalone one fully featured, robust, and user friendly as possible.
Both approaches have their pros and cons.
edit : some missing words
#16
Of course, if tom's sdk make it a simple afternoon's work to get an exporter going for any modeller that has a plug-in interface, then I don't see as much of a problem with this.
ie If the grunt work is hidden away in the SDK, and that it takes care of giving you some kind of error messages for features it does not understand, well, it starts to take the role I'm seeing being filled by the standalone exporter : some "middleware" between the modelers and the RE.
There is also the matter of supporting all those exporters, which again, depending on how much of the work is actually done by the g3d sdk, and what is left to the particulars of a modeling app remains to be determined.
Again, I'm not saying you shouldn't work on whatever you want to. Just wanted to bring up the points i mentioned, kinda to cover all bases.
I also thought that the g3d sdk wasn't available, which means all the work being done now on exporters (except tom's milkshape one) is done without the grunt work being taken care of... :)
have fun
07/29/2003 (12:34 pm)
Well, lots of posts while I was writing...Of course, if tom's sdk make it a simple afternoon's work to get an exporter going for any modeller that has a plug-in interface, then I don't see as much of a problem with this.
ie If the grunt work is hidden away in the SDK, and that it takes care of giving you some kind of error messages for features it does not understand, well, it starts to take the role I'm seeing being filled by the standalone exporter : some "middleware" between the modelers and the RE.
There is also the matter of supporting all those exporters, which again, depending on how much of the work is actually done by the g3d sdk, and what is left to the particulars of a modeling app remains to be determined.
Again, I'm not saying you shouldn't work on whatever you want to. Just wanted to bring up the points i mentioned, kinda to cover all bases.
I also thought that the g3d sdk wasn't available, which means all the work being done now on exporters (except tom's milkshape one) is done without the grunt work being taken care of... :)
have fun
#17
@Clint,
Cool, glad my work managed to convince someone to buy RE ;-)
@George,
I didnt realise you'd started. Can you keep me posted too, and send me source for integration ?
@Nicolas,
Ah, thanks for the clarification. Maybe I should clarify too ;-)
The G3D SDK exists now. It's still a little rough around the edges, but it supports all features of the (rather limited) G3D file format. It's basically an interface between modeling packages and RE, as you say. All an exporter writer has to worry about is the interface to the modelling package and the interface to the .g3d SDK. Knowledge of the .g3d format helps, but isnt really essential. It's not quite a simple afternoon's work, but it's as close as it's going to get.
The reason for not supporting animation in the 3ds converter at the moment is simply because I'm using some code that Matt wrote for loading .3ds files and it doesnt do animation. I don't fully understand the 3ds file format, so it will take someone who does to finish off the 3ds converter. This could take quite some time, and thus leaves an incomplete solution for the interim. Animation is one area of the G3D SDK that's untested and is probably very rough. I'll be doing animation in the Milkshape exporter probably end of this week/early next week and thus the G3D SDK will get updated as to what I find then.
I agree with you about incomplete exporters/converters being bad. I am trying to balance usefulness and completeness, hence the Milkshape exporter is released early without being finished, but when everything is integrated, it will all be completed to at least beta stage before release.
You are sort of right in thinking the G3D SDK isnt available yet. However, anyone who wants to start working on exporters/converters now is welcome to it to get a head start. George and Sam already have it, so there's no reproduced work there.
I think I covered everything there. Lot of typing!
Tom.
07/29/2003 (1:28 pm)
Wow, lots of posts in the last couple of hours ...@Clint,
Cool, glad my work managed to convince someone to buy RE ;-)
@George,
I didnt realise you'd started. Can you keep me posted too, and send me source for integration ?
@Nicolas,
Ah, thanks for the clarification. Maybe I should clarify too ;-)
The G3D SDK exists now. It's still a little rough around the edges, but it supports all features of the (rather limited) G3D file format. It's basically an interface between modeling packages and RE, as you say. All an exporter writer has to worry about is the interface to the modelling package and the interface to the .g3d SDK. Knowledge of the .g3d format helps, but isnt really essential. It's not quite a simple afternoon's work, but it's as close as it's going to get.
The reason for not supporting animation in the 3ds converter at the moment is simply because I'm using some code that Matt wrote for loading .3ds files and it doesnt do animation. I don't fully understand the 3ds file format, so it will take someone who does to finish off the 3ds converter. This could take quite some time, and thus leaves an incomplete solution for the interim. Animation is one area of the G3D SDK that's untested and is probably very rough. I'll be doing animation in the Milkshape exporter probably end of this week/early next week and thus the G3D SDK will get updated as to what I find then.
I agree with you about incomplete exporters/converters being bad. I am trying to balance usefulness and completeness, hence the Milkshape exporter is released early without being finished, but when everything is integrated, it will all be completed to at least beta stage before release.
You are sort of right in thinking the G3D SDK isnt available yet. However, anyone who wants to start working on exporters/converters now is welcome to it to get a head start. George and Sam already have it, so there's no reproduced work there.
I think I covered everything there. Lot of typing!
Tom.
#18
I feel the more tools that are availabe, especially the low end tools, since RE is a "hobby" engine the better. Granted we will have cases with very poor exporters, but I am hoping, as I am planning to do this myself that the writers of the exporter will release the source code as well, just in case they "disappear" or lose interest in the code someone can pick it up and add on to it.
Off to finish my game and get to work soon on the exporter.
07/29/2003 (2:01 pm)
Wow nice to see a lot of people chiming in with their opinion. I am going to start work on either AC3D or 3D Canvas PRO still trying to decide. I want to finish up this game I am working on, and thank Tim for his hardwork on the G3D SDK I didn't have a chance to look at it, but if its just pushing in vertex and triangle information thats good.I feel the more tools that are availabe, especially the low end tools, since RE is a "hobby" engine the better. Granted we will have cases with very poor exporters, but I am hoping, as I am planning to do this myself that the writers of the exporter will release the source code as well, just in case they "disappear" or lose interest in the code someone can pick it up and add on to it.
Off to finish my game and get to work soon on the exporter.
#19
Yep, the more the better. We won't have very poor exporters, since we just wont make them part of the official release :)
If I were you I'd start with AC3D since a few people have asked for it.
Tom.
07/29/2003 (5:44 pm)
Who's Tim ? :)Yep, the more the better. We won't have very poor exporters, since we just wont make them part of the official release :)
If I were you I'd start with AC3D since a few people have asked for it.
Tom.
Clint