Archangel35757

First I would like to ask this sub-forum admin to create additional topic tags relevant to tools development, like: "Plugin" or "Plugin WIP", etc. or tags for the specific 3D modeling package the plugin is for: "3dsMax Plugin", "Maya Plugin", "Softimage Add-On" etc. Because currently the only tag is "JK2." Secondly, I would ask that there be a sub-forum under coding for "Tools Development" and move this thread under it. So, with the Beta(R1) dotXSI exporter out and continuing beta testing (seems pretty quiet out there), and before I get back to creating a controls rig for the 3ds Max Humanoid Skeleton, I thought I would try to re-create the ROFF exporter for 3ds Max 6+ (as the only working version was for 3ds Max 5). I've read Mr. Wonko's blog about his recreating the ROFF exporter for Blender (kudos to him for that); and I have his scripts, as well as the ROFF header file from the JKA source code release. So hopefully I'll be able to pull this off. So for those of you who don't know... what is a ROFF??? It stands for Rotation Origin File Format with an extension of ( .ROF ). A ROF contains position and rotation data for very complex trajectories and paths, animated using a 3D modeling program for either one or multiple objects, and exported as a binary file. More specifically it constains delta positions and delta rotations from the previous frame of animation. It enables/allows for scripting very complex world object animations of brushes/models. How? You create a brush entity, which must be square or rectangular and apply the origin shader to it. The origin point is the exact center of the origin brush and the center of rotation. You then export this origin brush out of GtkRadiant and into your modeling program (making sure you are using consistent units) to get the initial position and orientation of the origin brush entity. Then animate whatever complex trajectory you want in your modeling program and export this trajectory out as a .ROF. When included in scripting, the game uses this .ROF file to play the animation in-game. A ROF in the hands of a knowledgable scripter could probably pull off some amazing things... and not just your ordinary fly-by. Think of this as like "motion-capture" data for brush models (that could even be grouped with misc_model entities) or baking in motion data from Physics simulations. Or what if you tagged the bone joints of the AT-AT Walker's legs with these origin brushes and then exported out a walk cycle? Mo-Cap for brushes! Allowing you to maybe have better interaction with the models and pull of a Luke Skywalker AT-AT take down... who knows. Perhaps ROFFs are being heavily used once again since Mr. Wonko's Blender scripts were released... but I'd like to be able to create these files from my favorite 3D modeling program. So back to the point of this thread... I don't know how long it will take, but I'm hopeful I can pull this off as my knowledge of the 3ds Max SDK grows. I'll post updates here...

I wholeheartedly agree with you! Actually, this guy (Hugo Apellido) at maxplugins.de here: <http://maxplugins.de/max2011.php?search=Hugo Apellido&sort=Author> has generated newer versions of .map exporters, .bsp level importers, .GLM importers, and .MD3 importers/exporters for a number of versions of 3ds Max up to R2011. However, he's missing some critical ones for Max 6, 7, 8. I've tried to contact him but haven't gotten any response. If anyone knows how to contact this guy please let me know. One of the plugins that is still missing for 3ds Max is the ROFF exporter that allows you to generate custom complex paths for scripted map object animations (i.e., vehicle flight paths, etc.). I plan to build a ROFF exporter soon. I also want to fix the broken dotXSI importer...

Good News! I've traced the root cause of the problem for the "broken animations" ( ...like @@AshuraDX and I were experiencing). In the code they do a test on all objects to see if it is animated, and if this test returns "true" then they export the fCurves (i.e., Animation Data)... however, those objects that are animated indirectly using Constraints or IK Chains will fail this test; and as a result are omitted during the animation export phase. :blink: I've fixed this issue... and have tested it out on a few things. I also verified that I am able to compile a model with carcass.exe and play it in ModView. Hopefully there aren't any more bugs... I'll be releasing new beta versions for everyone to continue beta testing phase. Thanks!

Well it appears the original code has issues when an object uses procedural type controllers or constraints... hopefully I can have it fixed soon. Until the code is fixed, if you should run into this issue, the workaround is to export-select your skeleton & mesh objects and bake out the animation to an FBX file. Re-import this baked FBX file and then do a scene export to dotXSI.

