Lightwave to Ogre3D 1.0.1 - source opened

The place for artists, modellers, level designers et al to discuss their approaches for creating content for OGRE.
Post Reply
P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

ok :)

Yes I want to make a baker integrated into the plugin, well that will be a command that will launch another plugin. First the 1.0 and then I look at that.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

first post updated ( 1.0.0 ) :

- fix the last keyframe when sampling skeletal animations
- fix the conversion from left to right hand coordinates for the scene export

warmi
Gnoll
Posts: 674
Joined: Sun May 27, 2007 3:56 am
Location: USA

Post by warmi »

Actually, it would be easier to simply sample IK directly from your plugin.

It is not that hard to do and it would be much easier on the user.

I wrote couple of import/export plugins for HalfLife 2/Lightwave conversion (http://www.warmi.net/lightwave/) - if you need some guidance on how do it I can send you the source code.

Belleal
Gnoblar
Posts: 1
Joined: Sun Jun 03, 2007 9:45 pm

Post by Belleal »

Great work with this plugin, P. I just want to know, is it able to export more than 1 texture and some of the more advanced properties of the materials? I am exporting my test model which has 3 textures (color, deffuse and bump) but I am getting only the color texture and basic properties of the material. Are there some specific options I need to set in Lightwave 9 or what I try is not possible?

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

@warmi :

Yes if you had already done an IK baker i'm really interested to see how you did that.

@Belleal :

Yes it can export more than one texture, but only color ones, which are using UV projection.

Bumps map are not very well suited directly, nowdays we use normal maps, a bumpmap could be converted in a normal map but that requires a shader anyway to render it. About diffuse it's the same, you need to write a shader.

I may write a couple of shaders in the future, but anyway the surface properties in Lightwave are not very well suited for realtime rendering.

The surface properties exported are described in the manual.

warmi
Gnoll
Posts: 674
Joined: Sun May 27, 2007 3:56 am
Location: USA

P

Post by warmi »

Check your PM.

Reinaart
Gnoblar
Posts: 5
Joined: Sun Jun 17, 2007 11:32 am

Post by Reinaart »

Just a quick question..

When i export my objects and after that my scene (in lw 9 and 9.2) It seems my object nullpoint gets reset/displaced by the exporter or the OgreXMLConverter.

I was wondering if someone knew where it is placed so i can do it myself and start exporting correct scenes/objects.

TIA

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

Reinaart,

Sorry I don't understand your question, what do you call "nullpoint" ?

Reinaart
Gnoblar
Posts: 5
Joined: Sun Jun 17, 2007 11:32 am

Post by Reinaart »

I'm sorry i'm used to modeler programs..

The nullpoint i'm talking about is the center point. (The point all the other points in an object refer as thair origin (0,0,0))

Somehow it seems that or lw2ogre or OgreXMLConverter displace this point, and thus when i export a scene as soon as i rotated objects in the scene they will rotate about another axis then the one it had in the origional scene.

This is quite a strange behavior, but since i don't need to rotate objects after exporting i could position the origin to the right place so my export doesn't end up strangely displaced.

I know i'm bad with words, but i hope u can help me.. ^_^

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

The origin of the mesh is the origin of the world axis in the modeler. The exporter doesn't take in account the pivot point as explained in the manual.

OgreXmlConverter just convert from xml to binary, it doesn't transform any vertex.

Maybe there is a bug in the scene exporter, I will test it again.

Reinaart
Gnoblar
Posts: 5
Joined: Sun Jun 17, 2007 11:32 am

Post by Reinaart »

I checked the numbers that were exported in the dotScene file and they were consistent with the numbers in Lightwave.

So the only think i could come up with was if the objects thair center was "displaced" when converting.

GPM
Halfling
Posts: 42
Joined: Thu Aug 10, 2006 12:08 am

Bone influence

Post by GPM »

Is it possible for the exporter to take into consideration the "Falloff" type: for example, Inverse Distance^16 or ^32? Right now it appears that the exporter supports only Inverse Distance.

GPM
Halfling
Posts: 42
Joined: Thu Aug 10, 2006 12:08 am

Bone influence

Post by GPM »

Is it possible for the exporter to take into consideration the "Falloff" type: for example, Inverse Distance^16 or ^32? Right now it appears that the exporter supports only Inverse Distance.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

Yes I could add that, but the question is how to translate that into the parameters required for realtime light attenuation ? I think I hadn't done it because I hadn't found how to do it.

http://www.ogre3d.org/docs/api/html/cla ... _1Lighta11

It's a long time I haven't worked on the plugin, mainly because of a lack of time but I will get back on it soon.

broli
Halfling
Posts: 48
Joined: Fri Mar 31, 2006 5:08 pm

Post by broli »

Well I've beeing using the exporter and found out something troublesome. Basicly the exported exports more vertices than there are on the model.

For some reason it adds some verts with the same position but with a different normal. Here's an insight...

Image

The reason I noticed this is I need to compare and look for split verts. Obviously now the test should give no result but it did. So I went looking in the .xml and found out about this.

I use lw 9.3 and lw2ogre 1.0.0.

And another thing lose from the above issue. The exporter doesn't seem to care anymore if you have one submesh and you select " Don't Use Shared Geometry" it always saves it as shared geometry.
I can understand the idea why you did this but not everybody wants to be forced to use the shared geometry tags eventhough they don't want it.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

This is absolutly normal, splitting new vertices is the normal behavior on hard edges and uv seams.

It's hard to see on your screenshot if there is an hard edge or if there is an uv seam. Try to not export UVs and choose the maximum smoothing in the Surface panel.
And another thing lose from the above issue. The exporter doesn't seem to care anymore if you have one submesh and you select " Don't Use Shared Geometry" it always saves it as shared geometry.
I can understand the idea why you did this but not everybody wants to be forced to use the shared geometry tags eventhough they don't want it.
I don't see any reason why you would not use shared geometry with a unique submesh but I will take a look at it.

broli
Halfling
Posts: 48
Joined: Fri Mar 31, 2006 5:08 pm

Post by broli »

P wrote:This is absolutly normal, splitting new vertices is the normal behavior on hard edges and uv seams.
Shouldn't it then average the normals to one common normal.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

Let's take the example of a smoothed sphere. Each vertex normal will then be the average of the normals of the polygons connected to this vertex.

If the sphere is not smoothed, then the exporter will split new vertices as necessary, each triangle will have its own vertices, their normal being the same as the polygon one.


The result after the export should be exactly the same "smoothing" result as what you can see in Lightwave viewport and should also be the more optimized mesh.
I don't say there is no bug, it's always possible, but I haven't noticed anything yet.

As I said in my previous post, in the process which is splitting new vertices, the uv seams are also taken in account.

broli
Halfling
Posts: 48
Joined: Fri Mar 31, 2006 5:08 pm

Post by broli »

I'm not using any uv's btw that was just a test object and I understand your reasoning. I think what I'm really asking for is to save multiple normals per UNsplit vertex. But I don't think that's possible with either dx or opengl.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

I think what I'm really asking for is to save multiple normals per UNsplit vertex. But I don't think that's possible with either dx or opengl.
Sorry, I don't understand that question.

Borogove
Gnoblar
Posts: 3
Joined: Sun Jun 17, 2007 6:12 pm

Post by Borogove »

broli wrote:I think what I'm really asking for is to save multiple normals per UNsplit vertex. But I don't think that's possible with either dx or opengl.
In theory you could do it with custom shaders, but then each triangle would need to know which normal to use, etc., and you'd be paying the cost of the additional normal(s) for every vertex whether you needed them or not (a complex model might have a few hard edges that needed multiple normals plus many blended edges that didn't).

