Weird Collision problem and or issue


#1

Can someone explain why this is happening? I have made MANY collision hulls before but this does not seem to inheriting the x,y,z values from the FBX ( or even OBJ) files I bring in from 3ds max. They are both in the same location in max but not the same in hifi.

here is the mesh -

here is the collision :open_mouth: -

here is the model in Max


Beta Release 14 - Release Notes
#2

Looks like you have Z=up issues, in max the Z (blue) is up but in Hifi Y (green) is up, you need to reset the orientation at export, or correct it inworld. Hifi uses Y up and -Z forward settings. Maybe the FBX export is set but the OBJ export isnt?
It’s in the same location but just has the wrong rotations.

Also looks like you have the 0.01 issue. It looks like your collision model is about 100 times too big so in Blender there is a method to change the scale to 0.01 and Apply location, rotation and scale. Not sure what steps for Max, but it is clearly looking for a “scale down by 100X” type fix.


#3

Thanks for the quick reply Adrian!. I tried this and I know if I recreate the collision from scratch , it is possible the z up could be off but in this case its not. I have tried with other models and objects as well. Both results are the same for both Obj and FBX. Again, I have made many collisions before and am familiar with the process in general but this only seems to be happening in hifi. Still working out why >.< I will post my findings here as well in case anyone else is having this issue


#4

When you say you have made many collisions before you mean other platforms? The process for Hifi is generally quite different from what you might be used to, sadly you cant use other platforms as a guide, you have to do in Hifi what works in Hifi.

The why is less important than the “How to work around it” Because there is probably stuff internal to Hifi that causes these odd changes, (and there are lots of them) nothing we can do but find a workaround and post a bug report.

Others will have had this issue, and others will have had to use a workaround, I also urge them to post here.


#5

yeah you are absolutely correct :wink: I realize that this is quite different as I am treating it as such. You were correct about the Z up in the FBX settings. Which is quite strange since the setting I used for the model ( from maya ) was y up and centimeters. I used Max to export the collision. since I’m not an avid Maya user, I only use it to compile the textures with stingray for Hifi. the mesh shown in the above post was Y up and centimeters as well as the collsion. This time I set the collision to Z up and Meters ( which put it to the 0.01 scale)

Still yields the same result sadly :confused: ( reference the above collision)
Ill continue until i figure out why


#6

ok So just to be sure, I started over and exported them BOTH out of maya with Z up and meters ( 0.01 scaling ) imported them to atp and this is the new result lol

with the collision applied -