Years ago Tinny modified the jamp code using the GHOUL2 Hit/Collision detection to allow me to fly the T-47 vehicle under an AT-AT... now if I only had that grappling hook (tow cable) code, and Phsyics, to make a workable harpoon and bring it down! My apologies for getting off topic from Mini's original post... perhaps this discussion should be moved elsewhere.

I get that... but out of curiosity then, why do the Raven released dotXSI animations not include the root pose on Frame 0? Does it really need to be in there for Carcass? Or is carcass happy as long as you include a root.xsi file of the basepose when compiling multiple files into a .GLA? or is it needed for GLAmerge only?

Yes, the plugin code uses a method called PlotSRTAnimation-- it functions in theory as you describe... no baking required.

@@AshuraDX First off, Frame 0 must be your root pose (i.e., neutral pose where you add the skin modifier and weight your mesh objects to the bones). The exporter expects this basepose to be Frame 0. Every animation must have the root pose on Frame 0... perhaps @@DT85 or @@Psyk0Sith can expound more on the reason for this... Also, it's good practive to Freeze Transforms on your Control Objects before you start connecting them up to the hierarchy so that you can easily get back to zero after doing any animations (Refer to 3ds Max documentation and rigging tutorials for freezing transforms). Still something going on with plugin... but not having the root pose on Frame 0 is a contributing factor.

Thanks for your XSI screenshots... The plugin code should have automatically handled the constraints... I'll need to dig into the code and see what's going on... I'm thankful to have you guys beta testing it to find issues like this.

Nice! Are you using the new 3dsMax dotXSI v1.8 Beta exporter to get this in-game?

"Export Selected" still has Softimage's original flaws... it is high on the list of things to fix. If you run into this issue then the only workaround (though I've not tested it... but should work) would be to save out your selection as an XML Animation File. Load back up this file and export to dotXSI. Please report if you run into this and explain what the offending object is, how you're using it and how it's tied into your hierarchy.

Thanks! FYI... 3ds Max 9 plugins usually work in 3ds Max 2008. The 32-bit plugin will only work with 32-bit Max 9 (and 32-bit Max 2008), and the 64-bit plugin will only work with 64-bit Max 9 (and 64-bit Max 2008). So if anyone has, or knows of someone with, 3ds Max 2008-- please give this plugin a try and post your results with it!

Hmm... my file submission to the Utilities section is still pending approval.

What version of 3ds Max are you using? Also, to all those following this thread... does anyone see any benifit to changing the default projectName: "3ds Max Scene", in the file info section, to something useful? And it would only be useful if you look at the dotXSI file in a text editor or XSI Dump v1.3...

Crosswalk 2.6 has those 3.0 templates as well... I'll try and do a clean compile against 2.6 rather than include the paths to the XSIFTK 3.6.3 headers, etc. If that fails then I'll try 5.0. It also looks like in SDK 5.0 they give you all files you need to recompile the Crosswalk plugin, no?

So using the later Crosswalk plugins... when you select the filename to save as .xsi it doesn't give you a drop-down list for dotXSI versions?

Ok... I was only going by the info stated in this link: http://softimage.wiki.softimage.com/index.php?title=DotXSI_File_Format_and_Templates Looks like they are full of crap!

Be sure to uncheck the NURBS options... Does it give you an option for .xsi3.0??? Can you post a screenshot of the dialog?

Apparently Crosswalk SDK v5.0 (and plugin) added back export support for dotXSI 3.0. This version of Crosswalk supports Max2008 to Max2011-- both 32/64-bit. Can someone with those versions of Max verify this?

By Max 10... do you mean Max 2008 or Max 2010? Because after version 9 they started going by years... I can try-- it mainly depends on how drastic the SDK changes are between Max versions that could break the plugin code and require more effort to fix. (Off topic) However, Blur Studios released a plugin that enables Python scripting support that works back to Max 2009-- and so for the later versions we might just try and implement Mr. Wonko's GLM/GLA Python scripts for Blender in 3dsMax.

