Jump to content

Fixing the dotXSI 3.0 Exporter for 3ds Max...


Recommended Posts

Update:

 

So far I have uploaded/released version 1.9 dotXSI 3.0 exporters for Max6 thru Max2011. I'm working to get versions for Max2012 thru Max2016 submitted as quickly as I can.

 

I would appreciate user feedback. Thanks.

 

Would definitely appreciate the newer version that supports 2015.  But I won't need it for a few days yet.

Link to comment

Update:  I just submitted the 3ds Max 2013 dotXSI 3.0 v1.9 Exporter (32/64-bit) for approval... @@eezstreet or @@Barricade24 or @@AshuraDX -- please approve the files in numerical order (lowest to highest) if possible. 

 

Remember that Max2013 plugins also work in Max2014...

 

I'll update, recompile and submit the Max2015/2016 version tomorrow.

 

User feedback is greatly appreciated.

 

Thanks! :winkthumb:

Link to comment

Update:  Still waiting on approval of the 3ds Max 2013 exporter.  I also have just submitted the 3ds Max 2015 dotXSI 3.0 v1.9 exporter... so hopefully they'll both be approved soon. 

 

I would really appreciate some user feedback regarding how the vertex normals look in Modview, as well as in-game, as compared to 3ds Max viewports (temporarily apply an Edit_Normals modifier to see vertex normals in the 3ds Max viewport).

Link to comment
  • 7 months later...

Here are my results with the new exporter compared with the old one. 

You can clearly see a difference in lighting!

3ds Max 2014:

xizorvertex3dsmax.jpg

 

Modview old xsi export:

xizorvertex1.jpg

 

Modview new xsi export:

xizorvertex2.jpg

 

Ingame old:

xizor13-13-55.jpg

 

Ingame new (standard smoothing groups):

xizor13-14-02.jpg

 

Ingame old:

xizor13-59-32.jpg

 

Ingame new (specified/explicit normals test on mouth)

xizor13-58-45.jpg

So, when is this coming...?

Link to comment
  • 1 month later...

Update: Ok... so it seems we got lucky. I just compiled the dotXSI 3.0 exporter v1.9 source code for 3ds Max 2017 using the Max 2017 SDK and the XSI Crosswalk 2015 SDK (which is no longer being supported).

 

I emailed it to a few people to beta test. If you have Max 2017 and would like to beta test it for me... then send me a PM.

 

Thanks! :winkthumb:

Smoo likes this
Link to comment
  • 2 months later...

Alright, I'm making a list of feature enhancements for Release 2.0 of the dotXSI 3.0 exporter.

 

Working with @@Psyk0Sith on the MotionBuilder/3dsMax Integrated workflow has revealed a shortcoming when you want to export the CS Biped, but not the root BIP01 node... however, this does not affect current CS Biped shadow rig workflows.

 

Anyone have any other needed fixes?

Link to comment

Yeah, when it comes to games you never want to directly weigh a character to a biped rig, you'll only limit yourself with how you can arrange the hierarchy so that it can work in game otherwise you'll have problems. You also lose a lot of control and freedom over how the rig drives the character.

Link to comment

Yeah, when it comes to games you never want to directly weigh a character to a biped rig, you'll only limit yourself with how you can arrange the hierarchy so that it can work in game otherwise you'll have problems. You also lose a lot of control and freedom over how the rig drives the character.

I disagree... if a 3dsMax user creates a shadow null rig constrained to either a CS Biped or CAT setup-- you limit yourself already to what either CAT or CS Biped can do (this goes to your point...).

 

However, what I'm proposing is for those who would use CAT or CS Biped to "drive" their constraind Null helpers... is to allow them to skin directly to either CAT or CS Biped and export CS Biped or CAT bones as nulls with correct game bone names-- thus making a shadow Null rig unneccessary. But folks could still work that way if they choose.

 

@@Psyk0Sith - would like the new capability for new creatures. If the exporter is modified to export the CAT or CS Biped as game friendly bones... why force the artist to create a Null shadow rig?

 

EDIT: One issue I foresee that could kill this idea (at least for the JK game engine) is... if the game requires the bones to have a specific bone axis (X, Y, Z) orientation. Any such requirement may, or may not, align with the CAT or CS Biped bone axis orientations-- then I believe a Null shadow rig would be mandatory.

 

However, the exporters are meant to be generic/agnostic... so I will still implement these enhancements.

Link to comment

I don't see how using shadow rigs is limiting, you just simply pose constrain the nulls to the biped then plot the animation on export.

 

Every 3d forum I visit game artists use shadow rigs, I'm sorry but saying it's the less ideal solution is flat out wrong. When using custom custom rigs especially you can arrange the hierarchy how you need to get the rig to move in ways that require animating fewer controllers and automating certain movements. For instance, moving the hip controller should NOT move the entire character like it would by just simply moving the game skeleton hip object. It should however let the character crouch because the feet controls are NOT child to the hips or any of the leg bones but under a move all control.

 

My rigs also do NOT have the same local orientation as the FK game skeleton nulls, in SI we use the constraint compensation option to allow the driven target to retain it's local transforms rather than inheriting them from the driving source. This is how I was able to fix the issue with the AT-ST's feet, I simply removed the pose constraint on the talus bones, removed the envelope, rotated the bone, redid the envelope, applied a pose constraint and exported plotting the same animations with no need to touch anything else. It literally was a super quick fix.

Link to comment

@@minilogoguy18 - your whole point was that CS Biped and CAT systems have limitations and may be more restrictive than a Bones based custom rig. On this point you and I are in violent agreement.

you said,

I don't see how using shadow rigs is limiting, you just simply pose constrain the nulls to the biped then plot the animation on export.

here you misunderstand... as you know, when you constrain null helpers (to which you skin the mesh) to CAT or CS Biped-- you do not animate the nulls, but rather you animate CAT or CS Biped... thus you are limiting yourself to the capabilities of those systems. <-- That is my point.  We are saying the same thing.

 

Skin bones constrained to a custom Max Bone FK/IK rig and a REACTOR/MassFX skeleton (for simulating ragdoll physics) is what I am planning to make for Jedi Knight.  So in my planned character rig, an artist will be able to blend the skin-bone skeleton between the FK/IK Rig and the REACTOR (or MassFX) Skeleton.

Link to comment

Can't really use CAT or CS Biped as in-game bones for JKA due to bone angles for torso pitch/yaw being hard-coded. If only it were like HL2, where you could specify it yourself.

 

Hard-coded?  For humanoids only?  Or for any new creature or alien?  These enhancements (if possible, as I said above...) could be used for new NPC creatures/aliens having their own custom skeletons.  Folks can still keep their current CAT or CS Biped shadow-rig workflows.

Link to comment

They are limited, and bones are just part of what you can do to make a custom rig, mine include IK chains, nulls, curves, implicit objects and polymeshes.

 

I've seen custom rigs in 3DS Max that make those preset bipeds look like FK animation in Dragon. You forget, I used to use max, I know all about the CS bipeds, I used to use Keshire's that he made that was a shadow rig with the JA skeleton as dummy objects that received the plotted motions. The Max 4 or 5 (I can't remember which) file is probably floating around the net somewhere but I may have in on another HDD.

 

To the second part after the quote, well duh. There isn't a single bit of animation on my null skeletons, they just receive the plotted motions from shadowing the rig on export. If the CS biped can't get a good result without animating the nulls that the model is weighed to that will be the game skeleton then it isn't a very good solution.

 

Using the biped as the game exported skeleton is what's not going to work that great. You wont get the local transform values you need and the heirarchy of the biped I'm almost certain varies from the hierarchy the game uses for say a player model. A custom NPC you can arrange the bones however you want but rearranging the biped I'm almost certain will keep it from working the way it was meant to.

Link to comment

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
×
×
  • Create New...