Universal Model Converter - Side Development Thread

[Tcll]

well...
progress is finally coming along on the new GUI scheme, and the results are amazing! ^_^

the management is working perfectly:
performing operations of adding, modifying, and removing data only when needed.

a very small amount of positioning calculation is done per frame...
though this is only for pre-positioning and verification calculations.

still not quite finished though as I have about 40 calculations performed per frame which can be done once per video_resize.
(though really there's about 150 calculations performed because of functions with multiple calls)

that aside though, the performance rate is about 50FPS at least

so once I clear up these pre-calcs, you can expect a high FPS in the release. :D



EDIT:
moved the precalculations to a resize function...

however... due to some minor issues with this, the GUI system is now like SDL in that it needs to be cleared and redrawn with the proper positions when resized...
(some portions don't correct themselves unless the data is cleared)

but now the 98% disabled math calculations I mentioned before has finally taken it's place...

I just have to finish porting the rest of the GUI and get font-textures working properly...

 

[Tcll]

Total expected progress by release:
|||||||||||||||||||||||||||||||||||||||||||||||||| : 22%

module colors:
orange, can be expected by the release
green, can be expected shortly after the release
gray, the module will have another major overhaul done.
if the main progress bar that's gray, it's just outdated

Spoiler: Current Progress on things:

UMC bases:
VIEWER: the OpenGL, OpenCL, and SDL interface
|||||||||||||||||||||||||||||||||||||||| : 37.5%
COMMON: the general script verificarion and function routing interface.
|||||||||||||||||||||||||||||||||||||||| : 0%
FILE: the file management and data handling interface.
|||||||||||||||||||||||||||||||||||||||| : 70%
FORMAT: the internal data formatting interface
|||||||||||||||||||||||||||||||||||||||| : 15%
GUI: the fully featured Smart GUI interface (UMC access only)
|||||||||||||||||||||||||||||||||||||||| : 40%
WIDGETS: the GUI interface for scripts
|||||||||||||||||||||||||||||||||||||||| : 0%
CONFIG: UMC's configuration interface (UMC access only)
|||||||||||||||||||||||||||||||||||||||| : 0%
UPDATE: manages script updates (UMC access only)
|||||||||||||||||||||||||||||||||||||||| : 0%

UMC libraries:
the Minecraft library (MCNBT.py)
|||||||||||||||||||||||||||||||||||||||| : 0%
the Nintendo SDK library (Dolphin.py)
|||||||||||||||||||||||||||||||||||||||| : 0%

UMC scripts: (need to be updated)
UMC Session script
|||||||||||||||||||||||||||||||||||||||| : 0%
Blender Session script
|||||||||||||||||||||||||||||||||||||||| : 0%
MCE Schematic script (not using the library)
|||||||||||||||||||||||||||||||||||||||| : 22.5%
SSBM model import script (not using the library)
|||||||||||||||||||||||||||||||||||||||| : 75%
FSYS model import script (not using the library)
|||||||||||||||||||||||||||||||||||||||| : 5%
MDL0 model script (not using the library)
|||||||||||||||||||||||||||||||||||||||| : 15%
MMD PMD model script
|||||||||||||||||||||||||||||||||||||||| : 10%
Wavefront OBJ model script
|||||||||||||||||||||||||||||||||||||||| : 7.5%
Steam BSP model script:
|||||||||||||||||||||||||||||||||||||||| : 0%
Ntdo Anim Pack1 script (what brbx supports)
|||||||||||||||||||||||||||||||||||||||| : 0%
SSBM DAT Anim script
|||||||||||||||||||||||||||||||||||||||| : 0%
BMP image script
|||||||||||||||||||||||||||||||||||||||| : 0%
PNG image script
|||||||||||||||||||||||||||||||||||||||| : 5%
TIF image script (pending)
|||||||||||||||||||||||||||||||||||||||| : 0%
JPG image script
|||||||||||||||||||||||||||||||||||||||| : 0%
TGA image script
|||||||||||||||||||||||||||||||||||||||| : 0%
TEX0 image script
|||||||||||||||||||||||||||||||||||||||| : 2.5%
TPL image script
|||||||||||||||||||||||||||||||||||||||| : 0%
zlib compression script
|||||||||||||||||||||||||||||||||||||||| : 57.5%
LZ77 compression script
|||||||||||||||||||||||||||||||||||||||| : 0%

UMC Externals:
UMCSIDE: the IDE for UMC Script development
|||||||||||||||||||||||||||||||||||||||| : 32.5%

UMC Future implamentations: (sub-programs)
UMC Game Script Editor: Images
|||||||||||||||||||||||||||||||||||||||| : 25%
Dynamic Mesh sub-system: (my replacement for NURBS) Images
|||||||||||||||||||||||||||||||||||||||| : 0%

@mods: ----- post split here plz ----- (it's lagging)

Spoiler: UMC's functionality

UMC comes complete with Python 2.7.5 x86 and x64 installations with the supplied modules:

Python x86:
- PyQt
- PyOpenGL + Accelerate (havn't tested unofficial release)
- GLEWpy - Advanced OpenGL (can't build on my system)
- PyOpenCL (havn't tested unofficial release)
- NumPy

Python x64:
- PyQt (acquiring x64 installation)
- PyOpenGL + Accelerate (havn't tested unofficial release)
- GLEWpy
- PyOpenCL (havn't tested unofficial release)
- NumPy (havn't tested unofficial release)
^ (don't have x64 builds)

Shared Packages: (just .py files)
- [ I ]Python (with PyReadline)
- LiveCoding
- ArcBall (for PyOpenGL)
- PyStream - Python Shaders (trouble with installation and usage)

as you can probably tell, I don't have a 64bit system,
so if you guys experience any issues with x64, I'm going to need details.

Spoiler: Bin: Suggested Scripts to add:

this bin is for suggested model/animation/image/compression scripts you'd like to see in UMC.

NOTE: these scripts are for anyone's taking...
if you'd like to contribute to developing one of these scripts,
please let me know and I'll add you as the title-holder for that script.

- 3DS model script - open
- XML library - open, Tcll (if no takers)
- DAE model script - open, Tcll (if no takers)
- VRML model script - open, Tcll (if no takers)
- DirectX model script - open

(some scripts may not be able to be developed until the release of dev5)

if you wish to not hold the title for a script anymore,
then please let me know, and I'll remove you.
(for whatever reasons you may have)

as always, if you have any ideas for new implamentations, feel free to share.

 

[Tcll]

new poll: http://forums.kc-mm.com/index.php?topic=54619

hello everyone, and welcome to the new and improved development thread.
the old thread just contained too many bad memories for me, but you can still view it for history:
Universal Model Converter (UMC) Development Thread - Deceased

Universal Model Converter (UMC)


is a tool used for converting models from any particular format to any other particular format.

UMC is written entirely in Python 2.7.5 and distributed with it's own interpreters
which makes the development as Open Source as it can get. ;D

UMC itself doesn't support anything other than it's own SES format.
UMC's compatibility with 3D models comes from the scripts and libraries built for it.

scripts are basic plugins that add compatibility to simply convert from one format to another.
(this includes formats for various models, animations, images, and compression methods)

libraries are a more complex interface built for scripts,
and allow in-depth handling of data between the script and UMC,
as well as the ability to rebuild and redraw UMC's internal data in real time.

Spoiler: New features to be expected by dev5:

Official Release: (console only)
- an improved file handler with advanced model and animation export options.
- a working animation system

Additional Modules:
- VIEWER:
-- much better viewing control
-- joystick support (maybe)
- GUI: (loaded by VIEWER)
-- a fully featured, functional GUI- a more improved modeling interface
-- data modification operations (Normal Generation)

Spoiler: Building Scripts for UMC:

I won't clarify on things here
as I've already written documentation (included with UMC) to do that for me.

UMC makes writing scripts extremely simple
as it's functions do all of the hard work of file handling and formatting for you.
all you have to do is convert the data your given from the file
into a format easily handled by UMC's formatting functions
or vice-versa and get the data recieved from the formatting functions into the file.

UMC does the rest of the work of managing the 3D data for you

as of dev5 UMC's formatting functions have undergone a complete overhaul...
the functions are still being worked on, but you can see most of them here:
UMC formatting functions

Spoiler: an update:

Pre-Transformation Functions:

Spoiler: an update:

Bones:

----Set:

-ugeSetPTBoneLoc.....( float/(list/tuple), float, float )
- ugeSetPTBoneLocX...( float )
- ugeSetPTBoneLocY...( float )
- ugeSetPTBoneLocZ...( float )
-ugeSetPTBoneRot.....( float/(list/tuple), float, float )
- ugeSetPTBoneRotX...( float )
- ugeSetPTBoneRotY...( float )
- ugeSetPTBoneRotZ...( float )
-ugeSetPTBoneSca.....( float/(list/tuple), float, float )
- ugeSetPTBoneScaX...( float )
- ugeSetPTBoneScaY...( float )
- ugeSetPTBoneScaZ...( float )
-ugeSetPTBoneBindMtx.( list/tuple )
-ugeSetPTBoneInvMtx..( list/tuple )


----Get:

--ugeGetPTBoneLoc.......() >>> [float,float,float]
-- ugeGetPTBoneLocX.....() >>> float
-- ugeGetPTBoneLocY.....() >>> float
-- ugeGetPTBoneLocZ.....() >>> float
--ugeGetPTBoneRot.......() >>> [float,float,float]
-- ugeGetPTBoneRotX.....() >>> float
-- ugeGetPTBoneRotY.....() >>> float
-- ugeGetPTBoneRotZ.....() >>> float
--ugeGetPTBoneSca.......() >>> [float,float,float]
-- ugeGetPTBoneScaX.....() >>> float
-- ugeGetPTBoneScaY.....() >>> float
-- ugeGetPTBoneScaZ.....() >>> float
--ugeGetPTBoneBindMtx...( *UGE_MATRIX_TYPE* ) >>> list
--ugeGetPTBoneInvMtx....( *UGE_MATRIX_TYPE* ) >>> list


Meshes:

----Set:

-ugeSetPTVertArr.....( list/tuple )
-ugeSetPTNormalArr...( list/tuple )
- ugeSetPTBiNormalArr( list/tuple )
- ugeSetPTTangentArr.( list/tuple )

--ugeSetPTVert.....( (float/int)/(list/tuple), float/int, float/int, float/int )
--ugeSetPTNormal...( (float/int)/(list/tuple), float/int, float/int )
-- ugeSetPTBiNormal( (float/int)/(list/tuple), float/int, float/int )
-- ugeSetPTTangent.( (float/int)/(list/tuple), float/int, float/int )


----Get:

-ugeGetPTVertArr.....( int(dimention=None) ) >>> [ [X(,Y(,Z(,W)))], ... ] #dimention=3: [ [X,Y,Z], ... ]
-ugeGetPTNormalArr...() >>> [ [X,Y,Z], ... ]
- ugeGetPTBiNormalArr() >>> [ [X,Y,Z], ... ]
- ugeGetPTTangentArr.() >>> [ [X,Y,Z], ... ]

-----ugeGetPTVert........() >>> [X(,Y(,Z(,W)))]
-----ugeGetPTNormal......() >>> [X,Y,Z]
----- ugeGetPTBiNormal...() >>> [X,Y,Z]
----- ugeGetPTTangent....() >>> [X,Y,Z]


Description:
the usage of these functions is no different from the original functions...
the difference with these functions is the buffers they access.

when importing a model, once finished,
the data has to be untransformed (or pre-transformed) by the model's bones
in order to properly animate the data.

the pre-transformed data is stored in the pre-transformation buffers,
which are accessed and re-transformed by the animation system. (transformed with new coords)

to describe the real usage...
Nintendo's formats are already pre-transformed to them easy to load directly into their XF buffer.
the buffer, once filled, can then work with transforming the data as needed, on a fast-paced level.
(their XF buffer == my pre-transformation buffers)

^the functions make it easy to send and recieve formatting data to and from UMC.

I don't have the data functions defined online yet, but they havn't changed much since dev4
(the only thing that's changed is file handling with multiple files (including the usage of temporary files) )

I don't think archive scripts will be fully supported yet by dev5 :/
however various compression methods (such as zlib compression) will be


animations are in the works and are being implamented through OpenCL.
(I'll need some C++ experts to help me out on this)

I do have some animation functions defined,
but they're not included in the functions above as they're not complete yet...

Spoiler: Building Libraries for UMC Scripts:

as I've mentioned above, Libraries are ment to work for Scripts,
and provide simple functons for a specific type of file formatting technique.

Libraries are for advanced programming for UMC,
which is why they're allowed to modify UMC's internal data.
(this goes for the data already imported in UMC)

UMC is still in it's development stage...
you can be sure to expect minor to major interface changes.
currently the GUI is ment to be functional, wich is simply ment to work...
I'll be sure to pretty it up the by the official release.



updating scripts wil also be available by th official release...
for basic users:
you will be able to update existing scripts and download new scripts.

libraries will be downloaded and updated if a script calls for it.


for script developers:
you wil be able to upload and update your scripts as expected.

if your script uses a library, it will be uploaded with your script.
(you may choose wheather you want to update user-libraries or not)

For updated links, see the official thread:
http://tcll5850.proboards.com/thread/144

 

[Tcll]

@Moderators:

feel free to edit my posts above if you happen to find any grammatical errors,
or know how to state something better.

when editing: DO NOT USE THE RTE! (Rich Text Editor)
the RTE has caused many problems for me and being able to edit my posts.

any multi-line block of text between text formatting BBC tags will have those tags applied to each line in the block.

for example:

these 5 lines put into the BBCE:
[size=4][color=white]line1
line2
line3
line4
line5[/color][/size]


then edited with the RTE:
[size=4][color=white]line1[/color][/size]
[size=4][color=white]line2[/color][/size]
...
[size=4][color=white]line5[/color][/size]


then edited again with the RTE: ([code] sections only)
[size=4][color=white][size=4][color=white]line1[/color][/size][/color][/size]

^ that was a pain to type in D=
(let's not forget I'm on wii)

the BBC tags do have an order, but I'm not sure of which one's prioritize the others...

this BBC formatting order will be applied to each line of text in the block.

 

[Tiberious]

Umm, will the Pokémon Battle Revolution converter be of any use to you in figuring out the format for weighting and possibly bone information?

 

[Tcll]

perhapse...
I guess I could add a script to my project list...
but keep in mind, I'm working on UMC itself, a few scripts and libraries (for models, animations, images, and compression methods), and a few other things that are involved in UMC.


I'm only just one person, so while I may add it, it will take a while to get done.

EDIT:
I will be adding my projects for UMC to the progress list in time.
(I'm only on a wii, and the post is already starting to lag when I type)


EDIT2:
I forgot...
PBR models was requested for me to work on over at KC-MM...
so yeah, I'll add it

 

[Tiberious]

Alright, so this link is what you'd want. It's got source in it, I'm pretty certain.

The only issues at the moment are:
1) Some models only come in partially. I'm pretty sure this has to do with some being multiple objects, and this only extracting the first one.
2) It doesn't get bones. I'm almost positive these -have- armatures, but the creator didn't seem to think so.

If you can figure out how to fix either of those two problems, I think you'll have something better than even Pharrox had before he dropped off the 'net.

 

[Tcll]

thanx...

from what I've heard... it seems to use vertex animation...

the up-side of this is the mesh size is smaller as it wouldn't need bones...
(though maybe they do for positioning the model like TopN in Brawl)

but the down-side is the keyframe has to store basically a copy of the vertex data with new positions... >_>
(animations having the same keyframe positioning can be larger)


as an added operation (for other uses) in UMC.
you'll be able to convert a bone animation into a vertex animation.

converting a vertex animation into a bone animation will take some work, but it's possible, though a little loose...
(too many loose ends open for inaccurate data errors)
^ though could probably be easily managed in ways I don't know of yet


EDIT:
also, models from Kirby Air Ride are in almost exactly the same format as Melee models...
their structure starts out differently though, but it's being looked into...

I'm simply looking into KAR because I want my slick-star for a test-game I'm intending to make.





this post is completely OT from my last.
please don't bamf me for my multi-posting...
(editing the main post now laggs on my wii)

a little info about the libraries I'm working on:

- UMCSES: the library for handiling UMC's SESv1 and SESv2 formats.

the only use for this library is small scripts (from the previous and future history of UMC's SES format) and easy data access.
FORMAT has basically been scrapped and redone since UMC dev4.
VIEWER has drastically changed as well.
(this library will handle old data properly)

UMC now uses class-dictionary instancing for the data structures...
(instead of the old (slow) method of structred single list interfacing done though structured multidimentional indexing)

the new sub-system means the SES will have to be built from the class heirarchy when it's saved...
(the data is scattered about in UMC for faster referencing via direct interfacing)


- Dolphin: the global Nintendo format library based off the RVL_SDK.
(the library should support features back from the NES, all the way to the WiiU, including the hand-helds back from GBC)
^ IDK if the original GameBoy was implamented with the SDK.

using the library should be almost exactly like using the actual SDK.
though my knowledge in python of using class-method decorators and other stuff really needs work...


- MC_NBT: the global library for handling RAW Minecraft NBT data.

this library contains an extra feature which will turn an animated model into blocks.
(I hope to get the lighting accurate so it looks just as it would in MC.

if a model size goes over the 256 block height limit, a warning will be displayed.
(you can continue with the export if your MC can handle the data)
^ I use the old JAR updater, so mine can't... (because I don't pay for software)






EDIT: UPDATE!
finally got the script updates section to open and tab between the options section like I want.

the GUI layout is finally looking alot more professional now. [/color]

 

[Tcll]

just wanted to verify something...
the PBR converter came with an fsys file yes...
but I'm also concerned about the output format... (.obm)

the OBM format seems to be similar to the OBJ format...
it supports most of the common obj tags...
but then there are other tags such as 'ft', 'fc', and 'ff'...

is this format known??
apparently there's a blender script built for it...
but I'm not sure if it was built by the same person...

if the format is not known, then I won't add it to the wavefront script...


a quick google search turns up that the format is unknown...
but that could be previous history getting in the way of new history...


EDIT:
looking closer at the format...
fc seems to stand for 'face color'
ft seems to stand for 'face texture' (image directory)
ff seems to stand for 'face format'

these don't seems to be structured as a common wavefront format:

ff v/n/t/w (vertex,normal,texture, weight? (not sure) )
fc 255 255 255 255
ft /*.tga

ft can be handled almost similar to the mtl file...

also...
f indecies start at 0 instead of 1


I guess the remaining Q (if I could edit my poll) would be...
do you guys think I should support this format??

 

[Tcll]

ANNOUNCEMENT:
a new feature in COMMON which may or may not be released by dev5:
(I've only just now thought of this)

this feature is aimed at script writers...

you will now be able to use pointers.
this will work like C, but not in the same context...
relax, it's simple

s = 'string'
p = pointer(s)
r = p
if r.pointsTo(s): r.set('new string') #printing s should output 'new string'

I do not fully understand pointers...
but from looking at other srcs, I think this is how they work.
PLEASE CORRECT ME IF I'M WRONG BEFORE IMPLAMENTATION


EDIT:
well...
I've just had some experts over at StackOverflow tell me that this wasn't possible...

however...
knowing my rep, I'm not the easiest one to give up w/o trying something first >_>

 

[A6M Zero]

Edited. Apparently I'm not allowed to ask that.

 

[Tcll]

may I ask for some input on theme design?? :/
(you can follow UMC's album to get an idea of the layout and how far I am in designing it)

sure I'm coloring the GUI, but building a theme for it is a completely different section...

EDIT:
although the resent GUI img draws one platform over another...

some new info provided tells me how to:
1: draw the model
2: draw the BG panel
3: draw the FG panel with no color influence from the BG panel...

meaning I'll only have a single alpha to set,
instead of having to precalculate the differences between 2 alphas with the results nearly how I want them...

 

[Tcll]

just so you guys know...
I'm going to be adding a script suggestions bin to the main post...

if anyone would like to suggest a script for a model/anim/image/compression format to add,
please let me know and I'll add it to the bin...

alternatively...
since this is a free bin for anyone to take from...
if you'd like to call a position on development for a script,
let me know and I'l place you as a title holder for that script


the bin is not just for me to get to...
like I said... it's open for the taking...
(you can't expect me to work on every interface now can you...)

anyways... hope to see some suggestions soon :3

 

[Tcll]

oh comon...

a whole forum full of people who have been eagarly awaiting for this opportunity (or so it seemed) to tell me what they want UMC to support,
and when the opportunity finally arrives, nobody wants to take it... D=
what is this nonsense... :srs:

EDIT: yes... a multi-post... whatever...
wouldn't happen if people actually replied -.-*


I'm starting to want to quit working on this thread honestly and just continue working with no tips or suggestions... =3=


EDIT2:
you know what... screw it...
I'll keep updating the thread...

if nobody wants to reply, give me tips, make any suggestions, or give me any feedback of any sort,
then that's their fault if they don't like some of the features I've put into the release.


so... whatever...

I'm going to resume the positive approach from here-on...

 

[Tcll]

just wanted to let you guys know...

I've just thought of a MUUCH better method towards handling the GUI interface more properly and efficiently...

and it's so simple too, yet extremely complex to perform

currently the GUI fills a buffer whith it's widgets, draws them, and then clears the buffer for the next frame...

the new method will simply modify the data in the old buffer instead of clearing it...

the downside...
I have to scrap my current GUI module entrely... =(

the upside...
the math calculations performed for each widget is what caused the lag...
98% of this will be disabled when you're not doing anything.
at the highest most, when you are doing something, 60% of the calculations should remain disabled.

to add, widgets will only have to be added to the buffer once,
and will be added only when needed to even greater improve efficiency.

this will take a while to build...
resetting the GUI progress now.


EDIT:
btw, NBT support will be enabled in UMC...

I'll try to add NBT support to SESv1...
(I have an idea on how to add it)
but if I can't, then saved sessions won't be able to remember NBT data...
(you'll have to re-import)

 

[Tcll]

oh yea...

if anyone would like to help out:

I'd like to do a little something for the Minecraft library...
but I can't really go into minecraft and start on this myself as I'm busy enough with UMC's GUI and FORMAT sub-systems...

what I need is a 255 x 255 x 255 color cube (or table) as a schematic file.

but the part that gets tricky is the blocks used for the color table...

these blocks must not:
- not be a full cube (such as cacti, chests, redstone, or sugar-cane)
- have any physics applied to them (such as water or sand)
- have a different color on one (or more) of the faces (such as wood (not planks)), Pumpkins are OK as they can be turned around via the block data
- be affected by outside sources (such as dirt or ice)

if you can't see how this is going to work yet,
the block index (X,Y,Z) is going to be the color that block imitates.
( R=X, G=Y, B=Z )

or to better explain the function...
BlockFromColor( R, G, B ) >>> ( BlockID, BlockData )

so all I need is the block table to match the input color.
if someone could work on that plox, I can do the rest

EDIT:
if there are other special-case blocks such as Pumpkins, please let me know before sending the schematic.


EDIT2:
I guess I should also note Minecraft likes X,Z,Y instead of X,Y,Z...

meaning Z is height and Y is depth (or length)

 

[Tcll]

well guys...
IDK weather to explain this as good news or bad news...
(it's kinda both)

I've just recently stumbled across a module for PyGame/PyOpenGL which does everything I was previously working on and more...

Albow give's PyGame/GL a complete widget interface to work off of...
though it hijacks the SDL/GL run-loop...

meaning about 30% of the code in VIEWER is now scrap, and GUI is now completely scrap.

though I won't have to add not nearly as much code to get the thing working again

 

[Tiberious]

I'd say go ahead and use this new module, but feature-freeze the UI/viewer development after you get it to functional state or close to what was in dev4. That will give you more time to work on the model format conversions for the next version.

Remember, as far as I can tell, you're the only one working on a public Melee converter, and I'm hoping this will be every bit as good as BRRES Viewer for the Melee format.

 

[Tcll]

heh...
well first off, the switch from GLUT in dev4 to SDL (PyGame) in dev5 has forced me to scrap the entire command interface...

SDL was much more loose and allowed for much better control over user events on that end...

meaning commands that didn't work before, such as Ctrl+1 (back view) now work perfectly.

the new FORMAT encoding with the PT buffer (the new functions in the first post) forced me to scrap all the model generation functions as well as UMC's old model buffer...

and as I've just recently found out,
Albow isn't exactly what I want...
it draws to GL using pyg surfaces which are drawn using glDrawPixels()

meaning that with the 20 to 50 widgets this thing has to keep track of,
it really throws a large rock into the performance side of things...

so I've done some research and found SPG (Simple Pygame GUI) which actually mentions a "proper widget order" which caught my interest...

on the front page, it also draws using pyg surfaces,
but I'm asking some Q's to see if it'll work with GL polygons.



and truthfully, brbx has far exceeded Kentalin's BRRES viewer,
but I want UMC to function more similar to Blender24 with Blender26 compatibility.



EDIT:
I must thank you though...
getting caught up in the GUI development has kinda shoved aside the rest of UMC's works...

I guess I could work on a dev5 pre-release without a GUI, and just re-implament the commands from dev4 until the GUI is finished

dev5 is ment to work w/o it's GUI module anyways XD

truthfully, all you'll really need to keep dev5 running is VIEWER, COMMON, and FORMAT...
though I guess I could bring that down another level and bring back the 2x console operations if VIEWER isn't present

 

[Tiberious]

Well, I say BRRES Viewer because I haven't actually had -any- success with the exported .dae files put out by BrawlBox. Even Noesis won't load the files it writes, and that's really bad. At least the files BRRES Viewer exports to can be loaded, even if it's only to Blender 2.49.

 

[Tcll]

well I can't say you're wrong there :/

they work with 3DS and Maya only so far as I know...
I've reported the blender-texture errors...
though you might want to report the error in Noesis to BJ.

also...
when importing a DAE into blender, use Blender26.
it's importer works with any DAE version (1.3.0, 1.4.0, 1.4.1) and also supports animation.

though animation data and model faces will be lost if opening .blend(26) in blender24.
I don't think materials are lost

or you could even export a .3DS from 26 and import into 24


in my blender script,
I'll be supporting both blender24 and blender26 (24 as default).



EDIT:
also... I'm working on some professional-looking documentation (finally) which explains everything in dev5.
it also gives the credits, and explains my Auto-Dynamic Mesh system.

the system was ment for rendering games, but now it's scrapped and being worked on simply for HQ model development.
(scrapped because I've got a much better system in the works)

another note, unless you have an alienware, this system wasn't ment to run using binary.
(I expect it to lag even on alienware)

 

[Tiberious]

Nope. Blender 2.63 also fails importing the .dae files.

 

[Tcll]

ROFL aside from brbx XDD
I did mention brbx only works with Maya and 3DS.

I did report the issue to BJ and got slapped in the face for it

 

[Tcll]

well...
time to make an announcement I guess...

UMC is going on break until I can figure out how to properly design the dual-shared-buffer formatting interface...

until then, I'll be working on my Auto-Dynamic Mesh (ADM) system.
I've just gotten some great help from 404Error over at kc-mm who got me to look into pycurve.

I've stumbled over the interface before, but read that it was incomplete and didn't bother with it...

now, I've hand-copied the file (using my wii) and have gotten it to work perfectly
though it currently only works on a 2D interface,
so I have to work on making it 3D.

once that's done, I can work on implamenting the same interface from my DM2 viewer and turning it into a full-fledged editor for developing HQ models with extremely low file-size


EDIT:
how does this tie into UMC?
well, this will be implamented into one of it's releases when the ADME is mature enough

 

[Tcll]

something for you coders looking for a decent GL viewer written in Python with support for bone and vertex animation.

I've started work on converting Kentalin's BRMDL viewer version 1.43 from C++ to Python.

I actually have 2 reasons why I'm doing this for myself:
- to properly structure a decent animation system
- to test my C++ knowledge


so far... there's only one thing I have to question about, but I know I won't get my answer until I'm able to import an MDL0.
(yes I've changed the import format from '*.brmdl' to '*.mdl0')

anyways... what I have in question is this little bit of code:

class Triangle(object):
    def __init__(self):
        self.a = Vertex()
        self.b = Vertex()
        self.c = Vertex()
        self.next = Triangle()
        self.prev = Triangle()

ptrt = Triangle()
while ptrt != None:
    ptrt = ptrt.next

I have a bad feeling that's going to lead to an infinite loop.
but I'm not nearly finished converting the code yet, so we'll see

 

[Tiberious]

Um, is there going to be a version for importing straight into Blender? Would love to be able to skip the exporting to MD5 step with BRRES Viewer as I have to now.

 

[Tcll]

sadly, the blend format isn't exactly a peice of cake

that script's gonna take a while :/


I'm not sure how much support the md5 format has...

 

[Tcll]

you guys may have noticed everything has been grayed out with UMC's main interface...

I've been looking into C-type builds of 3D viewers, and my standards hardly come close to the standards of the C-type viewers...

a complete scrap/rebuild of (nearly) everything is needed.

don't worry about scripts
the only thing this'll affect there is new features to be added such as data types.

what this REALLY affects is the internal data handling systems.

this is what the data types are for, which will allow better render performance as well as conversion results.
(you won't have to convert a float to an int with an exponent as UMC wil do that for you.)
^ as well as it's supported by GL

 

[Tcll]

well...
here's a nice artical that desctibes everything relating to the normal vector: :D
http://jahovaos.com/groups/kb/wiki/19ed6/

I'm looking for as much documentation as I can find about how the 3D system to implament into UMC so I can have as much support as I need for the internal formatting system...

I won't exactly know just how well this is going to work until I'm able to build a viewer for all this data...

oh yea, and I'm scrapping the SES v1 format as I'm not going to build a writer for it.
(the SES versions are for FORMAT's internal structuring)

you will be able to load any version of an SES file in the current FORMAT version.

and because the new structure of the interface now uses classes, you can expect the version to increase more rapidly, but still easily support anything previous

as for v1 vs v2:
it's simply a list vs a dictionary...
but the dictionary is structured as defined by the class structures.
(no verification will be needed as the data will already be verified when exported)

however, in each class, constant structure verification is performed, so it will know if your ses file is a fake and will try to load as much valid info from it as possible.


EDIT:
ohh ho ho! =D
I've just found THE SOURCE OF LIFE!

I've been drooling all over this and have knocked out a good portion already :D
but there's still thousands more to go through. ^_^

lol, I'm having fun.
if dev5's viewer can't render the highest quality gfx,
SHOOT MEH AND BURN MY CORPSE UNTIL THERE'S NOTHING LEFT OF MEH! =D


the only thing I have to apologize for is how long this is taking...
but I need to learn this stuff to build the most efficient HQ model buffer with sub-buffers for holding UMC/UGE conversion data.

 

[Tcll]

well...
the ATI documentation just bamfed my float manager by 1 bit. >:O

24bit IEEE754 float bit-size:
ATI: [1,7,16]
UMC: [1,6,17]

I guess, for right now, you can only use these float bit-sizes:
8bit, 16bit, 32bit, 64bit, 128bit.

I'll get to work on fixing the algorithm for ATI's manager,
but don't use other bit-sizes as I'm not sure which ones are mis-matched because of this. :/

EDIT:
actually, I've only changed the 24bit structure...
anything above 32bit seems to structure correctly according to the IEEE754 terms.

 

[Tcll]

well...
I'm still trying to learn how to structure the internal buffers to handle the data properly...

buuut I've gotten some stuff to help me out with it

PyStream is an interface which will allow me to write GLSL shaders in Python (for UMC's viewer)
CorePy is an interface which will allow integration of ASM in Python code


truthfully this stuff has nothing to do directly with the internal buffers...

PyStream will be used entirely with VIEWER
CorePy will be used more-so in COMMON, and some future stuff

my scripting language will need to use ASM as it's base, but I'm programming it in python...
(where CorePy takes it's place)

this will make it easy in scripts/libs to call functions which will port code to my scripting language.

oh yea, I forgot to mention that PyStream will also make it easy for me to build part 2 of the libraries.
part 2 deals with the data displayed by GL.
you can modify that via special functions allowed to the libraries...

PyStream will allow me to perfect this to allow you to perform calculations via the GPU in the libraries.


this is how the MineCraft library will be able to render an animated model as cubes,
and properly position those cubes per frame.
(like blender26's modifier except better)

NOTE: the actual model will not be rendered when re-rendering through a library


this interface is just as complex as it seems though,
so it won't be finished upon dev5's release.
sorry about that guys...


EDIT:
alright... forget CorePy...
apparently that doesn't work with win32 platforms

guess I'm gonna have to substitute python instead of ASM -.-*

 

[Tcll]

well, dev5 isn't going well at the moment

until I can manage a little progress, I'm working on dev4.5 just to give something good

this thing still uses the script interface of dev4, so your scripts will be compatible
but there are a few renamed functions which I will have documented in a list

I will try to get support for basic materials and textures working, but I don't think I'll be able to do anything advanced :/


in any case, I do need a little help if you guys want faster performance.
I have a 32bit system so I can't install a 64bit python interpreter...
that's where I need help...
can I ask that someone:
1: download and install Python 2.7.5 x64
2: put the C:/python27 folder in a zip
3: upload the zip to DropBox (Not Mediafire)

if I don't have the 64bit interpreter by the release, you guys will be stuck with the slower interpreter.

 

[Tstar360]

keep working. get that pichuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

[Tstar360]

i have 64 but not coding skill. tips might help

 

[Tcll]

i have 64 but not coding skill. tips might help

coding is simple and easy, especially with python.
if you use anything like C though it gets complex real fast...
I have a tutorial/reference I'm working on for programming in Python27
though it's still, very much incomplete. XDD
you can find it in the kc-mm programming tutorials.

however, coding for UMC is made even simpler by the functions you're freely provided.

UMC aims to make programming it's scripts and libs as simple as possible! :D
(speaking out for dev5, dev4 needed some work)

as for tips...
all you really need to know is algebra and logical sums


if you'd like to lend a hand...
if you'll notice the runtime, there's alot of things in red...

you can download/install python 2.7.5 x64
and download/install PyQt x64 (latest version) for python
and send me the distribution in a zip on DropBox.

because you're not good at coding,
that's all you can really do there...
the other packages need to be built before they can be added to python...


anyways... thanx in return

 

[Tstar360]

im on it . soo.... I just download it and compress it in a zip and then send it to you via drop box? you don't need me to do anything? im young (12) but im smart. I taught bill gates how to create xbox. not really but I know math really well.




EDIT: do I download Python 2.7.5 Windows X86-64 Installer
or Python 2.7.5 Windows Installer



EDIT (I sometimes post without thinking.): I downloaded the first link and am setting up first time installation all that's left is the other program and compress them with WinRAR and create a dropbox.



ANOTHER EDIT: its downloading python 3.3.2,and your gonna get tired of me


never mind I downloaded the wrong installer

 

[Tstar360]

for some reason I cant use chrome :/ anyone else have that problem?

 

[Tstar360]

downloaded python now for PyQt x64

 

[Tstar360]

wait it says I have to purchase pyqt.

 

[Tstar360]

pyqt says I need python 3.3.2 installed Im going to leave it here until you tell me what to do . good bye