Jump to content

Mdd Reader


eetu

Recommended Posts

Hey Colin, good to know it is of some use, maybe you could put the fixed version up somewhere?

(If you don't have suitable webspace, I can add it to the original mdd page)

eetu.

Link to comment
Share on other sites

  • 4 weeks later...

Now that 9.5 has integrated mdd import/export (yippee!), i think we can lay this to rest.

I'll keep the page up for reference if someone is writing something similar in the future.

(I also added Colin's fix for completeness' sake)

eetu.

Link to comment
Share on other sites

Does anyone know if Point Over .mdd files are inherently different from LW .mdd files then? This presents a dilemma for the new .mdd support in 9.5. The .mdd support in H9.5 is based upon a variant that was previously developed internally for a production a few years ago. I had assumed that it was the right variant but it seems that it's not that simple.

Link to comment
Share on other sites

Does anyone know if Point Over .mdd files are inherently different from LW .mdd files then?

They should all be the same, without any 'variants'.

The only 'official spec' that i know of is in the bottom of this page http://www.ef9.com/ef9/PO1.5/LW/PointOven_lw.html (as you most probably know:)

It doesn't say anything about e.g. the possible padding frames for motion blur, though..

eetu.

Link to comment
Share on other sites

I've used my modified versions of these scripts in production extensively in the last month. They work very well besides that offset issue, which is very easily worked around.

LW looks at the world backward. All I had to do was negate the z-coordinates in eetu's script and everything worked perfectly.

Edward, I saw that other thread. I'm not sure there's anything I can add, but if you have any questions about the .mdd format, feel free to ask them. I know it pretty well -- I've even written custom C plugins that read and write them.

Edited by ColinCohen
Link to comment
Share on other sites

As I said, LW looks at the world backward. That is,

x,y,z in Houdini = x,y,-z in LW.

For example, I've created a complex road system in Houdini, part of which gets smashed. I imported both parts into LW. I then did the DOPs in Houdini and exported the .mdd file using the original script. But .mdd file caused the geometry to appear on the opposite side of the z-axis in LW. So I negated the z-coordinate in eetu's script and all was well. It should be noted that if all you're looking at is one piece of geometry, you might not even realize it was flipped, as you'd have no reference point. But with multiple pieces, it'll become very obvious.

LW's rotational system is also different than yours. Fortunately, you don't have to deal with that with .mdd files. But if you guys ever decide to write a .mot file exporter (for motion paths) as I recently did, you certainly will.

Edited by ColinCohen
Link to comment
Share on other sites

As I said, LW looks at the world backward. That is,

I don't think it's just a Lightwave thing, it can appear in other contexts as well. Having designed and tested the inhouse MDD tools Nicholas is talking about in the other thread on the SESI forum, I've also seen the necessity to have an option to flip the Z axis. Mind you, in that environment there was no data flow from Lightwave to Houdini, but rather we had an inhouse geo exporter for Maya that would export the static meshes later used to receive the MDD point cache. Earlier we had a Maya->Lightwave pipeline as well, and they seemed to be working consistently together.

It might be the case that Point Oven did some "smart" manipulation to make Maya and Lightwave work together better, but that's likely to be the tool used by many people intending to use the factory MDD tools in Houdini as well, so I would say it's a good thing to have that option in general, it costs almost nothing performance wise. PO was the tool that we use that time to generate the MDDs from Maya before we rolled our own one, and I vaguely remember thinking about an option in the exporter to emulate that as well. Sorry for being a bit hazy but it was over a year ago I've been into this.

cheers,

Andras

Link to comment
Share on other sites

I don't think it's just a Lightwave thing, it can appear in other contexts as well. Having designed and tested the inhouse MDD tools Nicholas is talking about in the other thread on the SESI forum, I've also seen the necessity to have an option to flip the Z axis. Mind you, in that environment there was no data flow from Lightwave to Houdini, but rather we had an inhouse geo exporter for Maya that would export the static meshes later used to receive the MDD point cache. Earlier we had a Maya->Lightwave pipeline as well, and they seemed to be working consistently together.

It might be the case that Point Oven did some "smart" manipulation to make Maya and Lightwave work together better, but that's likely to be the tool used by many people intending to use the factory MDD tools in Houdini as well, so I would say it's a good thing to have that option in general, it costs almost nothing performance wise. PO was the tool that we use that time to generate the MDDs from Maya before we rolled our own one, and I vaguely remember thinking about an option in the exporter to emulate that as well. Sorry for being a bit hazy but it was over a year ago I've been into this.

cheers,

Andras

I cant quite rememeber the problem with the Z axis flip either, we did need the option on our reader when we were caching with point oven for some reason, once we had our own mdd exporter it somehow wasnt needed any more. We do still get a flip on normal direction however possibly to do with the correction of the Z axis, i can look back over our notes to see if we can help out with the issue. I have seen a few people mentioning the flip in normals with all houdini based mdd readers at some point, as mdds contain no information on normals so z axis flip sounds like the culprit(or the correction of the z axis flip).

Thanks

Nicholas pliatsikas

Link to comment
Share on other sites

As eetu and Colin mentioned, it's because LW uses a Right-Handed coordinate system while Houdini uses a Left-Handed one. That was why the normals appear to be flipped. They were "flipped" only because the point positions caused the polygons themselves to flip inside out. If you load the .mdd file from LW into Houdini and look at the point numbers, you will notice that they're into totally different places after applying the .mdd. The funny thing is that I was testing with newcube.obj and newcube.mdd which were both exported from the same program (Modo which is for intents and purposes neo-LW :). newcube.obj would be in a Left-Handed coordinate system (presumably for export to Maya, Houdini, etc.) but then the .mdd file would be Right-Handed.

.obj files still have the reversed vertex order problem but that's separate.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...