Anyone know what causes this?

[Monkor]

I've been fiddling with adding things in VRS, saving the .DAT, exporting to .MQO from model viewer, and then editing the .MQO in 3DS MAX. From time to time, it seems that when I make edits in MAX and then export back to .MQO it shows up fine in model viewer. I'll then open the .DAT in VRS again, maybe add or delete a few verts/faces, save back to the .DAT and try to export again from model viewer. When I do this, occasionally model viewer will begin to export the single mesh into multiple meshes.

For example I did a test of just adding a sphere and moving some of the verts around. After that I brought it back into VRS and added a few more verts, and when I would export it from model viewer it made the sphere into a mesh for every face instead of one mesh for the entire object.

I've noticed this several times now, and once the model starts to screw up, it always screws up no matter what I seem to do in VRS. It's also happened where it will reorder all of the vert numbers so the mapping gets completely screwed up, and even remapping the entire thing in MAX and importing it back to the model viewer doesn't fix it. I've also tried opening these files in Meta to see if it was a problem with MAX, but it does the exact same thing.

Any ideas on what causes this?

[Irisjir Callard]

Re: Anyone know what causes this?

It might simply need to be 'rebooted'. I know the graphics converter I got off Amaduns sticky to edit alpha maps with starts 'stalling' after I update the alpha map 10 or 15 times, and I have to exit the program and restart it. (after which I simply re-save and THEN it displays my changes...go figure).

I also know I need to 'reboot' modelviewer if I haven't had it displaying for 15 or 20 minutes, or it'll go to displaying a blank white screen, like if my screensaver had gone on.

I'm not sure what causes either of these problems, I always assumed it was small programming errors that started building onto each other every time I jiggled something.

[Monkor]

Re: Anyone know what causes this?

It happens no matter what, new instance of model viewer/VRS or not. The model displays fine in model viewer, that's not the problem. It's a problem with VRS saving to the DAT or with model viewer saving to MQO. The model viewer is, for whatever reason, deciding to split up the mesh into 300 separate meshes containing one face each, as opposed to one mesh with 300 faces. I don't know if it's a problem with model viewer itself exporting incorrectly, or if it's a problem with the way VRS is saving to the DAT file which causes this to happen.

It sounds like your problem is something else, possibly related to your video card or drivers.

[Irisjir Callard]

Re: Anyone know what causes this?

It happens no matter what, new instance of model viewer/VRS or not. The model displays fine in model viewer, that's not the problem. It's a problem with VRS saving to the DAT or with model viewer saving to MQO. The model viewer is, for whatever reason, deciding to split up the mesh into 300 separate meshes containing one face each, as opposed to one mesh with 300 faces. I don't know if it's a problem with model viewer itself exporting incorrectly, or if it's a problem with the way VRS is saving to the DAT file which causes this to happen.

It sounds like your problem is something else, possibly related to your video card or drivers.

Quite likely, and I think just now I finally figured out what you were exactly saying. I didn't really understand the first post.

If I have a grasp of the situation now (and I don't use VRS, have it but haven't fired it up yet) I would say that the problem is not with modelviewer. It sounds to me like you reset something (if you have a prefrences menu, I would examine that for anything that looks out of whack) that codes for links in the mesh between polygons. Having lost the data for how to link the polygons together, modelviewer doesn't really have a choice, and HAS to export a whole bunch of tiny meshes.


Of course, this is the kindergardener trying to help her teacher with a radiator problem, so I probably still don't know whats going on. But I don't know of a single way to do what you seem to have done with modelviewer (and I'm pretty sure I've personally discovered every single way to screw up with that particular program) so it seems like the problem has to either be a VRS setting or you lost the raw FFXI data.



EDIT


Ok I reread the first post.

I bet the whole root of the problem if you ADDING polygons where there weren't before. The program doesn't know how to wrap mesh onto those polygons, so the entire house of cards comes tumbling down.

[Macht]

Re: Anyone know what causes this?

If it's a problem with the Textures then it's likely VRS. One bug that in the export back into the .dat that VRS ALWAYS does is it writes the wrong DataSize for the textures. This is an issue for FFXI when the DataSize is smaller then the Texture and for AltanaView (AltanaView can crash from this error).

ModelViewer ignores DataSize which is why it appears to work fine in it, but when it saves out to .mqo the DataSize error is still in there. This might be what is causing 3DMAX to crash on you. Correcting the DataSizes is very second nature to me now, if I get that .dat I can correct the datasizes and see if that doesn't solve your problem.

[Monkor]

Re: Anyone know what causes this?

I guess I'm not explaining this well. I have attached two images to help.

First, I'm not modifying any textures. They have nothing to play in this problem. I added a sphere to an existing head object inside of VRS. I saved this DAT file, and exported from DAT to MQO using model viewer. I imported the MQO into MAX. I then moved verts around inside of MAX. This is where the first image comes into play. The object is a single mesh, with 184 faces. You can tell it is one object because there is one bounding box around the mesh.

After moving these faces, I convert MQO to DAT inside of model viewer and it works as expected, no problems visible. I then open the DAT up in VRS again, and I add a new row of faces at the bottom of the mesh. All faces are tris, no quad faces. I then save this DAT and view it in model viewer. Everything looks fine.