You might have a *lot* of triangles meeting in one vertex, and if they wanted to be faceted (hard-edged), each would need its own normal -- so you can see it doesn't scale well.

Simpler to just duplicate vertices when you need more than one normal.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

There is indeed a problem with the plugin.

It's sometimes creating more vertices than needed on smoothed edges. The problem is that normals which should be the same are in fact slightly different because of floating point accuracy, the plugin's logic identifies that as a vertex element with a different value and it leads to the creation of additionnal vertices.

The source of the problem has been identified and I will work on a solution as soon as I get enough time.

Thanks to broli who brang this bug report.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

Version 1.0.1 available, first post updated.

- Better error handling when the Lightwave version isn't supported.
- Fix the export of light colour for the dotScene exporter.
- Fix a problem which was leading to the creation of too many vertices on smoothed edges. The model exported will be exactly the same, but now only mandatory vertices will be created.

P
OGRE Expert User
OGRE Expert User
Posts: 421
Joined: Fri Jan 07, 2005 9:49 pm
Location: UK
x 2
Contact:

Post by P »

The plugin is now open source, you can find it next to the other Ogre addons in the repository in the LightwaveExport directory.

I will continue to maintain Windows binary versions.

If someone is interested to build a version for Mac users, please contact me.

RA/pdx
Halfling
Posts: 47
Joined: Thu Dec 28, 2006 4:55 pm
Location: Nuernberg, Germany
Contact:

Post by RA/pdx »

Thanks again for a new version which solves some bugs and that you have released it as open source. :D

Again i have got a problem with the UV-maps. This time i have got a lightwave object(one layer) with two submeshes. Each submesh has got it´s own material and UV-map.
The second submesh is showen corretly in Ogre but the first submesh is just showen in one color (it´s a colour of the texture).

If i have just one submesh everything is okay. Also two and more submeshes works fine if they have the same UV-map.

We have tried all UVS techniques of your converter but all failed. :cry:

Any idea what could be the problem?

If you need the lwo file i can send it to you.

Post Reply