Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Converting to/from DBO format - Progress

Author
Message
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 3rd Oct 2018 08:45 Edited at: 3rd Oct 2018 08:49
I have been working for a few months very sporadically (95% of it the last 5 days) on converting DBO between different formats byte by byte. My end goal is I want models made in my model editor of choice to be converted to DBO with no jank or missing functionality (like animations or vertex weights). These are longstanding pains people have complained about on these forums.

The first step was to decompile the editor's file format. That was fairly easy. The second step was to decompile DBO file format. That was like 100 times harder. I managed to get this done tonight.

A few things I noticed about DBO format:

Documentation is vague. Thank goodness the source code for DBP is available, and I was able to use that to fill in the knowledge gaps when documentation left information out. This was needed a lot.

DBO files have a few unexplained sections which the documentation promises can be skipped. (Supposedly things like terrain data)

One of the sections of DBO files is called "Arbitrary Value" and the value is an arbitrary number.

The file format stores everything in a sort of optimized manner making it difficult to sort out. Most of the information is stored nested in frames, linked lists and data sets. Contrast that to my editor's file format which lays everything out like dumping an array, much simpler.

Now the work turns to doing actual conversions of the data. Does anyone know anything about Matrices or Frame Matrix or Animation Matrix? There's some university level math stuff I am I afraid might bog me down if I need to start recalculating stuff. Documentation says nothing here.

I'd ask more questions but I haven't run into the really nasty stuff yet.

Bored of the Rings
User Banned
Posted: 3rd Oct 2018 09:38 Edited at: 3rd Oct 2018 13:52
I've been reworking my DBO2X (and OBJ) converter for skinned and non skinned meshes (which also reads in GameGuru EBE and PBR enhanced DBO's which programs like Fragmotion can't read in due to the FVF. Yes, the documentation is dreadful, but got it all working (took almost 1.5 years to get right). Here is a small code snippet of the enhanced code (draft currently) which now uses as close to C code as possible using pointers / memory (IanM's Matrix Utills ALLOC or bank). Alloc is slower and banks a lot faster. The code doesn't show all the embedded DBO codes at the moment as it's a reWIP and I'm still doing more tests / debugging.

I haven't used any special mathematics (and I'm a stats programmer), just obtained the matrix / animation data (if any) and formatted to X specific format. Although, I need to figure out bone weight recalculations for GameGuru so they don't come out disfigured in some cases.

Code has also been added to the Code Snippets thread.



The attached debug output was produced using the "hummer_dynamic" DBO found in the Desert Storm FPSC pack (pack 75 I believe).
This DBO contains multi-materials and textures and you actually have to write the code to generate the X format to handle multi mats / textures correctly.
My DBO2X (v1.4) can be found here if you want to try it --> https://forum.game-guru.com/thread/219806#msg2602285 OR here for direct download from my GMAIL account https://drive.google.com/open?id=1QAwOkqgdSmQJqMYR76XlmgOCN-4cfpAU
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others

Attachments

Login to view attachments
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 3rd Oct 2018 20:31 Edited at: 3rd Oct 2018 20:36
Thanks this and the 2005 spec sheet were a big help.

Well you certainly know this mountain well. Part of the problem with the documentation is it doesn't describe big picture how the model is arranged. It mentions child and sibling frames without explaining the difference between them. So when you see a bunch of empty frames there's a question of why that's there. Maybe important or maybe the existing converter I have been using tossed in a bunch of junk data. FVF is simple enough to load in, but the data isn't explained well. Docs mention for example FVF_XYZ which seems to be vertex x/y/z but then there's also FVF_XYZRHW with a description "float X, Y, Z transformed" which is not much to go on. Right handed? Or this one from the FVF section "FVF_PSIZE float point size for sprites".

One of the things saving me a little though is that I am constrained by the editor's format which doesn't use all of these things. I am a little doubtful about multi-material mesh support. What is that really? How is that different than using the 8 or so textures the FVF section can store? Knowing this would give me a better indication of whether or not I can even do anything with the feature.

Another thing is this style of using buffers/pointers/and blocks of data. It is quite impressive and as far as DBP is concerned you need the engine running as fast as possible. However for my purposes taking 30 seconds instead of 5 isn't worth much. I have focused more on reading the byte and storing it in an appropriate variable. Now when I start to do conversions this might bite me in the ass or it might make certain things easier. For example if I need to return multiple variables from a function, then a fancy packed data block is easier to return. So we will see how that plays out and if I have problems.

Additionally I had an idea that if your converter has a command line interface, I could put it in the same folder as a tool I made and interface them, and the reverse also. That would let someone bridge conversion capabilities of both tools in one action rather than needing to manually launch both. Not sure if you're on the same page with something like that. Seems like a good idea.
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 6th Oct 2018 04:42 Edited at: 6th Oct 2018 04:43
I managed to convert the entire 3D mesh of a character from DBO to my editor.
It was hard because documents give variables names and tell you how to read them from a file but not how to use them. So a number of questions had to be investigated and also there were bugs in the loading code that allowed the model to be loaded slightly incorrectly but not enough to initially reveal a problem until conversions took place. (Like do vertex indexes start at 0 or 1).

- I was surprised that so far the coordinates and u/v data didn't need any serious math, just complicated repacking.

