|
|
« Reply #165 on: November 03, 2014, 03:38:32 PM » |
|
i tested the latest build on my comp, (not even sure if it is functional yet but was curious xD) but it seems to work fine for me on windows 8. i'm not 100% certain how to use it tho. i can see that you were able to import models, but i couldn't figure out how to do much more then open it at the time. i think i read somewhere as well in the last release it was not possible to export models yet?
anyway i was just checking in to see how progress was going. what can we epect in the next release?
eh, the latest release right now still uses the old scripting system... that's the reason why I stated the only possible exports were not much more than OBJ worthy (could get bones, but not weights)
and I do have a README in the release with info on how to use it
sorry that build has a horrid GUI I can't do too much to the GUI w/o maxing out one's CPU (I can make a good GUI, but being a noob, I'm using the wrong interfaces)
this next release will still use the CPU as I'd have to completely rebuild GUI.py to make it run on the GPU... (I'd rather rebuild UMC and THEN redo the GUI, when most of my work in the viewer will already use the GPU)
one problem with using the CPU like I'm doing is it's extremely slow and weak compaired to the GPU. the only upside the CPU has is it's ability to handle more advanced data structures.
so while I'm still using the CPU, I'll do my best to optimize the draw-code and make it alot less tasking on the CPU. just keep in mind, the more you have displayed in UMC's window, the higher the CPU usage will be.
this is the main problem with OpenGL's Fixed Function Pipeline. UMC 3.0 will fully use the GPU, and if needed will wait for the CPU to process a few requests. (this is how animation will be much more possible to display in 3.0)
let's not forget, Python is slow when compared to C++, though it's not the slowest language for being interpreted
what can we epect in the next release? the only reason I'm still working on 3.0a is because 3.0 is going to take a heck of a while to develop (with me being the only one working on it)... however, I've modified the SES format with NBT support (bump maps), so I'll probably push out a few more releases before officially scrapping it.
as of the next release, you can expect to write scripts using the functions supported in UMC 3.0: http://tcll5850.proboards.com/thread/182/layout ^ I do intend to document these a little better
What this means is that any scripts you write for the next release of 3.0a will work in 3.0 whenever it's released.
one problem that still persists in 3.0a though is library support is very lacking... so try to keep things at script level, or contact me if you need help on an advanced interface with extended support.
a problem with the library support is that UMC's viewer uses the CPU to do it's work, however, the model displayed is stored in GPU RAM, so it's kinda hard to gain access to the data for modification. (scripts are not allowed to have this kind of access as they're meant to be single file)
OpenGL does provide an interface to share data between the CPU and GPU, but doing so requires a shader to properly handle the data, which UMC 3.0a lacks.
This means something like my minecraft library will be pushed back to UMC 3.0. I can still work on basic scripts for this, but you won't see any viewable features until 3.0.
the purpose of a library is to provide extended and shared support for scripts, thus meaning your scripts can be made smaller and contain less code, rather than contain duplicate codes.
the only library I have right now to test with is for Nintendo texture formats (RVL_IMG.py) this is being used across my TEX0 and DAT scripts
|
|
|
Logged
|
|
|
|
|
|
|
« Reply #166 on: November 06, 2014, 10:02:51 PM » |
|
|
|
« Last Edit: December 01, 2019, 03:52:00 PM by DarkPikachu »
|
Logged
|
|
|
|
|
|
|
|
« Reply #168 on: February 07, 2015, 11:34:27 PM » |
|
figured I may as well post an update since the GUI has now come a long way since I got the dialog working
I'm still sorting out a few small issues with the select box functionality, but after this, I'll be working on the panels and perhaps a few options as well or I might save the options for an update either way, they'll be added
since the UI is alot simpler to work with now, I might start updating a bit more often on here as well as other forums. but I think I'll save the updates for something major... heh
if you want the most up-to-date stuff, my most active location will be SmashBoards until my forum's activity picks up a bit better. (not saying the inactivity is bad, I actually currently like it as it's less stress for me) :3
|
|
« Last Edit: December 01, 2019, 03:53:44 PM by DarkPikachu »
|
Logged
|
|
|
|
|
|
|
|
« Reply #170 on: February 10, 2015, 09:13:28 AM » |
|
question, what animation formats will it be able to export?
|
|
|
Logged
|
Stupid Tinypic :C
|
|
|
|
|
|
« Reply #171 on: February 10, 2015, 10:37:29 AM » |
|
question, what animation formats will it be able to export?
well... when animation support is being focused on... any formats you could write a script for.
here's a piece from COMMON showing planned support
global _UGE_Scripts; _UGE_Scripts = { UGE_MODEL_SCRIPT: { 'Import':{}, 'Export':{} }, # I'll leave this... might update FORMAT later (SES can suport it w/o messing anything up) UGE_ANIMATION_SCRIPT: { 'Import':{}, 'Export':{} }, UGE_IMAGE_SCRIPT: { 'Import':{}, 'Export':{} }, UGE_PALLET_SCRIPT: { 'Import':{}, 'Export':{} }, UGE_COMPRESSION_SCRIPT: { 'Import':{}, 'Export':{} } }
I should change "might" to "will" lol
also, that's SESv1 supported internally by 3.0a VIEWER can't support animation w/o some huge framerate drawbacks. but FORMAT can, which I can add later.
back then I wasn't sure if this interface could handle it as it was only an idea... heh
I plan to have a release out soon after if not within the week
script support is not planned because UMCSL cannot run properly in this build. UMCSL will be supported by 3.0 (along with alot of other stuff 3.0a just can't do well, if at all)
Post Merge: February 12, 2015, 07:54:48 AM well... I hate to say it... but I'm not gonna be able to make the release...
it WILL be extremely soon, but I can't exactly say how soon
hey at least I'm not like the low-lifes at Ubisoft. XD I want to clear up as many bugs as possible to have this thing as functional as needed by the release.
|
|
« Last Edit: February 12, 2015, 07:54:48 AM by DarkPikachu »
|
Logged
|
|
|
|
|
|
|
« Reply #172 on: February 14, 2015, 05:01:14 PM » |
|
Post Merge: February 15, 2015, 01:28:49 PM I AM NOW BETA TESTING!
for those who want to try it out, download a zip of my folder here: https://copy.com/3Zg7S8HwFyVaXstm
Please understand, this is my active collaborative repository, which is updated as I edit the src. alot of included scripts here don't work properly if at all and won't be in the release.
the official release will be hosted on GitHub
Post Merge: February 15, 2015, 04:29:19 PM just to notify, I know about the GL error on some model imports:
importing TyPichu.dat 100% Converting from import format... Verifying data... Finalizing... Updating Viewer
Traceback (most recent call last): File "Z:\home\tcll\sync\copy\UMC_v3.0a\API.py", line 40, in run VIEWER.Init() File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\VIEWER.py", line 1039, in Init else: __Draw_Scene() #no 3D display File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\VIEWER.py", line 565, in __Draw_Scene __GL.glCallList(__MODEL_DATA) File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\Python\x86\lib\site-packages\OpenGL\error.py", line 208, in glCheckError baseOperation = baseOperation, GLError: GLError( err = 1281, description = 'invalid value', baseOperation = glCallList, cArguments = (270L,) ) this will eventually be found, I'm not sure what causes this, so please don't report these cases
|
|
« Last Edit: December 01, 2019, 03:59:41 PM by DarkPikachu »
|
Logged
|
|
|
|
|
|
|
|
|
« Reply #175 on: April 04, 2015, 08:58:31 PM » |
|
stages ehh? noice
|
|
|
Logged
|
|
|
|
|
|
|
|
« Reply #177 on: April 11, 2015, 06:53:02 AM » |
|
just wanted to make a mention
older:
I'm still working things out
EDIT: btw, I want to mention, during the next few updates before I officially scrap 3.0a, we may or may not see a dev6 and definitely not a dev7
the devs usually update with a major interface change.
by rights this current version should actually be called 4.1b (due to another (almost) major rebuild), but recent sub-standards and no releases have kept the version at 3.0a
for those who need an explanation as to why there's still no release yet: the front-end interface is still far too shoddy and the data verification is still incomplete, though it's being worked on with my best knowledge:
def __VerifyBoneTree(BID,Data,children,wpbind,wptransform): BoneName, BDL, (l,r,s), Res, Bind, Inv_Bind, PBID, PrBID, CBID, NBID = Data default = __rr.Matrix44(DM) # default (same as identity) transform = __rr.Matrix44.from_scale(s) * __rr.Matrix44.from_eulers(r) * __rr.Matrix44.from_translation(l) # Local Transform bind = __rr.Matrix44(Bind) # Local Bind inverse = __rr.Matrix44(Inv_Bind) # World Inverse Bind wtransform = __rr.matrix44.multiply(transform,wptransform) # World Transform wbind = __rr.matrix44.multiply(bind,wpbind) # World Bind cinverse = __rr.matrix33.inverse(wbind) if (transform == bind).all(): if (default == bind).all(): # possible problem (this may be the proper local location) if (default == inverse).all(): # this may not be the proper locations if (default != wpbind).all(): # assume identity to parent and recalculate the inverse bind. inverse = __rr.matrix33.inverse(wpbind) else: # recalculate defaulted bind and LRS wbind = __rr.matrix33.inverse(inverse) pinverse = __rr.matrix33.inverse(wpbind) bind = wbind * pinverse transform = bind else: # make sure the bind matches the inverse if (default == inverse).all(): # this is obviousely wrong inverse = __rr.matrix33.inverse(wbind) elif (cinverse != inverse).all(): inverse = cinverse elif (default == bind).all(): pass elif (default == transform).all(): pass else: # neither are default, but don't match pass # recalculate #wtmtx = __rr.matrix44.multiply(ltmtx,wptmtx) #wbmtx = __rr.matrix44.multiply(lbmtx,wpbmtx) if BID in children: # if this bone has any children for CID in children[BID]: __VerifyBoneTree(CID,Data,children,wbind,wtransform)
^ what does this do?
after everything has been imported, the data is still likely unstable, especially for bones. what this does is gather the current bone's LRS, Bind, and Inverse coords (for each bone) and tests to make sure everything matches accordingly and even attempts to fix what doesn't match.
what this means is you only need to specify 1 of any: - Loc,Rot,Sca - Bind Matrix - Inverse Matrix
and the verifier will calculate the rest.
if everything is defaulted and nothing is supplied, the verifier maps the Inverse to an inverted world-bind matrix at the parent's location. (LRS and Bind don't need to be touched as they're locally defaulted)
so all in all, the verifier stabilizes the supplied data to make it display and export properly as needed.
|
|
« Last Edit: December 01, 2019, 04:04:58 PM by DarkPikachu »
|
Logged
|
|
|
|
|
|
|
« Reply #178 on: April 11, 2015, 03:24:06 PM » |
|
r those maps from kirby air ride?
|
|
|
Logged
|
|
|
|
|
|
|