Page 1 of 1

Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 4:32 am
by Frisbeetarian
Basically, what I have here is an observation with a question attached to it.

Recently viewing some objects, I have come to notice certain inconsistencies between different viewers that I use as well as Rep's importer. Viewing rax_ind_1_t_v3_red.msh from the Raxus Prime assets in the SWBFViewer and Ultimate Unwrap3D gives the first result below while viewing the mesh in 3DOC and XSI (after importing with Rep's tool) gives the second image (the view in XSI is slightly different than this arrangement, but the same pieces are out of place).
Hidden/Spoiler:
ImageImage
The same sort of thing happens when I try to to view Psych0fred's SPHA-T model (ignore the collision spheres and the order of the pics is the same as above).
Hidden/Spoiler:
ImageImage
I say all this because, while I can think of a work around such that I don't have to put Humpty Dumpty back together again, I'm open to options. I know that I can export VRML2.0 from the SWBFViewer, but I need a way of getting it back into XSI somehow, whether through .3ds, .obj, .xsi, etc., and a cursory search of the internet/XSI forums reveals nothing useful.

I briefly looked at importing the VRML2.0 into Blender and exporting as a Wavefront OBJ to be imported into XSI then exported the normal way through Rep's exporter, but while the UVs seemed to tag along, the texture didn't want to apply to them. Unless someone wants to walk me through how to get the textures to stick, then I'd just as soon join the king's horses and men.

My questions (finally) are: Does anyone know of a VRML converter that will do what I need it to do? Does someone want to figure out the Blender work around for me?

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 5:20 am
by DarthD.U.C.K.
the textures never stick, that could be an issue of the obj format

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 6:40 am
by Frisbeetarian
Let me describe what I mean by "stick." I know that you have to manually reapply the textures, but when I do it after using Rep's importer, the UVs automatically catch on and the texture is applied. When I go through the process described, this doesn't happen when I try to reapply the texture in XSI.

The reason I said that the UVs seemed to be there is because when I look under clusters in the explorer, there are separate clusters such that a single texture applies to the whole cluster. (More than one cluster has the same texture, but if the model as a whole has multiple textures, there isn't a cluster that uses multiple textures.) The reason I came to the conclusion that I did is because a similar thing happens when I apply textures to an imported model that uses multiple textures, the polygons I select to become a different texture form a cluster when the texture is applied, as seen below.
Hidden/Spoiler:
It's hard to see, but the color difference in gray is the selected cluster, and thus where a different texture is applied.Image
This is why I ask a separate question for if someone wants to walk me through the process. I probably just need to apply the textures in Blender before exporting as an OBJ. (If it were an issue with the OBJ format, then it wouldn't work after using Rep's importer :wink: .)

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 10:34 am
by ryukaji
blender blender..... OK so if you want to reapply a texture in blender then split the screen so that you have 3d view and then change the other one to UV Image Editor. Then in the 3d one go into edit mode and textured view and press "a" to select all. In the UV Image Editor at the bottom click Image>open and select the texture and it should go right on. Its pretty easy

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 3:53 pm
by AceMastermind
Frisbeetarian wrote:I know that I can export VRML2.0 from the SWBFViewer, but I need a way of getting it back into XSI somehow...
Hang tight, i'm working with someone to get a vrml 2.0(aka vrml 97) export plugin for Mod Tool 7.5 done(it's nearly finished), then we'll see about getting a vrml 2.0(aka vrml 97) import plugin made for it as well. *fingers crossed*
The export plugin will allow you to go:
Mod Tool 7.5 > SWBFViewer > SWBF1 or 2

The (hopefully)import plugin will allow you to go:
msh > SWBFViewer > Mod Tool 7.5

in the meantime please continue to use what is available in your conversion pipeline.


EDIT:
vrml 2.0 export plugin progress
Hidden/Spoiler:
Image

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 4:11 pm
by Fiodis
Hooray, a new way to export into BF2!

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 4:21 pm
by Frisbeetarian
AceMastermind wrote:Hang tight, i'm working with someone to get a vrml 2.0 export plugin for Mod Tool 7.5 done(it's nearly finished), then we'll see about getting a vrml 2.0 import plugin made for it as well. *fingers crossed*
Sounds great! That's just what I was hoping for.
AceMastermind wrote:conversion pipeline
Great way to put it. So many different ways to get caught in piping.

I'm guessing no one knows exactly what causes the aforementioned inconsistencies?

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Sun Apr 26, 2009 5:25 pm
by AceMastermind
Original post content:
Hidden/Spoiler:
[quote="Frisbeetarian"]I'm guessing no one knows exactly what causes the aforementioned inconsistencies?[/quote]
"inconsistencies" is the key word, unfortunately this happens way too often with many 3d file formats in various applications, code may be poorly written or misunderstood and plugins may not read/write data correctly or in the same formatting. The obj file type is one of the simplest but still has been screwed up in some apps, I guess it's just too difficult to keep it standard across apps.
To sum it up, not all importers/exporters are created equally.

