Lightwave to Ogre3D 1.0.1 - source opened

P · Post by P » Tue May 29, 2007 10:46 am

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 · Post by P » Tue May 29, 2007 3:12 pm

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 · Post by **warmi** » Tue May 29, 2007 4:35 pm

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 · Post by **Belleal** » Sun Jun 03, 2007 9:57 pm

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 · Post by P » Sun Jun 03, 2007 10:20 pm

@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 · Post by **warmi** » Tue Jun 05, 2007 4:57 am

Check your PM.

Reinaart · Post by **Reinaart** » Sun Jun 17, 2007 2:26 pm

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 · Post by P » Tue Jun 19, 2007 11:38 pm

Reinaart,

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

Reinaart · Post by **Reinaart** » Thu Jun 21, 2007 11:02 am

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 · Post by P » Thu Jun 21, 2007 11:36 am

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 · Post by **Reinaart** » Fri Jun 22, 2007 10:31 am

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 · Post by **GPM** » Wed Jul 18, 2007 5:41 pm

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 · Post by **GPM** » Wed Jul 18, 2007 5:41 pm

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 · Post by P » Wed Jul 18, 2007 11:39 pm

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 · Post by **broli** » Wed Aug 29, 2007 12:20 pm

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...

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 · Post by P » Wed Aug 29, 2007 12:45 pm

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 · Post by **broli** » Wed Aug 29, 2007 12:57 pm

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 · Post by P » Wed Aug 29, 2007 1:25 pm

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 · Post by **broli** » Wed Aug 29, 2007 1:32 pm

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 · Post by P » Wed Aug 29, 2007 1:41 pm

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 · Post by **Borogove** » Fri Aug 31, 2007 10:41 pm

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 · Post by P » Fri Aug 31, 2007 11:09 pm

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 · Post by P » Sat Sep 29, 2007 12:23 am

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 · Post by P » Wed Oct 10, 2007 12:50 am

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 · Post by **RA/pdx** » Fri Nov 02, 2007 11:16 am

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

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.

Any idea what could be the problem?

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

Ogre Forums

Lightwave to Ogre3D 1.0.1 - source opened

P

Bone influence

Bone influence