- DBO format seems to store U/V coordinates for each vertex, while my editor stores U/V data with each polygon (3 sets for 3 vertices). This seems to cause models to become unwelded when converted to DBO. More investigation is needed. Imagine if you had a sphere and your texture was the front and back side by side, those edge vertices can only have one u/v coordinate so the only solution would be to duplicate the vertex. Seems like this might be at play here.

My next step is to export the bone data which then leads to exporting the animation data. I am seeing some serious convoluted mess with the bone structure in the DBO. I'll need to really take a hard look. I have noticed that the whole DBO is broken into sections called frames, followed by animation data section. The frames are named after the bones and are in a hierarchy. The first frame contains all of the mesh data. The mesh data contains data for most but not all of the bones. Why? I don't know yet. So there's no obvious way to correctly extract the bone data. There's no simple list of bones and things they are attached to.

Forward momentum.
Bored of the Rings
User Banned
Posted: 8th Oct 2018 09:54 Edited at: 8th Oct 2018 19:27
for indexes, these start at 0, see output snippet below and are WORDs:

will try and provide more info after work. In the example below, this was taken from the Elhumongo.DBO which has 1 mesh frame that contains the mesh data. There are 2 types of frame, mesh frames and bone frames for the animation data, and there are DBO's that don't have any Frames and are purely mesh (apart from a possible root frame).
there is a hierarchy for the bone frames so when outputting to say X format, have to be output in the right order.

pBuffer = 164674059 dwCode = 116 dwCodeSize = 65280 pData = 164674059 pBlock = 131072
ptr to dwCode = 164674051 pBuffer = 164674059 dwCode = 116 dwCodeSize = 65280 pData = 164674059 pBlock = 131072
pBuffer = 164674059 pData = 164674059 WORD = 0,
pBuffer = 164674059 pData = 164674061 WORD = 2,
pBuffer = 164674059 pData = 164674063 WORD = 1,
pBuffer = 164674059 pData = 164674065 WORD = 2,
pBuffer = 164674059 pData = 164674067 WORD = 0,
pBuffer = 164674059 pData = 164674069 WORD = 3,
pBuffer = 164674059 pData = 164674071 WORD = 2,
pBuffer = 164674059 pData = 164674073 WORD = 5,
pBuffer = 164674059 pData = 164674075 WORD = 4,
pBuffer = 164674059 pData = 164674077 WORD = 5,
pBuffer = 164674059 pData = 164674079 WORD = 2,
pBuffer = 164674059 pData = 164674081 WORD = 3,
pBuffer = 164674059 pData = 164674083 WORD = 6,
pBuffer = 164674059 pData = 164674085 WORD = 5,
pBuffer = 164674059 pData = 164674087 WORD = 7,
pBuffer = 164674059 pData = 164674089 WORD = 5,
pBuffer = 164674059 pData = 164674091 WORD = 6,
pBuffer = 164674059 pData = 164674093 WORD = 4,
pBuffer = 164674059 pData = 164674095 WORD = 2,
pBuffer = 164674059 pData = 164674097 WORD = 8,
pBuffer = 164674059 pData = 164674099 WORD = 1,
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 8th Oct 2018 18:06
Well I have only tested DBO files that were converted from X format so far, so this is interesting as you suggest other DBO types with significantly different structure.

Quote: "will try and provide more info after work. In the example below, this was taken from the Elhumongo.DBO which has 1 mesh frame that contains the mesh data."

I have noticed so far that only one bone ever contains significant mesh data (vertices/bones/polygons). Are you saying that the proper mesh can instead be split up across multiple bones? (So far every model I have seen has a 'body' bone attached to the root bone with all significant mesh data)

Quote: "There are 2 types of frame, mesh frames and bone frames for the animation data, and there are DBO's that don't have any Frames and are purely mesh."

I have noticed that the bone frames are only the ones that have a mesh code section, their mesh section is typically empty except for the one frame with all of the mesh data packed into it. These frames are named after each of the model's bones and have a proper hierarchy.

On large models I see there are also these seemingly empty useless frames with no names and no mesh code sections. Always a sibling frame. I am not sure what these are for or if they are just junk data from the original 'conventional' conversion process to DBO. Small trivial models do not seem to have these.

Quote: "... and there are DBO's that don't have any Frames and are purely mesh."

That's good to know. Right now I have it looking for a root frame and in the frame processing code it looks for Mesh codes and other things. Maybe add a mesh code check to that top level loop along side the frame code check.

Quote: "there is a hierarchy for the bone frames so when outputting to say X format, have to be output in the right order."

I have that mostly worked out. The real mystery are these frame matrix things. They are a 4x4 grid of float numbers. The bottom row seems to be X,Y,X,? for the bone position. However there's like 3 other rows and no indicators what those numbers are for. Probably Scale and rotation, but which?, and yet there are still way more numbers than what that would need. I have seen this grid in X model files too. Perhaps looking at that specification would provide an explanation.

Bored of the Rings
User Banned
Posted: 8th Oct 2018 20:08 Edited at: 8th Oct 2018 20:22
Quote: "I have noticed so far that only one bone ever contains significant mesh data (vertices/bones/polygons). Are you saying that the proper mesh can instead be split up across multiple bones? (So far every model I have seen has a 'body' bone attached to the root bone with all significant mesh data)"

