Lightwave converter

dennis · Post by **dennis** » Sun May 09, 2004 2:13 pm

It seems Ogre assumes that objects are 0,0,0 centric. To me this isn't a very realistic assumption.
Example:
A character standing usually stands on floorlevel at 0. If the character is 2 meters tall, the bounding sphere should then be 1 meter instead of 2.

Hmm ... I probably have to take some pivotpoint into the equasion.

dennis · Post by **dennis** » Mon May 10, 2004 10:14 pm

Patch for 0.14 submitted:
createDeferred() => create()
addTextureLayer() => getTechnique(0)->getPass(0)->createTextureUnitState()
V coordinate flipped (v = 1.0f - v)
bounds set

dennis · Post by **dennis** » Sun Aug 15, 2004 4:06 pm

Why is the alpha now integrated into the colour value and what do we use it for?

PJB · Post by **PJB** » Mon Sep 13, 2004 2:40 am

Hi Dennis,

sorry if this has been suggested before - I did a search before making the code change and didn't find it on these forums.

I made a change to the lwo converter based on my own experience with material name conflicts for freeby downloaded meshes. The bunch I found all had the same names for many of the materials and so I couldn't get the variety of cars in my test scenes that I wanted.
I added a -n parameter option to the lightwave converter to permit the user to specify a superscript string that is added to all material names in both the material script and the output mesh file.
I just hacked it in using a global variable, but I think this would be a useful feature for very many of your tool's users so perhaps you would consider adding it (more neatly!) to the next update?

BTW: thanks for an incredibly useful tool

cheers

Pete Baron
antispam_sibaroni@hotmail.com (remove 'antispam_' to mail me)
http://home.btconnect.com/pete/homepage.html

dennis · Post by **dennis** » Mon Sep 13, 2004 11:50 am

Hello Pete,

This seems to be a problem that could otherwise only be fixed by either editing the surface names in Lightwave or hacking the materials in the XML-version of the mesh. So I'll add the option, although I can't promise it will use the -n parameter.

regards,

Dennis

TSi · Post by **TSi** » Wed Sep 29, 2004 10:15 am

Mjello.

I've got the source for this tool from cvs, but it seems that there's been no change in the cvs repository for this tool for a long time. And the source in CVS doesn't compile with g++, and there aren't any makefiles either. So before I begin to write / "port" it to linux, I would loooove to know if there's a different updated source somewhere which compiles using g++ =) And where it is, of course =)

Meddten · Post by **Meddten** » Wed Sep 29, 2004 1:20 pm

i would like to know that too, if the converter is being still in development or if its canceled

dennis · Post by **dennis** » Wed Sep 29, 2004 1:48 pm

Yes, I still maintain it. There's a patch in the queue ...

http://sourceforge.net/tracker/?group_i ... tid=302997

The last patch was to keep the converter up to date with 0.14. The source is in \ogrenew\Tools\LightwaveConverter. I currently use VC6 only.

Sputnick · Post by **Sputnick** » Wed Sep 29, 2004 2:15 pm

Good to know

- Sput

Meddten · Post by **Meddten** » Wed Sep 29, 2004 6:38 pm

How can i apply a patch with tortoise cvs?

TSi · Post by **TSi** » Wed Sep 29, 2004 8:11 pm

Meddten wrote:How can i apply a patch with tortoise cvs?

You have to go through sf.net:

Code: Select all

http://sourceforge.net/tracker/?func=add&group_id=2997&atid=302997

What kind of patch is it? For making it compile with gcc? I did that myself to day (was kinda bored). The only thing that still bugs me are the windows api functions _splitpath and friends.

Meddten · Post by **Meddten** » Wed Sep 29, 2004 8:16 pm

oh sorry for my misunderstanding spelling. i didn´t want to create a patch file i want to download this patchfile

http://sourceforge.net/tracker/index.ph ... tid=302997

and apply it to my version of ogre on my harddisk

how can i do that

TSi · Post by **TSi** » Wed Sep 29, 2004 8:33 pm

I'm not sure you can do that with Tortoise CVS. If you were using Linux, you would normally use the program called 'patch'. Or you could apply the patch by hand, by opening the patch-file, and copy-paste the changes to the files (only four files).

I'm sure other people know how to do this "the proper way" when using Windows =)

5 minutes later...

I found a windows port of patch. You could try that one out:

Code: Select all

http://gnuwin32.sourceforge.net/packages/patch.htm

TSi · Post by **TSi** » Thu Oct 14, 2004 11:47 am

The lightwave converter doesn't seem to support lightwave objects with discontinuous vertex maps. It converts them with no errors, but the texture mapping is all wrong when the object displayed in Ogre.

TSi · Post by **TSi** » Fri Oct 15, 2004 4:21 pm

I've submitted a patch to make the converter compile / work under Linux with GCC.

http://sourceforge.net/tracker/index.ph ... tid=302997

dennis · Post by **dennis** » Sun Oct 17, 2004 4:20 pm

TSi wrote:The lightwave converter doesn't seem to support lightwave objects with discontinuous vertex maps. It converts them with no errors, but the texture mapping is all wrong when the object displayed in Ogre.

These discontinuous vertex maps are known as VMADs in the .lwo-format. They are probably one of the greatest assets to the .lwo file format. It's just that they are evil

to convert of course.

A VMAD provides an extra set of UV-coordinates which is tied to the polygon instead of the vertex itself. This means that for the conversion to work, the vertex has to be copied in order for it to contain the second UV-coordinate. Since I probably won't use VMADs any time soon, I don't know when I'll get around to implement a fix.

