|
|
|
Tell us what you think of the site.
|
|
Autodesk® 3ds Max®
|
|
Autodesk® Maya®
|
|
Autodesk® Softimage®
|
|
Autodesk® MotionBuilder®
|
|
Autodesk® Mudbox™
|
|
Autodesk® ImageModeler™
|
|
Autodesk® Sketchbook® Pro
|
|
Autodesk® Smoke on Mac®
|
Posted: Mar 06, 2009
Category:
3DXI (previously known as IGame) is an extension to the 3ds Max SDK that was designed to make it easier for plug-in developers (esp. those in games) to write export plug-ins. Some people have mentioned to me that they found it intimidating, and prefer to just parse the scene graph using INode pointers.
I can't help but wonder if the documentation just did a poor job of presenting 3DXI to our users. If you write export plug-ins, let me know whether you ever tried using 3DXI, and if so whether you continue to use it, or left it for some reason or another. Thanks!
In order to post any comments, you must be logged in!
|
| Posted by guppyd on Jul 10, 2009 at 04:35 AM
|
Hi, are u the 3DXI author ? ^^
We use 3DXI to export our scene data to ogre.
We found there are some memory leaks come from the igame.
Even we use releaseIgame() and releaseIGameObject(), it still leak.
We write our material plugins, and guess the igame will collect data from them.
Does the igame do release the datas when releaseIgame() called ?
BTW, is it possible to get the debug version SDK for us ?
We use max 9 SDK.
Best regard,
Victor Tseng
|
|
| Posted by nedelman on Apr 28, 2009 at 08:45 PM
|
I used IGame for an exporter I created and released publicly. I was already familiar with the standard Max API but I wanted to throw together something quickly and it seemed IGame would help me to achieve that end. On the plus side, I WAS able to get a plugin working quickly. Unfortunately, after adding more features I eventually ran into odd behavior and a couple of serious bugs that required me to add lots of ugly hacks to my exporter. Eventually things were such a mess that I just decided to rewrite the exporter to go straight to the regular Max API. Based on that experience, I will never use IGame again, and I would caution anybody against using it.
At this point, I don't think there is a lot of value in Autodesk updating IGame. Even if you were to fix more bugs, add detailed error reporting, and make IGame great, it won't fix the issues with the IGame DLLs that are included with previous versions of 3DS Max, which is a problem when building an exporter than needs to work on multiple versions of Max. As Diggins mentioned, isn't IGame just a wrapper around the regular Max API? Considering the extensive amounts of code already included with the SDK, it's odd that the code for IGame wasn't included as a sample for developers to build on, since it feels like an ideal "how to" code base.
My opinion: discontinue IGame, then update the SDK documentation, explaining how to accomplish what IGame does using standard Max API.
|
|
| Posted by AshMathesonUFG on Mar 19, 2009 at 08:57 PM
|
| Actually, all it would have taken would be to have some 'Last Error Value' that the developer could interrogate to see just exactly why it failed. That would have been more than sufficient (at least for my purposes).
|
|
| Posted by Christopher Diggins on Mar 19, 2009 at 08:55 PM
|
| I have been thinking that the mistake with 3dxi/IGame was not making it a transparent (open-sourced) wrapper around the SDK. This way people in a pickle could have corrected any problem by tweaking the source and recompiling the igame.dll.
|
|
| Posted by AshMathesonUFG on Mar 18, 2009 at 03:48 AM
|
| We use it, but in a lot of cases, we kind of wish we hadn't. Our biggest problem is when we call IGameScene::GetIGameNode() and it returns NULL, we don't exactly get a warm fuzzy feeling as to *why* we got NULL back. Especially when we know the requested node actually exists.
|
|
|
|
