meow; mesher.

[snow_Cat]

I believe that this will take me the better part of this week as Studio2005 is making me hate Microsoft with an incredible fervor; though they've given me so much free stuff.

Current functional features (crude, like my manners):

• functional command system interface - isn't making any new typos, just overloading the interpreter
• Drag-and-drop file interface - Just like windows... not necessairly a good thing.
• Annoying popup - If it is not a problem, then it was not my fault.

Current expected features (in development):

• Append list - do it all with the click of a button
• file type recognition - an apple with an identity crisis is an orange in drag
• Console loging - for those times when you really want to know what just happened here
• cutesy-cute logo - :D if you get this; then I do a dance of glee.

Features desired but not expected (need info):

• Translation distance
• orge format support
• append to other than binary?

Quick questions:
Is it safe to use long filenames and paths using quotes?

What is the command character for orge format?

What is the proper format for translation distance?

forceflatshade ?

Are there other argument paramaters I could implement?

Code: Select all

wrong number of arguments 1, aborting
0 : mesher
usage:
        mesher <inputfile> <outputfile> <command> [-x|-y|-z<Translation Distance
>] [-forceflatshade]

Where command is a 3 letter sequence of:
        Inputfiletype:
                b:BFXM
                o:OBJ
                x:xmesh
        Outputfiletype:
                b:BFXM
                o:OBJ
                x:xmesh
        Commandflag:
                a: append to Outputfile
                c: create Outputfile

[hellcatv]

inside the mesh itself make sure it's one word without quotes---taht just avoids hassles

translation distance is
-x5 -y2 -z3
for instance

forceflatshade forces the normals to be actually perpendicular to their surfaces

[Halleck]

Wow! An improved mesher app will go a long way towards helping us tired developers/modders.

GUI even, you say?

Will the GUI be crossplatform?

EDIT: Oh, don't forget about mesher --dims, that's a handy argument (already implemented, just make sure it doesn't get lost).

[snow_Cat]

:shock:
dimms
how do I use it?
how is it currently called?
^ · ·,^

I think thtat there's been a misunderstanding here;
I'm writing a GUI that will wrap around the existing Mesher to make it more user friendly (for windows users, I don't understand unix, but then unix users are smart enough not to need a gui, right?).

Though more challenging than simply dumping the existing mesher code into my own app; this 'front end' will allow Mesher to continue to be developed without my involvement.

Additional functional features:

• Append list
• cutesy-cute logo

Broken features:

• command system interface - windows...

• PhotoBucket.com

[Halleck]

I think I just fell in love with that screenshot.

You don't know how much easier this will make my life... having to cd manually into my meshes folder and do everything from the commandline can be such a pain sometimes. Doing batches of ships can be even worse.

I don't think I can thank you enough for this.

By the way, the -dims option grabs the dimensions of the bounding box for the current mesh (max and min values for x,y, and z).

jackS posted about this handy argument in my old luddites=headaches thread. He said:

for future reference on scaling:

running

mesher -dims <name of bfxmfile>

will give the min x,y,z and max x,y,z coordinates of the model, scaled by the model's internal scaling variables, in meters.

the unit's scaling var then multiplies this as one would expect. Thus you can know exactly how wide, tall, and long the model is... although the box approximation is poor for most other possible calculations

... remind me to put this option in the usage text for mesher...

Looks like I forgot to remind him.

[klauss]

And... I pretty much like the idea of backend/frontend for mesher. It is NOT a tool that would be phased out after ogre, because it has the ability to edit Ogre meshes in useful ways (add edge/binormal precomputations, for instance).

So... nice to know there'll be a frontend for it, lots of people will love the idea. Be sure to add "batch" modes, both for converting multiple files, and for performing complex operations (like... make this bunch of meshes go together as LOD0, this one as LOD1, etc...). Well... that's just a request, do what you can/will.

If you need some specific command to make your life easier, just ask - I'm pretty much acquainted with mesher, and will probably be able to fullfil your request in little time (RL-permitting).

[Halleck]

Be sure to add "batch" modes, both for converting multiple files, and for performing complex operations (like... make this bunch of meshes go together as LOD0, this one as LOD1, etc...). Well... that's just a request, do what you can/will.

I think that complex operations like appending specific LOD levels would best be coded into mesher itself, as opposed to a windows-only frontend.

[klauss]

Mesher already has that... it only takes multiple invocations.
That's exactly one place where a frontend would do wonders, being able to invoke mesher as many times as required while hiding such complexity from the user.

[Halleck]

Oh.. but don't LOD's have to be referenced in the top level xmesh and then appended into a single bfxm through multiple invocations? I thought that you were asking for the frontend to automate this entire process (including referencing the LODs).

I agree then, the frontend's append mode should certainly have a simple "batch mode".

[klauss]

Yes, and furthermore, if you want LODs coming from .obj files, you need to convert from obj->xmesh, edit xmesh, then xmesh->final format.

The frontend *could* automate this. If it's too much to ask for it to edit the .xmesh files, I could add parameters to mesher to "override LOD specifications in .xmesh files".

[Halleck]

If it were to include such functionality, then by extension, it should be able to automatically reference specular, damage, and glowmaps (as specified by the user) without having to convert to xmesh and edit these manually.

Is it wise to implement such features only in the frontend, though? I think that it would be wiser if mesher itself were updated, so that users on all platforms would have access to such convenient functionality. If you add the 'ovveride' parameter to mesher, perhaps you can also force it to set the aforementioned maps?

[klauss]

Check again.
Mesher now can take glow/spec/damage maps from .obj files.

Only it requires manual editing of .mtl files usually, since little (or no) tools generate the proper commands.

There was a post of mine about it somewhere... If you search the forums/wiki for "MAP_KE", I think you'll find it.

[Halleck]

Check again.
Mesher now can take glow/spec/damage maps from .obj files.

Only it requires manual editing of .mtl files usually, since little (or no) tools generate the proper commands.

Doesn't sound much better than going to xmesh and back again. At least xmesh files are easy to read.

It would be better if it could just accept command-line arguments to assign these maps. Then, it could be done without the user having to edit any files at all, and the front-end could easily support it.

[klauss]

I could do that, but it would be even more cumbersome.

Because you would be required (or the commandline) to previously parse the .mtl file identifying each material, then passing, in parameters, for each material, each map (4 - diffuse, glow, spec, damage).

Parsing .mtl files is trivial, and editing them is so as well, so I'd bet making a frontend for editing them with a nice GUI, material selector, and all the niceties would be rather simple.

Still... I'm at your service. If you really prefer parameters, tell, and I'll add them. But do try editing .mtl files first - and see how much easier it is. In fact, I added those to .mtl parsing because I got tired of having to go to .xmesh, edit, and then go back. That way, you skip one step entirely, and the editing is much simpler (a single file, rather than multiple, with more intuitive syntax).

[snow_Cat]

Batch jobs and clear cutting:
Thing work[ed] by generating system commands;
effectively doing batch jobs on the fly; this is how append mode work[ed before I toyed with the internal scripting to try and make it longfilename/path/unicode-compatible even if a verson of mesher suddenly takes only twelve ascii characters for file names.]

I may change my approach to generating batch scripts as then the generation of log files becomes automatic (read: 'pathetically easy') on 2k/XP machines... I don't remember how to invoke log console in 2^5/9x; but I could google it later...

With all of this inplace[/placebo] adding batch conversion jobs is trivial, however I would only allow user output paths (same as orig/all to one) and no base-name changing as I do not want to create a parser for all the near infinite (8^256) chaos that may emerge as a result.


OGRE and other formats:
I am told that (our) mesher currently supports OGRE as an output format, however I do lack the necessary character-code to implement it;

and E is for t' Effort · which I won't make.

Appendectomy (as demonstrated by that orange)
The problem of LOD/Append order is not something that I am sufficently equipped to handle. Perhaps once I have a finished version to submit another might find a solution; like adding an integrated mtl editor or something... blarg feature creep... add that to the list of things to do...
^ > < ^ *curses his inate problem solving ability that ironically creates more problems to be solved that ....*

I have not yet implemented the extension checker that will prevent the wrong extension from being passed to the mesher resulting in a mash- something that happens too easily with drag and drop. With VB's already oversized/built string maniupulation libary I will have that fixed in a jiff, that is once I have more Jiff, my roommate's friends seem to have eaten it all.

• PhotoBucket.com

[Halleck]

I could do that, but it would be even more cumbersome.

Because you would be required (or the commandline) to previously parse the .mtl file identifying each material, then passing, in parameters, for each material, each map (4 - diffuse, glow, spec, damage).

Parsing .mtl files is trivial, and editing them is so as well, so I'd bet making a frontend for editing them with a nice GUI, material selector, and all the niceties would be rather simple.

Still... I'm at your service. If you really prefer parameters, tell, and I'll add them. But do try editing .mtl files first - and see how much easier it is. In fact, I added those to .mtl parsing because I got tired of having to go to .xmesh, edit, and then go back. That way, you skip one step entirely, and the editing is much simpler (a single file, rather than multiple, with more intuitive syntax).

I will certainly take a look. I was mostly thinking of the commandline args as a quick way to provide support to the GUI wrapper for setting maps without having to implement an MTL wrapper editor, but I can't imagine that they would be terribly difficult to invoke via the commandline (as long as all arguments were optional), ie
mesher foo.obj foo.bfxm obc -diffuse=foo.png -ppl=fooPPL.png
And of course, these would only be used to force the assosciations, otherwise they would be pulled from the MTL file.

This should also handle cases where you want to change the texture maps on a bfxm/ogre model without going back to obj and fooling with the MTL file.

In the end, if you really see no merit in the idea, then don't feel that you have to implement it. I just thought it would be a nice all-around compromise that could help both commandline users and potential GUI users by saving snow_Cat a ton of work.

[klauss]

Maybe more like

Code: Select all

mesher input.obj output.mesh omc -matname wood -diffuse wood.png -matname blarg -diffuse blarg.png -emissive blarg.png -specular blarg.png -damage blarg.png

(See? multiple materials - that's the cumbersome part.)

Also... since someone asked... 'omc' is 'obj to mesh - create' (mesh is Ogre's format).

[snow_Cat]

^ o · ^ would it not be easier to include a <texture paramater file> argument, greatly reducing the potential for typos and minimizing the risk of exceeding the 128 character command limitatation on older machines?

[klauss]

As in

Code: Select all

mesher tada.obj tada.mesh omc -matfile tada.mtl

?

[snow_Cat]

yes, though mtl is an implicit format of Alias Wavefront;
ma is used by Maya and
mat is used by Corel Agl-angle-et[cannot spill word];

Which I think is the bigger issue here.
mtl editors abound for doing exactly what we want here, but are cumbersome at best, I'll make a crude mtl viewer once I'm satisfied that this masher works as is first.

Current expected release features:

• Create file
  • Individual file+output location/name control
  • multiple files+automatic location/name control
• Append multiple files
• Dimension reading
• log file
• file name/path format support*
  • http
  • adm
  • udm
• drag and drop interface
• scalable GUI
• transpose and forceflatshade support (all modes)
• cutesy-cute logo

expected release date: thursday

future features:

• proper ogre format support
• file paramater override/editing
• *won't store udm file names on a adm system when asked
  • don't ask
• bug fixes
• win32 support (2k ok, annoying bugs turning up on 98 test machine, still usable though...)

Ugh, thogught that I'd hammerout the bugs in my text pasrsing scrtipt andpitch up a midnight demo, thing's buggy.
reall buggy.
i've decided to strip out all the features that I've not thoroughly rested and give you something to chew on.
Proceedure

• select the 'configure tab'
  • drag any file from your mesher directory to the 'mesher.exe' box,
    • I don't think it really cares
• return to the 'create tab'
  • drag any mesh file to the input box
    • notice how the extension is automatically removed;
    • this is to allow fast extension/revision swapping
    • and because I won't bother fixing up the parser any more tonight
  • now select an output format and change to any thing you like
  • mesh it and repeat

melw... I sleep now, will fix remaining features after work, expect release by 10 pm.

download balleted!, try next version plz, fixed bug with spaces....

[snow_Cat]

stupid apache-interface-firewall; automatic permissions my arse, may well of installed a shiv.

My system caught a virus today; though I had ample time to finish the program before being hit and after cleaning up; the fact remains that I didn't.

Next thursday...

Act in haste and repent at leisure; Code too soon and debug forever.

levels.unisa.edu.au/marwk

ran out of time again... next work day I'll try again; that is if I show up to work, unlike yesterday...

forgot to list fixes from previous WIP-06-01-17:

• automatic VS 0.4.3 instalation recognition
  • immeadately sees the 'install' dir and links to mesher
  • drag/drop functionality remains
• longpathname support
  • properly handles the longpathnames in scriptbuilding
  • invalidpath not checked for...
• dimmension
  • any input format
  • calculates 'total span' too
  • hella buggy, didn't include if error routine in script
• broken
  • batch convert
  • batch append
  • error handling
  • configuration storage
  • overwrite behaviour control...
  • udm in adm database problem
    • should not be possible
    • files cannot be deleted in windows GUI shell, use DOS or console...
  • logo not implemented.

today is the 23rd, it has been five days since I showed up to work; apparently I'm up for promotion....
I hate my job.