Universal Model Converter - Side Development Thread

[Astrodelta]

hai r u good with riivoulation? u seem leik a boss making converters so my problem should be easy to fix hopefully lol.

 

[Tcll]

eh, I used to be... lol
was working on a custom menu to allow me to select from among many various hacks, but that was before stuff like cBliss and BrawlEx...
since then neither my wii nor my brother's wii has been able to read my Brawl disc and I've been forced down to CFG USB Loader which uses a Gecko GCT method.

would love to use Riivo again though but through a means that could load an ISO.
(tbh I would rather like something that can load the raw files instead of an ISO so I could actually build a game)
^ it's a shame how many wii developers there were and not one of them did something in terms of wii game development (not through HBC)

anyways, yea it's been more than a few years since then, and sadly I don't have the knowledge I once had...


EDIT:
give me a go though and I'll see what I can do

 

[Astrodelta]

yeepee :D so here's something strange that im experiencing. so the app named riivoluation same capabilities as geko but no thing resides that geko cant do and thats sfx audio stuff. so i downloaded learn to how to use the app and so forth. well after a few times loading up riivo and playing on it, I thought to go to the replay archive room and load up my sd card to view my replays, well the sd card wasnt inserted as the words wrote the sd card was and clearly is a lie since im playing on my sd card to begin with so yeah. i then tried this on geko and it worked so ik something is up wth riivo.

edit: im uh pretty bad with this type of stuff lol i barely understood a few stuff like iso and riivo xD forgive me sempai <3

 

[Astrodelta]

uh... ok...

 

[Tcll]

lol, the ISO is basically a copy of the game as a file (an ISO disk image file).
it's the only way I can play games on my wii now... heh

anyways, yea, Gecko has some problems with audio, but that's because of the method used...
the audio is basically loaded with the executable DOL, so in Gecko, it's not possible to mod those outside of the GCT.
some changes have been made though that allows some complex audio replacements, but I'm still using the older FPC which doesn't do that... lol

anyways, what you're experiencing...
yea, load your game off a USB and then insert your SD and it should work
there's not much I remember, but I do remember figuring that out from my friend's tourneys

 

[Astrodelta]

lol, the ISO is basically a copy of the game as a file (an ISO disk image file).
it's the only way I can play games on my wii now... heh

anyways, yea, Gecko has some problems with audio, but that's because of the method used...
the audio is basically loaded with the executable DOL, so in Gecko, it's not possible to mod those outside of the GCT.
some changes have been made though that allows some complex audio replacements, but I'm still using the older FPC which doesn't do that... lol

anyways, what you're experiencing...
yea, load your game off a USB and then insert your SD and it should work
there's not much I remember, but I do remember figuring that out from my friend's tourneys

yeah but how can i see my replays in riivoulation when it states no SD card which is dumb lol. usbloader... wat that? is it better than riivo? I stopped using geko when I found out geko can't do sfx audio so I have to use riivo, right?

 

[Tcll]

yeah but how can i see my replays in riivoulation when it states no SD card which is dumb lol.

anyways, what you're experiencing...
yea, load your game off a USB and then insert your SD and it should work
there's not much I remember, but I do remember figuring that out from my friend's tourneys

usbloader... wat that? is it better than riivo?

CFG USB Loader (or any USB loader) is like Gecko in that they all use Ocharina (spell check), but they all load ISOs (Riivo and Gecko do not)

my wii can't read disks anymore so it's the only way I can play wii/gcn games
(if you want to play GCN, you need to install DIOS MIOS and use it through CFG or whatever USB loader you use)

 

[Astrodelta]

CFG USB Loader (or any USB loader) is like Gecko in that they all use Ocharina (spell check), but they all load ISOs (Riivo and Gecko do not)

my wii can't read disks anymore so it's the only way I can play wii/gcn games
(if you want to play GCN, you need to install DIOS MIOS and use it through CFG or whatever USB loader you use)

ok but one last question plz? do the codes, textures all transfer to the usb loader? if so then sign me up!

 

[Tcll]

^solved in IRC

 

[Tcll]

just for some news, here's for some support:
who and all here remembers my blender script which could export bf32 vertices?
well, now I'm working on a script for UMC which can export more than the same data Smiley
more info here: http://smashboards.com/threads/zack-fair-tournament-legal-project.407245/#post-19483358

also, I'm thinking about including the 32bit header regardless of float or int formats (that way you don't need to tell people more info when schooling them on how to hack with UMC) Tongue

as far as melee vertexing, I can only hope it'll work well since Melee vs Brawl is global vs local vertices >_>

 

[Tcll]

better idea for local vs global vectors:

local:
data.vtx - bf32()
data.vtx16 - bu16()
data.vtxs16 - bs16()
data.vtx8 - bu8()
data.vtxs8 - bs8()

global:
data.gvtx - bf32()
data.gvtx16 - bu16()
data.gvtxs16 - bs16()
data.gvtx8 - bu8()
data.gvtxs8 - bs8()

what's the difference between local and global?
vertex order.
if you export as global, all of the vertices for every object are exported as 1 array
if you export as local, you export separate vert arrays for each object.

for Melee you'd want global
for Brawl you'd want local

as for progress, I'm working on a method to keep as much precision as possible with a lower quality mantissa...
see here: https://www.daniweb.com/software-de...nent-from-a-bunch-of-float-values#post2175274

basically, most Melee verts are 16bit ints.
if you wanted to save some space, you could export 8bit ints which would cut the vert data size in half, however, the precision wouldn't be as great, meaning your model could be a tad malformed.

here's the conversion so far:
16bit to 8bit:
5.09375 to 5.0625 # cut at 4
1.703125 to 1.6875 # cut at 5

the "cut at" number is the exponent, anything above that exponent results in the exact number
if you were converting to 8bit, the highest you could go would be 5:

>>> 5.09375 * pow(2.0, 5)
163.0

6 puts that number at 326, out of the 8bit range of 255
what that means is a quality loss on other numbers which is what 4 was meant to test.

 

[Tcll]

update:
I'll be getting rid of the signed/unsigned specifications

it's unlikely the data would be different...
most models are T-posed at 0, meaning if it has depth, it will likely have vectors at -Z and even more likely vectors at -X

for those occurrences where the data is different, you can just change the data type in the attributes like you would change the exponent

there's only 1 probable issue I see with Melee, and that's if Melee's vertices aren't exactly global, but more like appended.
this means objects could use separate attribute specs on the same vert data, which could cause issues and major complications when you want to mod it since all of the vertices are in 1 large data field (if it's not an array)

 

[Tcll]

sorry I forgot to notify, I'm currently on what you could call a "vacation"...
and by that I mean I'm taking a Minecraft break on the DNS Tech Pack.

don't worry, my mind won't let me stay away for too long

I've already thought of a better method for namespace integration for UMC-scripts that makes integration with SIDE 10x easier AND restricts the needed namespace functions to those particular script types.
what is it?

UGE_MODEL_SCRIPT.NS = {}

^ that dictionary will hold everything that's needed for a UMC model I/O script
models normally tend to use all formatting standards including archiving (MDL0) and compression (FSYS), for which everything needed is supplied for use.

for stuff like UGE_COMPRESSION_SCRIPT, the NS won't contain functions like ugeSetObject()

 

[Tcll]

ok, so the secluded namespace works more than perfectly...
it works too perfectly:

importing PlPcNr.dat 100% 
Converting from import format...
Error! Check 'session-info.log' for more details.

Traceback (most recent call last):
  File "Z:\media\tcll\copy\Tcll\UMC_workspace\UMC_v3.0a\data\VIEWER.py", line 654, in _ImportModel
    exec 'ugeImportModel()' in NS
  File "<string>", line 1, in <module>
  File "scripts\HAL_Labs_DAT2.py", line 297, in ugeImportModel
    def _Material(offset,_apply=True):
NameError: global name 'True' is not defined

so yea, I've got some cleaning to do... lol

 

[Tcll]

ok, so I've gotten all the base stuff for my Hal Labs 2 script registered with the namespace...
however, I've just ran into a bump:

  File "scripts\HAL_Labs_DAT2.py", line 213, in _Image
    img = readimg(imgWidth,imgHeight,imgFormat) #the library works, yay! ^_^
NameError: global name 'readimg' is not defined

I forgot about the libs

the problem I have with libs is, while I want to provide as much backend access as possible for them,
I don't want that backend access forwarded to the scripts.

libs are meant to work FOR scripts on much more complex levels.

it's a standard applied by UMC to keep things simple in a needed controlled environment.
forwarding the backend would break that standard.

also, it would make it alot harder to pinpoint an issue.
the controlled environment is meant to provide everything you need and help you find issues, which is the purpose of session-info.log.
using the backend might not log what you'd need to track.

not only would it make it harder on you, but for the devs as well if an error were to occure.
at least if the backend is kept in a lib, it'll be easier to pinpoint the error.

and there's also the possibility of UMC getting confused over the backend loop, thus creating an even bigger mess.

so if you're going to write a UMC script, please keep the frontend separate from the backend.

 

[Tcll]

ok, so since apparently there's multiple terms that're almost as common to each other, I've made an extension to UMC's formatting functions, script constants, and I/O functions:

UGE_PALETTE_SCRIPT

ugeSetImagePalette
ugeGetImagePalette

ugeImportPalette
ugeExportPalette

I've even changed the script loader:

Palette/Pallet Importers:
Palette/Pallet Exporters:

when it comes to image data, apparently the proper term is palette, however, I've grown up knowing pallet since I built MUGEN characters using PSP7

so yea, you can use either term however you prefer, and they're exchangable so it doesn't matter if you mix them

EDIT:
oh yea, the secluded namespaces work perfectly btw, and I've even applied it to the image functions

now I just have to figure out how to seclude the backend to libraries only >_>
(meaning if you use a lib in your script, you won't have access to UMC's library functions w/in the script)

 

[Tcll]

finally figured out how to seclude library access from scripts.

basically, in the lib, you'll need to register specific functions with UMC.
what this registration does is create wrapper functions in a secluded namespace while attaching your lib's namespace to the function.
this secluded function will be passed to your script, take note that your lib's namespace is attached to the function so the execution of the data you pass to it will take place in lib, not your script.
(this means you will not have access to anything in the lib other than the registered functions)

EDIT:
basically, it's the same thing I'm doing with the script callers:

            # credit to Gribouillis for this block:
            # ---
            NS = dict( COMMON.UGE_MODEL_SCRIPT.NS.items() ) # clone
            NS['__builtins__'] = sys.modules['__builtin__']
            if script.__name__ in sys.modules['/UGE_ScriptLibs/']:
                for libName,libMod in sys.modules['/UGE_ScriptLibs/'][script.__name__].items(): NS.update(libMod.__dict__) # apply libs

            ugeImportModel = FunctionType(script.ugeImportModel.__code__, NS) # clone
            ugeImportModel(filepath.split('.')[-1].lower(),None)
            # ---

basically, using the above:
NS would be your lib's namespace
ugeImportModel would be the registered wrapper function sent to your script

there's nothing special you'll have to do to call these functions, just use them the same as before.

EDIT2:
idea considered:

@ugeScript() # register with all script types
def libFunction( arg ): pass

@ugeScript( UGE_MODEL_SCRIPT ) # register with model scripts only
def libFunction( arg ): pass

@ugeScript( UGE_IMAGE_SCRIPT, UGE_PALLET_SCRIPT ) # register with specified scripts only
def libFunction( arg ): pass


hope you leik

 

[Tcll]

ok, so that registration is a bit complex and won't be available by the release.
(it'll take too long to implement)

on a side note though, as an extension of this, I'm looking into python's multiprocessing, which I think I'll used to create the namespaces for the import and export processes.
what this means is I may be able to actually display the valid data in the viewer while it's importing.
(no more having to wait for the import to complete before the data is displayed)

the extension part comes from how multiprocessing works...
basically, imagine it as if you were starting another python.exe and linking it's namespace with the main process.

basically, this means I'll need to pass the script and lib namespaces to the new import/export process while providing shared access to UMC's backend namespace for libs.

so yea, there's something you can expect to see next update

EDIT:
btw, updated the loader to be more dynamic:

Loading scripts...

ugeImportModel(): 9
| UMC_SES.py
| HAL_Labs_DAT.py
| MDL02.py
| MMD_PMD.py
| testBoneRel.py
| Sm4sh_NUD.py
| NTDO_MDL0.py
| Wavefront_OBJ.py
| HAL_Labs_DAT2.py
|
ugeExportModel(): 3
| UMC_SES.py
| PNG_Textures.py
| Wavefront_OBJ.py
|
ugeImportImage(): 2
| NTDO_TEX0.py
| IMG.py
|
ugeExportImage(): 1
| IMG.py
|
ugeImportPalette()/ugeImportPallet(): 0
ugeExportPalette()/ugeExportPallet(): 0
ugeDecompressor(): 0
ugeCompressor(): 0
ugeImportArchive(): 0
ugeExportArchive(): 0
Bad Scripts: 0

what this means is I'll now be able to extend script-type support (such as game scripts and logic) w/o having to update the loader.

 

[Tcll]

looks like I forgot about some users and hadn't considered users w/o an MMB to rotate and do all kinds of stuff with...
so what I did was copy the button code for the MMB over to key-bind Q

that should make things alot easier, especially for laptop users w/o a mouse, or mac/laptop users who have a mouse w/o an MMB

I've got a mouse that doesn't have an MMB, but it's an old ball-mouse with a serial (7-pin) connector

 

[Tcll]

EPIC NEWS!

not joking, I finally got it!

the problem was a compilation of the influence matrix calculation and application.
the calculation was using the local bind instead of the world bind...
and the application was applying the transformations each time a vert was referenced, where it should only apply the transformations once.

so yea, now I can finally start cleaning this thing up and getting it ready for a release =)
hope you guys don't mind if I work on a few scripts before releasing
(specifically unfinished topics I'd covered previousely)

 

[Tcll]

New Poll: (can't edit the poll here)
Would you like me to hold off on UMC to work on SIDE??
http://forums.kc-mm.com/index.php?topic=54619.0

what is SIDE?
SIDE stands for Script IDE and is specifically designed to give you a highly interactive and intuitive experience when testing your script on some files.

here's some screenshots taken before I took some time to rebuild the project with co-compatibility for 3.0 and 3.0a:
(since 3.0a was majorly updated with 3.0's backend structure)


^ I'm changing the tree-view and building my own (Qt sucks)

here's some changes since the rebuild:

<<< the types, functions, and constants will update depending on your script's supported namespaces
(yes, that means the lists are now per-script rather than global)

as of current, SIDE is borked due to unfinished code-ports for the data viewers.
but overall, SIDE is much easier to work on since the last build

 

[Tcll]

think I'll just leave a little progress :3

^ I think the script name says enough about what's going on

 

[Tcll]

just showing off

really it's just a test, but it was so stressful I had to post

 

[Tcll]

for those of you who want to see the script: :3
https://copy.com/jkpWpRrFrjxtILlc
^ I'm currently working on materials/textures

I havn't heard not one peep from RTB out of my requests for help or anything on this thing >.>
@RTB: it's dangerous to do that to me you know, it makes my flame burn hotter and causes me to boast about being the better programmer >_>
(not that I'm competing or anything)

in my defense though, I've been talking (1-sided) to him about cleaning up his code while suggesting proper termages and better methods, again with no response...
so yea, ultimately I do have the better (cleaner, more-understandable, and sensical) code... not to sound like a douche about it

 

[Tcll]

last minute decision that will ultimately prove to be better in the long run...

I've decided to bamf string() and turn it into a struct: string()().

this will ultimately be better as it will be less confusing to work with (on both ends):
string( settings )( R/W )

take it as this, I've always had a problem with string(), and this is finally the solution to it
(this is not a lie, UMC 3.0 still doesn't yet support string() due to a data-system conflict)
^I'd considered adding the char() data-type to fix some issues (I might still add it as something useful)

anyways, the only problem with this is reworking string()() will take some time...
not to mention porting all of my scripts

 

[SuperShus]

So you're working on exporting smash wii u models right now?

 

[Tcll]

yep
tbh, I've just redone string()() and removing the old string() standard before releasing...
this has always been a problem since I started designing UMC3.0 (not 3.0a), so I've finally decided to remove it... heh

but yea, as for Sm4sh, I'm currently working on a GX2 lib to handle the raw image data from the NUT files.
hopefully I can get NWPlayer123 on this while I work on other fixups and such with UMC.

but as for the release, I intent to support assimp-supported formats (blend, 3DS, DAE, etc) along with possibly FSYS and Spyro (PS1)

in it's current state, I still need to fix and revamp most of my scripts, and I NEEEEEED to build a few exporters.
I wish the assimp package could export...
anyone wanna bludgen the assimp devs with requests to implement export support? lol jk

anyone wanna find me a decent library for supporting a common export format??
not PyCollada, that only supports triangle primitives, and I don't have time to learn and improve the library's backend.
(the library needs to work with Python27 with no dependencies)
^ I even want to scrap NumPy due to the slow object handling

 

[SuperShus]

I only know Java, C#, and C++ and haven't really done more than hello world in python, and had trouble 3d modeling 6 years ago when I last tried to use blender, but I can try to help.

Is this the kind of thing you're looking for?

" 3d model io library for mqo, pmd, pmx, vmd and vpd

`pymeshio` is a package for 3d model io. create for blender import/expoert plugin backend.

Compatible with Py 2.7

I'm not that interested in exporting models from wii u compared to melee ( obvious bias is obvious ) but I figure helping you helps everything get done faster so I'll throw in my 2 cents while you dig in the trenches. *salute*

 

[Tcll]

welp, with that, you've just thrown my PMD script out the window... lol
(it's one of the scripts I needed to redo... heh)

anyways, yea, I need something like that, but for common 3D formats

but I figure helping you helps everything get done faster so I'll throw in my 2 cents while you dig in the trenches. *salute*

indeed it helps :D
many thanks

hey, being able to export Melee models is 1 thing I desperately look forward to for my own reasons, so for you guys, that means all the better


also, the whole coding thing is not required unless you'd like to try writing a script
I still boast UMC scripts using at least 65% less code than a Blender26 script.
heck, I designed the frontend for noobs
so yea, writing scripts for UMC requires at least algebra-level math knowledge, and being able to write and use up to basic functions in python.
you also need to be able to understand how to read binary, which isn't difficult, but can be confusing at first.

also, since UMC-scripts are based off python, they're very easy to read and understand (unlike max-scripts which are just confusing)

if you'd like to write a script, add me on skype and I'll help you out on my dev-chat
Tcll5850 (DarkPikachu)
just edit the contact request message so I know you're not another bot... lol
(I've got 4 on my pending contacts already)

 

[SuperShus]

Lmao - i'll get in touch with you but I'm in summer school so I've got negative time: hopefully I can help somehow

 

[Tcll]

I should probably mention I've updated string:

string()() - reads until stop character: '\x00'
string('.')() - reads until stop character: '.'
string(4)() - reads a string of 4 characters
string(4)(8) - (overridden) reads a string of 8 characters
string(bu8)() - reads the 8 bit length of the string before reading the string
string(0)() - returns the file as a string
string()(0) - returns the file as a string (override)

string(bu8)( offset=bu32() ) - reads the 8 bit length of the string before reading the string at the specified offset

the standard here is an application for automation.

the idea behind automation is to make only 1 call while specifying no or very few python keywords.

EDIT:
btw, I've removed string encoding in favor of string()().decode( ... ) however for automation purposes I'm considering adding it back before the release:
string( code= ... )()

EDIT2:
also
another thing I'll be working on is:
- forward-compatibility:
string( 4, label='hard-label' )() <<< ignored argument
- handling for noob-errors:
string( 4, labl='hard-label' )() <<< ignored argument

however this won't be anything solid until the next update

 

[Tcll]

new change, which should be pretty small and possibly easy to implement:

old:
ugeScriptFormats( 'Hal Labs', ['dat'] )

new:
ugeScriptFormats({
'Hal Labs': ['dat'],
})

this is easier to implement than having to call the function multiple times (which will also be supported later)

I should have this done by the release as it's very simple to modify

EDIT:
done, and to show it's working:

^every format shown (among many more) is supplied by my assimp script.

assimp has a really good interface, but now that I'm looking into it, it seems to support only the simple part about model conversion.
it doesn't seem to support local vectors or advanced primitives such as tri-strips or polygons.
and I can't stress enough it doesn't have a way to export data.

I can't believe UMC is already doing better than ASSIMP... haha

I KNOW NOTHING! D=
HOW IS NOTHING BETTER THAN SOMETHING!?
I don't even understand GLSL, how am I doing better! D=

EDIT2:
btw, I'll be implementing this soon before the release:
if there's 2 scripts that share a file type, even if there's different names, you'll see a 3rd bar to select the preferred script.
the only difference the name makes is it selects that script automatically.

 

[Tcll]

also, thanks to this:
https://github.com/assimp/assimp/blob/master/port/PyAssimp/scripts/fixed_pipeline_3d_viewer.py
in either of the update after the release, or the next update after that (if pushed), UMC 3.0a might just actually support animation

I'd like to try for a more-modern GLSL-FFP setup though which might be possible:
https://github.com/assimp/assimp/blob/master/port/PyAssimp/scripts/3d_viewer.py

I've seen more modern viewers than that, but that stuff is reserved for UMC 3.0 since it's complexity is beyond advanced

 

[Tcll]

erg, I just found half the stuff I was looking for...
anyone remember when I did this:



take a guess at where that stuff was...
no seriousely, here's the script that converted it:

and here's the interface that added compression support:


so yea, I have to redo all of that work again, unless I can manage to manually recover it, and no I don't remember all of what I did.
(recovery software recovers 0KB files)

for this reason, I will never use NTFS again, or if I'm forced to, I will never use compressed NTFS.
if using Windows, use ExFAT to replace NTFS.
it's MS's fault they want you to use LITERALLY the WORST filesystem on the planet!
ReiserFS is the best with EXT4 following 2nd, an there are many others between NTFS and EXT3.
FAT32 is even better than NTFS, it still corrupts more often than EXT3 (which EXT3 is next to never), but it's still not NEARLY as often as NTFS.

I format mine to EXT4 because windows can be extended with it's support, but you have to hack it in to get it working.

also, EXT4 makes HDDs last muuuch longer than NTFS.
with NTFS, you need a fan blowing on the drive because of how hot it gets during normal operation...
with EXT4, you won't ever burn your hand on the HDD.

heat causes wear and tear on your HDD which means connections on the circuit board will crack over time, causing shorts with age.
(I've ran a 1hr-long copy process between my 1TB EXT4 and my 200GB EXT4 (laptop drive) and they only got mildly warm compared to NTFS)

sorry for going off on a rant...
it's amazing how many people still defend NTFS after mentioning my experiences with it AND ChkDsk.

I will never trust ChkDsk and will always disable it's ability to scan my drives.
I'd rather fix my drives manually.

 

[Tcll]

good news, I'd just created an img of my 500GB HDD
I'm not sure it's workable as I can't mount the image like the HDD, however a search with a hex editor reveals data from my old files
of course though there's a bunch of noise from being on a compressed filesystem...

I'm using a new recovery software to test this thing with, so hopefully I can actually get something better than 0KB files... lol

if I can, then I just might have MC supported quite soon

btw, I'm also going for Trove support on the same level
trove at least won't have to be block-mapped to pre-defined textures, so it should be alot easier to manage

 

[Tcll]

looks like it may be workable, however no recovery program I use seems to be able to get any sort of data from the image.
so I'm building my own brute-force recovery program :3

I've found the NTFS partition on the img and it looks rather in tact
what I'm worried about is the file-table...
I'm hoping it will at least give me the data offsets which I can use to determine the data sizes...

I hate NTFS

 

[pokemoner2500]

So glad to know this project is alive, need to remember to follow this thread, is anything currently possible? I remember downloading a very early beta a few years ago and was wondering if anything actually works yet :D

 

[Tcll]

lol I think the beta you downloaded is the same thing still up for release

alot of progress has been made since then, including a rehaul of the formatting frontend (not alot on the backend), the script loader, the GUI, and the the interpreter environment.
other stuff has been minorly rehauled, such as COMMON with interface access provided for SIDE, and various other things.

as for support, currently, everything's just importing... I still have yet to work on anything that exports anything properly.
a problem I'm facing is quality loss with 3rd-party libraries such as ASSIMP and PyMeshIO...
that and 3.0a's backend sucks

overall though I may be supporting animation next update (after the release)
(I'll be overhauling things again to make the GUI even faster while extending feature support to be more like my plans for 3.0)
^ I refuse to overhaul the backend, since I've already gotten a load done with 3.0 in that area (tested with SIDE)

so yea, there's alot that actually works now, but unfortunately there's no release yet.
you can download and test what I currently have at any given time
repo here can be downloaded as a zip: https://copy.com/gs8OGUauqMuQmjtl
but note, until I have a solid release, what you download is likely to be updated within the hour >_>
(if what you've downloaded is broken , just wait a bit, I'm likely adding a feature or improving something)

at this very moment I'm currently working on a brute-force recovery tool for my 500GB HDD destroyed by ChkDsk.
(because no other recovery tool can recover my data)
if you'd like to follow my progress, feel free:
https://copy.com/cZ6XHzOFjMDcWskP
you can do what you like with the code too, I don't care... heh
if it actually works though, and I actually get my data back, I'm releasing this thing
(I won't have any sort of write operations, so it won't corrupt anything)
^ currently it only reads from an img file, so it doesn't even touch any HDDs

Recuva, and DMDE, and all of those other worthless recovery tools I've tried can suck it.

yes, the data IS there, I found it using HxD on the img, but of course it's compressed so it's useless without any sort of tools... heh

EDIT:
just made a thread on my forum about my tool:
http://tcll5850.proboards.com/thread/329/brute-force-compressed-ntfs-recovery
I'd suggest following some of my tips to ignore NTFS at all costs

it IS the worst filesystem in the world.


btw, I know some of you may be questioning how this relates to UMC.
the reason I'm building this is to recover my old function information and all my old work I'd done for UMC.

I'll have a plus if I can make it releasable because it'll be better than all free and some paid (which I pirated, lol) disk recovery tools.
and when I release, I can boast because I'll be releasing something for free that does a better job than paid software. >:3

 

[Tcll]

for some interesting news, I've got some planning going into the console-API for UMC
(this is for when VIEWER is not supplied)
^ this is likely never to happen with 3.0a, 3.0's release on the other hand will be a short moment without a viewer.

so I'm looking into curses which adds mouse and keyboard events to the console.
http://stackoverflow.com/questions/...a-console-window-for-python/31755528#31755528
I'll be using this to turn my tool's console into a directory browser, but I can port the works from this over to 3.0a's console-API.
this is just in case people want to get to a lower level with UMC, and the lack of OpenGL support will make it even more cross-platform

thsi will be good for things like Raspberry-pi installations which can't run OpenGL (depending on the model)

or heck, if WiiPy was ever to improve, you could convert models with the Wii

 

[wahabthesmasher]

idk how to quote sorry

In reply to the UGE/USESL: So you make the model without vertices? I don't get it vertices are everything in 3d modeling.
Would UMC support converting a model back to the original format or to another one?