HELP! Importing the OZMAV dumps to Sketchup

[john_smith_account]

Hello everyone.

 

Got a copy of OZMAV2. Went to the command line, and turned on .obj dump. It didn't work. I tried all the releases of OZMAV2. No dumps. So, I assumed after trying it on a second system that .obj dump in OZMAV2 was nonfunctional at this time.

 

I spent some time this weekend, and created a method for getting the .obj's generated by OZMAV r76 imported *perfectly* into goolge sketchup. Why bother? To create modded versions of the games original maps of coarse!

 

I've even modded some ruby scripts to make the job easier.

 

The imports are perfect to the original, all verts, and almost all faces are correct.

 

However... Then I read I something stating OZMAV2 *CAN* export objs.

 

*Mind blown*

 

Were my efforts wasted? Is OMAV2 already dumping sketchup importable .obj's?

 

Also, before I make a fool of myself and post my methods for perfect sketchup ports, does anyone else have an alternate method for getting the maps out of the ROM and into sketchup?

 

Any input on the topic is welcome.

[xdaniel]

OZMAV2 dumps models to "<OZMAV2 directory>\dump\<game name>\scene_<number>\"; whenever the "dumpobj" command is issued in its console, the program dumps the currently loaded scene there.

 

Also, what is a problem with OZMAV2 is that it doesn't add groups to the model at all. I since have changed libbadRDP to add group definitions per DList, but neither have I committed those changes to the SVN, nor have a made a new OZMAV2 build with those badRDP changes yet. Another problem might be how the library tries to compensate for mirrored textures, mirroring the dumped texture image and modifying the texture coordinates appropriately. That works in .obj viewers as far as I'm aware, but I'm not sure if ex. SharpOcarina correctly understands and imports those.

[john_smith_account]

I guess it doesn't really matter if OZMAV2 can dump. Are the dumps produced by OZMAV2 any better? I've got the OZMAV r76 dumps, which I already put in the effort to get working in Sketchup.

 

Also anyone else having luck importing the original maps to sketchup?

[xdaniel]

I have no idea which ones are better to be honest, as I can't even remember the original OZMAV's code and its features all that well

[Jason777]

I've used OZMAV2 to dump scenes as OBJ and then used a plugin to import it into SkethcUp. From there I modified it to my pleasure and then imported the map with ye ol' Obj2Area.

[john_smith_account]

So I am the only one who OZMAV2 doesn't dump maps for?

 

Is it my OS maybe? Windows XP?

 

It creates 2 folders on start up dump and one I *think* is called extc (not at home to check), or something like that. Then... nothing.

 

Am I missing something here?

[xdaniel]

