Jump to content
eetu

Mdd Reader

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

As niko3d pointed out in the other thread, I think the first copy of the geometry is always at time 0.

The thing that worries me right now is this "flipping of the z axis".

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Colin, what was specifically the problem that you encountered that required the z coordinates to be flipped?

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

×