So, yes, in most cases, the root frame will have a child frame that contains the main "body" mesh. As is the case with the example Elhumongo. That is, the child frame to the root frame is named "El_humongo" but isn't a bone i.e. there isn't an embedded DBO code 301 bone name named "El_humongo" only a frame name that contains the mesh. However, there is an animation frame (embedded code 211) named El_humongo .
For some FPSC classic models, there can be more than 1 mesh in 2 different named frames e.g. the main body mesh and a separate mesh for say, a sword or weapon of some sort.
In a lot of cases, where there are "no name" bones, I tend to remove these, but for some Weapon HUD .X/.DBO files these are required asthey most likely have assigned vertices that affect animations.
In general, I do a lot of validation checking to make sure things tally up. So if there are 60 bone influences, I do a check to make sure that there are 60 bone weights present as well as various other cross checks.


If I think of anything else, I'll add here, it's quite involved.
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 8th Oct 2018 22:06
Bored of the Rings wrote: "In a lot of cases, where there are "no name" bones, I tend to remove these, but for some Weapon HUD .X/.DBO files these are required asthey most likely have assigned vertices that affect animations. "

That is troubling and I have reason to doubt this because it seems the only real link vertices have to a bone is by matching the name. In the Mesh Data Block all the vertices get listed. Then the polys which each list 3 vertex id numbers. Then the bones get listed without their hierarchy but each bone has a list of vertices connected. These bones can only be matched to the hierarchy by name, unless there is some clever sorting pattern I have missed that one can then deduce the correct bone to frame matching.

However each frame has a Frame Matrix (even those empty ghost frames) which is from what I can tell meant to determine the orientation of that frame/bone relative to the parent/bone. So if a bone was the child of a "no name" bone then I could see the "no name" bone being important. Though I have never seen this as yet. These no name bones sometimes seem to appear on the ends of the hierarchy with no clear rule governing when they appear. What I do is export from the editor to X format and then resave the object as DBO then I am reading the DBO so this process may be adding some junk into the object.

Bored of the Rings wrote: "For some FPSC classic models, there can be more than 1 mesh in 2 different named frames e.g. the main body mesh and a separate mesh for say, a sword or weapon of some sort."

Well that's a mess to handle. It's not enough to just know that. You'd have to know whether the vertex list started at 0 (which would be sensible) or some other number, because the polygons and bones reference the vertex id's. So if all of those are being pooled into a master list for conversion to another format they would need to be adjusted to higher numbers. So the devil is in the details.

I find this while format is one big convoluted tangle of nesting loops, a house of cards. Very clever and probably quite speed efficient. Just not straight forward at all.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Oct 2018 20:00 Edited at: 10th Oct 2018 20:06
Hello,

I don't know if it will help, but there is an old DBPro export plugin for Deled 3d. What I remember about Deled 3d format (the non XML format) was that it was very straight forward and easy to parse. My point is that if you can look at the plugin for DBPro and see how the simple Deled format was exported to DBPro, it might give you some insight into what is what.

here is the link though I can't remember if the source is included.

http://www.delgine.com/plugins/viewPlugin.php?catid=40&catdesc=Exporters&contentid=29
Enjoy your day.
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 11th Oct 2018 19:57
Thanks for the suggestion.

At this point the only obstacle to being able to fully convert formats is converting the angles in each animation frame. The values require some clever university math, I haven't had the opportunity to exhaust all options with it just yet. I have noticed that this might not be a conversion needed when converting between DBO and X format. It's an issue caused by the editor's format. The angles stored in the X model and DBO model are the same values.

Here is an example of what I am working with:
Rotation in the DBO and X formats: X:0, Y:0.707107007504, Z: 0, 4th rotation value: 0.707107007504
Rotation in the editor format: X: 0, Y: -1.57079613209, Z: 0

So you can see there is not much here to work with. Some how 3 XYZ rotation values turned into 4 values. Both appear to be in radians. They don't seem to correlate at all. The model appears to have been rotated 180 degrees between the two formats part of the original conversion process when I was creating the DBO from a model made in the editor. I need to account for that and maybe the values will look simpler to sort out when that happens. Like how can an angle turn into a 0? The only reason I can think of is if there is a rotation 90/180/360 degree rotation of some sort. So a clue there.

I have looked at the source code for DBP and the editors X format exporter, but these are difficult to use in this case. DBP source code tends to read a whole block of data, store it as a block and in the labyrinth somewhere the block is peeled apart and processed. The editors X exporter will say something like get rotation matrix or transform vector and proceed to use internal API's that I can't use or examine. So there's no A = B + C moments.

What I am planning to do is to simply create a model with 2 polys and 2 bones. Then I will create very specific animation rotations and examine how those values get converted. Then hopefully I can learn the conversion process. If not then I will need to learn some serious matrix math.



Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Bored of the Rings
User Banned
Posted: 11th Oct 2018 20:34 Edited at: 11th Oct 2018 20:40
ah yes, for ROTKEYS/ROTDATA animation data (not MATRIX), I had to swap some data around i.e. for X format, W,X,Y,Z but in DBP is X,Y,Z and W:



code below, also ensured object didn't move/rotate to wrong position when the animation was selected in Fragmotion.

Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 11th Oct 2018 21:00
I don't suppose you know that W refers to in this case? It would explain why the rotations are 4 values in DBP and only 3 in the editor.

Bored of the Rings wrote: "code below, also ensured object didn't move/rotate to wrong position when the animation was selected in Fragmotion. "

