Universal Model Converter - Side Development Thread

[Tcll]

some useful blender (and other) related tools:
http://www.katsbits.com/tools/

I'm getting as much info on the MD5 format as possible.
(the more info, the better my library)

ASSIMP only supports MD5 v10, where the script you referenced also supports v6
both seem slightly poorly structured, so I need better references...

also inverted the OBJ export script for Blender
(if other importers have a problem, let me know)

 

[Tcll]

well this is just great 9_9

I've just decided to import an obj export into Blender24...

not sure if this has something to do with OBJ exporting and importing into Blender, but objects are messed up:


I'm thinking it's a small issue with DAT importing...
I've loaded the session I saved as it loads faster, but it's the same session I saved after fixing the normals...
(a saved session in dev4.5 is literally a dump of the model info array)
^ it is what's handled by UMC (this is gonna change by dev5 though)

EDIT:
something of interest to note:
that diamond-trail pattern you see on Pichu's head and body is the result of a poly-reduction algorythm.
Meaning Pichu was originally developed with nearly twice as many polygons.

now imagine how HQ that would've looked in game. ^_^

 

[Tcll]

well here's a small bit of progress =3


bet you never seen surface normals on a brawl preview before huh =3
I intend to build a mod to make them editable by dev5

displaying them is very simple and only took me 20 minutes to build:
gl_line ( vert, vert+normal )


sorry bout no progress yet on the MD5 format...
I will have it working, but things get complex when you try to stuff a HQ format into a LQ format through a library
(MD5: doesn't have normals, has a choppy UV interface (single channel), and has only 1 rig)
^ then again MDL0 only has 1 rig XDD

 

[Tiberious]

Stupid question time, but in the case of multiple UV channels, would it be feasible to have it write an extra copy of the mesh with the other channel?

I've noticed this as the reason for (most notably) the eye textures on BRRES Viewer exports of Brawl characters being all fouled up.

Now, I don't mean UV channels that are 'generated', like the reflection on the Alloys, but like Mario/Luigi's eyes, and so on.

 

[Tcll]

I know what you mean
Nintendo has 8 UV channels, and the default for OpenGL I've figured out has 32 (I think)

a pseudo code (commented out) to fit Nintendo's prefs using GL_ARB (Multi-Texture):
#if U0!='': glMultiTexCoord2f(GL_TEXTURE0,Fl(UVs[0][U0][0]),Fl(UVs[0][U0][1]))
#if U1!='': glMultiTexCoord2f(GL_TEXTURE1,Fl(UVs[1][U1][0]),Fl(UVs[1][U1][1]))
#if U2!='': glMultiTexCoord2f(GL_TEXTURE2,Fl(UVs[2][U2][0]),Fl(UVs[2][U2][1]))
#if U3!='': glMultiTexCoord2f(GL_TEXTURE3,Fl(UVs[3][U3][0]),Fl(UVs[3][U3][1]))
#if U4!='': glMultiTexCoord2f(GL_TEXTURE4,Fl(UVs[4][U4][0]),Fl(UVs[4][U4][1]))
#if U5!='': glMultiTexCoord2f(GL_TEXTURE5,Fl(UVs[5][U5][0]),Fl(UVs[5][U5][1]))
#if U6!='': glMultiTexCoord2f(GL_TEXTURE6,Fl(UVs[6][U6][0]),Fl(UVs[6][U6][1]))
#if U7!='': glMultiTexCoord2f(GL_TEXTURE7,Fl(UVs[7][U7][0]),Fl(UVs[7][U7][1]))

I do believe GL_TEXTURE# goes all the way up to GL_TEXTURE31


that aside, I was originally planning that for OBJ :3
(saving a copy of the model with the >>Next UV channel)

also... those channels weren't generated
I don't even think reflective textures actually USE UVs... heh
it's a material/lighting thing

 

[Tcll]

I'm currently trying to figure out why certain vertices are not being colored properly when applying the material...

things work slightly better when applying the material through vertex-color change...
(the material does not get updated unless there's a change in the vertex color)
^ glColorMaterial can't handle seperate ambiant, diffuse, and specular settings properly

however when doing that, some primitives aren't applied with the proper result.
(some strips end up being colored differently)
^ it's usually a difference of 2 colors though and the colors don't change upon video resize (why I say "slightly better")

though the current results yield full coverage when doing per-vertex operations
(yes, I'm using the old fixed function pipe-line instead of shaders)
^ I hope to change that by dev5

to apply these colors properly:
Combined = (Vert+Material)/2

 

[Tcll]

just now fixed the keyboard shortcut for toggling between Ortho and Perspective.
(did the hack properly this time too (editing GUI instead of VIEWER) )

NumPad 5 - toggles between them.
you can do it in the current release, but you have to hide the visual toggle before the shortcut will work.
(the GUI overrides the shortcut, hiding the toggles also doesn't check their values)

I've fixed that by adding a check before checking the GUI value.
(if the values don't match, the GUI value is updated)
^ this happens before the actual GUI toggle, so when toggling via the GUI, it overrides the check, and THEN sets the mode.

 

[Tcll]

._.
ok...
scratch what I said about basic texturing...

apparently I have the interface noobishly ready to support Nintendo's methods. :af:

Material
-Texture
--image

reason for the texture being a seperate slot...
Blender can have up to 10 textures for the material

that aside, 2 textures can share the same image

all I had to do was update the structures a tad:

global Libs; Libs=[ [], # Reserved
                    [], # Reserved
                    [["UMC_Def_Scene",[]]], # Scenes
                    [], # Objects
                    [], # Materials
                    [], # Material Add-ins
                    [], # Textures
                    []] # Images

the Material Add-ins are called Shaders in brawlBox (they're NOT Shaders)
I've re-termed them as add-ins because of what they do...
they're a plugin for the TEVs and advanced material/texturing functions.

how are these NOT Shaders??
well, when you actually use shaders in GL, this entire interface is ignored.

as far as BrawlBox goes, it's using this interface... not actual C-style shaders.
(bacause Nintendo doesn't have a GPU)
^ at least, not until recently with the WiiU

 

[Tiberious]

So I'm guessing you're aiming for direct-to-Blender export option instead of some intermediary format? Could be interesting, and cut out the need to write an exporter for MD5 or DAE, as Blender would handle those just fine.

I'm pretty sure Blender supports having multiple UV maps on a single object, though I could be mistaken. I just don't know how much of a hassle it would be to code an importer to create/fill those channels in Blender.

 

[Tcll]

I've actually been trying to code an exporter for it's format :3

it has a little thing called file-rewind which confuses the crap outta me :s

but yea, that's the reason functions such as u32() have the "big" setting
(it stands for Big-Endian, which is the direction the bytes are read in)
^ 8 = 0x00000008 (big) or 0x08000000 (little)

but yea, that format's extremely complex.
it's better I work on the MD5 format for now,
but I've also got planned features I need to implament first to be able to test it properly...


keep in mind though, this viewer isn't just any viewer like Blender or Steam...
it has to be optimized to work under a common interface for over 500 different formats,
and also be easily extendable.

it's an overwhelming amount to think about, especially with modern GL viewers and such


but yea, it needs to have support for every last feature and be able to easily optimize for a particular export format.


I'm just hoping I can have textures working by this next release. =D
(including reflective, dual-layered textures such as what Samus uses) ^_^

 

[Tcll]

AHAH, I FOUND YOU!!! ^_^
well that coloration issue is fixed:

found out I was actually applying 2 materials at the same time per vertex.
(these got mangled between primitives which is why some were drawn another color)

with the other method (per color update) the first primitive in the group was only getting drawn with the first material color.
(I'm now using this method in the fix-image)

lol I actually found this while I was working on the texture application per material and noticed there were 2 materials per vertex.

in any case... it's fixed now ^_^

 

[Tcll]

just testing to see if seperate vertex colors get along with this method:

sure enough they do ^_^

if anyone wants the script for it: (you can import any .txt file, it doesn't matter what as it's not read from)

from data.COMMON import *   #essentials
Header( 0.001,              #Script Version (for updates)
       ('Vertex Color Test',['txt']), #model
       ('',['']), #anim
       [''])             #included libs

def ImportModel(T,C):
    SetObject()
    SetPrimitive(UMC_QUADS)
    SetFacepoint([1,1,0],[0,0,-1],([255,0,0,255],''),('','','','','','','',''))
    SetFacepoint([-1,1,0],[0,0,-1],([0,255,0,255],''),('','','','','','','',''))
    SetFacepoint([-1,-1,0],[0,0,-1],([0,0,255,255],''),('','','','','','','',''))
    SetFacepoint([1,-1,0],[0,0,-1],([255,255,0,255],''),('','','','','','','',''))

 

[Tiberious]

See, I'd thought you had changed plans to make a Blender importer for your SES format, which you'd told me was simply a dump of the data UMC was working with. Blender appears to support pretty much anything Nintendo's format does in one form or another, though it may be a pain to try figuring out which options do what, and some just plain don't seem to work (repeat flipping and the 'extend'/'clip' texturing ones are the worst offenders in 2.49, as I have -no- clue how to make them work properly). Considering how you've stated the SES contains all the weighting data, it seems like the perfect way to get a weighted model and skeleton into Blender.

 

[Tcll]

well, sorry if I misled you
yea, I don't intend to make an importer as SESv1 is constantly being updated and extended to support new features.
(I'd have to update the blender plugin every time I make an update to the format)

that aside writing a script for blender is roughly 3x more complex than writing a script for UMC
for example, you have to go through all the work of grabbing your file AND defining the SAME functions for every other file to read the data from your file.

ok so the SESv1 format is extremely simplified as the dump itself is the Libs var found in VIEWER which makes things alot simpler to use an eval() on the data...

but things are made even more complicated by blender's class methods and such.
with UMC, everything is functions meaning it's all single level (no DOT '.' operator on any names)
and to make things even better, I'm following OpenGL's fixed function method:

SetObject() #create a new object in the default scene
SetPrimitive() #sets our newly defined object with a defaulted Triangle primitive
SetFacepoint(Vert,Normal,(Colors),(UVs)) #adds a facepoint to this primitive (data can be RAW or an index)

unlike Blender, my functions are EXTREMELY loose and built with a pre-defined structure to work as noobs would expect

yes, UMC's scripting interface is designed and built for the most noobish of noobs in 3D programming ;D

however, I won't say that doesn't throw a small wrench into the gears...
behind the scenes, alot has to be redone to add a simple feature...
so simple things can get extremely complex very fast.


aside from UMC's 3D interface, there's also the file management interface.
a script doesn't do it's work not until you've imported a file.
once the file is imported, the data is nothing more than an optimized u8() array.
UMC's binary int/float handling functions are all based off of one main function called _BIT() which reads/writes an int/float of any specified size/format to/from the file data

feel free to use that function for your works, but it's strict about the data used or it messes up...

another complex function (which needs to be redone) is StructArr() which reads/writes a given structure of data to/from the file...
such as verts:
Jump(VertsOffset) #jump to the vert data from the start of the file
StructArr( ['bf32','bf32','bf32'], NumVerts ) #read the verts from the data
# returned data: [ [bf32(),bf32(),bf32()], [bf32(),bf32(),bf32()], [bf32(),bf32(),bf32()], ... ]


UMC is meant to do all your hard work for you when dealing with 3D data.
that why the development of a single feature takes so long...

UMC is truely a pro program, but it's completely free and truely open-source (it literally runs off it's source)
another reason this is taking so long is people aren't willing to co-develop this or even so much as help me out with info...
(I'm still working on a good method for co-development though... heh)

have you tried python programming?? (python 2.7.5)
would you like to be a co-developer of UMC??

if so, I can upload this to my server an we can host a convo discussing new features for interfaces and stuff...
I could use an extra hand honestly

 

[Tiberious]

I just... don't understand exactly what it is you're working on at any given time. I'd hoped you would have been putting the finishing touches on a script to export to some format that supports weighting, considering the fact you have the Melee importer perfected, giving UMC an initial use similar to something like BrawlBox or BRRES Viewer, but for Melee, with more to come later.

 

[Tcll]

well... your argument IS valid... and I have more than somewhat been lazy at trying to finish this >_<
I work on whatever I'm currently thinking about, which is considered to be among many projects aside from UMC.

as of the moment, the new implamentations to string() somehow broke my Melee script making it fail soon after the initial import.
(I didn't want to mention this, but now it's taken too long to fix)

that aside, I havn't been working on more formats for UMC as I've been trying to make UMC display more info as well as make graphical and performance improvements towards the viewer.

documentation for my needs is very difficult to get a hold of...
I'm currently trying to figure out the ends of material and texture application so I can effectively bulk the SES format where needed.
(I don't want to make too many bulks in a short time as it could end up breaking support in certain areas)

I've PM'd BJ asking him his knowledge while I try and skim google for resources...
but BJ hasn't responded, and my searches have lead me through shader application
(I need texture parameters and TEV info, along with any other missed info in the area)

I know your eagar to see this thing fly, but I'm only one person, designing the most complex of projects...
why not lend me a hand and write a script yourself
(for what UMC can currently do)

also...
for the MD5 side, I havn't been sitting around there either...
I've been more collecting sources to study the format a little better.
I currently have 5 sources I can reference from.

if you'd like to build a temporary script until I can finish the library, I can send you the sources

 

[Tcll]

also... the Melee importer is only near perfect...
Revel8n told me about this file a while back and I havn't been able to fix it... >_<

^ last released build (current build broke the script)

what I'm doing wrong is using an inverse of the inverse matrix as a bind matrix and applying that to the influences...
what I need to do is calculate the bind matrix from the transformations and parent bind matrix...

however, last time I tried that, things didn't work out well... :/
I'm still not sure what's causing the issue, but it'll get figured out... in slow time sadly >_<

if you'd like to help, I've created a GitHub repository for my last released build:
https://github.com/Tcll/Universal_Model_Converter_dev4x

I'll only update it with working commits
(VIEWER and GUI will be getting updated here soon)
^ once I get my crappy text display method working... heh

 

[Tcll]

ok... I'm so lost XDD
first test of a texture:

^the display remains normal UNTIL the model shows up

I have no functions defined to test the texture...
so I edited the SES to add the material, texture, and image in my format. (the image is an 8x8 2-color RGBA image)
this is the exact same model I used for testing the vertex color integration with the material, which you can see, still works
but why does my screen turn blue XDD

I'm lost now XDD

 

[Tcll]

solved half the problem... heh

^the alpha channel may be the cause of the issue, but IDK

/has played around with alpha textures before (failed UMC fonts which lagged the viewer like heck)

I'm still having no performance issues with this :3
(runs at max FPS)


EDIT:
did the background checks, this is actually working perfectly ;D

the blue-ish color is actually correct:
R,G,B,A = 64, 128, 255, 128

however, I'm not sure why alpha isn't working >_>
(it worked for the fonts last time I tried it)

 

[Tcll]

ah, I fixed melee importing :3
for some reason the recursion setting for String() -> pString() was causing the parser to just stop with chr(0)...
not sure what happened there >_>

so I've set recursion to False by default and it works perfectly.

I'll have to look into why it's fussing about that >.>

all that's left to do now is to define the material, texture, and image functions for importing and exporting.
then I can support the texture data in melee files ^_^

 

[Tcll]

well here's a quarter of the work done :3


now it's time for the more complex stuff XD

which I was an idiot and hit up Ian Mallet for information about multi-texturing w/o shaders (like GX)
I'm currently getting my butt chewed out about how I should use them.

problem is, dev4 isn't built for them, due to improper and misleading documentation.
dev5 will be though, but I need more knowledge before I can start building it... heh

 

[Tiberious]

Hmmm... that blue almost looks like Blender's Weight Painting mode. Is that a hint at something?

 

[Tcll]

lol I didn't write that material XDD
the SSBM script did :3

however, it is a hint since you mention that ;3
(thanx for reminding me)

but that'll be wrapped around the GUI rather than the display,
otherwize you may have a bit of trouble making things out XD

EDIT:
actually, I don't think I can display that w/o shaders, or a crap-ton of memory usage
(wait until dev5)

right now everything is currently drawn using display lists...
that'll be changed to VBOs by dev5 (the whole system is being rebuilt)

 

[Tcll]

sry this is taking a while to post a melee model with actual textures...
while I do have enough info to simply apply the image, I don't exactly have enough info to properly set it... :/

this is everything known about Melee Textures so far:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
00 00 00 00 00 00 00 00 00 00 00 00 3F 80 00 00
3F 80 00 00 3F 80 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00
00 05 00 10 3F 80 00 00 00 00 00 01 00 00 E9 08
00 00 00 00 00 00 00 00 00 00 E9 20

everything in green:
wrap_S
wrap_T
scale_W
scale_H
image_ptr
pallet_ptr

 

[Tiberious]

Meh... I'm most interested in having some way to get weighted Melee models/armatures into Blender. Anything beyond that is gravy.

 

[Tcll]

I hear ya

problem is I need to worry about the internal support for the scripts...
that's where all the magic happens between conversion.

once I actually make the dev4.5 release,
THEN I can work on the scripts for exporting to other editors.

UMC has to be able to support itself to be able to support the externals peoperly
and while it DOES come that far with weights, I promised texture support by dev4.5
along with a more-usable GUI that won't slow the crap out of the viewer...

I gotta work on those features first as dev4.5 is a final release before a complete rebuild using modern OpenGL with shaders.
(in the time I'm learning to build this, scripts can be worked on for dev4.5)
^ AND I'm working on a library for implamenting dev5's function layout into dev4.5,
meaning the only porting you'll have to do is the header and the main functions

the functions such as ImportModel() will be deprecated

all scripts will use only 2 functions for Import and Export.
the type of data the script can handle will be defined by calling the Header() function for each data type.
such as:
---
Header(UMC_MODEL_SCRIPT, ... )
Header(UMC_ANIMATION_SCRIPT, ... )

def Import( Type, File, Commands ):
. . sw = switch(Type)
. . if sw.case(UMC_MODEL_SCRIPT):
. . . . #do model stuff here
. . if sw.case(UMC_ANIMATION_SCRIPT):
. . . . #do animation stuff here
---
NOTE: some things are subject to change

dev5's function system is much more stream-lined than dev4.
it is also much more loose meaning you barely have to use any of them when setting your data.
(you can just set an array of vertices, and it'll display a series of dots in the viewer)

auto-control is another feature which can now be enabled.
(it's auto-defaulted in dev4x due to the safety system)

in dev5, if enabled, when you set a vertex array, and a slew of polygons with indecies to the array,
it'll automatically generate the scene -> object -> mesh before filling it with your data.
(it'll also generate smooth normals so your model doesn't appear flat when displayed)
^ you will be able to recalculate solid normals

yes dev4x DOES have auto-control, but it's more directed at display safety rather than convenience...
(it is also noobishly implamented because of this, so there may be issues)
^w/o it though, the system is more prone to error from bad data types such as SetFacePoint(["1.0","1.0","0.0"])
(notice how the data is given in strings)

dev5 aims to give ease w/o overloading the CPU with instructions
though that's made difficult when python's dynamic simulation puts enough load on the CPU as is

 

[Tcll]

well... come to find out I had the material color and texture offsets reversed... XP

anyways... a first test for Melee textures:

^ freakin CMPR format, I hate you so much >_<

EDIT:
on a side note though, Materials are working rather perfectly: ^_^

 

[Tcll]

well this doesn't look good...

I had a feeling something like this would happen >_<

back to the drawing board I go 9_9

 

[Tcll]

a minor update...
found a few bugs and got it working like this:

 

[Tcll]

decided to take a short break from the stress of Melee's textures and work on a useful fix...

remember how you couldn't do this before: (look at the console)


I purposly put that error there
you can't add an int object to a none-type object XD

turns out the fix was extremely simple XDD
in the file import function, I wasn't resetting the directory on a new file import,
so it was mistaking the new file for a local file and basically adding a global directory to a local directory.
(this didn't happen after a good import because the reset happened after the model was imported)
^ the error stopped it from getting that far

so that's fixed now, errors won't break the file import anymore XD

 

[Tcll]

well guys, take a guess at what I'm getting working :3

[ #File Type:
'blend', 
	'blend1', 
		'blend2', 
			'md5mesh', 
				'pmd', 
					'mdl0', 
						'brmdl', 
							'dat', 
								'txt', 
									'ses', 
										'obj', 
											'mod']
[ #Script Name:
'Blender data file', 
	'Blender data file', 
		'Blender data file', 
			'MD5', 
				'MikuMikuDance', 
					'Nintendo', 
						'Nintendo', 
							'Melee', 
								'Vertex Color Test', 
									'UMC session data', 
										'Wavefront', 
											'Wavefront']
[ #Required Image Scripts (by name):
[], 
	[], 
		[], 
			[], 
				[], 
					['NtdoImg'], 
						['NtdoImg'], 
							[], 
								[], 
									[], 
										[], 
											[]]

^hint: the last block (pay attention to the indentation level)

this is some extremely complex stuff right here, but basically,
this is the feedback from the model scripts...
the last block (as stated) is for setting up ONLY the image scripts used by that model script.
this is to prevent a conflict between image formats when calling SetImage() with a file-directory for the data input.

later on, common image formats will automatically be supported (no specifications required)

you'll be able to disable these by putting ["UNCOMMON"] for the required image scripts
(why use them if you're not gonna need them)

 

[Tcll]

finally an update
and a progressive one at that =D

first test of the external image import interface:

yep... a complete swerve and crash >_<
I hate errors...

what happened was the interface didn't switch the file back when it hit the error, so it read from a blank file internally... heh
(that's been fixed already)
^ I'm currently working on figuring out that key error which is supposed to initialize the image script

yep, 2 errors displayed here, how bout that
(it was supposed to continue with the model import)
^ just no image for that material (including exports with internal images)

 

[Tcll]

2nd test... almost working:

^I havn't checked the log yet, but the TEX0 script uses the same code as the SSBM script... heh
(this is why I need to work on the library interface) >.<

 

[Tcll]

ok... so to verify...
I've gotten the format fully working:

^ignore that XRotN image... I'm not sure why that's there >.>

the texture problem that followed Melee apparently also follows Brawl...
I'm not sure exactly why this happens, but I know it's a problem with VIEWER in the display list generation function for the model.

everything is getting passed for what I believe to be proper,
it's the GL context that's messing everything up... >_>

it might lead down to me having to re-haul the Display function and display-list generation.

the format is working perfectly as with Brawl, I can follow the links between objects, materials, textures, and images...
with Melee, the names are the offsets to that data-block...
(very hard to follow as it doesn't tell me if the texture is for Pichu's cheek or eye)

 

[Tcll]

update:

getting there:

^in VIEWER: applied textures after creating the model (nothing done to the Melee script)
definitely a GL context issue

Brawl still has problems... heh

 

[Tcll]

well...
I've switched to an inefficient method of re-creating the image for each texture instead of testing if an image exists:


Pichu looks no different for some reason <.<
maybe that's just something I need to fix in the melee script... heh

 

[Tcll]

fixed up a minor issue and repositioned the light for a better view


I've still got TONZ of other errors to fix with certain imports... heh
(Melee Pika screws with the GL context and causes it to return a tuple instead of an int for the model display-list ID)

could be due to a few variables which I've named the same name

EDIT:
yes I've saved an SES from the same trophy imported in the above posts
told ya textures were imported properly

 

[Tcll]

here we are... another update
anyone remember the script reloader I had working in the scrapped dev5 build?
well:


a release should be on the way soon
I'm just working on reimplamentation of the old stuff along with the new.

 

[Tiberious]

So you finally have MD5 export working?

 

[Tcll]

sry... I got a long jump to hit before I can get to that...

good news is I'm almost strong enough to make that jump

in short... I should be able to get to that soon

I have an idea for writing the seperate parts of the string recursively ;D
string( 'string0' )
string([ 'string1', [ 'string2', 'string3' ] ], start='{', stop='}', recursive=True )
^this will write this:

string0 {
    string1 {
        string2
        string3
    }
}

hope you like