Code simplification request: Mesher Classic

A forum for the discussion and development of programs to assist working on or playing with the Vegastrike engine and data sets.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Code simplification request: Mesher Classic

Post by chuck_starchaser »

This is a request for any C++ coder with some time to spare.
It is not an "official" request, as in coming from VS developers; I'm a 3D modeler, asking for a "fork" of an existing tool.

The job does not require knowledge of the VS engine.
It's about *simplifying* a small program, a utility called "mesher", which is used to convert 3D meshes from Wavefront .obj format to Vegastrike BFXM format and back; and from BFXM format to Vegastrike XMESH format and back. The code is available on svn.

Using mesher:

Typically, you'd export a .obj file, then go,
mesher myship.obj myship.bfxm obc
mesher myship.bfxm myship.xmesh bxc
Then you would edit the xmesh file, then,
mesher myship.xmesh myship.bfxm xbc
--That's it.--

It used to work well, until 3 or 4 years ago, when a new feature was added to it, to enable it to read .mtl files. MTL files are files that accompany OBJ files, and list the materials used.

I suppose this feature was added in order to be able to take some ready-made, existing model *with textures*, in some modelling app like Max or Wings or whatever, export to .obj + .mtl, and have mesher seamlessly convert that to bfxm for inclusion in Vegastrike.

The problem is, this new feature was not made optional, but mandatory.
You *must* have an .mtl file for mesher to work.
This is problematic because mesher also assumes that each "material" denotes an intent to put something into a separate mesh; which precludes your exporting obj from a working mesh with multiple materials.
To get around that, one has to copy the file, and assign materials so that they correspond to export meshes (one material per mesh). Then one has to manually edit the .mtl file, and then use mesher to convert. If it sounds complicated, it's because it is.

The alleged advantage of this new system is that one supposedly does not have to edit xmesh files. Xmesh files, however, are easy to edit. Moreover, the current mesher is not complete enough to really avoid editing xmesh files; --and, in my personal opinion, will never be.

The story is a bit worse than that: The general understanding for the past 3 or 4 years was that mesher was "broken". A couple of days ago, however, the subject of .mtl files came up, and the fact that a .mtl file was a requirement came to light for the first time.

Furthermore, the current mesher is reportedly full of bugs. Apparently the story is that, based on the idealistic concept that editing the xmesh file was going to become a "thing of the past", conversions between bfxm and xmesh formats were neglected.

I've pleaded for a return to the simpler paradigm of the original mesher, but mesher's maintainers disagree and refuse to.
You can read our argument here:
http://vegastrike.sourceforge.net/forum ... 765#101765

For the past 3 or 4 years, the current revisions of mesher were simply not used, AFAIK. Myself, and everybody I know, used the very old version of mesher that shipped with PR1.2 (Privateer Remake). The later meshers couldn't be used because nobody knew that they required .mtl files; and because the consensus --right or wrong-- was that they were "broken"; so the method of editing .mtl files was never used.

But now there are new features in the pipeline, such as tangents and techniques, which are being built into the new (buggy and .mtl-imposing) mesher, so we are faced with either give up on the idea of using the newer features, or be forced to use the cumbersome .mtl method, with a bloated and buggy version of mesher.

So, this is a request for someone with the C++ knowledge, time and gumption, to take on the task of forking the current mesher, removing all parts of the code relating to its reading and taking input from .mtl files, and fixing some of the later conversion bugs. Ideally we would have a lightweigh, clean and functional mesher that works in the same way, and as well as, the old PR1.2 mesher, but with just a few features added, such as "techniques".

The "good old mesher"'s executable can be found here:
https://svn.wcjunction.com/utils/mesher

I'd like to call this project Mesher Classic.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Why not just make the .mtl file optional?
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Yeah, that was the first idea, actually; thanks; I just wasn't thinking right last night.

