PDA

View Full Version : Parent MDD object?



cyclopse
01-22-2017, 06:49 PM
I noticed that an MDD deformed object stays in place no matter what. Any way to make MDD playback relative so that I can parent the MDD object to a null and move it to a different location in my scene?

lertola2
01-22-2017, 07:51 PM
I can move an MDD object around with no problem. How are you applying your MDD file? I am using the MD_Reader displacement.

cyclopse
01-22-2017, 09:41 PM
Same here, but it appears that the object is locked to global coordinates when I use the MD_Reader.

Surrealist.
01-22-2017, 10:35 PM
If you bring it in as Alembic import there is a bug or limitation where you can not use Object Space. Even though is uses the same MD Reader. It will be locked in World Space even if Object Space is selected. If however you load save out an Mdd for that, and load it up, it will allow you to switch it to Object Space. But it still won't work unless you create a new scene and load the same object as a .lwo or obj. Then add a new reader. It should work to set it to Object Space.Then you can just translate, rotate, parent etc. You change it in the Apply Cache To: Dropdown.

cyclopse
01-23-2017, 01:08 AM
Alrighty, gotta love Lightwave for its workarounds. Thanks man, I'll give it a try.

Surrealist.
01-23-2017, 01:35 AM
Love the 15 min time limit. Sorry for the typo, frozen in time. Good luck with it anyway, I am sure you can get it to work.


If however you save out an Mdd for that...

Greenlaw
01-23-2017, 10:21 AM
It depends on your player.

If you're using the native MD Reader, under 'Apply Caceh To:' select Object Space instead of World Space. This allows you to affect the object with normal transformations and parenting.

In other players, it might be called something else. MDD Pointer, for example, calls it Key Move, I believe.

Edit: Oops...I see Surrealist already answered this. Never mind. :)

bazsa73
01-23-2017, 10:46 AM
It depends on your player.

If you're using the native MD Reader, under 'Apply Caceh To:' select Object Space instead of World Space. This allows you to affect the object with normal transformations and parenting.

In other players, it might be called something else. MDD Pointer, for example, calls it Key Move, I believe.

Edit: Oops...I see Surrealist already answered this. Never mind. :)

Sure this is a helpful community.

Surrealist.
01-23-2017, 11:48 AM
Yeah my workflow for Alembic/mdd has been to have a mesh or meshes with the same vertex order in one scene. Surfaces applied and so on. That is loaded into my render scene as I usually would. But it has no rig. Just a mesh. I set up all my lighting and camera work in that scene.

Then in a separate scene I load up the Alembic scene and save out my .mdd files. In the scene with my mesh and light setups, camera animation, I already have the mdd readers set up on the render meshes. So when I am ready to change the animation and set up other shots/lighting or whatever I simply load in the new mdd files, position the character where I want it etc.

I just keep going like that, each time I want to bring in new animation I just do it in a fresh scene and save out the mdd files and then go back to my working render/animation scene.

Hope that makes sense.

prometheus
01-23-2017, 12:17 PM
One super easy way...(if you at least just run a simulation in lightwave that is..like bullet to explode something)
just add old legacy clothfx...(on the geometry properties fx tab and add clothfx from there on the object in question) go to the clothfx file tab and scan motion..it will prompt with an mdd file save requester, save it.
In the same cloth fx tab, set playback mode to local, now you should be able to directly move the mdd object itself, or parent it to a null..then you can move the null or the object freely and also rotate it.
Turn off bullet dynamics so it doesn´t interfere.

Greenlaw
01-23-2017, 12:40 PM
I used to do that in 11.x and earlier.

Nowadays in LW 2015, I like using MD Multi-Baker instead...this scans everything you select in your animation or sim, and it automatically saves a separate MDD for each object. I even use this for single objects because it's so convenient.

Then to load the MDDs, I use MDD Mult-Loader--this lets you auto-apply multiple MDDs to the same objects. The tools is pretty smart--it can find the correct MDD's based on a variety of parameters.

Surrealist.
01-23-2017, 12:46 PM
Cool Tips. Thanks. I recently discovered the multi baker. Works great. Have not tried the multi loader though. Sounds sweet!

jwiede
01-23-2017, 12:56 PM
It depends on your player.

If you're using the native MD Reader, under 'Apply Caceh To:' select Object Space instead of World Space. This allows you to affect the object with normal transformations and parenting.

In other players, it might be called something else. MDD Pointer, for example, calls it Key Move, I believe.

This raises a good point: Does LW itself really need so many different "MDD reader"-type options available? IMO, it's another instance of the classic LW "show a bunch of options, many named similarly, without even the tiniest hint at the difference between them" LW GUI anti-pattern. The issue commonly occurs with plugin/entity selection from a drop-down text menu -- selection of the various object properties sub-tabs' add-ons (incl. the many MDD reader options) serve well as examples.

