Sign in to follow this  
RandomAxess

Creating a model exporter plugin for 3dsMAX

Recommended Posts

I wasn't sure if this was the right forum, but anyway: I'd like to make a custom plugin that's a model exporter for 3dsMAX. I was wondering if anyone knew any good tutorials on how to get started. thanks

Share this post


Link to post
Share on other sites
I'd recommend using MaxScript. It can export data binary as well.
In the script reference there are quite a lot exmples that should get you started...

Share this post


Link to post
Share on other sites
using MAXscript will be a big PITA, especially if it comes to heavy exporting tasks in combination with complex export logic; better way would be to write your own exporter.
the number one resource for information regarding writing own MAX exporters is support.discreet.com (free registration).

the easiest way would be the one as mentioned by RobTheBloke: following the SDK's included ASE/ASCII.


Share this post


Link to post
Share on other sites
using DLL(native) plugins will be a big PITA, especially if it comes to heavy exporting tasks in combination with complex export logic; better way would be to write your own exporter.
;)

exporter from modeling package shouldn't be monolite block of logic and stuff - if artists need tools to complete various tasks, besides export or relevant to exporting - make them as distinct maxscript plugins.
final export should be done as simple as it can be, so in future/eventually you can write another simple exporter from Maya for example. Non-indexed geometry for example. All indexing, stripification, texture compression, atlases - this is good to be done *outside* the modeling package.
reasoning:
- big&heavy native exporters, need STL, processing libraries such as NVTristrip, NVMeshmender, ... However, linking those, is not very straightforward with the new MSVC for example. Autodesk say one should use MSVC 2002... :)
- pumping a exporter with logic will strike back when you need to write similar exporter for different modeling package.
- native code crash like nothing else, to the point where MAX is dead cold. maxscript hardly do so.
- memory management - maxscript has no single line devoted to that, compared to native code. which is not big plus, but is something.

And one disadvantage of maxscript is the hard error detection, when your script is badly written - maxscript 'compiler' is not the friendliest one, if it comes to error messages... :)

So, my advice is to start with maxscipt AND use some examples - like MAX -> Doom 3 exporter, for example.

Share this post


Link to post
Share on other sites
Zemdelec,

some of the reasons you mentioned might be true, but:
in today's project pipelines you need a more integrated way to support your studio - so, doing any (no matter which) additional step is not good; i.e. exporting to an "game engine unoptimized" format, and after that using additional tools to prepare the gameengine-ready content.

however, i agree to the point "..big&heavy native exporters, need STL.." - a fairly intelligent plugin could increase the memory consumption of 3DSMAX by 20 - 40%, *but*: only temporary... and, as you know: your aritst machines will have (nowadays) a memory count >= 2GB...

regarding the point "..similar exporter for different modeling package.." - depends on, i would say, because: no studio is using today modelling package A and tomorrow modelling package B - this trap could be handled easily by using an additional transforming-layer in the exporters logic, wich accepts native streams of geometry (delivered by the modelling package).

the point "..to the point where MAX is dead cold.." is absolutely true - no any further comment :) (but if you have developed your MAX plugin in a safe manner, this problem won't harras you - but, to be honest: we needed more than 6 month to reach this point...)

but, i have to decline MAXscript. still. and so i will do for the next years ;)

Share this post


Link to post
Share on other sites
I have written exporters using the Max SDK, and using MaxScript. I would not recommend the latter. MaxScript is a bad, bad language. It's okay for quick one-off automation scripts; it is not suitable for long-term maintained software.

Share this post


Link to post
Share on other sites
(The following is speculation based on my experience with writing exporters for Maya using the SDK and the scripting language. It is probably similar for 3dsMAX though.)

An exporter written with MaxScript will probably be a lot slower then one written with the SDK as well. This may not be too big a deal for you because you would really only notice a huge slow down if you have pretty large (as in high vertex-count) models, and for a game the models may not be too large. In my exporter I wrote with Maya's scripting language, for a pretty large model (~30k triangles I think, it was a while ago) it took a LONG time to export. If I remember correctly the exporter written with the SDK was about 10 times faster.

Again, this may not matter for your purposes, but it's something to keep in mind.

Share this post


Link to post
Share on other sites
...perhaps Sneftel's comment may not be exactly clear:
i would highly recomment *not* to use MAXscript. (to say in other words: "you will get, what you invest").



Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
I have written exporters using the Max SDK, and using MaxScript. I would not recommend the latter. MaxScript is a bad, bad language. It's okay for quick one-off automation scripts; it is not suitable for long-term maintained software.


I've also used both. I'm curious why you think Maxscript is so bad. I've actually had a lot of good success with it. In fact, for long-term maintanance, it's a bit nicer in many ways. Especially since you don't HAVE to re-write your Maxscripts every release, but with most releases you have to, at the very least, re-compile all of your plugins.

I'd also toss a third suggestion into the mix. Use Maxscript, and if you find things that take too long or run into areas where you can't access some data then you can write a simpler plugin that exposes new functionality to Maxscript. On the last project that I did a lot of heavy Max tool creation I used this hybrid approach a lot. It's really nice. You can keep all of your high-level logic and functionality in Maxscript and then call your custom functions to do your heavy lifting on the SDK side.

