Jump to content
Hash, Inc. Forums
nemyax

MDL format details needed for exporter development

Recommended Posts

Almost there =)

 

4bd8bc8d7887583d6fbb3d1fae9ae046.png

 

 

EDIT:

...and it's done!

 

160d5aacbce4883e16d0283024cef2c2.png

 

I'll make a dedicated announcement when I've done some more testing.

Share this post


Link to post
Share on other sites

This sounds extremly promising guys :) Very cool what you have reversed engineered here :)...

 

See you

*Fuchur*

Share this post


Link to post
Share on other sites

you're humble Nemyax! ... many have stopped along the way.
You are an important person for the AM community. (There are so few programmers.)
Thank you for making this work. This allowed me to better understand the patches. and understanding among other difficulties in automatically close 5 pointers in AM). But there is still a lot to discover in the writing of the AM format. (hooks ....)
Your work is a hope to bridge between the world of polygonal and that of AM. Thank you again.
:)

Share this post


Link to post
Share on other sites

Impressive sluething!

I'm even more impressed if you did that in python.

 

That teamwork/communication thing... keep that up! :)

Share this post


Link to post
Share on other sites

there is still a lot to discover in the writing of the AM format. (hooks ....)

I'd rather hooks remained a post-Blender tweak. Not so much out of laziness as because there's no direct counterpart to a hook in a polygon mesh. You'd have to come up with artificial rules and impose them on the artist.

Share this post


Link to post
Share on other sites

Well, there's no cause for celebration yet. On a model that isn't a measly strip of three patches, the five-pointers still aren't textured correctly:

 

250_32653833b0fe59b451f256f3b6bebc4c.png

 

But it gets crazier. Nudge a CP, undo, and you end up with this:

 

250_d7e6fd16c7c9b4aa02eba026883d6ec2.png

 

Here's the .mdl if anyone wants to see for themselves: https://drive.google.com/file/d/0B___ge5IO2JdVUMzTEprb0N4aVE/view?usp=sharing

Share this post


Link to post
Share on other sites

It is normal that some 3 and 4 pointer disappear. AM does not accept patches that are bypassed with the same spline. It is possible to write them but once refreshed, the AM's motor destroyed them. :(
I will see deeper for the UV.

Share this post


Link to post
Share on other sites

AM does not accept patches that are bypassed with the same spline.

Do you mean a spline that crosses itself?

Share this post


Link to post
Share on other sites

I mean this :

1spline.png