This tells me what I was suspecting. That all these different codes and things don't necessarily come in the same order for all models. So Frag Motion must assume some order that screws up the animation a little if your DBO isn't arranged that way. Because (for people reading this) when reading the DBO file there's a lot of [ID CODE][DATA][ID CODE][DATA]. Maybe the Bone name comes before the coordinates, maybe before, etc.


Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Bored of the Rings
User Banned
Posted: 11th Oct 2018 21:15 Edited at: 11th Oct 2018 21:25
I believe W means Weight.

Quote: ""code below, also ensured object didn't move/rotate to wrong position when the animation was selected in Fragmotion. ""

It's the same problem whatever modelling program I use and also when loading into GameGuru.

For codes/codesize/data, there is a specific ordering. Here's a complete output of all codes and ordering on the example I used previously i.e. Elhumongo.DBO. NOTE: this is a reWIP and so some of the output / counts for the embedded DBO codes need fine tuning.

It's a good idea to split the main data i.e. Root data from the animation data. I've yet to do that in the reworking project, and will do so shortly. So you might see some odd codes in wit hthe animation data at the moment, so can ignore those ones but in anim data you should /will eventually see only codes from 200 onwards.

Just to re-iterate, if anyone else is reading this, my program reads in a DBO (or binary X file) and produces an ASCII direct X format or OBJ. The reason I dis the program was so that I could read the formats in human readable form and change texturefilename in the X format mainly for Gameguru tools I wrote (mainly to import objects/segments and levels from FPSC to begin with).
The program works with skinned / animated meshes / objects and static objects.

What I also did in the program was to add ID's of frames so I could link any meshes etc to linked frames as well as texture / materials / bones etc.
In some cases , pBLOCK / pData does not exist for e.g. boolean flags e.g. USE MULTIMAT and similar codes.
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others

Attachments

Login to view attachments
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 11th Oct 2018 22:04
Very strange. I would have expected that value to be 1.0 if it was a weight as the exporter I used does not support weights. Also 0.707107007504 is repeated with other values which are not weights.
Thanks for the info.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Bored of the Rings
User Banned
Posted: 11th Oct 2018 22:55 Edited at: 11th Oct 2018 22:56
correction, sorry it's been ages since I worked with this. axis is made up up XYZ and W is rotation around that axis. So, I believe it's WXYZ . I guess it could named R, but I just used W as read in some reference docs somewhere and can't recall where, maybe microsoft docs or EZRotate docs.
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 13th Oct 2018 19:31
4 values in an angle is usually a quaternion

https://en.m.wikipedia.org/wiki/Quaternions_and_spatial_rotation
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Bored of the Rings
User Banned
Posted: 13th Oct 2018 22:12
Correct. I guess I should have just said that ha . Oh well it's been a long week .
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 14th Oct 2018 19:31 Edited at: 14th Oct 2018 19:44
Thanks for the tips, little details like this are very helpful. I have seen the term Quaternion mentioned in the documentation. So I will need to familiarize myself with this concept. I have to go through the added step of taking apart the math here not just unpacking and repacking existing angle values. Before I began all of this I knew that it would eventually end up in the lowest dungeon on the highest peak with this demon to slay. Now I am standing face to face with it. The hardest part of the process.



When I have enough free time I will be able to go deep with the math and hopefully sort this out.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 15th Nov 2018 23:04 Edited at: 15th Nov 2018 23:06
Still been working on this a few hours a week. Went deep with the math. This might seem like babbling.
So DBO and X format use Quaternion's (basically a set of 4 convoluted numbers ) to represent bone rotation. Not an issue.
The real problem is that the editor uses fixed axis XYZ rotation. This requires some complicated math to convert between the two.

It took a bunch of research to find out that Euler XYZ is not the same as Fixed Axis XYZ. Basically fixed axis rotates along axis that don't move. With Euler XYZ the x rotation happens, then y then z and the axis of rotation shifts each time. Apparently this produces a completely different orientation. This matters because if you look up a converting to/from Quaternion it will make the values completely wrong. Making matters worse Fixed Axis XYZ rotation is considered a type of Euler rotation, 'Extrinsic' instead of 'Intrinsic' rotation. Worse still rotation order is important XYZ/ZYX/etc. which means certain conversion examples won't work and often you don't know which. Then if that wasn't enough everyone has different terminology (Attitude/Heading/Bank or Pitch/Yaw/Roll or X/Y/Z).

I've been able to convert between Quaternion and Euler XYZ. Just going the extra bit converting Euler XYZ to XYZ Fixed Axis is still not done. Though I have some leads on the issue.

With Quaternion there seems to be one standard so it's just a matter of getting the work done. With Euler and Fixed Axis, it's a mess and when you look at an implementation, everyone has different terminology or rotation order (Attitude/Heading/Bank or Pitch/Yaw/Roll or X/Y/Z) so you never really know if the implementation will help. Then in my case some tweaks might be needed. I have noticed that when I convert the MESH+Bones back to the editor they come back Y rotated 180 degrees. So that has to complicate figuring out the bone angle conversions.

Also I have noticed checking source codes is not as helpful as one might think. I checked the source code for my editor's plugin to find out how it converts to X Format (since I noticed the DBO angle values are identical to X Format's) and what tends to happen is the angles will get sent to a few API calls that I obviously can't use and some magic voodoo will happen and they get spit out as the converted values. Leads to a bit of a dead end.

