Anybody using the .Rig format yet?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 08 August 2004   #1
Anybody using the .Rig format yet?

Anybody using the .rig format to save and reload their skeletons yet? It would be really cool if we could start trading these rigs with each other and begin to tap into the potential of having a library of rigs available from which you could mix and match different rig parts.
 
Old 08 August 2004   #2
wow, so nobody is using this at all yet?
 
Old 08 August 2004   #3
haven't use it, but good idea. To trade various configs, dino, humanoid, quadraped
 
Old 08 August 2004   #4
only works on basic rigs so far ( some parented item don't get saved, items that Ik targets at parented to get lost too )

maybe next update it's going to be free so looking forward to it

Last edited by T4D : 08 August 2004 at 06:58 AM.
 
Old 08 August 2004   #5
Indeed, it does not seem like it would be able to store more "exotic" rigs. I think what they should do is make it easier to save and load specific items to/from a scene instead. That would be more versatile. Their thought was good though, however that's not always what counts.
 
Old 08 August 2004   #6
i got to thinking that lw could benefit from having a 'unified' file format. for example, in apps like maya, shader info could be stored in maya ascii or binary files (but the ascii vs binary is not what i'm getting at - although). all relevant information is stored in that file, and importing that file appends a particular part of the scene based on the "block" the imported file contained. in addition, maya can also store trax clips - in lw, .hmot - in maya ascii or binary scene files.

while i somewhat understand the implication of this. lw's scene file does not contain object info. that's fine, at least for now. the idea is that the scene file is already broken up into blocks of data. lw could ideally export only bits of desired information (keeping file size small, and organisation simple) that can be imported later on.

lastly: granted, this scene file importation and exportation is quite achievable already using lscript / plugins as importers and exporters. but this only makes the .RIG format all the more seem obsolete. i personally dont see anything innovative about the .RIG format. all the needed information for rigs is in the scene file already. all we have to do is to extend lw's modularity to the scene file itself (as opposed to simply the relationship between meshes and the scene). a third-party could do it - i know i can, and might actually try to - but i think lw developers will go on the right track introducing this sort of "principle" in lw file format handling.

just my opinion...
__________________
"If in this life only we have hope in Christ, we are of all men most miserable."

Advert:
Janus - multi-pass rendering for LightWave3D
 
Old 08 August 2004   #7
I believe the rig file format also has an SDK so its expandable. The file format on this release doesnt suppport expressions and other modifiers on the rig, just the basics. A rig file can also be part of a full rig like a hand, arm, leg etc.
 
Old 01 January 2006   #8
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:14 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.