So, scratch removing code; the idea is to stop the code from requiring that an .mtl file be there. If there is a .mtl file, it can proceed as it currently does. If there's none, it should proceed as the "good old mesher" did: ONE .obj --> ONE mesh. Dummy numbers for constants. Dummy names for textures. It would be up to the modeler to edit the xmesh file.
Simple change.
What's not so simple is that bfxm->xmesh and xmesh->bfxm conversions have to work correctly. Currently they are buggy, and I'm afraid they won't be getting much attention, based on the premise that the .mtl method should replace manual editing of the xmesh files; --which IMO never will; --and even if it did we would need such conversions for visual inspection.

EDIT:
IOW, my worry is that we are about to end up *completely* without a tool for mesh conversions, given the path currently taken by its maintainers. I can see us having to do triple the work to get models into the game:
  • Having to change around material assignments before exporting to obj
  • Having to edit .mtl files
  • Using the new mesher to convert from obj to bfxm
  • Having to use the OLD mesher to convert from bfxm to xmesh, because of bugs in the new mesher
  • Editing xmesh files
  • Using the OLD mesher to convert back from xmesh to bfxm, because of bugs in the new mesher.
I really don't care if .mtl reading parts of the code are preserved and made optional or removed altogether; but I fear that perhaps many of the bugs are related to it: a) because The Age of Bugs for mesher began around the time this feature was put in, and b) because it is the least tested part of the code since probably nobody ever used it, as everybody was using the old mesher all this time, AFAIK. IOW, I do believe mesher and its end users have A LOT to gain, and nothing to lose from the removal of the .mtl file reading parts of the code, and that simplification of the code is the only sure path to success; but I could be wrong.

Now we face a situtation where we are going to be *forced* to use this arduous and probably buggy .mtl exporting and editing procedure, whether we want to or not; or else we will have to kiss the new features good-bye. Negotiations are stalled.

I (and I'm sure many others) want the option to continue to work the way we always did; and if the bug-fixing process in the new mesher fails, as I fear it will, inexorably; to at least have a parallel development in Mesher Classic that, by virtue of its simplification, might succeed where the main branch fails.

EDIT2:
Forgot to mention: I'm a C++ coder myself, though I'm compiler-less at the moment; and I'm willing to devote time to the task myself. I just need someone who is a C++ coder AND *has* a compiler and is also willing to put in some time. I'm also willing to pay some reasonable amount for the help, if necessary; though I could not afford a standard salary or contracting rate. That is, I can pay hundreds but not thousands. Also, you can PM me (send Private Message) if you prefer to work on this anonymously, as to avoid involvement in politics.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Update:

Improvement to the specifications
(Yeah, nobody's yet taken up my offer and the target's already moving :))
(Perhaps the name "Mesher Classic" will have to change.)

The new ideas involve ways in which to hopefully reach the Mecca of having to edit neither an .mtl file, nor
the xmesh files. In order to achieve this, we can look at the various parameters that an xmesh file requires,
and brainstorm about possible ways we can obtain this info without bothering the end user. "Bothering" is a
perfectly apt word here: Having to specify parameters one never cares about, again and again, is drudgery.

Let's take a look at a typical xmesh file header:

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="0"
     polygonoffset="0.000000" blend="ONE ZERO"
     texture="diff.png" texture1="spec.png" texture3="glow.png" texture4="norm.png" >
<Material power="50.0" cullface="1" reflect="1" lighting="1" usenormals="1">
	<Ambient Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="1.000000"/>
	<Diffuse Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
	<Emissive Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="1.000000"/>
	<Specular Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
</Material>
Scale
This allows you to adjust the scaling of the mesh. It is perfectly possible to scale the mesh prior to export
to obj, in the 3D modeling app of your choice. In the Vegastrike Universe, 1.0 units of length = 1 meter. If
modelers would stick to this standard in their models, this parameter would always be 1.0. But there are more
and better reasons why modelers should be working at 1.0 = 1 meter scaling. As a modeler, if I want to model
a 1 meter window, or a ladder with 30 cm spacing between rungs, or a hand railing 4 cm wide, I can simply count
grid lines to get the size right. If you work at an arbitrary scaling, you have to measure something else for
reference, then dance tango on a calculator. There is NO advantage and every DIS-advantage in working without
a standard scaling. So we can simply decree that meshes have to be in meter scale at the time of exporting, and
have mesher always write 1.0 to this parameter.