I think the biggest hurdle overall though is not knowing what needs to be done. So I've been chipping away at this little by little and there's progress.


Edit:
Also I haven't found a clear quick example anywhere of converting between Quaternion and Fixed Axis rotations. Though I was looking at that EZ Rotate plugin and it might allow me some options to bypass some of the hard math here. More investigation needed.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 17th Nov 2018 19:12
Quote: "The real problem is that the editor uses fixed axis XYZ rotation"

If it's not a secret , can you tell us which editor is this ? I can't imagine an editor where you can't use quaternions or 4x4 transformation matrices directly... Are you sure "quaternion to fixed axis" conversion is necessary ?
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 17th Nov 2018 20:53
I try to cut down on details that don't matter but sure I'll go further in areas if asked. I mentioned this earlier this year I am converting between MS3D and DBO.

Reasons being:

1. The editor is simple to use, so I use it.

2. The built-in plugins require me to export to X format, and then optionally use Dark Basic Professional convert from X to DBO. The editor does not export vertex weights this way.

3. I was using Frag Motion as an alternative. It's annoying to constantly need to type the lords prayer to launch it, and the resulting export omits one of the bones in the model!

Wouldn't it be nice if I had a program that just converted the model 100% no defects, exactly the way I wanted it?

So I decided, swallow the pill, write a program that byte for byte reads the MS3D file and writes out a DBO in the exact way it's supposed to be, and the reverse. So all of the many obstacles have been beaten except a final few. One of them requires higher order math skills to resolve. In DBO and XFormat the angles for each bone during animation are stored as a Quaternion - A set of 4 numbers that through complex math represent XYZ rotation. The editor stores the angles as just the X Y Z values as radians. Converting between the two appears to be difficult. Also figuring out that this was the problem was it's own problem since all I began with was me looking at some decimal numbers and trying to make sense of them. It's a lot easier once you know that needs to be done.

So then I went looking for methods to convert the values and they didn't work.

Then I found out there is a difference between Euler XYZ and Fixed Axis XYZ. Briefly: Imagine you have a character facing forward, X rotate 90 degrees so he is facing down, then Y rotate 90 so he is still facing down but his head is now pointed to what was originally his left. This is fixed axis and the way the editor works and stores it's angles. Euler XYZ works by first X rotating 90 so the character is facing down, then y rotate according to is current orientation so he turns on his side facing what was originally his left but the head still points forward. So both are XYZ but have different orientation and the order XYZ/ZYX matters. This causes any implementation you find to be a complete mystery on whether it will be correct or not. People play lose with the terms, have their own terms, use different rotation order,etc.

But figuring out what the problem is, is a major step towards fixing it.

Then after that I need to figure out what these frame matrices are. They seem to be yet a 4th means to store rotations in a general math sense. However why each bone would have them (in DBO format it seems they are stored twice - once for each bone in the bone data - once again in frame hierarchy) is a mystery that needs to be solved. I don't simply need to move the data around, I need to generate and convert it. This requires a firm understanding of what it is, why it is used, and the math. I suspect to a high certainty this is for bones that have base rotations that are not zero that offset all of the animations. This is by no means certain, and even if true there may be some special treatment to correctly calculate the values. The editor stores just XYZ angles for each bones starting rotation. They are typically all zero. Why two sets of Frame Matrices for DBO? Very strange. If I am right then only one should be needed.

Once I can convert between Quaternion and Fixed Axis reliably then I will likely find myself needing to convert between one of those and Rotation Matrix.

Assuming that goes well. That leaves me with a pathway where the conversion process works and I just have to widen it. So I'll need to go back and handle multiple texture support. Also as Bored of the Rings implied there are some unconventional ways DBO files can be organized that will break the code I have that processes the structure. The DBO file is like a recursive tree that has been flattened and put into a file line by line. My process has been to take a character exported from MS3D to X to DBO, read the DBO, process it's parts and convert it back to MS3D. There are specific things like bone hierarchy being all stored together with the root frame (or was it the frame after the root frame) that might not be the case if I say download a FPSC world file or a Dark Matter Pack humvee model. So that's some last stretch before the finish line stuff that will need to be done in the next phase.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 18th Nov 2018 08:57
Did you try the Ogre ms3d converter method ?
https://bitbucket.org/sinbad/ogre/src/10fa39065c763a605e16466a84fbeab00433d133/Tools/MilkshapeExport/src/MilkshapePlugin.cpp?at=default&fileviewer=file-view-default#MilkshapePlugin.cpp-687

Starting from line 687 the guy complains about ms3d's stupid and limited euler rotation and tries to build a quaternion from it. Not sure if it works but worth a try.Unfortunately ms3d was abandoned like 10 years ago so most of the informations and tutorials are from 2002.
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 18th Nov 2018 22:06 Edited at: 18th Nov 2018 22:07
Thanks for the suggestion.
I can see this does the a similar thing to the X format exporter but it's much more readable here.

He creates a Quaternion to store the values in:
Ogre::Quaternion qx, qy, qz, qfinal;

Then he invokes an API I can't use to do all of the hard work:
qx.FromAngleAxis(Ogre::Radian(msBoneRot[0]), Ogre::Vector3::UNIT_X);
qy.FromAngleAxis(Ogre::Radian(msBoneRot[1]), Ogre::Vector3::UNIT_Y);
qz.FromAngleAxis(Ogre::Radian(msBoneRot[2]), Ogre::Vector3::UNIT_Z);