Some indication on each entry whether "native" or which plugin provided would be useful, but even then I don't believe LW needs to make so many distinct options available to choose in GUI. If it's going to do that, then it really needs to provide some means for evaluating between them (as a proper text description) somehow. Another useful addition would be glyphs on certain entries to indicate "preferred" as well as "deprecated" entries (perhaps triggered by plugin class/handler-associated flags passed during plugin registration).

LW3DG might not yet be up to replacing the entire UI engine, so be it. There is still plenty of improvement possible in the current UI engine, and requiring fairly minimal dev effort in many cases, so improvements won't be grossly wasteful to implement despite knowing the UI engine itself will eventually be replaced outright with Qt or whatever. Done properly, they could even somewhat "ease" the eventual Qt transition.

Greenlaw
01-23-2017, 12:56 PM
Yes, I've been using them for a few years now and they great time savers.

Thank Matt for those tools...I believe those are his babies. :)

Surrealist.
01-23-2017, 01:10 PM
Thanks Matt! :)

Greenlaw
01-23-2017, 01:22 PM
This raises a good point, though: Does LW itself really need so many different "MDD reader"-type options available?.
I agree but I understand why this happened.

Partly it's because some of these readers are third party alternatives to LW3DG's versions. DP's MDD Pointer or the old Point Over reader for example.

The old 'native' MDD reader was part of the ClothFX package and is still needed if you wish to use any of the FX tools like FX_MetaLink. None of the other readers, like the current native MD Reader or the third party readers know what to do with scans made by ClothFX if you want to use other FX tools with it. I'm guessing this is because the developer of ClothFX is no longer with NewTek and they probably consider the FX suite 'legacy' anyway.

(Although, I must confess, ClothFX came to the rescue for me just last week because I couldn't get a points-only simulation from Bullet Deforming. I don't know for certain that Bullet couldn't do the job but I didn't have time to figure that out and I knew I could do it with ClothFX. That was probably the first time I touched ClothFX for a sim in about four years.) :p

jwiede
01-23-2017, 01:47 PM
I agree but I understand why this happened.

Partly it's because some of these readers are third party alternatives to LW3DG's versions. DP's MDD Pointer or the old Point Over reader for example.

Understood. They definitely don't improve the drop-down menu situation described below, but the GUI issue would still exist even if they didn't. As I noted, just adding plugin owner in parens after their entries would mitigate their part of the overall issue.


The old 'native' MDD reader was part of the ClothFX package and is still needed if you wish to use any of the FX tools like FX_MetaLink. None of the other readers, like the current native MD Reader or the third party readers know what to do with scans made by ClothFX if you want to use other FX tools with it. I'm guessing this is because the developer of ClothFX is no longer with NewTek and they probably consider the FX suite 'legacy' anyway.

That's the _real_ problem, IMO. Adding new ones that didn't fully replace the existing options was a mistake, and while (arguably) understandable in context, doing so without also providing a way to easily differentiate between the new and "legacy" versions is less excusable. Even just considering "native" MDD options, there's too many, they're all named similarly, and as noted, the entries in the menu themselves offer minimal distinction between them.

Again, this has become a recurring GUI anti-pattern that occurs much too often in LW: Users are given a bunch of options with minimal info about why they differ, and just expected to know a priori which to choose, yet no docs/reference, help, etc. explain the comparative benefits/limitations of the different choices (at best, docs might describe each, but similar entries will have similar descriptions). Such cases have objectively-measurable poor GUI discoverability for novice users, and the lack of mnemonic differentiation even makes it difficult for experienced users to retain the differences between uses.

These situations arise in other apps, but are almost entirely mitigated by tooltip/status-line text, context-based help descriptions with compare-and-contrast info, etc. In comparison, LW's situation is "death by a thousand little cuts": Existence of similar options, absence of tooltip/status-line info support, absence of contextual help support, and poor docs (w.r.t. distinguishing options) all combine to greatly magnify the problem. LW3DG could easily address a few of those (f.e. at least (re-)enabling contextual help and providing more useful docs) at minimal dev cost/effort required.

Greenlaw
01-23-2017, 01:53 PM
That's the _real_ problem, IMO. Adding new ones that didn't fully replace the existing options was a mistak.
Again, I agree. But to be fair, LW3DG did add replacements for some the meta tools as nodes, and they don't require specifically scanning through, say ClothFX. (DP also has a useful alternative replacement called DP MetaFit.)

But from time to time, I do run into odd situations where the 'legacy' tools can do something I can't with the current tools.

It would be great if the new tools could simply do everything and we could get rid of all the old 'legacy' stuff. I'm sure that's been LW3DG's goal, and I do see progress made in each new release. But for now, I'm glad the old stuff at least still works in 2015.3. (Some of those 'legacy' tools are 16 years old!) :)