TSi · Post by **TSi** » Fri Oct 22, 2004 6:55 am

dennis wrote:Since I probably won't use VMADs any time soon, I don't know when I'll get around to implement a fix.

I thought Lightwave, as default, saves objects with VMADs if applicable. *shrug* I guess I'll look into it when I have time, and when fixing buuugs =)

Post by **_mental_** » Sat Oct 23, 2004 11:28 pm

I've committed the Linux compile fixes. Could someone check that this still works ok under Win32.

dennis · Post by **dennis** » Sun Oct 24, 2004 9:44 am

It still works under Win32.

Post by **_mental_** » Sun Oct 24, 2004 6:46 pm

Cool. Thanks dennis.

dennis · Post by **dennis** » Mon Oct 25, 2004 4:15 pm

Instantiating MeshManager seems to be requirement now ...

Code: Select all

Index: Tools/LightwaveConverter/src/main.cpp
===================================================================
RCS file: /cvsroot/ogre/ogrenew/Tools/LightwaveConverter/src/main.cpp,v
retrieving revision 1.6
diff -u -r1.6 main.cpp
--- Tools/LightwaveConverter/src/main.cpp	23 Oct 2004 22:24:26 -0000	1.6
+++ Tools/LightwaveConverter/src/main.cpp	25 Oct 2004 15:24:38 -0000
@@ -19,6 +19,7 @@
 Math* mth;
 MaterialManager* matMgr;
 SkeletonManager* skelMgr;
+MeshManager* meshMgr;
 MeshSerializer* meshSerializer;
 MaterialSerializer* materialSerializer;
 SkeletonSerializer* skeletonSerializer;
@@ -651,8 +652,9 @@
 	{
 		logMgr = new LogManager();
 		mth = new Math();
-		matMgr = new MaterialManager();;
-        matMgr->initialise();
+		matMgr = new MaterialManager();
+		matMgr->initialise();
+		meshMgr  = new MeshManager();
 		skelMgr = new SkeletonManager();
 		meshSerializer = new MeshSerializer();
 		materialSerializer = new MaterialSerializer();
@@ -709,9 +711,10 @@
 	else
 	{
 		delete bufferManager;
-	    delete skeletonSerializer;
+		delete skeletonSerializer;
 		delete materialSerializer;
 		delete meshSerializer;
+		delete meshMgr;
 		delete skelMgr;
 		delete matMgr;
 		delete mth;

dennis · Post by **dennis** » Tue Oct 26, 2004 8:06 pm

Since the matter of supporting VMAD's (discontinuous vertex maps) has come up I feel strong about throwing out some code and do it better.

The datastructures for referencing this mapdata are really complex. What also intrigues me is the way different types of vertexdata can be declared separately. (VertexDeclaration) Does this mean I CAN attach 2 UV-coords to a vertex even though Sinbad stated I can't? (Actually this means attaching a second UV-map to all the vertices and not a single UV-coord to a single vertex.)

One thing I would like to do is to get the best possible mesh after conversion. Currently vertices are being copied per surface/submesh in the order they are encountered. This means that a single triangle could have one vertex at the start, one at the middle and one at the end of the vertexbuffer. Does that matter?

My idea is to traverse the triangles of a surface in some way and copy the vertexdata along the way. What would be the best traversal algorithm?

What should be taken into consideration for the optimal use of the shared vertex data structure? (Currently the user decides if the vertex data should be shared or not. The user can't specify which submeshes should share a vertex data buffer.)

TSi · Post by **TSi** » Fri Oct 29, 2004 1:07 pm

dennis wrote:One thing I would like to do is to get the best possible mesh after conversion. Currently vertices are being copied per surface/submesh in the order they are encountered. This means that a single triangle could have one vertex at the start, one at the middle and one at the end of the vertexbuffer. Does that matter?

If it does, then you could probably sort the stuff afterwards?

dennis wrote:My idea is to traverse the triangles of a surface in some way and copy the vertexdata along the way. What would be the best traversal algorithm?

Humm.. My idea is to eliminate the VMADs after the object has been loaded, but before you convert the object to a mesh. So I have been looking at doing something like this:

Code: Select all

lwObject::eliminateVMADs() {
  for each layer {
    layer->eliminateVMADs();
  }
}

lwLayer::eliminateVMADs() {
  for each vmap {
     if vmap->perpoly {
        for each point {
           check polygon, check vertex, replace uv-coords for points in toher vmaps.. yada yada.. not totally sure how to do this yet.
        }
     }
  }
}

.. and then finally convert the object to mesh. Anyway, I'm trying it out =)

dennis · Post by **dennis** » Sat Oct 30, 2004 3:55 pm

I think traversing the polygons in the right order should solve everything in 1 go. I also think spreading the vertices of a single triangle out over the buffer is a bad idea, but I would like to know what some other experienced people think about this. Is the buffer optimised (stripified?) before it's written to disk?

Post by **sinbad** » Sat Oct 30, 2004 4:33 pm

The serializer does absolutely nothing to the data apart from writing it. Yeah, having vertices scattered around the buffer is sub-optimal since the vertex cache will not be used to its full. I would iterate over the faces of the mesh and identify unique vertices as you go. Alternatively nVidia has a vertex cache optimising tool IIRC which might offer some tips on this.

Ogre Forums

Lightwave converter

Where's the source?

Working with Lightwave is good. Exporting from it is better

Doggie does Debbie's Dallas.

Patching all the way.

discontinuous vertex maps

LightwaveConverter Linux patch.

Re: discontinuous vertex maps

Re: discontinuous vertex maps