There is a W which is the 4th quaternion value. It seems like he calculates it here although I am not certain. Ogre::Quaternion qx, qy, qz, qfinal; implies qfinal is W. Though I am not sure that is how you calculate W and why is it that when he finally sets the orientation all he uses is qfinal? ogrebone->setOrientation(qfinal); Why not pass the entire quaternion? Somewhat strange.
qfinal = qz * qy * qx;
ogrebone->setOrientation(qfinal);

It's possible though that in one of those include files is an implementation for quaternion.FromAngleAxis() otherwise again its just magic mystery box numbers go in one side and come out converted on the other.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 18th Nov 2018 23:35
Quote: "Ogre::Quaternion qx, qy, qz, qfinal; implies qfinal is W"

No. qx, qy, qz, qfinal ARE ALL QUATERNIONS. All of them have their own w component (eg qx.w or qfinal.w ) So there are 4 identity quaternions set up. Then he builds 3 of these quaternions from axis angle. The axis angle function usually (in all game engines)looks like this :



As you can see this function takes a float value and vector3 which represents you axis of rotation.In your case the rotation is msBoneRot[0] (the rotation on x axis) msBoneRot[1] (y axis) and msBoneRot[2] the z axis.
because the function works with radians he first convert degrees to radians with the OgreRadian() function. The Ogre::Vector3::UNIT_X Y and Z are constant 3d unit vectors where Ogre::Vector3::UNIT_X is a Vector3(1,0,0) Ogre::Vector3::UNIT_Y is Vector3(0,1,0) and UNIT_Z is Vector3(0,0,1)
Now the quaternions are set up.Each contains a rotation on one of the axes.