With all that being said, if this is for a commercial game, then I'd recommend just licensing Rad Gametool's Granny exporter and be done with it =)

-John

Share this post


Link to post
Share on other sites
Hello,

I'd recommend writing your exporter with the help of the IGame wrapper of the maxsdk. There's plenty of documentation for it and it's really intuitive to work with.
The only problem I've run into so far is loading the model back into my engine when it has texture coordinates assigned to it. Max stores seperate indices for the vertices and the texcoords, whereas OpenGL has to have one index for both arrays.
I've found some code to merge the arrays, so you can render the vertices and the texcoords with one index. It's at: http://www.mindcontrol.org/~hplus/graphics/vertex-arrays.html

Unfortunately when I use the code, the geometry loads in fine, but it's all black instead of having a texture.
I've also written a .3ds loader for my engine and those objects load perfectly fine. The resulting vertexcount for the .3ds file and my file does differ though.
Does anyone know what the problem could be? (looking at the code on the above site)

Thanx

Share this post


Link to post
Share on other sites
godmodder,

regarding your uvcoords/vertex-index problem:
you have to "unroll" these arrays in the code (may look a bit complicated, but it's easy).

Share this post


Link to post
Share on other sites
Quote:
Original post by godmodder
I'd recommend writing your exporter with the help of the IGame wrapper of the maxsdk. There's plenty of documentation for it and it's really intuitive to work with.


hmmm... in my experiance IGame has never been up to production ready statndards. The collada max exporter is based on this, and it tends to fail a lot. I still say the ASE example is the best way to go.

Quote:
I've also used both. I'm curious why you think Maxscript is so bad. I've actually had a lot of good success with it. In fact, for long-term maintanance, it's a bit nicer in many ways. Especially since you don't HAVE to re-write your Maxscripts every release, but with most releases you have to, at the very least, re-compile all of your plugins.


maybe, however debugging and profiling tools are far better in C++ than any tools to help you locate max script problems.

Quote:
With all that being said, if this is for a commercial game, then I'd recommend just licensing Rad Gametool's Granny exporter and be done with it =)


I bet they started with the ase example in the sdk.

Quote:
final export should be done as simple as it can be, so in future/eventually you can write another simple exporter from Maya for example. Non-indexed geometry for example. All indexing, stripification, texture compression, atlases - this is good to be done *outside* the modeling package.


not strictly true in my experiance. If you started in Maya, then at a later date switched to max, then that is fairly easy. Starting in Max then writing a Maya exporter is going to be far less successful.

Share this post


Link to post
Share on other sites
Well, everybody tells me it's soooo easy to "unroll" those vertices and uv-coords. So why come that there isn't a single site that has code that actually DOES the job? The furthest I've come to the solution is that the geometry draws correctly, but it's all black instead of having a texture.
Could somebody please SHOW me how to do it instead of saying it's sooo easy.

PS: 'cause it's NOT easy :)

PS2 (pun?): this is not meant to be offending in any kind

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
I have written exporters using the Max SDK, and using MaxScript. I would not recommend the latter. MaxScript is a bad, bad language. It's okay for quick one-off automation scripts; it is not suitable for long-term maintained software.

Yes, I agree completely. I have done very simple small formats in MaxScript before, and that was bad enough. Our DLE exporters are so large that it would be inconceivable to write it in maxscript. Also, if you ever consider supporting more than one DCC, you should probably make a centralized exporter library, and then just call that from the specific tool - which isn't possible with MaxScript. Otherwise, your the time you spend maintaining your code is immense. If you have completely separated exporters for Max 4, 6, 8, Maya, ect, each thousands and thousands of lines a piece, you will get swamped very quickly.

Quote:
With all that being said, if this is for a commercial game, then I'd recommend just licensing Rad Gametool's Granny exporter and be done with it =)

*cough* EmotionFX > Granny *cough*

Share this post


Link to post
Share on other sites
Quote:
Original post by godmodder
Well, everybody tells me it's soooo easy to "unroll" those vertices and uv-coords. So why come that there isn't a single site that has code that actually DOES the job?


because you are not looking hard enough.

http://www.robthebloke.org/source/ObjLoader.zip

Quote:
The furthest I've come to the solution is that the geometry draws correctly, but it's all black instead of having a texture.


are you sure that is a problem with the vertex arrays? does your texture load correctly? have you tested texturing on a single quad? the code on the website doesn't handle normals, have you got lighting on? are you using GL_MODULATE as the texture mode and have you set the colour to black? If your geometry draws correctly it probably isn't the fault of the vertex arrays, but a fault somewhere else in your code.

Quote:
PS: 'cause it's NOT easy :)


yes, it is easy.

Share this post


Link to post
Share on other sites
Hello,

I finally solved the problem. I replaced a glColorub(255,255,255) with a glColor4f(1,1,1,1) and for some reason, it works now.
Could somebody explain why there would be any reason for this? (I don't use a glColor command anywhere else except for my fonts and this doesn't affect the end result)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this