Universal Model Converter - Side Development Thread

[Tcll]

UPDATE!

I've completely redone Melee's script with a pathfinder to validate known structures before parsing the data
I couldn't have done better, it's so beautiful! ='D

^ this is my favorite star from Kirby Air Ride, the Slick Star

let this be the first successful import from Kirby Air Ride ^_^


I'm still not finished porting the scripts fully, but you'll have this support by the next update.
this was just a little something I had to post as I love this star so much! ^_^

now imagine Pichu riding that in MKW with it's handling =D

 

[Tcll]

here's a model that's been confusing the pathfinder for a while:


the root structure is a bone, but it's size is 0x58 rather than 0x40
this pathfinder now knows how to look for padding in root structures, and compare known approximate sizes.

one thing that still thwarts the pathfinder is root image data found in Melee stages

but there's also a ton of unknown root structures to add
right now only 3 root structures are supported, though only 2 of those are actually parsed.

 

[Tcll]

just supported 57 common image extensions ^_^
and I schooled the pillow devs while doing it ^_^
https://github.com/python-pillow/Pillow/issues/1006


^ yes I'm still having the issue with the eyes...
I think it's cause I'm using a clamp rather than a repeat/mirror

importing DolPikachuR2.mdl0 100% 
Converting from import format...
importing Pikachu_eyes.05.png 100% 
importing Pikachu_main.png 100%
Verifying data...
Updating Viewer

this one was a pain because PIL (pillow) did NOT want to cooperate, I had to add extensions and such, and I still can't get it working in the library >_<
so I'm breaking my rule and importing it from my script.

I do intend to have a library later on, especially by the 3.0 release

EDIT:
called it:


EDIT2:
just got my library working, so I don't need to break my rule... yay ^_^

 

[Tcll]

good news, I've just fixed up image scripts to update UMC image data as they were originally intended

no more:

return W,H,img,plt

it's now:

    ugeSetImageWidth(Width)
    ugeSetImageHeight(Height)
    ugeSetImageData(img)
    ugeSetImagePallet(plt)

 

[Tcll]

updated the bone display a tad:


bones now display parent/child relation as a black dotted line, as well as each bone's head and tail.
just to note, the head is the pivot point, while the tail just swings in space.

I know the bones are pretty messed up in the image... heh
I've always had a problem with them

in this case, the tail position is 0,0,0

not sure what's going on with the bone locations and such... >_>

 

[Tcll]

just to show you guys what I'm going through so you don't think I'm dead or anything... I literally have no clue what's causing this:



I can say the SES format contains NONE for the bone's parent like Pichu's ears...
I was thinking this was a format issue, but it could also be as deep as the import script
and then there's also the issue of the verification (recent addition) which could be doing this...

here's what happens when I disable the verifier:



the verifier works on things like MDL0 imports where not all parents are resolved before the viewer is updated.

EDIT: WTF!?!
my verifier is supposed to fix model errors, not make more >_<

 

[Tcll]

ok, got the bones working using the locations from the Inverse Bind Matrix:



the parenting however...
this isn't the verification's fault, the verification reports back with no changes made

however, it does report back with extra bones...
I'm really not sure as to why this happens... but it tells me something's up with ugeSetBone()...

EDIT:
yep, I was right...


now I'm confused as to how melee models worked with this like that...

odd...

 

[Tcll]

just so you guys know, I'll be working on the bone tails in the next screenshots.

bone tails will be in the direction of the first child or opposite of the parent (if no childrn) and will show the scale and rotation if not explicitly set.

btw, for bones, I'll try to provide many different data specifications...
bones typically tend to have a:
- Loc,Rot,Sca (I'm not sure exactly what this is relative to, but I think it's the object-space matrix)
- Bind Matrix (typically relative to the parent bone's matrix as this is the common format)
- Inverse-Bind Matrix (relative to world-space, typically used for calculating an influence matrix from the current frame matrix, which should be a world matrix relative to *this* bone's current transformations)

the inverse is usually pre-calculated so the GPU doesn't have to double it's work-load to get it.
(getting the inverse of a matrix is a huge load of calculations)

yes, I've mentioned alot of matrices...

here how matrices work:

Transform = Mtx44( Loc, Rot, Sca )
Bind = World * Object * Transform * ... * Transform
Inverse = invert( Bind )
Influence = (( Bind * Inverse ) * Weight ) + Influence
TransformedVert = Vert * Influence


the frame matrix comes in with animation and is similar to the bind matrix, I'm only sure how to handle half it's data...
I'm not exactly sure how to apply key-frames yet, but once they're applied, the Bind matrix becomes the Frame matrix.

in GL terms, a bone is nothing more than a 4x4 matrix, meaning you can derive anything from anything

a 4x4 matrix is typically specified as:
[
[ R00Sx, R01, R02, Lx ],
[ R10, R11Sy, R12, Ly ],
[ R20, R21, R22Sz, Lz ],
[ 0, 0, 0, 1 ]
]

R = Rotation
S = Scale
L = Location

the 4th row is typically for view transformations such as perspective.

as far as UMC is concerned with these, you really only need to specify one of any, and it'll fill in the blanks automatically. (similar to Blender)

right now it doesn't do that... I need to work on the verification interface where THAT will do all that work.


UMC3.0 can be expected to fill in the blanks automatically as well as deal with data mis-matching.
the more data you supply, the more it can validate, which is a good thing
if everything you supply is in a different location (each to it's own),
each location will be drawn from red to pink to show the mis-matched locations.
(this will be selectable so you can export the proper location)

EDIT:
just got told by ImaginaryZ my info was hap-hazardly put together,
which I can understand considering how little I know about this stuff.

here's a reference that might help describe some of what I was trying to describe:
http://http.developer.nvidia.com/GPUGems/gpugems_ch04.html

but yea there's apparently more ways to roll-out data than I can even conceive...
all I need here is to supply easy functions for converting the data to and from what's needed to make it work in UMC.

due to the way UMC3.0a is built, this won't exactly be possible w/o loads of work on every angle...
UMC3.0 however can easily be extended with whatever's needed (since I now know how classes work)
problem there is UMC3.0 is only about 8% complete,
and I need to learn a crap-ton more before I can even design a decently-effective interface...


another topic I was hit up on was my use of terms which I guess can be confusing...
(I was brought up into hacking using these terms and they just made much more sense to me than the normal terms)
^ not to mention I chose these terms for noobs to make easy connections

my term - common term

Vert - Vertex Position or Vertice
UV - Texture Coordinate
FacePoint - Vertex
Rig - Armature/Skeleton/Matrix Palette
Bone - Matrix

the reasons I chose these terms:

Vert - mash-up between confusing Vertex and Vertice (singular term is usually called Vertex, not to confuse this with a facepoint)
UV - while TexCoord is the technical term used in GL, most editors tend to specify UV
FacePoint - derived from the OBJ file format, as it's much easier and less confusing than Vertex
Rig - I've seen the term used quite alot in various places
Bone - this one's pretty obvious and is quite common

 

[Tcll]

relation

this is something I hadn't considered which is gonna make a big change in bone functions.

something I'd recently been told by ImaginaryZ about typical LRS relation:
- Loc is relative to object space
- Rot and Sca is relative to parent space
but these can differ depending on the interface they're implemented on...

so to solve that, all LRS and Matrix functions will be given a 'relation' attribute, which will be defaulted to the typical relations.
the relation attribute will have the following globals:
UGE_PARENT
UGE_OBJECT
UGE_WORLD
UGE_INVERSE_PARENT
UGE_INVERSE_OBJECT
UGE_INVERSE_WORLD

with this in mind, UMC will only have 1 bone matrix function: ugeSetBoneMtx( ... )
(relation is required here)

this does NOT change the plans for the PT and UT buffers of the dual-ended model interface in 3.0, but this will change up the function defs a tad in UMC's function layout.

btw, just wanted to mention, 'default' will NOT be in the next update to 3.0a, nor in 3.0

what it did was enables the use of fall-through in switch/case/default in a C#/Java style fashion:

switch(3)

if case(3,4): # init
if case(3):
if case(4):

if default:

however, the way UMC handles switch/case is via a global location, meaning you can do this:

switch(3)

if case(3,4):

    # init

    if case(3):
    if case(4):

else: # default

also, I want to mention I'll be renaming the file interface functions in the next 3.0a update:

ugeImportFile()
ugeExportFile()
...

 

[Tcll]

just updated my function layout:
http://tcll5850.proboards.com/thread/182/layout
^I now have a pretty solid header format, and anything in green will be added in a later update to 3.0a (struct()() may be in this next update)

 

[Tcll]

updated one of my new functions: array()

if you've used StructArr() in my older builds, array() works very similar.

data = array( [ bu32, bf32 ] ) # reads until [ 0, 0.0 ]
data = array( [ bu8, [ bu(3) ] ], [ 255, [ None ] ] ) # reads until [ 255, [ * ] ]
data = array( [ bf32, bf32, bf32 ], 5 ) # reads 5 structures


this function can also read strings from data.
array( [ [string, bu8] ], bu8 )
this will read ['my_string', 'data'] from the data '\x02\x09my_string\x04data'

you can also read strings of a fixed size:
array( [ [string, 4] ], bu8 ] )

 

[Tcll]

well I think it's been long enough to tell that the OBJ format isn't going to be seeing any changes, so I'm gonna extend it with the ability to support weights and bones.

WGT files will be associated with the OBJ in a similar fashion to MTL files.
all the WGT file does is hold a rig and apply a weight of each needed bone to a vertice.
WGT bones will NOT have a matrix, this is to keep things simple, they will only have a loc, rot, and sca:

# bone name
b Bone_0

# bone transform
# bt LX LY LZ RX RY RZ SX SY SZ # questionable (format may change)
bt 0 0 0 0 0 0 1 1 1

# bone parent
# bp bone_ID bone_parent
bp 2 1

# weight bone_id/influence
w 1/0.0
# applies to the first vertice (weights should be collected before reading vertices)


I'm designing this extension for a game I'm working on which it's crummy engine can only import OBJ files.
(instead of completely rewriting the support, I'm only extending it)

 

[Anutim]

just to show you guys what I'm going through so you don't think I'm dead or anything... I literally have no clue what's causing this:

I can say the SES format contains NONE for the bone's parent like Pichu's ears...
I was thinking this was a format issue, but it could also be as deep as the import script
and then there's also the issue of the verification (recent addition) which could be doing this...

here's what happens when I disable the verifier:

the verifier works on things like MDL0 imports where not all parents are resolved before the viewer is updated.

EDIT: WTF!?!
my verifier is supposed to fix model errors, not make more >_<

Will this tool of yours be able to export/import models from/to Melee?

 

[Tcll]

eh, exporting to Melee is still being figured out, but it'll be able to import from Melee (and Kirby Air Ride), yes
(the format is so simple that doing anything for it is extremely complex, more complex than MDL0)

the reason it's taking so long, and why I havn't updated in a while...
I'm working on a game (a Nexuiz clone) so I can properly understand how bones work and how to build ugeSetBoneMtx() properly.

UMC's support comes from it's (user-written) scripts...
it's my job to make sure you guys have an interface that's simple enough for a non-programmer to use.
http://tcll5850.proboards.com/thread/182/layout
^make sure you enable JS or it won't display correctly (I've built plugins which manage the display)

in 3.0a with the current interface, I can boast a good 65% less code needed when compared to Blender26.
(UMC does all of the file management and data handling for you, all you need to do is pass the data between the file and UMC)


I must appologize though for the long wait...
I'm only a noob and don't know alot about game development, so learning this stuff as I build is quite a hassle.

one thing you can be sure of, you'll get the program even if I give up on it, though giving up is highly unlikely.


EDIT:
on a good note, I finally understand sin() and cos() :3

X = cos( radian )
Y = sin( radian )

 

[Tcll]

change of plans for a string in a struct, it can be done more simply and much better like this:

string(bu8)() which can also be used locally.
you can still call string() like normal, but supplying a UMC data-type function will return a wrapper function to call.

various uses:
read:
>>> string() #'string1\x00'
'string1'
>>> string(bu8()) #'\x07string2'
'string2'
>>> string(bu16)() #'\x00\x07string3' (not much different here)
'string3'

write:
>>> string('string1\x00') #'string1\x00' (does not consider stop character by default)
>>> bu8(7); string('string2') #'\x07string2' (old method)
>>> string(bu16)('string3') #'\x00\x07string3' (automated)


you can also use the wrapper as your own data type:
>>> str16 = string(bu16)
>>> str16('string') #'\x00\x06string'
>>> str16('another_string') #'\x00\x06string\x00\x0Eanother_string'


I tried working on the last idea when I realized it's just too much work for something small to perform...
with this new idea, it's not so bad. (the easier it is to code (via level, not size), the faster it performs)

this is why I glorify single-level generators and 1-liner codes.
(it's easier for the interpreter to translate into optimized byte-code which runs faster)
as for speed and performance, that lies in the pyc/pyo files after translation which can be made pretty fast if you code it right.
(python is naturally slow so it's best to optimize wherever possible)
^ and I'm using Python2.7 which is slower than 3x (PyOpenGL runs slower on 3x)

 

[Tcll]

just recently got into a discussion about UMC's array() function and came out with a few new ideas for it
basically it follows the recursive stack idea used on string()(), you can now use array() in struct().

read:
data = array( [ bu32, [ bf32 ] ] )() # reads until [ 0, [ 0.0 ] ]
data = array( [ bu8, bu(3) ], stop = [ 255, None ] )() # reads until [ 255, * ]
data = array( bu8, stop = bu8 )() # reads until 0x## (reads the stop structure before the data)
data = array( [ bf32, bf32, bf32 ], count = 5 )() # reads 5 structures
data = array( bf32, count = bu8 )() # reads 0x## structures (reads the count before the data)

write:
array( [ bu32, [ bf32 ] ] )( [ [ 0, [ 1.0 ] ], [ 0, [ 0.0 ] ] ] ) # writes the 2 given structures
array( bu8, stop = 255 )( [ 15, 32, 255 ] ) # writes the stop structure ( 255 ), before writing the data
array( bf32, count = bu8 )( [ 1.0, 1.5, 2.0 ] ) # writes the length as 0x## before writing the data

what I'm aiming for here is full automation of reading a binary file with VERY little work on your script's end.
(everything will flow through as logic intended it)

this new idea should decrease the amount of code needed by a tad more as well,
roughly speaking, about 74% to 75% in 3.0 and roughly 66% in 3.0a when comparing a UMC script to a Blender26 script.

EDIT:
updated with better ideas for helping people understand the function:
array( settings )( R/W )

 

[Tcll]

erg... my pain is just starting...

I've just successfully ported and tested all instances of StructArr() to array()()

what's left to do:
-string()()
-struct()()
-compress()
-decompress()

-matrix functions
-bone data relation (in FORMAT.py)
-bone data verification (in FORMAT.py (called by VIEWER.py))

-header functions (redoing API.py and part of COMMON.py)

everything used is defined here:
http://tcll5850.proboards.com/thread/182/layout
if anyone's willing to help with documentation, the spot's open
(you'll need to look at my source for 3.0 for copying the info on most of the functions)
^I'm better at describing in the __doc__ rather than on my forum... heh

EDIT:
I think I'll hold off on the bone tail display until 3.0, when I'll have a better interface to deal with them appropriately...
or perhaps the later update to 3.0a

 

[Tcll]

just wanted to notify, I don't think I'll have bone tail display working properly.

I'm actually considering removing the tail functions, because all the tail does is show relative rotation and scale.
(there's nothing really needed to set the tail other than the bone's base functions)

so I've removed the bone tails and made bones easier to see

 

[Tcll]

I know, you guys are prbly all like

TC SHUT UP!
JUST LET US KNOW WHEN YOU'RE READY TO RELEASE!

tbh doing this helps me out too, being autistic and all...
my mind gathers new ideas from visuals... it doesn't work if I simply think about this stuff...
I have to post it before I'll gain new ideas from it... heh

 

[Tcll]

just wanted to note what you'll be seeing with the new script system

the console is now much more informative

Model Importers: 5
| NTDO_MDL0.py
| MMD_PMD.py
| Wavefront.py
| HAL_DAT.py
| UMC_session.py
Model Exporters: 2
| Wavefront.py
| UMC_session.py
Image Importers: 2
| NTDO_TEX0.py
| IMG.py
Image Exporters: 0
Pallet Importers: 0
Pallet Exporters: 0
Decompressors: 0
Compressors: 0
Bad Scripts: 3
| web3D_I.py
| web3D_O.py
| Blender.py

and I've also changed up the header functions a bit more...
I wasn't following a standard I'd defined ever since I first built 3.0a

I'm following that standard now:

ugeScriptType( Type )
ugeScriptFormats( 'Name', [ 'fmt' ] )
ugeScriptLibs( [ 'Library' ] )

whether or not a script can import or export depends on the functions supplied:

def ugeImportModel( FT, CMD ): # validated with a UGE_MODEL_SCRIPT type

this new setup allows for extension, ugeScriptFormats is a sub-function of ugeScriptType and can even be called multiple times for new names.
ugeScriptLibs is global to the entire script

here's a few examples: (warning, spoilers)

ugeScriptType(UGE_IMAGE_SCRIPT)
ugeScriptFormats( 'NTDO_IMG', ['tex0'] )
ugeScriptLibs(['RVL_IMG'])#revolution'])
___

ugeScriptType(UGE_MODEL_SCRIPT)
ugeScriptFormats('MikuMikuDance',['pmd'])
ugeScriptType(UGE_ANIMATION_SCRIPT)
ugeScriptFormats('MikuMikuDance',['vmd'])


yes, animation scripts WILL be allowed.
the backend interface is capable of converting animations, but the viewer just can't play them.
so while my function list lies to you, the animation functions just may end up seeing light in 3.0a

 

[pokemoner2500]

So what exactly can this do atm, what is and isn't supported

 

[Tcll]

well, as of the current moment I'm rebuilding the GUI to use at least 50% less CPU
(I'm redoing it because I broke the Tkinter file dialogs when porting the script-header functions)
^ UMC's GUI will supply the dialogs now. (the import button will actually work)

but for support, 3.0a lacks support in animations, shaders, and it's library interface.

but for what is supported, you can take a look at what functions are available on the 3.0 function layout page:
http://tcll5850.proboards.com/thread/182/layout (make sure JS is enabled or it won't display properly)
every function in red is 3.0 only
every function in green is for a future update to 3.0a (I want to get a workable version out asap)


EDIT:
as of what's currently released, I wouldn't recommend downloading it.

the scripting system wasn't exactly solid and the rendering and formatting was a complete mess

 

[David_CARP96]

I can't import anything :/
And the UMC didn't show any option, look:

I've read a bit some parts of the post, and my conclussion is maybe I need learn C (or C++, I don't know about these things =P) with Python or any C language program to make working the program (correct me if i'm wrong).
That should be cool if I can put some .fsys (Pokemon Battle Revolution) files into that and convert them to any 3DS Max format, because Distro app doesn't work for the files I want to convert...
Any help? I'm new in that :v

 

[Tcll]

that's dev 4.5 (look at the title bar)
everything you're seeing on this page uses 3.0's down-ported scripting system (which hasn't yet been released)
as of right now, dev5 currently doesn't work due to the GUI re-structure...
if you can be patient, I'm trying to get the release out asap

to import, hit Ctrl+I (as stated in the README)

also, with FSYS, you're not alone
I've already gotten a copy of ImaginaryZ's src for his converter,

for building scripts, you need to at least roughly learn how to do functions in python 2.7 (which isn't hard).
the rest is just learning the structures of things and how they fit together

I wouldn't recommend working on libraries for scripts at the current moment as the system is still very immature...
so work on them only if you have to, and try to keep them small.
(you'll need to port the library from 3.0a to 3.0)
^that should be the only porting going on as you won't need to port scripts (I can't port the library interface w/o turning 3.0a into 3.0)

again though, I'm porting the 3.0 scripting interface to 3.0a, which has muuuuuch cleaner and more-solid functions
as for docs... I'm trying to work on something, but doing so is currently beyond overwhelming, so this is currently the best I can do:
http://tcll5850.proboards.com/thread/182/layout
I intend to link all the functions to relative pages describing what they do and how to use them.

I also intend to template a script in my 2nd post on that page (marked as "reserved")


may I also note, UMC is written entirely in python, so what your running is not compiled

 

[Tcll]

first test of the GUI remake:
(I ported it so that now it uses classes instead of in-line functions)
^ makes event handling a crap-load easier and takes quite a load off the CPU



yea... there's alot to be fixed...
first thing you'll notice is that hit-defs don't resize properly...
next you'll notice the buttons have no BGs

something you won't notice by image is the gainFocus() event (hover your cursor over a widget) breaks the UI

this is all being worked on and will be fixed (and then some) by the release

EDIT:
update:

everything works so far except fonts.

what you're seeing in yellow is an active hitdef

EDIT2:
update:
finally got the fonts working ^_^


I'm a freakin ******... heh
SDL sucks because it clears the GL context on video resize, which was causing each font character to have a list ID of 0L.

what was I doing?
I had the font creation code in the GUI-init code which was being deleted by the initial window creation.
so I moved the code to the GUI-resize code.

if SDL worked properly, I could keep the font creation in the GUI-init code
this is why GLFW is better (for being as limitless as SDL in not hijacking your run-loop)

EDIT3:
just posting a little update before I call it a night

everything works properly so far except:
- bottom and top panels don't yet resize when side panels are closed
- panels are not yet hidden when options/updates are open

oh and an old issue that's been for quite a while... heh
- VIEWER controls are active while options/updates are open

but a video resize event resizes the panels properly

 

[Tcll]

just to show off I'm still working on it...

this was a bit difficult to get working, but I got it


that font in the animation panel is actually a new feature :D
before that, the GUI-layer class couldn't do multi-line fonts, meaning the '\n' character showed up as a square.

so yea, that works properly now

I've also removed the control over the animation tabs.

just take note, while I do intend to add animation support (as the SES format supports it),
once added, the viewer won't be able to display them.
(this was a huge flaw with the current viewer, and I don't intend to redo the system while I'm already redoing it in 3.0)
^ that's the exact reason 3.0a is trash

 

[Tcll]

finally working on the import dialog I'd planned since dev4


though I won't say the layout will be the same as planned...

tbh, I never really had a solid plan for the layout, so for now I'm just gonna do something very basic and keep it quite similar to Tkinter.

though the scrolled dialog for selecting your files will just be made of buttons.

it's kinda sad to realize just how pointless this update is though when everything will be ported to shaders in 3.0
(that should say something about just how simple my GUI really is)

would be nice if display lists weren't deprecated already...
but using them very inefficient on your MBd as is... heh


EDIT:
lol every time I break this thing, I keep making it better XD

my code for my UI class is getting to be a bit bulky and hard to edit, so I've decided to split up the panels...
in doing so, I broke the very framework that handles the GUI-layering...

the problem was I had to define each layer and stack before I could use it, otherwize the interface would throw a KeyError exception.
so what I've done now was automated that part and removed the limitation of a fixed order.
meaning you can do this:

layer(1).stack(0).AddQuad( ... ) # this draws last
layer(1).stack(5).AddQuad( ... ) # this draws next
layer(0).overlay(2).AddQuad( ... ) # this draws first

normally this would throw a major key-error and cause the interface to cough, even when recompiling the UI display list.
but now everything is automated and you no longer need stacks 1 through 4 or overlays 0 and 1.
all the stack does is determine the position on the current layer and draws from top to bottom. (5 to 0)

 

[Tcll]

just showing off some progress on the file dialog:

still having coloring issues after splitting up the UI into separate classes,
but I actually have a file dialog class now which I can use for both opening and saving files

and yes, the 'x' button actually works

EDIT
oh yea
by 3.0, the "Manage Model" tab will be renamed to "Manage Models".

3.0 has a backend interface which supports what I call "roots"
these roots hold the scenes of an imported 3D format, and are later intended to support full games.
(basically it's the same thing as 3.0a importing grouped SES files)

I'm not making 3.0a support that, as I'd have to redo every function in FORMAT.py just to add that small feature...
that, and I'd have to redo the way VIEWER.py reads from the import data, as well as the import and export operations yet again.
no thank you.

 

[Tcll]

ok, got everything to behave and segregated the colors into a shared theme:

everything looks much better now

btw, I'm so close to a themes extension now, I can do this:

this is a theme based off the bios from my secondary compy
(this theme will be in GUI.py near the top of the file and will be commented out in class _theme)
^ feel free to play around with it on UMC's next release

couldn't do that in the old UI w/o doing a crap-ton more work :3

 

[Tcll]

jsyk guys, if anyone is wondering what I'm doing, I'm working on a function in UMC3.0's API-externals to return the names of the variables a called function returns it's data to.
https://copy.com/StUO1g4m7gwuQyiD

this would be useful for struct() for renaming the sub-class based on the var-name

it would also be useful for UMC_SIDE, for highlighting the variables holding a UMC/UGE data-type:
bigfloat5 = bf(5) # 'bigfloat5' would be highlighted wherever used.

note: the color of bigfloat5 would be dependant on a hash value of "bf_5" which is the internal class returned by bf(5)

anything sharing this will be highlighted that color


as for 3.0a, I'm currently asking Ian if he knows any tricks to pull off a scrolled widget box.

my autistic brain won't let me think of a low quality method w/o shorting out and trying to make it high-quality,
otherwize I'd probably have some actual progress done on the UI... heh

my brain won't let me work on the import panel either w/o pounding at the inside of my skull to try to work on a method for the scrolled widget box.
(not joking there, it actually hurts when I try to concentrate on something else on the UI topic)

so yea... I currently can't touch the UI until I get somewhere with that particular widget >3<

 

[Tcll]

just in case anyone's been wondering I've gotten an idea for the widget, but everytime I try to work on it, I get a migrane just thinking about what needs to be added (which really isn't much)...

so I've been taking a short break to let my brain cool down in that area and decided to work on an update to my DAT template:

basically, I've ported the pathfinder logic from my UMC script and redisigned it to work with HexEdit (since HexEdit doesn't support dictionaries)
the port hasn't been going too well as it currently takes ~2 minutes just to gather the structure sizes in a 37KB file. >_<
I've tried to cut down on my <eval> tag usage as much as possible, and that's as good as I could get it so far...
it freezes with anything tested above 80KB

and seriousely, this is just getting to the root structure... I havn't yet implemented the logic that deciphers the data...
this is the only gripe I have about HexEdit is how slow it is >_<
other than that it's better than 010 Editor...

though I've gotten together with a friend who's updating my DAT page with what I've missed, as he's another noob following my path who I'm helping to get up to my level.
anyways, his edit mentions a page which mentions HexWorkshop...
I've looked at the screenshots and am skeptical about if it supports templates which can highlight data like I'm doing in HexEdit.
if it can, I might switch if the program's free or cracked.


so yea, I'm taking a short break, but I'm still doing what I do best! ;D

 

[Tcll]

and thus finally, the part of UMC's GUI that gave me migranes just by looking at the unfinished class for the widget:


why?
cutoff and cutout
cutoff is for the layers above this scrollbox's layer
cutout is for the layers under this scrollbox's layer

for example, I will be drawing scrollboxes for the widgets of the model panel
the box visuals will not be drawn on the layer of the model panel
instead, it'll be drawn above, meaning the model panel won't be stenciled out.
as such, we need a cutout quad positioned on that layer:

----------scrollbox----------

-------------------flatten-------------------

------scrollbox cutout-----
---------------model panel---------------


the cutoff is for the widgets in the scrollbox, including scrollboxes on another layer

EDIT:
I will work on the transparencies and such before the release, because I know everything is currently a bit difficult to see.

EDIT2:
fixed up the colors and added a scrollbox for the tree-view area (like using Windows Explorer)

 

[Tcll]

just wanted to mention, I've picked up UMC_SIDE again and gave the hex viewer a small makeover:

looks a bit more familiar now huh :3

now that I overlook it after modifying a crummy game engine to be somewhat of a Nexuiz clone,
and redesigning UMC's UI with a similar method, my old code really isn't all that dirty... heh

UMC_SIDE, or SIDE for short, can't be distributed with 3.0a unfortunately as the interface is almost completely incompatible.
SIDE gets it's functions (shown in the left for reference insertion) directly from 3.0's interface and even uses them from there...
the imported file you're seeing in the hex viewer is actually the returned data from UMC 3.0's API

so what made me pick this old program up again?
HexEdit can't handle the pathfinder method I need to view the data structures in the file, so I'm working on SIDE and UMC 3.0 to get the data interface working.
I'm using the exact script from 3.0a to actually parse the file data, though there's alot of hanging wires I need to fix before I'll be able to show off the data highlights.

in any case, I'm saying screw you to HexEdit and building my own free hex viewer
but this isn't just for me, this tool is designed for noobs, to help them visually understand as much as possible and build scripts for UMC.

just keep in mind guys, I really don't know what I'm doing when I build this stuff...
I just do it cause it's where I have the most fun
and I have even more fun by sharing my works with everyone. =)

I mean what else can I say...
complexity == fun

so yea, about the fact I know nothing...
my mind logically puts stuff together, so actually I do know alot, but not in the sense that everyone takes knowledge for...
it's wierd to explain, but I literally learn just by my brain getting ideas from something I see, and deciphering the logic behind it.

to add, I can't read math... I failed at pre-algebra 3 times only because I was slow to finish my work.
my teachers didn't grade me on being able to find methods so simple that they couldn't understand them,
but because school and life made me incapable of finishing my work.

I'm not letting life get the best of me with UMC/UGE though.
it's just that this stuff is extremely complex, and I've never even been to college, let alone taken a geometry class.
so yea, I'm not the god of all knowledge when it comes to this stuff... heh
but this stuff is extremely tedious and I still don't know half the stuff I need to know to do what I'm doing.

that's why 3.0a is trash, even though I'm still working on it and hope to have a release as soon as I can finish this dang GUI... lol
I still have a few more complex widgets to build before this thing will be able to open files again... heh
again though, this release is only to allow everyone to develop UMC Scripts and probably some rough UMC Libs that can be dragged over to 3.0 whenever it's released.

and after I finish the GUI here, I get to have fun porting the entire thing to GLSL for 3.0... heh

and if that's not enough, I'm also designing UMCSL, perhaps for UMC 3.1

^alot of this stuff has been completely changed, and this interpreter was lost to a RAW HDD a while back
UMCSL thread: http://tcll5850.proboards.com/thread/271/umcsl

what this will actually do is...
UMCSL is a conversion language between code and ASM and is designed to provide ways to identify structures in ASM and decompile, or even recompile it.
the language itself is dynamic, but a types system is in the works to deliver a static pointer system in it's own virtual environment.


sorry for rambling, it's 3AM for me and I can't help my brain at those hours

 

[Tcll]

well, for some newer info, I've decided to play around with GLFW by designing a new interpreter for UMCSL,
and at the very least, got a working window out of the deal :D

it's nothing too grand, but... it's something:

^GLFW can do everything SDL does, and handles your input events much more efficiently, while giving you top-level control over the window.

SDL also deletes your GL context upon a window resize, where GLFW is more like freeglut and doesn't
(meaning now you'll see your window update while you're dragging the corners or edges, unlike SDL which updates after you release).
^ this is because, with SDL, you need to re-create all of your display lists, where with GLFW, you can continue using your old display lists.

also
unlike the last interpreter (last post), this one will actually BE an editor.
I'll be porting my hitdef and layer systems from UMC's GUI, which won't be too much work

but with that, I'll be able to design the node classes, and actually use a proper font instead of a bitmap... heh


I'll get back to UMC's GUI, don't worry
my mind just wants to work on all 5 of my largest projects at once, and is even getting more ideas for my smaller projects such as my Nexuiz clone.

Yes, I have yet another large project I havn't mentioned yet...
it involves something similar to setting minecraft as your desktop environment,
but with your windows (such as Chromium) displaying in 3D space.

these 5 projects aren't really a difficult task other than the ones using GLSL as they're all done with the same knowledge and interfaces.
that should tell you guys something about how powerful my interfaces really are

one reason my code is so powerful is because I don't follow pythonic standards.
another reason is because I look for the most efficient ways to do what I'm doing (more-so now than back then).

I try to visualize the entire logic of my code before I write it down, and try to make it perform in as little steps as possible.
(because with python, 1 step is about ~100 steps for your CPU)

the pros like to disagree with me and recommend the slowest of things for the sake of readability.
I on the other hand, just use comments, which is what every programmer should be using.
but last time I talked to the pros, they look at commenting as an inconvenience, and like to call your code bad simply because of it.

hopefully the way I do things will make them re-think their standards, because they're mis-leading a bunch of people with false beliefs.

 

[Tcll]

finally got somewhere, and am slowly getting closer to a decent UI! :D



in the last images, I defined the Browser widget (this was stupid)
so I split the entry and button widgets apart and got the entry widget working
it doesn't handle keyboard events just yet, and might not by the release...
the UI will work better as I make my final updates to 3.0a

note: the word "final" is speaking for 3.0a only.
I've been wanting to scrap 3.0a for some time due to it's poorly designed interface...
3.0 is the upgrade with a crap-ton better support for everything.

3.0 won't be around for a while, so this next release of 3.0a was re-designed with 3.0's frontend script support.
(the backend is still the same)

what this means is you can now write a script for 3.0a using most of the functions from 3.0
(3.0a is not capable of supporting certain specifics that 3.0 supports, such as file-data pointers and transformations)
^ 3.0a supports bones and weights, but everything is displayed as-is, unlike 3.0 which displays a validated and pre-computed result of the supplied data

3.0a is straight-forward (script-supplied conversion)
3.0 is complex verification (backend conversion)


>.>
looking at those standards now, I'm wrong about 3.0a's code usage compared to blender26
3.0a just handles the file data for you, and automates the model formatting process.
in 3.0a, you have to convert the data to the backend standards.
in 3.0, you can just pass most of the data directly to the backend (specifying where it goes)

so really, 3.0a only gives roughly a 45% code cut from a blender26 script
(in Blender, you have to tell the backend what to do, in UMC, it's fully automated/interruptable)
^ though in 3.0a it's fixed standards, 3.0 loosens that up depending on which buffer you fill


EDIT:
and here's the result of that entry widget


now I just need to work on the select box widget so I can have the file-filter selection... heh

 

[Aelo]

Definetely interested in this project as a whole. It looks too complex but at the same time it looks very interesting. I'll have to read through the entire thread from the begining to even try to understand whatever is happening here and what you are developing, but I'm glad the community, and the boards, have people so dedicated to what they like that they can post content constantly with updates about a project trying to give fellow modders more tools to edit and customize such a great game. Amazing work and definetely keep it up!

 

[Tcll]

Thanks! =D

UMC is actually meant to be simple to understand, it's developed for noobs to use
though that reputation has yet to really make it's mark... heh
(I can only attempt at so much major work which takes forever to pull off)

 

[Tcll]

finally getting somewhere:


sorry this simple task is taking so long...
it's not hard at all, I know exactly what I need to do...
though I do have a lack of knowledge on proper structuring which could make writing these widgets much easier >.>

but yea, it's not hard, it's just freakin tedious >_<
GUI.py is already roughly 80KB in size, primarily because of my layering system and UI classes.
the rest of that is the widgets and other small codes such as the init, event, drawing, and recompiler codes.
(the recompiler deals with compiling the GUI draw data into display lists which reduce frame-lag)

what I have running now would have lagged ballz on dev4.5's code
but now there's little to no lag

I havn't tested this on my secondary yet, but it should run more than well :D

 

[Tcll]

starting to look more like a legit file dialog now


and oops, I messed up with the text and used the widget names... lol
that's a simple fix

 

[Tcll]

fixed up a few things and am currently working on the item buttons for these scrollboxes

that new addition is what should be expected, a directory entry with a back button.
it's meant to be a mix of linux and windows browsing styles, so it should be easy to pick up.