Reverse, Forcetexture, Sharevert
No idea what these things are; never touched them.

Polygonoffset
Only used this once; it may be useful on occasion, but not often enough to warrant involving mesher with it.

Blend
This is a big one. We use ONE ZERO for solids, and ONE ONEMINUSSRCALPHA for glass. However, solids and glass use
different shaders, which implies, they use different techniques. So, the technique file can carry the blend mode
information. Alternatively, we can have mesher cheat and decide blend mode based on the technique you specify.

Texture(N)
There is really no reason whatsoever to push on the user the task of coming up with filenames for textures. I'd
rather devote my creative juices to something more interesting. Furthermore, having to make sure that the names
listed in the xmesh file and the actual names of the texture files match is a responsibility many can't match.
A month ago or so I started reworking an old model of a space station and less than half the texture names did
match the xmesh file. The other textures were not being found due to typos in the xmesh. This situation has to
stop. Actually, the same problem occurs with mesh names: It took the PU team months to iron out problems of
capitalization mismatches between meshes mentioned in units.csv and the actual mesh names. Thus, what I will
propose now is a naming convention: meshes AND textures will have fixed names, and the actual files will simply
have to be named accordingly.
To simplify mesher's argument line, rather than pass an obj mesh name, we'll pass to mesher a number. Example:

Code: Select all

    mesher 00 -cinemutopaque
This will be equivalent, in old mesher lingo, to the line,

Code: Select all

    mesher m00.obj m00.bfxm obc
That is, with a "00" argument, mesher will look for a file named "m00.obj" in the current folder.
The two digits represent the mesh number and LOD level.
The interesting thing is, mesher will take this two-digit number and use it not only for assembling obj and
bfxm filename, but will also use them to assemble texture names. In this case, it would generate the line,

Code: Select all

texture="t000.texture" texture1="t100.texture" texture2="t200.texture" texture3="t300.texture" texture4="t400.texture"
Magic, eh? :)
"t000.texture" is the first texture (diffuse or albedo, depending on technique) of the top LOD (LOD 0) of the
main mesh (mesh 0).
"t100.texture" is the second texture ("specular"), etceteras.

Material Power
This is not related to e=mc^2. This is the power one raises ReflectionVector DOT LightVector to in Phong shading.
It is also called "Hardness" or "Shininess"; and I prefer to call it "Gloss". But the question is, what's it
doing here? Well, long story short: Little, yet too much. Little because gloss is computed in the shader, --as
of this writing via an ad-hoc formula, from specularity, which formula doesn't work; and can't possibly work.
In the near future, gloss will come from the alpha channel of the specular texture. But I also say it does too
much because currently the gloss is multiplied by the value in this parameter. I disagree with this policy of
having parameters for "tweaking" stuff, and the CineMut shader will ignore the value in this field. However,
for backward compatibility with old videocards that can't compute the phong power formula per-pixel, or which
don't support shaders at all, this value will be necessary to have a single gloss for the whole mesh. Either
way, I think we could fix the value to 30 for opaque techniques and to 7777 for glass shading techniques.

Cullface
Always 1; or at least I can't think of an example where you wouldn't want to cull.

Reflect
According to Klauss, this variable does something weird like adding a totally arbitrary quantity to calculated
gloss after multiplying by Material Power. Something completely absurd like that. Leave at 0.

Lighting
This is probably for some obscure cases like screen text. Leave at 1.

Usenormals
Same as Lighting. Leave at 1.

Ambient, Diffuse, Emissive, Specular
Diffuse and Specular are colors that are used by non-CineMut shaders to multiply Diffuse and Specular texel
colors. Ambient was used until recently as input to OpenGL Ambient Light, which looks like crap and was taken
out finally. Emissive is a color that I think is added to the glow texture texel color in non-CineMut shaders.
Those who want to play with any of these parameters can convert from bfxm to xmesh and tweak them to their
hearts' content; but I don't think the rest of us should be bothered with having to set these parameters all
the time. Mesher should write fixed values to them during conversion from obj:

Code: Select all

	<Ambient  Red="0" Green="0" Blue="0" Alpha="1"/>
	<Diffuse  Red="1" Green="1" Blue="1" Alpha="1"/>
	<Emissive Red="0" Green="0" Blue="0" Alpha="1"/>
	<Specular Red="1" Green="1" Blue="1" Alpha="1"/>

We're done with the traditional xmesh header, but there's a new parameter in the pipeline: "technique".
What's "technique"? Klauss' latest creation. It's a .technique file you specify from xmesh that contains
a number of instruction about how to display a given mesh: What shader and texture packing to use, what
default to use for detail texture if one is not provided, and many other details. I submit that technique
should also include blend mode.
Anyways, considering that we've succeeded in getting rid of ALL information that one has traditionally been
forced to edit during mesh conversions, and that technique is the ONLY parameter left which we cannot get
rid of, I think we might as well pass it to mesher as a parameter. Ergo, my earlier example:

Code: Select all

    mesher 00 -cinemutopaque
"cinemutopaque" is the name of the technique file that specifies the CineMut Opaque shader.


Summary

In summary, the new mesher would take two parameters. The first parameter is a two digit number, or two
separate digigs might be better, specifiying mesh number and LoD level. The second parameter specifies either
a technique or a conversion. Specifying a technique causes mesher to convert from obj to bfxm.
Specifying a conversion (bxc, xbc or boc) causes it to do the conversion.
No need to specify filenames, as the names are standardized.
And as for the parameters in xmesh, it's already covered above.


I know one someone at least who will accuse me of making a system that is rigid and inflexible. Nothing could
be further from the truth, though. There is NOTHING to prevent anybody from using mesher to convert bfxm to
xmesh to edit the xmesh and convert back. What I've got here is a system that fills in the info in xmesh to be good
for most purposes, and I mean like 99% of the time.
Standardizing texture and mesh names is a GIGANTIC step forward. It's been nothing buy chaos, over the years,
having ships appear invisible in space because the name of the mesh doesn't agree with the name in units.csv,
due to a typo or capitalization. The situation with textures is even worse, because unlike units.csv, which can be
opened easily to check names, the names of textures are buried in bfxm files, which are binary files, and the only
way to see what's in them is to use mesher to convert them to xmesh.
Standardizing mesh and texture names will bring this chaos to an end.
Additionally, it allows us to have fixed names in the LaGrande texturing pipeline's output; --no need to edit the
outpt nodes.

THIS BABY IS A WINNER. 8)

Any takers? Or shall I put an ad in Sourceforge?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

At Pyramid's suggestion, I'm changing the proposed naming standard for textures:

texX_Y_Z.texture
where,
  • X = submesh
  • Y = LoD
  • Z = textureZ of the packing
Frankly, I don't see why we need even "tex" there; it could just be,

tX_Y_Z.texture

since the extension ".texture" says it all.

On the topic of name standardization for meshes, I got myself confused:
The .bfxm file contains all submeshes and LOD's, so there's no need for digits. We could standardize the name for meshes to,

mesh.bfxm

universally.

I neglected to mention, though it should be obvious, that there is no need for names like "mining_base.bfxm", since the mesh is placed in a folder under /units which is already named /mining_base.
This way there will be none of the constant problems of capitalization inconsistencies or typos leading to meshes becoming invisible in game.
The "mesh name" column in units.csv would always say "mesh.bfxm", and could eventually be eliminated. Then, if a mesh were invisible all we'd have to do is make sure there is a mesh in the corresponding units folder and that its name is indeed "mesh.bfxm".

What we can standardize *with* digits is the naming of .obj export files.

mX_Y.obj
where,
  • X = submesh
  • Y = LoD

Another thing came up: Pyramid is working on a GUI version of mesher.
This being so, the Mesher Classic project becomes even simpler: We don't need to to even have parsing of command line parameters. We can write the conversion functions as functions, and compile to a DLL/SO for Pyramid's GUI app to link to.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Let me propose a different naming scheme for textures.

Since referencing the submesh number is troublesome, it may be easier to add a commandline with a submesh name:

Code: Select all

mesher body.obj obc -technique=cinemut

equivalent to 

mesher body.obj body.bfxm obc
and
texture0=body_0.texture
texture1=body_1.texture
texture2=body_2.texture
texture3=body_3.texture
In fact, techniques define texture units with names. We could use those names instead of the number, so it would end up:

Code: Select all

texture0=body_albedo.texture
texture1=body_bla.texture
...
The names could be read from the .technique file by mesher automagically. Mesher could warn if a given texture file is missing, even, and ask for a replacement path interactively (or abort if none is given).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

This could work for conversions. The problem is that Osama Bin Laden later comes around and changes the name of a texture on you, and you don't have the benefit of automagical checking, since you're not converting anything. With a naming convention, the problem is easy to debug: You just open the unit's folder and spot a texture not following the convention. But if we have names, then you'd have to open other files and visually compare. And if you don't believe Osama Bin Laden will do that, let me tell you: In the PU refinery there was a texture that was mentioned in xmesh like "foo.jpg", but in the folder there was a "foo.png". I'm sure that extension was changed by someone *after* the conversions were done, and neglected to edit the xmesh.

As for referencing the submesh, I did not understand why you say it's problematic, as I mentioned in the other thread.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

You can always call your submeshes "00" and get your naming scheme the way you want. What I was saying is not to tie it to "submesh number", since it's really not that easy to know the final submesh number in the xmesh from the start. And furthermore the order of submeshes is irrelevant to the modeller. If a GUI added submeshes with drag and drop, and you dropped the submeshes in different order than the textures, you'd have trouble.

BTW: it's not all that hard to write a script that will check that all referenced textures actually exist. It could be tied to "make test" - we do need tests.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Klauss, can you explain to me what the problem with submeshes is? I still don't get it. I'm not arguing; I just want to understand the problem.

I do remember someone was once working on a program or script to check a lot of consistency things in Vegastrike.
That would be good.
It would be even better if it detected textures NOT being used, too. I suspect we have many of those in PU.
I'm still of the opinion, though, that a naming convention for meshes and textures is the way to go.
If for no other reason, because I *hate* having to come up with names; and I'm sure --positive-- I'm not alone.
Like I said elsewhere, I'd rather save my creative juices for more meaningful tasks.

EDIT:
It's also a matter of aesthetics for me: I like contrasts. I like to see certain things be ultra-chaotic, and other things ultra-neat; and for chaos and harmony to fall into the right places where they belong. I want to see as much chaos as possible when it comes to things like factional wars, free market economics, AI and asteroids; and to see neatness with things that can, and should be neat, such as code; or how data is organized. File naming conventions are great for creating neatness in the right places: lists of files that display as a vertically justified column, sorted conveniently. When I see long names in textures I see bloat; I see wasted machine cycles copying and comparing and storing long strings in variables; and I ask myself why? Who's the beneficiary? I know the time spent by the CPU on handling filenames is infinitesimal, but I still can't help the distasteful feeling about its being unnecessary. Plus, the fact that I have to waste my neurotransmitters to come up with names each time. Plus, the risk of mistakes. And the plain non-sense: You open one unit folder and the names are short; open the next folder and the names are ultra-long; for no reason at all; --and often don't make any sense, whether long or short; like a texture named "red", and when you open it it's green.
So, even if we had tools to automatically check naming consistencies, I'd be much more of a happy camper to just *know* what to name my textures, and NOT *have to* come up with them names, or remember to run the consistency checking tools.