Now comes the magic. Don't forget qfinal is NOT the W component of a quaternion but IT IS a quaternion.
So now he builds the final quaternion by multiplying the 3 quaternions in the proper order (XYZ) (actually the * does not perform multiplication in the world of linear algebra but i don't want to confuse you even more , so lets just call this operation addition or transformation...)
qfinal now contains (hopefully) the proper rotation for the bone.

Quote: "It's possible though that in one of those include files is an implementation for quaternion.FromAngleAxis()
"

You can find the implementation of that function in OgreQuaternion.cpp or OgreQuaternion.h file.
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 19th Nov 2018 02:05
Yeah thanks that makes a lot of sense. I had not ever seen that programming language before and I figured that my reading of the syntax was a bit off and I knew that my initial take on this could not be correct because I have seen enough completed conversions to know the math would not work that way. I have only had a few minutes at a time to look this over. The extra explanation is very useful. My giving a "hot take" however flawed worked well.

I can see that he basically has a simple function that will create a quaternion from a single angle, and a value that designates an axis. So he creates a quaternion for each angle XYZ and then creates a 4th by combining the 3 rotations. A very sensible approach. I am going to have to track down and tear apart that quaternion.FromAngleAxis() function. Hopefully it does not have more API voodoo in there.

Secondly the manner in which he combines the quaternions is an issue.
Quote: "actually the * does not perform multiplication in the world of linear algebra but i don't want to confuse you even more , so lets just call this operation addition or transformation..."


I had figured I must be wrong, qFinal must be a complete quaternion because why would he go through the trouble creating a quaternion above if he wasn't going to use it. So I suspected that the multiplication in this case was deceptively some higher order math at work and not regular multiplication. I picture in my head some convoluted 3 matrix addition or something like that is at work mathematically. I have a background in this kind of math but it has been a very long time. The bottom line though is that this is yet another special case that I can't use in DBP. However knowing is half the battle, this cannot be understated. So some other generic Quaternion combining code is likely to be helpful here.

If that all pans out then that leaves reversing the process. These are not the kind of equations you just rearrange. I'm about 90 percent of the way getting the reverse conversion. There's a few things I have a lead on. EZ Rotate plugin might have some useful commands , and there are a few math resources which would be a little harder. I have been looking at code examples online but because MS3D uses XYZ rotations in a specific fixed axis way I haven't found anything that actually works. Otherwise 'snap done.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 19th Nov 2018 11:22 Edited at: 19th Nov 2018 16:58
i already started to create a plugin for this. Unfortunately i don't have DBP on my machine but the functions should work.
The command :


will calculate the quaternion and after calling it you can access the last calculated quaternion components like this



EDIT : Ok so i attached the plugin and it should work however it is untested.
Example :

[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]

Attachments

Login to view attachments
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 20th Nov 2018 13:02
Ok.. so did you tried the plugin i posted ? Any luck ?
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 20th Nov 2018 21:04
Thanks for the help. I have not been able to work on this since then. Possibly later today or tomorrow.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 20th Nov 2018 23:59 Edited at: 21st Nov 2018 00:04
I just tried it and it doesn't seem to work correctly. I think it's because the editor's rotation is not quite typical EULER XYZ.
Also complicating things is the model seems to get a Y180 rotation from the editor to DBO. I know this since the mesh when converted back is rotated. So this might complicate things when comparing the bone angles. I am not 100% how just yet, if at all.


So Example:

Editor (radians):
X= -0.180733591318
Y= -0.565487265587
Z= -0.180733695626

Correct Result (quaternion):
X= 0.111382000148
Y= 0.268898993731
Z= -0.111382000148
W= 0.950200974941

Plugin Result (quaternion):
X= -0.111382
Y= 0.268899
Z= -0.111382
W= 0.950201

Now you might think that these values look similar. Under normal circumstances you might just apply a simple correction but that doesn't work. Many angles would end up wrong. No clear pattern. This plugin might work though to make 3 separate single axis quaternions that can then be combined like that previous code example but more work is needed to determine that.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 21st Nov 2018 02:46 Edited at: 21st Nov 2018 02:47
Not sure if it helps any, but keep in mind that dbpro uses a left handed system (y is up) while many other applications use a right handed system (z is up)

Just as another point of reference, you might check out the .x exporter script in Blender. It is in python, but it exports quaternions to left handed xyz and was originally written by an old tgc forum user for getting models from blender into dbpro.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 21st Nov 2018 15:55
Quote: "Now you might think that these values look similar. Under normal circumstances you might just apply a simple correction but that doesn't work. Many angles would end up wrong. No clear pattern. This plugin might work though to make 3 separate single axis quaternions that can then be combined like that previous code example but more work is needed to determine that."


If the only difference is the sign of the numbers then it might just need a bit of rework. Try different rotations and compare the result.If the results are the same (disregard the sign of the numbers) then i might be able to hack out something...
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 21st Nov 2018 19:58 Edited at: 21st Nov 2018 19:59
Possibly and the work goes on looking into that. However I have an impression that this might be a rare case where that isn't possible. Not giving up or anything.

Here's a good example, the conversion I mentioned above:

Editor (radians):
X= -0.180733591318
Y= -0.565487265587
Z= -0.180733695626

Correct Result (quaternion):
X= 0.111382000148
Y= 0.268898993731
Z= -0.111382000148
W= 0.950200974941

It turns out when I then convert back using an online angle converter I found out that X and Y have turned into -X and -Y. So then you think wow I'll just invert my X and Y then the conversion to Quaternion will work. Well it turns out you suddenly get a completely different Quaternion. Also (and I'll need to double check this) but it looks like this doesn't apply to all angles, like I might convert another set of angles and need a different correction entirely. So it's very tricky.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 21st Nov 2018 23:46 Edited at: 21st Nov 2018 23:46
Please try and post other converted values too. If the only difference between the correct and my plugin's result is the sign of the numbers then i might be able to work out something.
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 23rd Nov 2018 01:14
QUATERNION X, Y, Z, W - Extracted from DBO
Rotation: 0, 0, 0, 1
Rotation: 0, -0.382683008909, 0, 0.923879981041
Rotation: 0, -0.707107007504, 0, 0.707107007504
Rotation: -0, 0.923879027367, 0, -0.382683992386
Rotation: -0, 1, 0, -0
Rotation: -0, 0.923879981041, 0, 0.382683008909
Rotation: 0, 0.707105994225, 0, 0.707107007504
Rotation: 0, 0.382683992386, 0, 0.923879027367
Rotation: 0, 0, 0, 1
Rotation: -0.353552997112, -0.353552997112, -0.146447002888, 0.853552997112
Rotation: -0.270597994328, -0.653280973434, -0.270597994328, 0.653281986713
Rotation: 0.146447002888, 0.853552997112, 0.353552997112, -0.353554010391
Rotation: 0, 0.923879981041, 0.382683008909, -0
Rotation: -0.14644600451, 0.853554010391, 0.353552997112, 0.353552997112
Rotation: -0.270597994328, 0.653280973434, 0.270597994328, 0.653281986713
Rotation: -0.353552997112, 0.353554010391, 0.146447002888, 0.853552997112
Rotation: 0, 0, 0, 1
Rotation: -0.191341996193, -0.46193999052, 0.191341996193, 0.844623029232
Rotation: 0.323222994804, 0.780330002308, -0.323222994804, -0.426777005196
Rotation: 0.354662001133, 0.856230020523, -0.354662001133, 0.123691998422
Rotation: 0.275887995958, 0.666054010391, -0.275887995958, 0.635722994804
Rotation: 0.111382000148, 0.268898993731, -0.111382000148, 0.950200974941