cyclopse
01-23-2017, 02:37 PM
Again, I agree. But to be fair, LW3DG did add replacements for some the meta tools as nodes, and they don't require specifically scanning through, say ClothFX. (DP also has a useful alternative replacement called DP MetaFit.)

But from time to time, I do run into odd situations where the 'legacy' tools can do something I can't with the current tools.

It would be great if the new tools could simply do everything and we could get rid of all the old 'legacy' stuff. I'm sure that's been LW3DG's goal, and I do see progress made in each new release. But for now, I'm glad the old stuff at least still works in 2015.3. (Some of those 'legacy' tools are 16 years old!) :)

Ok... I'm thinking this GUI debate should have its own thread. That being said, I'll throw in my 2 cents...

Some of these legacy tools are even older than that. I've been using LW3D since 1995 (22 years - I guess I'm a legacy tool... wait... did I just call myself a tool?), and one reason I keep coming back to it (vs say... Maya - which IMHO is better software) is because other software packages are constantly renaming functions and features, removing /depricating functions and features, and just moving them around the GUI so you have to spend 10 minutes just finding the damn button. Lightwave has some courtesy to those that have been using it a long time. Some... not total. I do still have to spend time hunting around the GUI to find things that used to be right there in front of my face, but not nearly as much.

Yes, it's annoying that with LW3D to get just about anything to work, you have to find a work-around (hell, it used to be that we called bones in LW "magnet sticks" and thought it was ridiculous the way LW handled bones... back then, if you wanted realistic bones you needed to use a plugin called "puppetmaster"). And some moves that Newtek made in the past were pretty ludicrous and downright stupid (last time I left Lightwave for Maya in 2003 I threw my LW3D dongle into the dumpster from a 6th story window out of frustration). But at least the interface always feels like coming home when you get back into it. Try taking a year or two (or 10) off of Maya. You'll feel like a child lost at a doctor's convention.

*EDIT* Almost forgot... the one thing I wish LW had that Maya does above all else... a "search" field so you can find buttons that have been moved!

Greenlaw
01-23-2017, 02:59 PM
"Magnet Sticks"? That's awesome!

I remember using Puppet Master! I used it in LW 5.5 and I thought it was fantastic at the time. It would break any time point order changed but I was happy to put up with that because when it worked, the results were fantastic compared to bones. (That and Morph Gizmo too!)

Well, until LW 7 or so came along anyway. :)

jwiede
01-23-2017, 03:14 PM
But at least the interface always feels like coming home when you get back into it.

LW's GUI definitely does NOT feel like "going home" to me, it feels like being forced to live in a barn in Amish country. Survivable, but a painfully-limited anachronism.


*EDIT* Almost forgot... the one thing I wish LW had that Maya does above all else... a "search" field so you can find buttons that have been moved!

There's nothing quite like that in LW, but the search field in upper-left of menu editor is often useful for finding where plugin commands are manifested in the GUI (presuming you can figure out name of plugin -- were plugin cmds visible enumerated by plugin in the plugin editor it'd be easier, but alas, while they easily could be, they aren't).

jwiede
01-23-2017, 04:03 PM
Ok... I'm thinking this GUI debate should have its own thread.

I cited the (objectively-demonstrable) GUI usability problem with offering menus of multiple, similar options (with no contextual info to differentiate them) w.r.t. MDD readers, and noted a couple GUI mitigations that ought to be feasible even given LW's limited GUI engine capabilities.

If you're suggesting that's a "GUI debate", what is the topic of debate?

bazsa73
01-23-2017, 04:38 PM
LW's GUI definitely does NOT feel like "going home" to me, it feels like being forced to live in a barn in Amish country. Survivable, but a painfully-limited anachronism.

Infidel!

Surrealist.
01-24-2017, 01:33 AM
So don't shoot me for being the thread cop. I hate thread cops! lol

But just consider this for a second, then I will bow out.

Is it possible to simply allow a support thread to remain as such? And leave the LightWave rant arguments for other threads? Sure it is related but...

Is it really necessary to turn every thread into a "what is generally or even specifically wrong with LightWave"?

I have two alternate suggestions:

1) Start a new feature request thread.
2)Bring it up directly with developers

And then leave threads where a user has a specific question on something clear of other rants so that when searched in the future, a person can easily find the relevant data without needing to weed through a ton of banter, that practically speaking, is OT.

Just something to consider. I am not trying to be thread cop.

Rant on if you must, but consider the alternatives. Please. :)

Spinland
01-24-2017, 05:56 AM
Is it possible to simply allow a support thread to remain as such? And leave the LightWave rant arguments for other threads? Sure it is related but...

Is it really necessary to turn every thread into a "what is generally or even specifically wrong with LightWave"?



QFA. :beerchug: