just so everyone knows, I'm currently stuck at the end of my knowledge... if anyone would like to help out, I'm trying to figure out how to calculate the bind matrix from the supplied LRS coords.
I'm doing LRS only for supplying data to UMC's bones as it's the only solid method to start off with w/o alot of work
if you don't know, Sm4sh .vbn (bone data) files don't have any matrices... and with my knowledge in game development, the LRS is the root of all bone matrix data.
I'll add matrix functions later for formats that only supply a matrix (such as DAE)
so could anyone knowledgable help me out with creating a proper matrix from the LRS coords please every attempt BJ's tried giving me has failed...
so UMC's currently at a hault until I know what I'm doing.
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:
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
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.
yeh, it seems my hype is cut short though as it's literally the only stage that has shown anything on import w/o an error out of what I've tried so far.
eventually though once I figure out these extra structures (Shuall is providing some amazing documentation) I should eventually have the stage displaying as well as in Melee
though still, UMC currently doesn't support lights other than it's own, so that's a bit of a drawback for the release... I've still got a crap-ton of functions to port and more support to add to make it suitable enough to release.
EDIT: idk why the smileys are misbehaving >.>
EDIT2: and I just deleted the 2nd half of my post because this thing screwed up 9_9
I hope that wasn't sarcasm. Cuz you know, not everyone is able to code 3D engines. I don't know enough about them. Even the 2D stuff, I'm just picking up and applying logic and common sense. I learned it on my own time due to not being a pro game maker. I'm also tired of game engines that cost an arm and a leg.
it wasn't I honestly dislike 2D, and tbh, 3D isn't much different from 2D the only hard part is learning matrices and optionally integrating with GLSL.
and don't worry about learning stuff on your own, I'll be a first hand person to hijack BJ's thread and teach everyone 3D if that's what they want. :3 lol (I actually have fun helping people like that)
also, screw using a game engine, seriousely :/ it's better if you actually write your own game and structure it w/o an engine. but to do that, you need to understand object orientation, which can be difficult to learn :/ I can help with that too
hey I'm no pro game developer, and I learned what I know just about on my own as well. Ian Mallet taught me alot about OpenGL, but I've figured out more than what he's taught. I built my own transparent GUI widget system entirely with OpenGL's FFP not using the GL-Feedback buffer.
but yea, if you want to learn some cool tricks and such, just ask, and I'll be happy to clarify. (unlike alot of others who would hardly teach me crap)
basic 3D programming is actually very easy. it's basically the same thing as placing down blocks in minecraft, except the blocks connect to each other via lines that form faces with texures
oh good lord, another 2D smash game. >3< well, I'll give credit if it's good at least
I wanna see something in 3D that isn't a brawl mod >3< lol
I just so happen to be working on something btw using pyglfw with pyopengl ;3 I don't have a good name for it yet, but it'll have everything nintedo seems to be forgetting about that makes smash memorable and overall epic. (with my own twists to promote epicness with fair-play of course) ^ cheapness is bad and you will be punished with a lower score (can hurt your chances of winning the game)
argue with me about competitive play all you want, I wanna see tourneys promote this method
basically, I'm a fan of TAS battles and I try to fight like so (I know what TAS means, but now actually try fighting like that and being epic while doing it) ^ that will get you the highest scores in my game IF you can pull it off
If you're that worried about it, you could always take it upon yourself to be the BBox "XP guru" and handle all the xp related deeds. It is open source afterall. Though i think i remember you saying in the past that you won't use / dedicate time to learning C# or something to that effect.
only if you'll pay me back with working on these with me: -both versions of UMC (3.0a and 3.0) -UMC_SIDE (a fully interactive and intuitive IDE for teaching noobs (complete non-coders) to build UMC-scripts) -UMCSL (my recompilation language for translating executable byte-code between machines and actual code)
yes I know UMC scripts were already designed to be easy to write, but it can only get so easy before I have to start dropping interface support to get any easier.
I already have a fully automated and interruptable state engine like OpenGL's FFP (dual-buffered in 3.0) and my own file system (with pointer support in 3.0)
so UMC_SIDE is built to take care of the learning gap with more features and better intellisense than merging VS2010 with Aptana. and later on, hope to implement collaborative support. (I'm a big fan of real-time (synced) development)
(personally) if i absolutely have to choose between supporting XP and bringing the best possible experience to the most users, i will most certainly choose the latter. But again, if i can help it, i won't have to choose at all.
que commercial: Why can't we have both? XD
hey tbh, that's one reason why I program in python. it's just as cross-platform as Java
I hate 3rd party libraries, which is one reason I choose PyOpenGL over pyglet. this means even more low-end cross platform support than using something like .NET aka IronPython (IronPython sucks, don't ever use it) ^ Python already has a garbage collector, it doesn't need .NET
v0.69, it's right there in the changelog. I'm editing it right now, so I just searched for "1.5" to find the release that included that update and then told you the release version before that. Simple stuff m8.
you never told me that dude... haha unless I overlooked it on our skype chat, then I'll take full blame. (sorry if so)
I don't have skype open atm because of mother issues >3<
Can we stop talking about updating computers and talk more about BrawlBox?
+1
yes, I freakin agree! I'm sick of blowing my brains out over this trash. it's MS's fault people need to get smart or throw their computers away. (not joking, that's literally the only good Win7 and up is good for is filling up your trash bin with a broken computer)
at least I'm here to keep people from throwing out their compys. stick with XP or linux, and you won't have a headache to deal with later on!
getting back to BrawlBox now, I take it nobody knows which version last supported DAE 1.4.1??
I'll just see if I can find an alternative to the "await" keyword in a later release, that's the only thing that we need .NET 4.5.1 for in the BrawlBox application anyway. That won't fix the updater, but at least you'll be able to use BrawlBox itself.
that's not supported by XP BJ... sorry but you need to use things everyone can use.
I think you'll even cause issues for linux users if you do that :/
Show Posts
