STEAM GROUP
Blender Source Tools BleST
STEAM GROUP
Blender Source Tools BleST
269
IN-GAME
1,719
ONLINE
Founded
8 November, 2013
All Discussions > Bug Reports > Topic Details
Pte Jack 8 Feb, 2016 @ 4:13pm
Don't know if this is a problem or just me...
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=619705440

Looking for an explaination why the DMX compile is out of whack, everything in Blender is set up and SMDs produce a perfect model from the same session? Can someone explain what is happening?

Thanks
< >
Showing 1-14 of 14 comments
Zappy 8 Feb, 2016 @ 11:06pm 
Select all objects, press Space, search for "Apply", choose "Apply Object Transform", tick on all three boxes on the left (Location, Rotation and Scale), press Space, choose "Apply Object Transform" again, and do it one more time just to be absolutely certain nothing's wrong.

Edit: By the way, are you using bodygroups or in some other way using multiple groups when exporting? If so, this might not fix it, and you should manually export every group one by one instead of using a scene export.
Last edited by Zappy; 8 Feb, 2016 @ 11:07pm
Artfunkel 12 Feb, 2016 @ 6:01am 
The comments on the image suggest that you don't have a common parent for the different objects. Not sure what's going on with the "default" slider in SFM though. Perhaps that zeroes mesh transforms?
Zappy 12 Feb, 2016 @ 6:55am 
Originally posted by Artfunkel:
Not sure what's going on with the "default" slider in SFM though.
For controllers (flex sliders, camera field-of-view, and such), it sets it to the default value.
For bones, it almost always sets translation and rotation to 0 0 0, despite that (usually) not being the default location for the bone.
Last edited by Zappy; 12 Feb, 2016 @ 6:56am
Pte Jack 12 Feb, 2016 @ 9:24am 
All objects have been to assigned to Vertex groups and weighted with a value of 1. There are no blended weights in the model. Bones control 100% of the mesh assigned to them. Each object has an armature modifier, all bones/vertex group names are correct. All objects have the location, rotation and scale coords "Applied", so rotations of objects is 0, xyz location of all objects and armature are in the same place (0,0,0) and scale for everything is 1.

Besides, if things were not set up properly, the SMDs would not compile properly.

I had originally thought that maybe some other plug in might be inteferring somehow so I renamed the appdata 2.76 repositorty, grabbed a clean vanilla copy of 2.76b from blender.org and a did clean install of BleST 2.6.2 (which is the only plug in installed other than the ones that are preloaded on clean install) . Exported the DMXs again and got the same result, so it's got to be something in the model exported DMX files themselves that just isn't clicking. The SMDs compiled perfectly again.

Well, back to the drawing board. Maybe I'll delete all vertex groups and the armature and rebuild the structure (again). I'll let you know how things work out after doing that.
Last edited by Pte Jack; 12 Feb, 2016 @ 9:25am
Pte Jack 12 Feb, 2016 @ 11:27am 
After doing a backward decompile of the model compiled with the DMX files I found that the armature did have some problems. There were 90 degree rotations and an animation embedded in the bones (not sure how these got there because I had completely replaced the armature but they were there.) So I'm in the process of repairing the armature and attempting again.
Pte Jack 12 Feb, 2016 @ 12:51pm 
Found the problem. I had 2 object that were the same name, a mesh object (named fuse) and the main bone I parented the other bones off of was named the same (fuse).

After changing the name of the main bone to something else, everything came together properly. So, this is an asummuption,

I guess the SMD compile knows the difference between the object data types and the DMX compile doesn't. (Maybe??) Might this be something to look into on your end Artfunkle??

I don't know if the same behavour occurs if the objects are named the same deeper in the hierarchy... (haven't tested)

Thanks for the help!
Zappy 12 Feb, 2016 @ 12:53pm 
Originally posted by Pte Jack:
I guess the SMD compile knows the difference between the object data types and the DMX compile doesn't.
SMD merges all meshes together into one object before exporting. DMX does not. That means for SMD, there's technically not that object and bone with the same names, while there is for DMX.
Artfunkel 12 Feb, 2016 @ 3:54pm 
Originally posted by Pte Jack:
Found the problem. I had 2 object that were the same name, a mesh object (named fuse) and the main bone I parented the other bones off of was named the same (fuse).

That sounds like it could cause problems. I'll look into it.
Pte Jack 12 Feb, 2016 @ 4:10pm 
I wasn't sure if it's BleST or StudioMDL problem. I was going to do the drag and drop on to the studiomdl.bat to see if it was somethng that Studiomdl was doing, but if you have it in your court, I'll leave you at it...

Thanks Artfunkle...
Artfunkel 20 Feb, 2016 @ 3:10am 
It doesn't seem to cause problems. The problem must be something related to your lack of parenting (arf).
Last edited by Artfunkel; 20 Feb, 2016 @ 3:11am
Pte Jack 20 Feb, 2016 @ 9:45am 
hmmm, I have never had to parent models before, I just simply added vertex groups, and an armature modifier. This model had a mesh object called fuse and the main bone was also named fuse. When using my usual method, I got the problem of the FUSE weighted objects doing the 90 degree flip. As soon as I changed the name of the main bone, everything worked properly. This only happened with DMX exports and compiles, the SMD exports compiled without problems (using my usual parenting method) which lead me to the conclusion that the DMX compile could not distinguish between the mesh and armature data types when it came to parenting using vertex groups. It defaulted to the mesh as the parent.

Now this could also be a studiomdl bug as BleST is merely a GUI into the compile process. But I thought I would report it just in case. I'll do more testing as an End User on some other models later. But for this case... The problem was solved by renaming the main bone.

Thanks for the help and for checking into it Art...
Artfunkel 20 Feb, 2016 @ 11:08am 
Please upload your blend.
Pte Jack 20 Feb, 2016 @ 1:43pm 
I'll go you one better... Here's the entire project,

2 blend files - 109_original and 109 Bone Fix.
SMD and DMX exports with QC for both
Valve compiled mdl files and Valve mats

File is 57 megs...

Now, while playing with this...

The original DMX output with the problem_dmx.qc produces the spun up model...
The original SMD ouput with the problem_smd.qc produces a clean model (I did not add the VTAs to the SMD calls)

The Bonefix blend produces a clean DMX compile. (This is after renaming all the bones.)

But, I went one further and just renamed the fuse bone to bip_fuse and left the rest. The resulting compile flipped everything to normal except the prop. (The prop mesh object has the same name as the prop bone)...

I renamed the prop bone to bip_prop and just exported the prop object and recompiled. The result was the the prop flipped, except it flipped only 90 degrees and appeared in the starboard wing facing the wingtip instead of off the front of the aircraft. I had to export the entire model again to get a good DMX compile.

Anyway, if your interested in investigating, the RAR file is here... https://www.dropbox.com/s/l844qsejhfpy07n/Stuka_Rot_Prob.rar?dl=0

And thanks again for your time...
Last edited by Pte Jack; 20 Feb, 2016 @ 1:44pm
Pte Jack 20 Feb, 2016 @ 1:55pm 
You know, thinking this through, it maybe a Blender problem, because I used the default parenting which is object in the object property panel...

Eventhought there is a armature modifier, the object may only see the parenting based on the default because both the bone and the object are named the same.

But that doesn't explain why the SMD exports compiles properly where the DMX doesn't.
< >
Showing 1-14 of 14 comments
Per page: 1530 50

All Discussions > Bug Reports > Topic Details