If it can create those folder (the second one being "extr" for extracting the ROM's files), it should also be able to dump the model there. Windows XP is fine as well, seeing how that's the OS I've been developing OZMAV2 on... So what does OZMAV2 do when you try to use its "dumpobj" command? Any error message in the console or wherever? Does it appear to freeze for a second or two, then resume (during which it would/should write the model and textures)?

[spinout]

To be honest xdaniel, I believe that organizing visual mesh via groups is the wrong approach - though it does work well for collision. If visual meshes are organized by their groups, how can you implement mtls correctly? Say, for example, that a group contains two materials, and each of those materials have their own transparency and tint values - the only way to read these independently through SharpOcarina would be to split up the group (that is assuming you do implement Tr/a and Kd values). I do understand how much of a hassle it might be, though, to make SharpOcarina work this way.

 

*Ponders about downloading MS SDK and forking SharpOcarina*

nahhhh

[Arcaith]

If you split by mtl though, it means you have to assign a different mtl entry per blendmode for the same material, should you want to do something like that. Simplifies collision dividing somewhat, too.

[spinout]

assign a different mtl entry per blendmode for the same material

I don't quite understand what you mean by that - wouldn't it be a combiner for each material? The combiner is basically the transparency and coloring itself, which is why everything would be separated by it's material, as materials have their own individual coloring and transparencies.

 

As for collision, it would remain organized by groups, or all together if no group is present.

[Arcaith]

Ah...what I mean is if you wanted to use the same material twice, but have a different blendmode for each instance of that material.

[spinout]

I would think that that would be part of the modeling phase, no?

[Arcaith]

To an extent, except it's frustrating in practice. It's far easier to split the model than it is to add the same material twice, since most material editors only support a fixed number of slots and you have to overwrite an existing slot to add a new material once they are all full. Also, in any given map, it's probable that a large number of materials will use the same settings, so having them in a single group cuts down the file size in terms of definitions for the combiners, I would have thought.

 

edit: I suppose one could write a parser that defines by the mtl and add an option when importing to decide how for people who make models differently, but that's up to you guys.

[john_smith_account]

Tried 2 more XP systems, a windows 7 system, a different ROM, and updating the .DLL's.

 

Nothing.

 

 

I give up, could someone (Not XDaniel, I've bothered him enough) just dump me the maps for me to try. Please

 

(Side note: I tried OZMAV2 on a OLD p3 laptop last night. And it ran, and looked fine! That must be some efficient coding XDaniel. Good job!)

[spinout]

If it can create those folder (the second one being "extr" for extracting the ROM's files), it should also be able to dump the model there. Windows XP is fine as well, seeing how that's the OS I've been developing OZMAV2 on... So what does OZMAV2 do when you try to use its "dumpobj" command? Any error message in the console or wherever? Does it appear to freeze for a second or two, then resume (during which it would/should write the model and textures)?

 

I was trying to help someone on MSN today use the dumpobj feature, and it wouldn't work for them though it worked flawlessly for me. When I had the person try out the 'extract' command it also failed - it could not create the layout.txt file. I believe that some of the code which creates folders is failing for certain people, as the folders were never created in the extr or dump folders he had. I cannot reproduce this error in any way. I *believe* he somehow got what errno was - 2 ENOENT:

No such file or directory. A component of a specified pathname did not exist, or the pathname was an empty string.

[xdaniel]

1. dumpobj... I just can't seem to reproduce those problems. Gotta try and look into that some more, if I somehow even can.

 

2. SharpOcarina's design and .obj support. I did a hell of a lot of bad design choices, huh? Rewriting the .obj parser to support Tr and properly support Kd, and in turn the actual converter's material and group management, would in turn mean some heavy rethinking of the program's structural and interface design, and rewriting of much of the Display List generation code. And, while probably a good idea, I can't see myself throwing out that much code that already works - as flawed as it might be - so soon after writing it... Oh hell, I should stop trying to pick up such ambitious projects.

[john_smith_account]

1. dumpobj... I just can't seem to reproduce those problems. Gotta try and look into that some more, if I somehow even can.

 

2. SharpOcarina's design and .obj support. I did a hell of a lot of bad design choices, huh? Rewriting the .obj parser to support Tr and properly support Kd, and in turn the actual converter's material and group management, would in turn mean some heavy rethinking of the program's structural and interface design, and rewriting of much of the Display List generation code. And, while probably a good idea, I can't see myself throwing out that much code that already works - as flawed as it might be - so soon after writing it... Oh hell, I should stop trying to pick up such ambitious projects.

 

1. Never mind about OZMAV2. It's not important at all, and your efforts are better sent on Sharp Ocarina.

 

2. You did not make a bad choice! You chose the simplest method, which is easiest for most modders to understand. Consider spinout's own words...

 

To be honest xdaniel, I believe that organizing visual mesh via groups is the wrong approach - though it does work well for collision. If visual meshes are organized by their groups, how can you implement mtls correctly? Say, for example, that a group contains two materials, and each of those materials have their own transparency and tint values - the only way to read these independently through SharpOcarina would be to split up the group (that is assuming you do implement Tr/a and Kd values). I do understand how much of a hassle it might be, though, to make SharpOcarina work this way.

 

*Ponders about downloading MS SDK and forking SharpOcarina*

nahhhh

 

It does work well for collision, and it would be a pain, and I can't see how the results would be justifiable. Most users will never appreciate the difference. And honestly us more advanced users who would already have work arounds. Once users get to to the level they need such features, they can use the rather easy work arounds.

 

You can always makes the changes in a far distant release, or even start a SharpOcarina2. Right now the time would be better spent on working out the bugs and adding useful functions to the current system.