LWO exporter

[Bikerdude]

Ase Exporter

We already have this, what we need is a .LWO exporter. So Springs can tweak models made in DR etc.

[rich_is_bored]

You don't need an LWO exporter either.

 

File > Export selection as OBJ

[Springheel]

The obj exporter isn't very useful for modelling, as the resulting polys are flipped and the uvmaps are messed up. I've never been able to use it for anything other than scale comparisons.

[Bikerdude]

File > Export selection as OBJ

Doh, I keep forgetting about that.

The obj exporter isn't very useful for modelling, as the resulting polys are flipped and the uvmaps are messed up. I've never been able to use it for anything other than scale comparisons.

And thats why, Springs reminded me of the above the last time .OBJ's were suggested.

[Obsttorte]

We already have this, what we need is a .LWO exporter. So Springs can tweak models made in DR etc.

As long as someone can't point me to a description of how this binary format works, I cannot write an exporter for it. Object is text-based, though, and if the current exporter is messed up, I could write a new one exporting as obj.

[SteveL]

The official file format spec is in the sdk, browsable on the lightwave3d site here: http://static.lightwave3d.com/sdk/2015/html/filefmts.html

 

This article looks very helpful too. Much easier to read and broken down with a hello world type example of a simple cube: http://content.gpwiki.org/index.php/LWO

 

I don't know whether blender needs a specific version, but all the previous specs are linked on the same site.

[Obsttorte]

Writing the data in the utlined form isn'T a big deal, but how do I get Python Script to store it in the binary format?

[SteveL]

I'm not at computer to check, but I'd have thought you could use python's ordinary file() object to write the file. It supports binary too.

[VanishedOne]

It's a long time since I used it, but isn't struct the standard way of handling binary data?

Edited January 11, 2015 by VanishedOne

[SteveL]

It's a long time since I used it, but isn't struct the standard way of handling binary data?

Not one that I've used. Python's file() is enough. It can write a binary string created using the built in bytearray() function as easily as it can read and write text strings.

e.g.

>>> data = [127, 255, 64, 63, 0, 1, 255]
>>> f = file('binfile.bin', 'w+b') # 'w+b' means create or overwrite this binary file
>>> f.write( bytearray(data) )
>>> f.close()
>>>
>>> data2 = file('binfile.bin', 'r').read() # open, read, and close in one step
>>> data2
'\x7f\xff@?\x00\x01\xff'
>>> int_data = [ ord( for b in data2 ]
>>> int_data
[127, 255, 64, 63, 0, 1, 255]

[nbohr1more]

I think it would be cool if Biker could export his work as LWO for Springheel to review but I get the impression that the results

might still be less than optimal because the proper workflow requires two models so that a "proper" normal bake can be made.

 

It's a shame that the addnormals command is so low-fidelity and limited, it would be nice to be able to mix and match high quality

normal bakes with tiled normal maps too but I imagine that would slow down rendering or map load times if we ever changed it.

 

As it stands now, it's either one or the other. If only the normal bake in Doom 3 could take the high poly model "and it's normal maps"

and bake both to the low-poly at once. I think Blender can do this though, now sure about LightWave.

[VanishedOne]

struct isn't a replacement for file() IO; it's for converting Python types to and from packed binary data. Here's what happens if I take the bytearray() example and naively try to plug signed integers into it:

 

Python 2.6.5 (r265:79063, Feb 27 2014, 19:44:14)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> data = [127, -3, 64, 63, 0, 1, -6]
>>> f = file('binfile.bin', 'w+b')
>>> f.write( bytearray(data) )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: byte must be in range(0, 256)

[SteveL]

Ah, thanks for the clarification. I'll remember that as a more compact alternative to Pickle() next time I need to do it

 

In this case, writing a converter, it's not python types that want to be saved but some specific format for another program, so you'd likely want to write code that creates an exact sequence of bytes accordng to a spec. file() + bytearray() are ideal for that.

[VanishedOne]

That's exactly what struct is useful for. If you need to save, say, three doubles and a signed 8-bit int, you can feed struct a format string that tells it to convert your Python variables to the corresponding C types and output them as binary data, optionally with defined endianness and padding.

[greebo]

For reference, Darkadiant's picomodellib has LWO loading code (in C language) with a few comments, and Blender has its own lwo export script (Python) as far as I recall.

[OrbWeaver]

struct.pack is the way to do it in Python. You can dump byte arrays to a file easily, but if you want to write a 32-bit integer you are going to need to convert it into bytes first, and struct.pack is the way to do that.

[SteveL]

Yeah I can see that higher-bit ints and floats would be awkward, but what if you are working to a file spec that isn't laid out as a c-struct with padding etc? Where each byte is determined by a file format spec? Assuming no library modules, isn't it easier just to write your own conversion functions for the output that you need and to specify it byte by byte? You could still use struct.pack to convert your numbers and then embed them in the file, if its result happens to coincide with the target spec.

[OrbWeaver]

Yeah I can see that higher-bit ints and floats would be awkward, but what if you are working to a file spec that isn't laid out as a c-struct with padding etc? Where each byte is determined by a file format spec?

struct.pack has nothing to do with C-structs, the name is perhaps something of a misnomer. It is an unbound method (like a C++ static method) that accepts a format string and some values to format, and basically works a lot like sprintf (except without literal string output; everything in the format string is a format character). You can easily run it in a loop, or on a number of individual values, without needing to define any kind of "struct".

 

E.g. to convert a single 16-bit short value:

>>> struct.pack('h', 32767)
'\xff\x7f'

You could write your own conversion functions of course, but this wouldn't provide any advantage over what the pack method is already giving you.

[SteveL]

Useful to know, thanks. I did look it up and saw the article talking about it inserting padding to match the layout that a c compiler would use for a struct, but if that behaviour is optional and you can have full control while not needing to decode your own ints and floats, then great.

[OrbWeaver]

Right. The docs do make mention of C struct compatibility, and the default behaviour seems to be to use the padding and endianness that a C compiler would use on your current system, but you have full control over what padding and enddianness you actually want by using the appropriate format strings.