In my opinion, Unwrap 3d has the most robust import/export plugins that i've seen thus far.

New post content:
Another option to import vrml 2.0 files is to download the free Vivaty Studio, it can import files exported from SWBFViewer (vrml 2.0 aka wrl) and export them in various filetypes (obj,xsi,3ds etc...). I recommend exporting them as .xsi if importing them into Mod Tool.

To import a SWBFViewer exported wrl file into Vivaty Studio simply drag 'n drop it into the viewport.
To export the scene from Vivaty Studio to another filetype that Mod Tool can import:
Go to File>Export Other Format...
Choose a file type to export as SoftimageXSI (ASCII) (recommended)
Click on Export and give it a name and select a save destination then Save

To import the new file into Mod Tool just drag 'n drop the .xsi file into the viewport.
You may have to re-assign the texture, first switch from Shaded to Textured Decal so you'll be able to see the texture after you assign it, to re-assign the texture just select an object and press 7 to open the Render Tree, double click on the Phong node and in the ppg that opens left click on the first plug icon located in the Diffuse section then go Image>New>New From File then browse to and select the texture that belongs on that object.
You might also have to invert the polygons on the objects in the scene, to do this select an object with inverted polygons then go to the Model panel on the left of the UI then go: Modify>Poly. Mesh>Invert Polygons

You may have to translate some objects back into position as well but at least they're separate objects. :)

Another way to get a .msh file into XSI is to use this method instead:
.msh > SWBFViewer > .wrl > Accutrans3d > .obj > XSI


EDIT
I should mention that I used psych0fred's SPHAt for this conversion test, and being that it mostly uses 1 texture, the method I used to re-apply the texture was indeed the fastest(4 to 5 seconds) in this case.
XSI provides many ways to achieve the same result so feel free to use whatever method you feel comfortable with.

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Thu Apr 30, 2009 12:22 am
by MileHighGuy
im also looking for a way to export into vrml, i found this> http://www.xsibase.com/forum/index.php? ... adid=34001

would it work with xsi modtool?

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Thu Apr 30, 2009 12:30 am
by AceMastermind
MileHighGuy wrote:...would it work with xsi modtool?
It works with Mod Tool but the *.wrl syntax is different and therefore not compatible with SWBFViewer.
AceMastermind wrote:I'm working with someone to get a vrml 2.0 export plugin for Mod Tool 7.5 done (it's nearly finished)...
vrml 2.0 export plugin progress:
Hidden/Spoiler:
Image

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Thu Apr 30, 2009 9:54 am
by Teancum
Sorry if this was already covered, but the TRAN values found in MSH files are probably what put those pieces in their correct places, which is why MSH Viewer sees it correctly, but other programs don't.

Re: Viewer/Importer Inconsistancies AKA VRML2.0 Converter?

Posted: Fri May 01, 2009 11:31 am
by Frisbeetarian
AceMastermind wrote:You may have to translate some objects back into position as well but at least they're seperate objects.
The same parts did show up out of position, but this time it included all the collision and hard point primitives as well, and they all showed up with their "centers" at the origin. This helps more than what I've already done (corrected it with XSI) since Vivaty auto-applies the texture and has the ability to export to XSI, making the in between steps really simple (and makes sure I don't have to learn a new program :D ). The fact that they were separate objects also makes it easier to eliminate the primitives and to apply the different textures to the correct pieces.

Being a perfectionist, the thing I'm looking for, in addition to what Vivaty does, is something where the parts of the object don't get moved around (though Vivaty is better than what I had). I also don't understand exactly what's happening. Tean suggests that it's the TRAN values that are getting screwed around with, but if SWBFViewer views them correctly, why does it export incorrectly? (I guess the functions could be altogether separate and thus while it reads the TRAN values correctly for viewing, it reads them incorrectly for exporting.) So that I can check on things, is it safe to assume that the order that the objects appear the VRML2.0 file is the same order they appear in the mesh file (just realized that VRML can be viewed in text editor and not a hex editor :lol: )?

Also, why, in each of the different instances (three now, exported VRML2.0 by SWBFViewer, exported OBJ by Rep's exporter, and viewed in 3DOC) are the same parts out of whack (Rep's exporter even seemed to add extra geometry)? Finally, why are the same parts in different places instead of each program setting them to the origin if they can't read the TRAN value?

Offtopic: I know, Ace, that you like the XSI Default mode, but in this case, I could do things easier with the ModTool mode. Applying the texture your way (I'm assuming as the fastest way under Default) makes the texture apply to every object instead of just the one selected. Since I couldn't find a solution quickly doing this, I just applied it using Texture->Image in the ModTool Mode, brought up the same window you took many steps to get to, and this time it only applies textures to the objects I have selected (though it takes a couple of seconds to apply to a large amount of objects instead of doing it instantly).