Plugin Update: Here is the modified export dialog where I added the option for a Scene Root Name (this will allow other games/programs to use whatever root scene name they need for their game compilers, etc.-- because they don't all use "model_root"). Default is set to "model_root". http://img801.imageshack.us/img801/56/3dsmaxdotxsiexportoptio.png This morning I fixed the mesh to align with the skeleton when "Reorient scene" is unchecked (i.e., leave the model in 3dsMax coordinates and don't rotate to be upright in XSI coordinates... this leaves the model face down and the model_root represents the XSI coordinate system with +Y up). MODView screenshot: http://img703.imageshack.us/img703/3026/reorientunchecked.jpg ...and here is a MODView screenshot of results with "Reorient scene" checked: http://img15.imageshack.us/img15/2432/reorientchecked.jpg So again, we'll have a beta version soon for folks to test...

Ok... plugin update: The exporter has a dialog checkbox option for reorienting the model/skeleton from 3dsMax to Softimage|XSI coordinates. Today I got the plugin fixed for the case when Reorient is checked-- this fixes the plugin and generates a proper dotXSI file that Carcass.exe compiles into a proper Ghoul2 model/animation. I still need to tweak the code to get the mesh objects properly aligned to the skeleton if "Reorient" is unchecked. (I.e., leave character face down in 3dsMax coordinates). I also still need to fix the "Export Selected" feature... but we'll have a beta version soon for folks to test.

Thanks... I have the XSI FTK (File Transfer Kit) v3.6.3 along with its .chm help file for the FTK Developer's Kit... it's everything you need to build XSI plugins for any 3D software-- even make new plugins/features for Softimage (well the old Avid versions anyway...). Unfortunately it lacks in examples or tutorials... this XSIFTK supports the XSI 3.0, 3.5, and 3.6 file formats. I also have the Crosswalk SDK 3.3 (last version compatible with Max8)... and in looking at the files, indeed the Crosswalk SDK appears to be made from the XSIFTK... (makes sense) probably the differences with 6.0 are in the template names/formats-- with some templates being new (and thus not backwards compatible). One of the first problems we ran into a couple of years ago when we first tackled attempting to fix this Max exporter was a memory allocation issue that was causing Visual Studio compile errors... and we looked into the Crosswalk SDK and saw they had modified the particular XSIFTK file... we incorporated their change and eliminated that problem. I'm confident we can overcome this last remaining issue. Then it'll be just a matter of recompiling for later versions of Max. There may be other issues with later versions of Max but we'll take 'em one at a time. I'll register on the SI-Community forums as you suggested.

Maybe, maybe not... the Softimage exporter plugin code on sourceforge is entirely different from the one that Raven released with their assets. So if that is what they used... they modified it completely. The Raven plugin is both an importer and an exporter, the user dialogs are completely different. And if you open up the .dli file in a text editor you will see amongst the garbage that it says: "Raven Software" "Copyright 2001 Activision" (who knows... maybe Activision wrote the plugin for them???). The Raven plugin exports both SRT transforms and BASEPOSE transform data-- which is needed by carcass.exe to properly compile the model into a .glm/.gla. Without this BASEPOSE data the mesh is garbage... and the Softimage Sourceforge code does not export out BASEPOSE data; and it also rotates the root node "model_root" which is why we have to compile the WIP plugin with -ignorebasedeviations to use with the JKA .gla file. DT has verified that GLAmerge works properly and doesnt care about model_root being rotated. That's the last issue I'm trying to clean up. I've looked at the source code for all the Softimage released versions and it never exported out BASEPOSE data... and thus the original exported dotXSI file is garbage as far as carcass.exe is concerned-- we can post a screenshot of this original output later. This is why this tool has been broken for all 3dsMax versions after Max5. Perhaps the Raven importer/exporter source code goes back to SOF2 or an earlier game??? Could you ask your little birdie to look thru their SOF2 archives, etc.? It would be awesome if the source code is there... because then we'd have a good importer as well. Please let me know.

Well, I did give up for a couple of years... but I'm determined to get this fixed. Just this one last issue is giving me fits... there are not any real tutorials on coding with the XSIFTK. So I'm struggling to grasp some of its principles. Maybe I'll breakdown and write Dominic LaFlamme an email.