[RESOLVED] Some of the 3D Thumbnail .obj files for characters are loading backwards?

Bug Reports Website Bugs
#1

I was recently informed that my Rbx2Source converter tool is loading skeletons backwards for some models, but is working just fine for others

I checked it myself, and it turns out its true.

External Media

In this case, the “Left shoulder” bone is rotating the arm on the left even though its on the right side, and vice versa for everything else.

Now obviously the solution here would be for me to just flip the skeleton right? Well yes, that would be a valid solution normally. However, theres a problem. If I turn the skeleton around and just leave the mesh as it is, the built in animations become distorted

So I need to flip the vertices of the mesh itself, however I (apparently) suck at Geometry, so it usually results in some hellish mess like this:

I would SERIOUSLY appreciate it if you guys adjusted whatever is causing this :slight_smile:

Also, if anyone is willing to help me with the whole “vert flipping” situation, the converter script is here (Look around line 280):
https://github.com/CloneTrooper1019/Rbx2Source/blob/master/resources/lua/SMDconverter.lua

1 Like
#2

3d thumbnail files are created by the OBJ exporter. As far as i know, there is no “skeleton” data included in the obj file, are you sure its not a bug with your program?

#3

Its a bug with my program caused by a change that was made to the character model. They are facing backwards, and my program doesn’t know how to handle that yet.

1 Like
#4

I’ll look into this backwards facing issue if I get the time.

Until then, manipulating verts directly seems like a nightmare. I noticed that you’ve already added logic to detect backwards characters, have you considered trying to rename the bones rather than moving the verts?

#5

[quote] I’ll look into this backwards facing issue if I get the time.

Until then, manipulating verts directly seems like a nightmare. I noticed that you’ve already added logic to detect backwards characters, have you considered trying to rename the bones rather than moving the verts? [/quote]

Flipping the skeleton does solve the issue, however it distorts the built-in animations I added to the model. I would have to either provide animations made for the flipped version of the skeleton, or do something ridiculous like reading the file and adjusting the positions of the coordinates.

I ultimately decided the best action would be to try reporting this issue and hope it can get fixed.

I think this issue is related to the rendering changes made to the thumbnail. If I can somehow request roblox to rebuild the 3D mesh on the latest version, then maybe I could force the mesh to become backwards and just adjust my code to read the mesh with a negative x/z axis rather than a normal one.

In the mean time, I’m just going to do the skeleton swapping and leave the animations broken. Hopefully it won’t be a huge problem for people (unless they are making roblox machinimas in Source Filmmaker, which so far I haven’t seen anyone really do besides myself).

1 Like
#6

I looked into your program a bit and I’ve got a little information that might be helpful.

// My character (one of the affected backwards models)
{
    "camera":{
        "position":{"x":-2.12929,"y":106.754,"z":20.9495},
        "direction":{"x":-0.40558,"y":0.40558,"z":-0.819152}
    },
    "aabb":{
        "min":{"x":-1.8829,"y":102.001,"z":24.481},
        "max":{"x":1.8829,"y":107.494,"z":26.4291}
    },
    "mtl":"b6da3e06d62564d3fe10898a9f8af92d",
    "obj":"2ef92602e1b9661a9b909bde08d9cbf2",
    "textures":["dea5644c436252a8055a17a0eec2af29"]
}
// Your example model
{
    "camera":{
        "position":{"x":2.49432,"y":7.56931,"z":4.63778},
        "direction":{"x":0.40558,"y":0.40558,"z":0.819152}
    },
    "aabb":{
        "min":{"x":-2.0,"y":2.0,"z":-1.13807},
        "max":{"x":2.0,"y":8.33877,"z":0.338075}
    },
    "mtl":"03c825e6fc0f2fa07b2936e3bb4df359",
    "obj":"d58fbcd88debdfb683676a442c682651",
    "textures":["edccc70298037ead5e476ff0fce8d589"]
}

You’ll notice these two are opposite:

        "direction":{"x":0.40558,"y":0.40558,"z":0.819152}   //yours
        "direction":{"x":-0.40558,"y":0.40558,"z":-0.819152} //mine

Evaluating the direction parameter of the camera will tell you immediately whether or not you’ll need to reverse things. This should clean up the shouldFlipSkeleton function. In general, it’s a good idea to know both the position and the forward vector of objects for alignment purposes. With that being the case, it’d be better if your program were able to handle this even if we do update the web side of things.

Now, as for actually correcting this. I can see now why you can’t just rename the bones, I didn’t realize at first that you already provided screenshots of that.

The issue you were having with the mirroring code was that you were iterating over the faces, and then the verts for each face. The problem with that is that faces share verts. You were going over the same verts multiple times and that’s what was causing your model to get all scrambled as some verts were properly swapped while others were put back into their original position with multiple swaps.

I’ve taken the liberty to fork your repo on github and I’ve opened a PR for a patch that’ll correct your complier.

I’ve also updated your .gitignore to something more robust. I did not however update your shouldFlipSkeleton function, you’ll have to take care of that one yourself.

Let me know if you’ve got questions or there’s anything else i can help you with.

#7

Oh wow :shocked: I wasnt expecting that. I dont know how to thank you man, I really appreciate it :]

It all makes perfect sense, Im surprised I didnt think about that. It was really late when I was trying to fix the bug, so I was focusing on trying to figure out if I was just doing the math wrong. I totally forgot that obj files share vert links (and Im the one who wrote the parser in the first place, xD).

As for the .gitignore, I think that was auto-generated. Im still a bit new to github. Im actually using it for the program’s file hosting at the moment.

1 Like
#8

No problem man, I like to help out wherever I can.

A fun note about obj files and the faces thing. It’s not just this file format that does this. As you get deeper into graphics programming, you’ll learn that this is fairly common for efficiency. Most graphics packages will have constructs for a Vertex Buffer Object (for vertex data) and an Index Buffer Object (for polygon/face definitions). These sets of data are exported to the graphics card for fast rendering. A pretty good explanation of the how/why can be found here.

As always, if you have any questions let me know.

#9

No problem man, I like to help out wherever I can.

A fun note about obj files and the faces thing. It’s not just this file format that does this. As you get deeper into graphics programming, you’ll learn that this is fairly common for efficiency. Most graphics packages will have constructs for a Vertex Buffer Object (for vertex data) and an Index Buffer Object (for polygon/face definitions). These sets of data are exported to the graphics card for fast rendering. A pretty good explanation of the how/why can be found here.

As always, if you have any questions let me know.[/quote]

+1 respect for you.