Only Five pointers in this case can be patches when refreshed, alas :(

Your model have some "ghost patches" when refreshed.

You must used two or more splines to render this patches..

Share this post


Link to post
Share on other sites

I see. A hell of a limitation if you ask me.

But anyway, the fact that such patches are disallowed doesn't explain why A:M strips other, valid patches of their UVs. I've just tried the exporter on a torus, which has the most regular topology you can imagine, and the undo caused more than half the patches to lose their texture.

Apparently something's wrong about the way patches or CPs in them are ordered.

Share this post


Link to post
Share on other sites

"I'm not 100% sure of the solution, but it seems it is necessary to indicate the opening of the patches.
The patches with 5 pointers are written with 5 CPS (but indicates with four segments in the bitfield)
For UVs, there is 4 CPs, but you have to indicate which are in the
segment that are not indicated in the bitfield."
this is wrong.

 

For the momment here is what I found about writing UV patches :
The first CP of each UV patches must be the smaller. (and be the number with the coordinates)
example:
5 249 1396 1394 837
0 92 483 281 200
0 1206 1655 1574 1206

 

 

Is it the same for patches, must start with the smallest PC, careful not the one writing in patches, but the referent that carry the coordinates.

exemple

24 4 8 12 6

24 134 22 14 233 (if 134 is attached with a smaller CP than 14)

 

but I don't know if this is enough

Share this post


Link to post
Share on other sites

I've just tried your suggestion (start with the minimum-index CP) on the torus, and it came out partially textured. Interestingly, the nudge-undo trick didn't change anything this time.

The CP indexes are still those that carry coordinates.

Share this post


Link to post
Share on other sites

Nice model.

 

There is some patches that are bad,

for example :
Splines :
1 1 787 720 . .
1 1 795 788 . .
1 1 963 960 . .
1 1 959 553 . .
Patches :
96 787 963 959 788 1650 2558 1443 2918 0
UV :
0 720 788 738 890 0.749089 0.562176 0.000000 0.741461 0.563332 0.000000 0.733834 0.564488 0.000000 0.726183 0.565647 0.000000 0.720098 0.537709 0.000000 0.714013 0.509770 0.000000 0.707909 0.481748 0.000000 0.718851 0.479945 0.000000 0.729792 0.478142 0.000000 0.740767 0.476333 0.000000 0.743538 0.504919 0.000000 0.746310 0.533504 0.000000

or the smaller CP is not 720 but 553
so the patches must be :
24 959 788 787 963
an his Uv :
0 553 788 720 960 (...)

Share this post


Link to post
Share on other sites

Do you mean that the least-index CP should always carry the coordinates and be the target that other CPs are fused to? I think I checked for that specifically at some point, and it didn't always hold. But I might be wrong.

Share this post


Link to post
Share on other sites

What i mean is that :

 

The Patches is write as this :

 

bitfield CP1 CP2 CP3 CP4 ..

The CP1 must be the smaller CP (of all CPs, CPs attached too) if this is the CP that carry the coordinates, then it will be the CP attached to it.

 

To write UVdata:

0 CP1 CP2 CP3 CP4 ...

CPs are the same as for the patches (if a CP not carry the coordinates, so write the CP attached with the coordinates.)

Share this post


Link to post
Share on other sites

Hi,

 

I have been experimenting a bit in creating mdl files,

I tried understanding how you calculate the bitfield for every patch but I cannot get it to work.

 

In my particular implementation all splines contain only 2 cps, meaning I do not follow any spline flow at all,

I just create 2 cps splines as necessary to be able to create a patch and reuse the ones that are already created if adjacent.

 

This is what I am doing appart from the bitfield

CP1 = master cp containing position info to wish our cp is attached to.

CP2 = cp of the next spline attached to CP1 next cp.

CP2 = cp of the next spline attached to CP2 next cp.

CP3 = cp of the next spline attached to CP3 next cp.

 

then there are 5 numbers more, and as I understand the first four reference the index of each cp normal

 

so for example I am writing this

120 1 5 8 10 1 2 3 4 0

 

To go further I am just playing with the idea that you may not need to actually convert any polygon mesh to a Hash spline model but rather just build the model like the polygon mesh, and preserve uvs, etc.

This way the polygon mesh can be used and viewed as intended originally. And you can still animate, bend, etc and do everything else to it.

 

But! there will have to be a way to display them smooth like a 'Prop' would. Maybe a new property added to the models to set it to display sharp connected edges smoothly.

 

I think that would be a big jump, no more trying to convert polygons to patches but just use them as they were intended, even to be able to animate them, bend, etc.

Share this post


Link to post
Share on other sites

hello rasikrodri,

 

I hesitate before answering because I don't speak english , so I 'm not sure I understand what is being asked . (sorry if this is the case.)

 

You converted to splines EVERY edges, so every spline is a line with two Cps . (As Hamapatch was to import the objects from Metasequoia ) . It can be a solution for not having ghost patches (holes) ... but you lose the subdivision.

To return to writing the patches, it does not seem that changed a few things, because a spline that have two or more CPs , it has an orientation that must be considered when writing the bitfield of patches.

Share this post


Link to post
Share on other sites

Hi Malo,

 

Your English is just fine.

 

Yes! (As Hamapatch was to import the objects from Metasequoia )

 

I am not worried about loosing the subdivision. What I am worried right now is about writing the model file correctly including the patches, uvs, etc.

 

What I am trying to do is to import a mesh just as a polygon mesh and not converted to a spline mesh. Yes it is actually using splines to represent the polygons.

But the idea behind it is to stop trying to convert polygons to splines.

 

"I finally came to the conclusion and acceptance that the best way to import a polygon mesh is as a polygon, because it was designed like that, as a polygon mesh."

 

You will think that none of the patches/polygons are going to look smooth. And that is correct.

But the first step to an idea I have is to just turn a mesh polygon file into model file with the exact shape and exact polygons.

 

I would prefer to solve this first before going into the next step so I can show the idea more clearly.

 

Basically Animation Master may be able to work directly with polygons. Something that is not been built in it but that may be achievable using splines as polygons.

Share this post


Link to post
Share on other sites

Actually I can always create the patches with unique exclusive splines but that will increase the amount of splines in the model,

and AM will not know that those patches are connected.

That is why I need them connected.

Share this post


Link to post
Share on other sites

There may be a solution :
You must use one single spline by polygons and peak them.
for example :

262144 0 1 -14.9114 7.65905 0 . .
262144 0 2 -15.9959 0.135558 0 . .
262144 0 3 -7.38793 -0.0677792 0 . .
262148 0 4 -7.25237 8.26906 0 . .

for
v -14.9114 7.65905 0
v -15.9959 0.135558 0
v -7.38793 -0.0677792 0
v -7.25237 8.26906 0
f 1 2 3 4


The patche will be a hole if there is only one polygone, but once you stick to another closed spline , it will be possible to write patches. for example :
for
v -14.9114 7.65905 0
v -15.9959 0.135558 0
v -7.38793 -0.0677792 0
v -7.25237 8.26906 0
v 1.83004 10.9802 0
v 8 2.57561 2.64339 0
f 1 2 3 4
f 5 4 3 6

you can write this :

262144 0 1 -14.9114 7.65905 0 . .
262144 0 2 -15.9959 0.135558 0 . .
262144 0 3 -7.38793 -0.0677792 0 . .
262148 0 4 -7.25237 8.26906 0 . .


262144 1 5 4 . .
262144 1 6 3 . .
262144 0 7 1.83004 10.9802 0 . .
262148 0 8 2.57561 2.64339 0 . .


16 1 5 3 2 0 0 0 0 0
8 3 5 8 7 0 0 0 0 0


Hope that will help you.

Share this post


Link to post
Share on other sites

Thank you very much, that is a good idea, I will test it and let you know

Share this post


Link to post
Share on other sites

Hi Malo,

 

I am doing my experimentations now, for what do 16 and 8 at the beginning of the patch stand for?

I mean, I read all the info you posted earlier, I do not expect you to post it again, but I think is going to help me if you could explain the reason for choosing 16 and 8.

 

Also, I could just let AM calculate the patches, but I want to add the uvs as decals.

I don't know if I am doing it wrong but if write the uvs to the model file and not the patches when I load the model. AM crashes. Maybe I am loading them wrong.

 

I really would love to be able to write the patches my self because the code I wrote is extremely fast. For a dense polygon mesh it takes less than a second.

Share this post


Link to post
Share on other sites

Ok the patches get created like that but they look very messy I guess the bitfield is tells how the patch should generated the geometry inside of it

Share this post


Link to post
Share on other sites

Yes the bitfield is tells how the patch should generated the geometry inside of it
The choice of 16 and 8 depends on the orientation of splines that form the patches.
BITFIELD2.png
nemyax might be better explain in good English, because he understood the bitfield

Share this post


Link to post
Share on other sites

Yes, I saw the graphical explanation, but I think I am missing something, I can't understand some things.

Originaly I was creating two cp splines per polygon edge, many of the patches shared the some same splines. I would asume I could use only one or two different bitfields but it is not so.

 

Do I calculate the bit field according to the direction of each spline forming a patch?

Share this post


Link to post
Share on other sites

Do I calculate the bit field according to the direction of each spline forming a patch?

Yes. It matters.

Share this post


Link to post
Share on other sites

But I see that Malo does not always use all the splines of a patch to calculate the bitfield.
Do you know why?

Share this post


Link to post
Share on other sites

Could you tell me what is the bitfield I write where you don't understand, I will try to explain better :)

Share this post


Link to post
Share on other sites

In the example you wrote the one with 16 is calculated using only 3 splines,

in the one with 8 you only used one spline to calculate it why?

 

Thank you for your patience and willingness to help!

Share this post


Link to post
Share on other sites

There are different combination of CP to write a patch, for example 1 5 3 2, 5 3 2 1, 3 2 1 5... etc. but for each combinaison of CP the bitfield will be different. (It seem it better to began with the smaller CP)
I come back for the example 1 5 3 2, and explain it :
when I write the first patch in the orientation 1 5 3 2, the orientation is left, right,left, left. So the bitfield for that is 16
the second patch is 3 5 8 7, right, left, left, left. So the second bitfield is 8.

bitfield3.png
For the fun, it is possible to write a patche with only Cps from one spline with the bitfield 0 or 120 ( but when you will refresh, it will be clear)

Share this post


Link to post
Share on other sites

Ok, I think I am understanding now, but why did you use cp5 instead of cp4 in the first patch.

And again you used cp3 instead of cp6 in the second spline?

Share this post


Link to post
Share on other sites

When a spline arrive where an another spline arrive, you must take the Cp of the new spline.

You began with "1", you arrive to "2", but there is a new spline, so you take the CP of the new spline "5" you go to "6", but a new spline arrive, so you take 3, and after no new spline so "2" stay.

Share this post


Link to post
Share on other sites

Same with the other patch : you began with "3" you arrive to "4", but a new spline arrive, so you write "5", after no new spline so you wrte "8" and "7"

Share this post


Link to post
Share on other sites
but why did you use cp5 instead of cp4 in the first patch.

 

What Malo said... but also recall what he said about patches formed from the same spline disappearing upon refresh because (by A:M patch rules) a patch must consist of two or more splines. Malo has also demonstrated above an exception to this rule of a single spline forming valid patches via use of 5 point patches. The easiest way to demo that exception is to lathe a 2 CP spline with 5 cross sections and then delete the bottom (or top) of the resulting cylinder/cone... leaving a circular spline of 5 CPs. The remaining 5 CPs on that single spline can then be closed as a 5 point patch.

 

If he had used cp4 the patch would consist of CPs all on the same spline and therefore not create a valid patch.

 

I should add: In current releases we can draw a single spline and close 5 point patches. My memory says this hasn't always been the case. But... technically in current releases at least a quicker way to demo creating a patch using a single spline is to simply draw the spline and then close the appropriate/valid 5 point patches. I should warn you though that as opposed to lathing where A:M is doing the work... this manual drawing method is likely to result in a crash.

Share this post


Link to post
Share on other sites

Here's an example of a grid created out of 5 point patches.

There are 6 (closed) splines.

Each color represents a different spline.

 

 

Disclaimer: Texturing of 5 point patches is generally not an optimal workflow

all 5 point patches.png

Share this post


Link to post
Share on other sites

Here's a more complex surface with 2 splines and all 5 point patches:

complex surface with 5 point patches.png

Share this post


Link to post
Share on other sites

Thank you guys, now I understand it more how the patches are created, as soon as I write the new code I will let you know.

Share this post


Link to post
Share on other sites

In actualatity I want to create a file converter that keeps the uvs, the bones with weights, and if I have the time, the morph targets as pose slider.

 

The thing is I do not want to keep trying to convert meshes to AM splines, they look good with polygons because they were build with polygons. I am trying to just bring those meshes into AM as they were created, but animate-able.

 

Apart of being a hobby, I would like to submit an AM request, but I wanted to show something first.

 

The request would be for someone to create a shader to display flat patches that are connected as smooth like polygons do, and hopefully a real-time version will be added to AM.

 

But I am building the converter in a way that I can release a simple dll that anyone can use to incorporate any new mesh file type that I haven't added to the program. And they can do it even using Visual Basic.

 

I can already convert the mesh into a model. Because I work 8 hours a day I skipped the patch creation code(because I was having problems with it) but instead I am letting Am create the patches for me.

Then I reload the model with the patches and all the uv, normals etceteras, are added into the model file .

 

Right now I am trying to calculate and write the uvs the correct way. I can see some patches with the texture but some not.

 

 

This is what I understand about writing uvs in model file:

The first number is 0

after that comes the main cps(the ones that contain the x,y,z position)

After that comes each uv of every cp, with 2 uvs in between them

 

But when I check the stamp I do not see all the cps of the model there, for some reason not all of them are being adeddto the stamp when AM loads the model.

 

If you could help me with this I will really apreciate it and it will be done much faster, because as I understand you were able to write the uvs correctly

Share this post


Link to post
Share on other sites

In the stamp I can see some of the cps of the model, and the look organized but the stamp for some reason does not have all of the cps.

 

All of uvZ I am entering as zero, is that fine or do I have to calculate uvz, I don't understand what is for, as I understand uvs only contain x and y.

Share this post


Link to post
Share on other sites

rasikrodri

I can only really refer you to the Python code for a perfectly precise explanation =)

https://sourceforge.net/p/blenderbitsbobs/code/ci/master/tree/io_scene_am_mdl.py

The indexes for CP referencing in MDL's UV data block are stored in vertices' additional integer data layer (search for the uvc variable). See how these indexes get written and read.

Note that CPs start at 1 in A:M. Also note that while I managed to transfer UVs successfully, the patches may appear twisted when the MDL is first loaded (but that is easily fixed in A:M).

Share this post


Link to post
Share on other sites

This is a test of an obj polygon elephant converted with my program. All the polygons are there. There is no spline continuity. I am using flat patches, with all their cps set to smooth, all the patches are connected and they share splines, all the splines have 2 cps. And I have turned "Average Normals" ON

 

The average normals wold need to be tweaked to really make that mesh smoother.

 

Anyway, I don't know if I will have time to play with this any further, but I see that it is possible to bring a polygon mesh as a polygon mesh into AM, with textures and if you want bones and weights, and maybe more.

I was able to bring hi-res meshes fairly fast and easy. But for rendering I think a subdivision technique like the one that pixar released for free would be wonderful, ust t make sure it look as smooth as possible. I never thought on converting AM into a polygon modeler, but it would be great to be able to import meshes from MakeHuman and Daz Studio, because you could pretty fast design humanoids using genesis in Daz Studio and they will be animatable. And of course all those 3D meshes that are for free out there that you would want to animate.

Elephant.jpg

Elephant No Average Normals.jpg

Elephant.mdl

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...