Creating a model exporter plugin for 3dsMAX
Author
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
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...
In the script reference there are quite a lot exmples that should get you started...
follow the ascii exporter example in the max sdk. It's fairly straightforward to customise it for your needs.
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.
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.
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.
;)
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.
Complete source for a Max 7 exporter.
This is the source code to the Max 7 exporter for the WildMagic engine:
http://www.geometrictools.com/ToolsBody.html#Max7ToWm3
Look at the top where it says "Max7ToWm3"
This is the source code to the Max 7 exporter for the WildMagic engine:
http://www.geometrictools.com/ToolsBody.html#Max7ToWm3
Look at the top where it says "Max7ToWm3"
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 ;)
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 ;)
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