the model disappears now and the collision isn’t even shown . If the model is the same ( with the excpetions that the collision is a simplified version of the mesh, Why would both be at different scales in Hifi?


#7

phull must be a convex manifold for it to compute correctly in HiFi. I started working on my cruise boat manually and it was taking forever. I decided to just wait for the bvhTriangle thing @Balpien.Hammerer talks about. It’s coming, but until it arrives, you’re better off not stressing about the collision hull. Is there a way you can fake it with a box or a sphere entity until then?

cc: @leviathan, @Menithal


#8

Are you able to upload your FBX samples for closer inspection?

I ran into similar hull scaling challenges when first adapting THREE.js geometries into FBX / OBJ model pairs. Apparently 100 units in THREE.js corresponds to 1 unit in HiFi; for the FBX I just exported my vertices verbatim, but for the OBJ hull had to pre-scale by a factor of 0.01 for it to line-up.

It seems like 100:1 is the same as 0.01 – but I’m not entirely convinced of that yet (and suspect there might be something else to consider still with hulls and scaling).

Also with Draw Collision Hulls enabled I found some of my 100x scaling errors unexpectedly placed my avatar fully-inside the collision hull – making it only look invisible, when really it was there, ginormous and face-culled.


#9

I tried this too. Leaving the mesh as be and then only changing the value of the hull to 0.01 still with no change resulting.

Oh yes something to think about for sure. It did reappear when I toggled the view Collisions option in the dev menu. I dont think in this case it was so huge i was actually inside it. The process was this. Made the mesh. Using the same mesh, made the collision ( but at a much lower LOD and low poly. ) exported both out of Maya Y up, Meters ( 0.01) scale. No matter what I do or try, the collision just isn’t inheriting the same x,y,z coords as the mesh. ( even though they are both in the same spot in maya ) And since it is a collision, There is nothing in the entity edit pane that allows me to place and scale the collision and leave the mesh where be. here is the link to the models if anyone wants to look —

I dunno maybe im missing something. These were made in Maya 2016. I can post my export settings too if that helps.


#10

In blender you need to update the scale , so it’s again 1.0 then it can be exported as fb with the correct axis settings. Mabye your scale setting in the project is something else then 1.0 ?


#11

well no , the mesh is at 1.0 and so was the collision ( at first) which yielded the results at the top of this page. What is even more strange is that the collision set to a scale value of 0.01 created new results ( shown on this page as well) but still did not place the collision in the proper spot :confused: Im still playing around with this to see what is exactly happening on the export so I can post that info here.


#12

OK so tinkering with your raw .fbx files I was able to get things lined-up by:

  • Zeroing-out the 90° X-axis PreRotation (in both FBX’s)
  • Manually scaling the hull’s Vertices by 0.01

I think what’s happening is that when FBXs (or OBJS for that matter) are used for collisions hulls none of the typical transformations get applied (essentially the Vertices are used as-is).

In your case FBX UnitScaleFactor, PreRotation and Lcl Scaling would need to get applied for the two to match.

You might want to try using an OBJ for the hull again (because that format has fewer “moving parts” to go wrong), but either way you probably need to “apply all transformations” within 3ds/Maya before (or as part of) exporting the hull.

ps: with Draw Collision Hulls enabled your original FBX hull was hiding way way way up above in the sky!


#13

Wow thanks for all of your work on this Humbletim! I will try it out ( and im sure it will work :wink: ) I think an important aspect is that now there is something to fall back on for any users that may come up against this problem in the future and a mini guide to help them get it fixed :wink: so thank you!


#14

I’d like to try to fix this in our OBJ reader code so that workarounds are unnecessary, if possible.

It is true that the OBJ format doesn’t support global or local transforms for the points however some of the modeling applications will add a comment at the top that hint about the true units for the points. For example, in Maya the OBJ export window has a combo UI element where the units can be specified, however Maya will always write the actual point data in centimeters. Selecting the true units during export appears to affect the unofficial comment at the first line of the file, so I believe we can unambiguously determine the true intended units when we parse a Maya OBJ file. Dunno about whether it sometimes can insert a hint about rotation there… I’ll have to test.

I’m wondering if 3ds uses the same trick. Does it offer options during the export stage? Maybe someone here could supply me with example 3ds OBJ files of a box with dimensions <x,y,z> = <1,2,3>? If 3ds offers a transform on export then I’d like to get an OBJ of a box that was modeled Z-up <x,y,z> = <1,2,3> where the Z axis should be rotated into Y such that the box is supposed to show up with <x,y,z> = <1,3,2> (tall side up). I’d like to look at the resulting file manually to see if we can find clues in the comments.


#15

Yeah I can supply that tonite :wink:


#16

Cool. So is the recommended approach then to use OBJ files for collision hulls?

Because FBXs basically seem to work and the relevant transforms are being parsed – they just never get applied as part of the hull shape computing logic.

Maybe instead of applying transforms in the OBJ reader code itself, it could be updated to parse the current and proposed special comment headers into the corresponding geometry structures – and then the shape computer could be updated to bake transforms generically (ie: regardless of OBJ or FBX) as part of extracting collision hull points?


#17

Yes, the recommended approach right now is to use OBJ files.

I can confirm that we don’t yet handle the per-mesh transforms that are often non-trivial in FBX files in the code that generated the compound hull shapes for the physics engine. But it would be possible to do… I’ll see if I can fit it into my current project.

My current project is to generate simple compound hull shapes directly from concave FBX geometry – the algorithm should work well for some models so we think it is worth trying out.

In short: idea-1is to just wrap each sub-mesh in a convex hull: some models have their parts properly divided such that this will work well. Idea-2 is to do further connectivity analysis and break out each connected group of triangles into its own convex hull, but I’ll probably submit the first part as a PR as soon as it is done and re-evaluate if I should pursue the second part after that. These operations could probably be done in real-time for most models.

A final step would be to perform a full VHACD convex decomposition on another thread (can’t be done in real-time) to generate “compound URL” assets from within the hifi interface client that could then be stored on ATP or exported.


#18

Probably too, when those comments are not found in the obj file, assume z-up.


#19

OK sooooo (lol) I have the Collisions working properly ( with the OBJ set to 0.01 scale and the FBX at 1.0) but a new problem arises. as seen in this pic

The collision is in the perfect position for the terrain but the avatar stands on top of it.
I have seen this before as if the convex hull is filling itself as as solid.


#20

@Triin