FLOZi wrote:
Can't help but feel maybe there is a chicken and the egg situation here; I doubt it'll get picked up in a major way unless it offers things that s3o does not (materials, multiple diffuse textures per model, etc)
Maybe, but I don't know the consensus (if there is one) on what people find lacking about S3O. Multiple diffuse textures per model sharing the same UV space (or even per-piece textures) wouldn't be that hard to support for example, but there would still have to be a commonly accepted way of deciding when to bind and unbind them. And it's also already possible with Lua gadgetry, which is the more powerful approach in the end.
Guessmyname wrote:
what is the core_commander_alt section for?
To demonstrate you can specify the piece hierarchy in two ways, eg.
versus
Code: Select all
pieces = {
[1] = {
name = "pelvis",
...
}
}
The second ("alt") approach preserves the lexicographical ordering among child pieces, which might be important for converted S3O's.
Guessmyname wrote:
I'd like to know the difference between relative and global offset
A relative offset is defined with respect to the immediate parent piece, global offsets are defined with respect to the root. But actually the comments in the .obj are reversed, all global offsets should be relative and vice versa.
Guessmyname wrote:
I'm assuming from the "# name: objects3d/core_commander.s3o" line that they're referred to in units/ files same as real .s3os? ie "objectName = [[atreides.s3o]]," would be valid for both obj and s3o formats?
No, that comment (all lines starting with '#' are comments) is just there to indicate the name of the source S3O. For an OBJ model, you would write: