UnitConverter obj->bfxm

A forum for the discussion and development of programs to assist working on or playing with the Vegastrike engine and data sets.
Post Reply
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

This is indeed strange as it works fine on both of my machines (I have been converting models for the past 2 weeks with it).
Is there any error output from python in the command window when you click the button?
To run from command line, change to the UC directory and type uc (on windows) or ./uc on linux (there are shell starter scripts).
Alternatively, delete the unitconverter.ini file and try again.
For further debugging, please state your python version (type python in command line). Are you on Vista?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

pyramid wrote:@chuck,
marker class/name for placements of sub-units? short answer: no.
Not sure yet how this is working. The Archimedes has 3 subunits that were exported all in one obj file, so the positioning is already given by the model coordinates.
Those would be "sub-meshes". Sub-units are like units, with their own folders under /units or under /units/subunits, and having their own entries in units.csv. You could have a whole docking complex modeled and exported and unit converted as if it were a "unit" (ship or station), and then have a station call that docking complex as a sub-unit, in its own entry in units.csv, at 8 separate locations.
As a matter of fact, turrets ARE sub-units; but sub-units can include many things besides turrets.
I believe we haven't been USING sub-units for much except turrets, except for one space elevator station I was once working on that didn't have a mesh at all, because it was entirely made of sub-units... (It was split into 4 main body sections, plus a military installation on top).
Actually, spiritplumber started using sub-units extensively in WCU, to make parts of ships target-able and destructible.
In the future, we might start using sub-units more extensively. The main advantage is that sub-units have their own AI, so when you request docking to a space station, for example, instead of it giving you 50 choices for where to dock at, it might delegate your docking request to a specific "dock sub-unit", which then directs you to a docking on itself.
Sub-units are also independently target-able and destructible, so if in the future we have shield emitters on cap-ships implemented as sub-units, one strategy for defeating a cap-ship might be to target and destroy its shield emitters first (if you have a limited ammo weapon that can penetrate shields). ;-)
Were you thinking about a naming convention for the helper objects to mark the centers of the subunits in case they are exported in different obj files? *thinks* but the coordinates are still there relative to each other already... Please give me an example as I don't understand.
Calls for sub-units for a given unit appear in its entry in units.csv same place as turrets. Each sub-unit entry has a (sub)unit name (the name of the sub-unit type's own entry in units.csv), and its position, scaling, forward vector and up vector, IIRC.
By the way, sub-units can also have sub-units, ad infinitum.

EDIT:
In PU, we are planning to open up the Sol Sector map. The Sol Sector will feel different from Gemini: More high-tech, industrialized and "cultural". Many types of space-born factories... But rather than painstakingly model each of 6 dozen types of factories, we are planning to model a number (say a dozen) of different types of modules that can be called as sub-units by different types of space station frames (say another dozen), at different locations. So, we might end up with 200 types of stations in units.csv, but which are mere re-combinations of a limited set of frames and sub-units.

All you need, really, is a marker type with a name format such as,
"subunit_<subunitname>_<locationID>"
where <subunitname> is the name of the subunit type as per column A in units.csv.
<locationID> is to differentiate among multiple sub-units of the same type.
Last edited by chuck_starchaser on Sun Sep 14, 2008 1:06 am, edited 1 time in total.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

I'am running fedora 9 with Python 2.5.1 and there is nothing in the terminal window when i press the button next to new and remove model i have put the Shenzong's obj mtl and four texture files in the workspace defined in the ini file.here is the ini file

Code: Select all

[MODEL_0]
name = 
faction = 
technique = 
texture_4 = 
texture_1 = 
texture_0 = 
texture_3 = 
texture_2 = 
obj_path = 
blendmode = ['0', 'ONE ZERO']

[Model]
mtl_path = 
obj_path = 

[Config]
workdir = /home/denis/workspace/UnitConverter/Test
nr_of_models = 1
vegastrike_root = /home/denis/workspace/SVNvegastrike/data
active_model = 
model_0 = 
texture_faction = 
hud_image = 
active_modelnr = 0
unit_modelname = 
nvcompress_path = nvcompress
mesher_path = /home/denis/workspace/BuildBox/vegastrike/vegastrike-12390
does it make sense as is

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:All you need, really, is a marker type with a name format such as, "subunit_<subunitname>_<locationID>" where <subunitname> is the name of the subunit type as per column A in units.csv. <locationID> is to differentiate among multiple sub-units of the same type.
OK. This matches the current setup for turrets. I just need to make it more generic so that the subunit marker tag will be understood as well and the subunitname is matched against existing subunits in units.csv.

@loki,
If you put the line into the ini:

Code: Select all

obj_path = /home/denis/workspace/UnitConverter/Test/Shenzong.obj
and run the prog, it should register the the model in the workspace.
The "New" button clears the workspace, The dropdown just switches between registered models. I shall add there another button called "Add Model" with the same function as the "..." button on the "OBJ File" line which opens a file dialog and registers the model in the workspace.

Also the mesher_path shhould include the mesher, so:

Code: Select all

mesher_path = /home/denis/workspace/BuildBox/vegastrike/vegastrike-12390/mesher
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Well looks like i did a Homer DoH changed the window width and look there is the browse button to add the Obj file path :oops:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

@pyramid have you thought of how to use the markers for docking points as placing them inside the mesh has happened making that particular base useless. they are a bit of a complication as both position and size need specification.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Glad you found the button. 8)
Docking ports require a position vector which can be set with the helper objects in blender and the size. For the size we might require a special helper object that provides the docking port size. This could be accomplished by scaling the existing helper object in the local z-axis to the radius of the docking port. In this way I could reuse already existing code without much effort to get the docking port size.

The naming convention for type would then be 'dock'.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Again, an update on the UnitConverter progress for the latest v0.26 commit.
I will describe briefly the updated screens:

Models workspace:
Image

Add button was provided to add models to workspace and facilitate handling for Homer DoH users :wink: Buttons has also been reordered in the most probable frequency of use.

Unit editor:
Image

Many new additions:
* You now change the thruster type.
* Browse and change the turret types
* Support now subunit and turret helper objects
* Add upgrades (to change, just delete the corresponding entry between {} in the form)

Unit2 editor:
Image

Continuation of the unit editor (cause I was not successful in making the one frame be scrollable in tkinter, d'oh).
* For now it can read the mounts information from units.csv and you can edit them manually (if you know what you're doing).
* Automatically creates docking ports from "dock" type helper objects.

The mount_helper.blend committed to the modtools/UnitConverter directory in svn is a rename of chuck_starchaser's goodstart.blend file.

Supported helper object names are:
* engine
* subunit
* turret
* dock

I have also added the tool to the Scripts & Tools wiki page

Next task: wiki UnitConverter user manual. Best fitting category/page seems to me Development:Tools:UnitConverter.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Awesome work pyramid. I don't think it can be overstated how important this tool is.
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 »

Indeed. This is History in the making.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Pyramid, you should put the svn url for unitconverter and its wiki page in your signature. I had to go several pages back in this thread to find the url.
Once I found it, there's just a bunch of python and other files; no instructions. I suppose I have to create a folder and svn-chek-it-out, right?
I tried that, but I get,

Code: Select all

Error: PROPFIND request failed on '/viewvc/vegastrike/trunk/modtools/UnitConverter'  
Error: PROPFIND of '/viewvc/vegastrike/trunk/modtools/UnitConverter': 302 Found (http://vegastrike.svn.sourceforge.net)  
Also, I suppose I will need mesher, but I don't know what version from where.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Alright, so, created a folder, downloaded the files manually. When I tried to run uc.bat it told me that "python" was not a recognized program. I guess I need to add it to my path.
I looked for where python was installed, and found two pythons uncer C:\, 24 and 25.
I used command line to call 25's python with unitconverter.py and it told me that appwindow.py, on line 18, is calling C:\PYTHON24\LIB\LIB-TK\FixTk.py, which uses python24.dll, which is not compatible with python 25.

So, I tried with python24, but it tells me "no such file or directory as,
/home/software/vegastrike/data/units/units.csv

EDIT:
I put the test_bike on svn:
https://svn.wcjunction.com/utils/cinemu ... /test_bike
All the new textures and the new obj are there. If someone could convert it to bfxm for me, I'd appreciate it. For CineMut technique, of course.

EDIT2:
I figured the problem with my path; I had the pythonpath system variable set to C:\Python24 instead of 25.
I still can't run uc.bat. Somehow, pythonpath is not enough, it appears; windows doesn't see it as part of the path, but I can call it by typing the full path. I still got the problem of a strange folder there, but found it was in the .ini file. So, I edited the .ini file to remove all the stuff to the right of the equal signs.
Now when I try to run it I get,

Code: Select all

...line 975 in updateDocks
for t in range(len(self.docks[i])):
Attribute Error: UnitConverter instance has no attribute 'docks'
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

The link to svn I've provided is only for viewing the files in the browser viewer. To check out the complete path you'll need to

Code: Select all

svn co https://vegastrike.svn.sourceforge.net/svnroot/vegastrike/trunk/modtools/UnitConverter
To run you will require python 2.5 installed and registered in your PATH variable. I have actually started to make the documentation, but with the latest site problems, currently I cannot further edit the wiki.

The error you get is due to an untested situation, which I have revised in the latest revision. As I'm at work, I can only commit it to svn later at night. Meanwhile get the update from Space3D.

It should work with your ini file. In case of problems, just delete unitconverter.ini and configure it from scratch. You'll need to point it to the mesher_techniques.

The converter currently considers 5 textures. I see in your latest noodle that you provide 6 textures (0-5). I must have missed something, so bare with me, but will this be the standard for CineMut, i.e. do I need to provide the conversion possibility for 6 textures in UnitConverter?

In this current UC version, when exporting from blender to obj you'll need to export materials, too, otherwise the obj file will be missing the link to the mtl file which will be then used to assign the textures. You don't need to provide th emtl file as UnitConverter will recreate it from scratch, it's just to avoid manual tweaking for the time being (will be later automated).

Get the 7zipped bfxm here.
You'll need tex_000.texture to tex_004.texture. I couldn't test it on my win machine.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

pyramid wrote:The link to svn I've provided is only for viewing the files in the browser viewer. To check out the complete path you'll need to

Code: Select all

svn co https://vegastrike.svn.sourceforge.net/svnroot/vegastrike/trunk/modtools/UnitConverter
Gottcha; thanks. I still say, you should put the url's in your signature, like,
  • Latest unitConverter Version: 123.456
  • UnitConverter browse URL.
  • UnitConverter SVN check-out URL.
  • UnitConverter Documentation WIKI URL.
  • Mesher check-out URL.
As I'm at work, I can only commit it to svn later at night. Meanwhile get the update from Space3D.
Thanks! Will try.
The converter currently considers 5 textures. I see in your latest noodle that you provide 6 textures (0-5). I must have missed something, so bare with me, but will this be the standard for CineMut, i.e. do I need to provide the conversion possibility for 6 textures in UnitConverter?
Well, believe it or not it is still not decided if it will be 6 or 7 textures. The sixth texture right now is a combined PRT ((PRTp-PRTn)/2+0.5 in RGB; Sum of all channels/3 in alpha). Klauss really believes in having separate PRTp and PRTn. That would push us up to 9-textures if you add environment and detail; and if I get self-reflections to work, that will need 2 more textures, so, I'd be for sacrificing the separate PRT's any day. The only difference separate PRT's make is for ambient lighting, and only in distinguishing, for a covered up spot that only gets light from the sides of the occluder, whether most of the light comes from North and South, or from East and West. And I say "who cares?"; right now the environment map and the background don't even match in rotation, and nobody's ever noticed!
Like, if you look at a shiny surface at a shallow angle you should see like a mirror reflection of the background on it; but instead you see a totally different area of the environment. :( Haven't bothered reporting it, since we'll be moving to cubemaps, hopefully soon; but just goes to show how much people are likely to care about whether more light should come from North-South than from East-West.
The main advantage that I see in separate PRT's is the extra bit of precision, tho. Also, two PRT's, each using the alpha channel for luma to improve precision with DDS compression would probably take up less memory than a single, combined PRT uncompressed; but the growing number of texture units being used is worrisome.
Anyways, I think the combined PRT texture (moto_PRT) is probably specified in the technique, for now; I don't think the previous bfxm had it in the xmesh either.
I think it's a fixed name in the technique, for now, overriding xmesh; but I could be wrong.
In this current UC version, when exporting from blender to obj you'll need to export materials, too, otherwise the obj file will be missing the link to the mtl file which will be then used to assign the textures. You don't need to provide th emtl file as UnitConverter will recreate it from scratch, it's just to avoid manual tweaking for the time being (will be later automated).
Here I get totally confused: Why would unit converter do better with an mtl file full of materials that are NOT intended to be meshes, than with no mtl file at all? But then again, I exported NO mtl and yet, somehow, the exporter still managed to break up the model :( :( :( :( Damn exporter... all those buttons and settings are inscrutable what they do.
Get the 7zipped bfxm here.
You'll need tex_000.texture to tex_004.texture. I couldn't test it on my win machine.
Got it, thanks.

EDIT:
UC WORKS! (Well, at least it opens a window.) :D
EDIT2:
I've temporarily made the whole bike a single material in Blender before exporting the obj; this should work.
I still don't know what version of mesher to use, or where to get it from.
EDIT3:
It is still *requiring* an mtl file; displays a warning that won't go away unless I provide it. So, I exported an mtl, and it says,

Code: Select all

# Blender3D MTL File: motorcycle2_objexport.blend
# Material Count: 1
newmtl BluePaint_albedo_bake.tga.001
Ns 96.078431
Ka 0.000000 0.000000 0.000000
Kd 0.200000 0.400000 0.600000
Ks 0.062599 0.500000 0.198941
Ni 1.000000
d 1.000000
illum 2
map_Kd albedo_bake.tga
Which I know nothing of what it means; I hope it's not going to try to USE the bogus info in there.
More generally, I hope UC will soon work without an mtl; that we can get away from all this mtl torture.
EDIT4:
Bad news; won't let me add textures unless they are mentioned in the .mt.
:x
EDIT5:
Alright, it allowed me to select the textures in spite of the warnings, but it also warned me that they are not .png's (which they are, though I renamed them .texture) telling me it won't be able to compress them (which I don't care for, right now). Now, when I try to run modelview.mission the bike appears white. I looked at the .xmesh files and there's an .xmesh and a .xmesh~. This is very confusing: The .xmesh seems the right size (6 megs), but it mentions no textures. The .xmesh~ has the textures right but the size is wrong --150k or so...
Last edited by chuck_starchaser on Mon Sep 22, 2008 3:25 pm, edited 1 time in total.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:Here I get totally confused: Why would unit converter do better with an mtl file full of materials that are NOT intended to be meshes, than with no mtl file at all?
Don't get confused by the name. The Wavefront material library file (mtl), for our purposes, is actually used to store texture, techniques, and all other information that you previously would have had in xmesh. In this way we can avoid the extra step of xmeshing and convert directly from obj to bfxm.

By the Wavefront file standards (obj standard, mtl standard), the obj file stores only geometry, while the mtl file stores material and texture information. So we inevitably need both files. We just ignore the material information in mtl files and use the texture info to combine geometry from obj and texture from mtl in bfxm.

Now, in blender it really doesn't matter if you define one material or one hundred. The UnitConverter will do the right job as will the mesher. From the point of view of modeling and texture noodling, it is even preferrable that you keep your many materials (representing real-life materials).

From the point of view of the artist you just need to make sure that you actually export the "materials" so that the link between geometry and texture is given (by the standard, the obj file references the mtl file), at least until UnitConverter can detect the missing link and adds one (in the next version).

Hope that helps clearing the confusion.
chuck_starchaser wrote:I still don't know what version of mesher to use, or where to get it from.
You can use the compiled mesher_techniques.exe that klauss has posted somewhere on the forums. In case you don't have it, I'll commit it tonite to svn.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:Which I know nothing of what it means; I hope it's not going to try to USE the bogus info in there.
More generally, I hope UC will soon work without an mtl; that we can get away from all this mtl torture.
EDIT4:
Bad news; won't let me add textures unless they are mentioned in the .mt.
:x
Chuck, please stop worrying about the mtl files and just do 1 thing to make it work:
* Export to obj with materials button enabled.

Period, there is no more to it.

Then, and only then, you can happily go around adding textures.
As said in my previous post, I can get rid of requiring the mtl file altogether, just give me some time to implement it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

pyramid wrote:
chuck_starchaser wrote:Here I get totally confused: Why would unit converter do better with an mtl file full of materials that are NOT intended to be meshes, than with no mtl file at all?
Don't get confused by the name. The Wavefront material library file (mtl), for our purposes, is actually used to store texture, techniques, and all other information that you previously would have had in xmesh. In this way we can avoid the extra step of xmeshing and convert directly from obj to bfxm.

By the Wavefront file standards (obj standard, mtl standard), the obj file stores only geometry, while the mtl file stores material and texture information. So we inevitably need both files. We just ignore the material information in mtl files and use the texture info to combine geometry from obj and texture from mtl in bfxm.

Now, in blender it really doesn't matter if you define one material or one hundred. The UnitConverter will do the right job as will the mesher. From the point of view of modeling and texture noodling, it is even preferrable that you keep your many materials (representing real-life materials).

From the point of view of the artist you just need to make sure that you actually export the "materials" so that the link between geometry and texture is given (by the standard, the obj file references the mtl file), at least until UnitConverter can detect the missing link and adds one (in the next version).

Hope that helps clearing the confusion.
Well, not quite; if UC ignores the materials in .mtl, why can't it make its own? It doesn't need texture info from .mtl, if I'm linking the textures in the app itself. There must be something I'm missing...
chuck_starchaser wrote:I still don't know what version of mesher to use, or where to get it from.
You can use the compiled mesher_techniques.exe that klauss has posted somewhere on the forums. In case you don't have it, I'll commit it tonite to svn.
Okay, I'll wait, as it would probably take me hours to find that post of Klauss'. He should have the link to mesher in his signature too. :D

BTW, I was editing my last post; see EDIT5. Though, maybe it's because of having the wrong mesher; I linked the one from the /data/bin folder.

EDIT:
Sorry, I'd missed your last post. Gottcha now. ;-)
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:if UC ignores the materials in .mtl, why can't it make its own? It doesn't need texture info from .mtl, if I'm linking the textures in the app itself. There must be something I'm missing...
Actually UC does make it's own mtl. I need to revise the complaint. It should actually just check for the mtl link in the obj file (added to task list) or just create the link if missing (added to task list).

To be even more clear: When exporting the materials in blender you actually create a link to the mtl textures in the obj file and this is the only thing UC needs now. As a "bonus" you'll get the mtl file which you can happily ignore.
chuck_starchaser wrote:Okay, I'll wait, as it would probably take me hours to find that post of Klauss'. He should have the link to mesher in his signature too. :D
OK. Will be in svn in 3-4 hours.
chuck_starchaser wrote:BTW, I was editing my last post; see EDIT5. Though, maybe it's because of having the wrong mesher; I linked the one from the /data/bin folder.
Your mtl file should look something like:

Code: Select all

newmtl BluePaint_albedo_bake.tga.001
Ns 100
Ni 1.0
d 1.0
illum 2
BLEND 0
technique cinemut_opaque
Kd 1.00000 1.00000 1.00000
Ka 1.00000 1.00000 1.00000
Ks 1.00000 1.00000 1.00000
Ke 0.00000e+0 0.00000e+0 0.00000e+0
map_0 tex_000.texture
map_1 tex_001.texture
map_2 tex_002.texture
map_3 tex_003.texture
map_4 tex_004.texture
Just repeated for every blender material.
I think this only works with klauss' new techniques mesher which I'll commit later, as said.

The complaint about not being png is based solely on the file extension. I will be able to revise this only with python 2.6 with the new imaging functions coming with it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

LOL, I'm still totally confused: You say that all UC needs is the link to the .mtl in the .obj file,
but then you tell me what the .mtl file should look like inside... :P
Anyways, I'll trust you that all I have to do is export with materials. But the problem is that,
apparently, the .obj exporter splits my mesh into submeshes if I export with multiple materials;
so the last thing I did was to highlight the whole mesh and assign a single material to it, before exporting.
Sorry for all these troubles I'm dumping on you; probably my fault; I just don't know anything about obj format and the exporter options.
I'm super-late for work... Gotta go.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:LOL, I'm still totally confused: You say that all UC needs is the link to the .mtl in the .obj file,
but then you tell me what the .mtl file should look like inside...
He, he, my bad. :roll: Should have said: the mtl should look like that after UC has created it. :P
the .obj exporter splits my mesh into submeshes if I export with multiple materials
True. Not sure what are the implications, but it seems to work fine in VS as mesher puts it all together again.

I have just committed the mesher.exe with techniques support to svn: browse /vegastrike/trunk/win32/bin/ and download mesher.exe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Gottcha now, finally :D

Thanks, I'll install that mesher when I get home. Calling cab now.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Downloaded mesher.
New problem; now the program won't start. Running python from the command line it says,

Code: Select all

File "H:\unit_converter\objparse.py", line 132, in __init__
  self.objvertices[len(self.objnames)-1].append(v)
IndexError: list index out of range
Could you please post your test_bike.bfxm? I can't keep going on like this; I need to get back to work on CineMut.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

I have committed a fix for this error to svn yesterday.

You can also get Unit Converter v0.26b here.
The bfxm is here.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Well, that was quick! :) It works! Now mesher crashes with "This app has asked the C runtime to terminate in an unusual way...". Perhaps it needs a mesher.exe.manifest file.
Excuse my impatience last night.
That bfxm is the same as before; has no textures, no techniques, nothing.

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="1" polygonoffset="0.000000" blend="ONE ZERO" >
<Material power="100.000000" cullface="1" reflect="0" lighting="1" usenormals="1">
	<Ambient Red="1.000000" Green="1.000000" Blue="1.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>
The new one you made for yourself, that you posted a screenshot from; that's the one I need.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Oops, sorry, wrong upload.
The 7zipped test_bike.bfxm, now with textures.

No idea about the mesher. It runs just fine here. Does it also crash when you run it from command line?
Post Reply