But this is just my preference. We could have a vote, if you want; but I know I will win: You just have to do a forum search for "mesher" and look at the posts, and you'll see that everybody are screaming their heads off that they want *simplicity*; NOT features. Everybody is sick of this pipeline full of options and bells and whistles and whatnots. It's grown to the point of being completely unmanageable. We're being asked to reduce and simplify. Unanimously.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Besides, let's talk a bit of Philosophy: Have you read Marshall Mc Luhan?
Great Canadian Philosopher :D
He wrote The Laws of Media. Known for the quotation "The Medium IS the Message".

In the book that followed The Laws of Media, I forget the name now, he talks about 4 attributes of every technology and invention: IIRC, what it Provides, what it Replaces, what it Negates... and the fourth aspect is the most interesting, about how every technology eventually produces the opposite result from what it was meant to produce: its Inversion. The less well conceived a technology or invention, the sooner the inversion is reached. He had long lists of technologies and inventions analyzed. One of them, for instance: "Bed. Provides: Comfort. It replaces: Muscles". I had to stop and think about that, and then it made a lot of sense: When I was into body-building, one thing I noticed was that as my muscles kept growing, I felt more and more comfortable (when sitting, when lying down). Eventually, I could lie down on a hard floor and feel almost as comfortable as if I was lying on my bed; and I could fall asleep no problem. Indeed, well developed musculature provides natural cushioning to the skeleton.
Then he talks about the inversion: The bed allows us to be comfortable without muscles when lying down; and many other technologies allow us to live our lives with almost no muscularity at all, and eventually we develop back problems due to lack of support and bad posture that wipe out our comfort when lying down, bed or no bed.

Just an example.

Now, let's think of giving users the ability to name their textures whatever they want as a technology or invention. What does it Provide? What does it Replace? What's its Inversion?

I'll leave a deeper analysis as an exercise, but just mention that, in the mind of the "inventor", probably,
  • it gives users freedom
  • it gives users a chance to choose a real good name for a texture.
The almost immediate Inversion of this technology is that most users
  • get impatient as they feel their work is interrupted or delayed by the imposed need to produce and enter a name
  • use this freedom to name their textures badly.
Meaningful texture names are a rarity, while names like "metal", "red", "dark", and so on are ubiquitous.
Such names tell you absolutely NOTHING about neither what they contain, nor where or what they are used for. They make for chaos.
A name like t0_0_0.texture tells you, at a glance, that it is the diffuse or albedo texture for the top LoD of the main mesh.
Last edited by chuck_starchaser on Sat Aug 09, 2008 4:11 pm, edited 1 time in total.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Sounds like the Mesher needs some unit tests.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

charlieg wrote:Sounds like the Mesher needs some unit tests.
Here's one. Blender file:
http://deeplayer.com/vs/shaders/testmod ... ycle.blend

Obj+mtl exports and textures:
http://deeplayer.com/vs/shaders/testmod ... t_bike.zip

The mtl files contain multiple materials, which should NOT result in having multiple meshes.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Cool. I'll try to write a small unit-test framework in python with that mesh as its first test.

The test will go like this:
  • put mtl & obj in the same folder
  • invoke 'mesher bike.obj bike.bfxm obc'
  • test that it doesn't crash
  • invoke 'mesher bike.bfxm 0_0.xmesh bxc'
  • test that it doesn't crash
  • test that it generates as many meshes as there are materials (this is required in this operating mode, it may or may not be the default in the end)
  • invoke 'mesher n_0.xmesh bike2.bfxm xba' for all 'n' submeshes
  • test that it doesn't crash
  • compare both bfxm files, should be identical
A second test would be
  • put obj in a folder without the mtl
  • invoke 'mesher bike.obj bike.bfxm obc'
  • test that it doesn't crash
  • invoke 'mesher bike.bfxm 0_0.xmesh bxc'
  • test that it doesn't crash
  • test that it generates only one mesh.
  • invoke 'mesher 0_0.xmesh bike2.bfxm xbc'
  • test that it doesn't crash
  • compare both bfxm files, should be identical
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

That sounds perfect!
You could add "mesher test_lights.obj oba" there, too.
Post Reply