Convert DAT to MQO and open the MQO in MAX. Now image two comes into play. When MAX imports this MQO, it's now 204 meshes, each with one face. This is supposed to be one mesh, with 204 faces. Somewhere in the middle either VRS or model viewer is deciding to split the single mesh into 204 different ones. You can see in the image that there is no longer one bounding box, but 204 boxes, because it is no longer one object.

All I have done is to add one row at the bottom, from existing faces, and one of the programs is messing up the mesh. I have only added content inside of VRS, I have not modified outside of VRS in any way besides moving vertices around. I have had a similar problem when I opened a different mesh back into model viewer after editing weights in VRS (no changes to face/vert totals) and the faces were doubled and the vertices all became renumbered, which as a side-effect caused all of the mapping to get messed up. That's the texture problem I mentioned, the texture didn't change or get the size incorrect. The vertex numbering had been changed by one of the programs and the associated mapping was completely wrong due to the change.

[Irisjir Callard]

Re: Anyone know what causes this?

Oh well that's a bloody nightmare.

All I can say, is there any way to play around with the transfer protocols between the programs? You might find a way around the bug there. This is in way over my head.

I just hope I don't run into this when I start playing in VRS later this week.

[Macht]

Re: Anyone know what causes this?

I guess I'm not explaining this well. I have attached two images to help.

First, I'm not modifying any textures. They have nothing to play in this problem. I added a sphere to an existing head object inside of VRS. I saved this DAT file, and exported from DAT to MQO using model viewer. I imported the MQO into MAX. I then moved verts around inside of MAX. This is where the first image comes into play. The object is a single mesh, with 184 faces. You can tell it is one object because there is one bounding box around the mesh.

After moving these faces, I convert MQO to DAT inside of model viewer and it works as expected, no problems visible. I then open the DAT up in VRS again, and I add a new row of faces at the bottom of the mesh. All faces are tris, no quad faces. I then save this DAT and view it in model viewer. Everything looks fine.

Convert DAT to MQO and open the MQO in MAX. Now image two comes into play. When MAX imports this MQO, it's now 204 meshes, each with one face. This is supposed to be one mesh, with 204 faces. Somewhere in the middle either VRS or model viewer is deciding to split the single mesh into 204 different ones. You can see in the image that there is no longer one bounding box, but 204 boxes, because it is no longer one object.

All I have done is to add one row at the bottom, from existing faces, and one of the programs is messing up the mesh. I have only added content inside of VRS, I have not modified outside of VRS in any way besides moving vertices around. I have had a similar problem when I opened a different mesh back into model viewer after editing weights in VRS (no changes to face/vert totals) and the faces were doubled and the vertices all became renumbered, which as a side-effect caused all of the mapping to get messed up. That's the texture problem I mentioned, the texture didn't change or get the size incorrect. The vertex numbering had been changed by one of the programs and the associated mapping was completely wrong due to the change.

Well yes, I'm talking DataSize not the TextureSize. So if you looked at the .dat in ChangeText you'd get something like this:

64x64 (Texture Size) 8192 (Data Size, Incorrect double what it should be)

Correct should read:

64x64 | 4096

This problem often shows up in FFXI as a stripping problem on the model were the texture looks like a complete mess. Once you correct that DataSize however everything seems to read normal again. If the error is there I can correct if you want, or go get how to fix it off the tutorial provided here.

[Monkor]

Re: Anyone know what causes this?

I know what you're referring to and how to edit the DAT file to fix texture data size. That has nothing to do with the problem here though, but thank you for the offer to correct it.

The only 'problem' with the textures is that the mapping for the model gets messed up due to the vertex renumbering which is going on in one of the programs. It's not a texture problem, it's a UV mapping problem. I have attached an image to show what happens to the textures. In the first image, this is an example of how the vertices are numbered. After editing in VRS and exporting from model viewer the vertices are sometimes renumbered as they are in the second image. The mapping which was laid out for the first image is now completely wrong because the corresponding vertices are no longer where they were in the first model. I've drawn connection lines in blue to show you what the UV mapping from the initial model would look like overlayed this new, incorrect numbering of vertices.

This isn't an exact illustration of the problem, but it sort of explains the idea behind what's going on. You can see by the second image that there is a nasty mess where there used to be a nice clean layout for the mapping.

[Macht]

Re: Anyone know what causes this?

I know what you're referring to and how to edit the DAT file to fix texture data size. That has nothing to do with the problem here though, but thank you for the offer to correct it.

The only 'problem' with the textures is that the mapping for the model gets messed up due to the vertex renumbering which is going on in one of the programs. It's not a texture problem, it's a UV mapping problem. I have attached an image to show what happens to the textures. In the first image, this is an example of how the vertices are numbered. After editing in VRS and exporting from model viewer the vertices are sometimes renumbered as they are in the second image. The mapping which was laid out for the first image is now completely wrong because the corresponding vertices are no longer where they were in the first model. I've drawn connection lines in blue to show you what the UV mapping from the initial model would look like overlayed this new, incorrect numbering of vertices.

This isn't an exact illustration of the problem, but it sort of explains the idea behind what's going on. You can see by the second image that there is a nasty mess where there used to be a nice clean layout for the mapping.

Oh, that's probably the other issue I've seen from VRS. VRS has options to UV mapping the texture, but the cylinder and spherical type options it has does stuff sort of like that to the UV mapping.

What's odd though is even though VRS does that when it's pulled into Metasequoia it still looks fine.

Might be pointless to try, but since Metasequoia seems to read it fine ever try opening it to Meta save out as a new name then try with 3DMAX?