Fixed Axis Euler X, Y, Z (radians) - Extracted from MS3D
Rotation: X: 0, Y: -0, Z: 0
Rotation: X: 0, Y: 0.785398066044, Z: 0
Rotation: X: -0, Y: 1.57079601288, Z: 0
Rotation: X: 3.14159274101, Y: 0.785398602486, Z: 3.14159274101
Rotation: X: 3.14159274101, Y: 6.14124587628e-007, Z: 3.14159274101
Rotation: X: 3.14159274101, Y: -0.785397410393, Z: 3.14159274101
Rotation: X: 0, Y: -1.57079553604, Z: 0
Rotation: X: 0, Y: -0.785399079323, Z: 0
Rotation: X: 0, Y: -0, Z: 0
Rotation: X: 0.785398125648, Y: 0.785398125648, Z: 0
Rotation: X: 0.785398066044, Y: 1.57079601288, Z: 0
Rotation: X: -2.35619473457, Y: 0.785398423672, Z: 3.14159274101
Rotation: X: -2.35619449615, Y: 5.1796837397e-007, Z: 3.14159274101
Rotation: X: -2.35619449615, Y: -0.785397410393, Z: 3.14159250259
Rotation: X: 0.785398066044, Y: -1.57079541683, Z: 0
Rotation: X: 0.785397946835, Y: -0.785399198532, Z: 4.21468904221e-008
Rotation: X: 0, Y: -0, Z: 0
Rotation: X: 0.785398006439, Y: 0.785398066044, 0.785398006439
Rotation: X: 2.07126998901, Y: 0.47473976016, Z: 2.07126998901
Rotation: X: 2.51503348351, Y: -0.481814563274, Z: 2.51503348351
Rotation: X: 2.74068331718, Y: -1.52789902687, Z: 2.74068665504
Rotation: X: -0.180733591318, Y: -0.565487265587, Z: -0.180733695626

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Hotline
15
Years of Service
User Offline
Joined: 22nd Aug 2008
Location:
Posted: 23rd Nov 2018 21:41
It seems that (for an unknown reason) the rotation order is always different that it should be which ends up in this "sign inconsistency" nonsense... I am affraid without any detailed information i can't help you any further.
It must be something at DBO loading time because i swear , the values from my plugin are 100% correct. I get the same results from game engines , my quaternion class , and i even tried an online converter which gave me the same results.
[href=forum.thegamecreators.com/?m=forum_view&t=191567&b=5]Spark Particle engine[/href]
[href=forum.thegamecreators.com/?m=forum_view&t=199163&b=5]Transform gizmo plugin[/href]
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 23rd Nov 2018 22:57
Yes no doubt something very specific to the editor. However there is great value in at least being able to correctly make the conversion you have provided.

The first example you provided involved separating the X, Y, Z into their own separate rotations. Converting each of them to Quaternions. Then Combining those 3 Quaternions into one final Quaternion.

Even though there's some screwy stuff happening with how the editor does XYZ and it not being proper Euler XYZ, a single axis rotation is still equivalent between the two. X=90, Y=0, Z=0 would convert correctly using your code since it's just one axis for example.

So this then means one can use your code then figure out how to QFinal = QuaternionX * QuaternionY * QuaternionZ
Since as we both agreed the multiplication here is not actual multiplication but some convoluted vector matrix type math it is also convoluted to work out. But it might be something that could be worked out. It's a much more generic math problem not specific to the editor's implementation of angles so looking up a code example is bound to be easier.

This all assumes that first example you provided actually works.
There is also a slight possibility that one or more of the axis might be flipped as I mentioned the model seems to rotate Y180 in the exporting process. I can also take a second pass at trying to eliminate that with the exporting to make things easier if possible. It didn't appear to be.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 30th Nov 2018 03:23
I appear to have cracked the calculations.
So just to recap. I was converting MS3D files byte for byte to DBO directly. This was hard and the documentation not that great but I was getting along with it. Then near the end I hit a snag because the editor and DBO use different math systems for storing the angles of each bone in each animation. This required higher order math skills to develop a conversion. Hotline offered a few suggestions and some of them ended up being helpful.

So moving on:
The Ogre ms3d converter method of creating quaterions for each of the XYZ rotations separately then combining the quaterions with matrix multiplication into a final quaternion appears to work.
So as I mentioned just before the editor's XYZ is not the same as typical Euler XYZ. However if 2 of the 3 angles is zero then the conversion to Quaternion is the same. This is because rotation order issues cancel out if 2 of the angles is 0. So separating them out can be done with normal conversion methods. Then standard methods of combining them into a final quaternion also works.

Another issue comes from the fact that I needed to take a model and use the regular exporter to convert it to DBO so I could compare the original angle values with the proper DBO angles. I noticed this process turns the whole model around backwards. So I messed with the exporter settings and made it not do this so it would no longer screw with the angles and make things more simple for me. In more technical terms it was exporting as a left handed model and I set it to right handed.

This left a few sign glitches, but they seemed to go away when I wrapped the editors angles.

I still haven't sorted out how to convert back but that is a lesser priority and at this point I want to move on. I'll come back to it.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!
LBFN
16
Years of Service
User Offline
Joined: 7th Apr 2007
Location: USA
Posted: 1st Dec 2018 16:49
Thank you for doing this! I still use Milkshape and to have a direct transition from MS3D to DBO would be awesome. Keep up the good work.



So many games to code.....so little time.
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 1st Dec 2018 18:09
Thanks It means a lot to know that people are interested or might find this useful.

I will just mention a few things that I am thinking about. (Since someone might offer insight)

The bone list has a peculiar order (not the proper order) and I am wondering if this order is important.

The DBO is sorted into frames named after each bone, but then in one of the parent frames all of the bone hierarchy and data is stored. This seems to suggest that all these additional frames might not be necessary. I am wondering what happens when I don't include those frames but still keep the proper bone data. Or perhaps these frames are mandatory and not merely bloat from the exporter I use.

I have noticed that all of these bone frames (which form a sort of bone tree) always have an extra blank sibling or child frame (I forget which) at the tips. This seems like a waste. I am wondering what happens if I just delete them.

Some of these things will require experimentation. Some of it might be 'bloat' or 'flavour' from the exporter I used to create the DBO I am inspecting. Then again some of it might be undocumented structure and rules.

Mage's Modular Code - Get awesome UI controls and powerful Bitmap Fonts!
Screen Device Recovery - Stop your apps from crashing when minimized/tabbed/screen locked.
CPU Friendly Frame Limiter - Make your app generate less computer heat + noise, and use less battery life!

Login to post a reply

Server time is: 2024-03-29 02:03:56
Your offset time is: 2024-03-29 02:03:56