![]() ![]() ![]() We were surprised to see that Maya is actually the more demanding of the two systems when it comes to hardware requirements. There is no ceiling on what either is capable of, but there are a few key differences to take into consideration. This can mess up many things.Honestly? So much of the difference between Maya and 3DS Max will ultimately come down to personal preference. Let’s say you export that 2m default cube with both 1 scale factor, the dialog shows it’s in centimeter but you still can get a 200*200*200 cube mesh in UE.īUT here comes the fun part, if you use the “import into scene” way, you will get a 100 times scaled big actor and a 2cm*2cm*2cm static mesh!! It means UE read the fbx unitlessly as 2*2*2 and multiply them with the “File Units” factor witch is centimeter means = 100. When you “import” in UE you can see that info in the “File Units” section of import dialog, even you set blender unit scale and export scale both to 1, it will always be a “centimeter” fbx and amazingly UE still somehow can convert(scale up 100 times) the mesh to centimeter unit. But blender’s true problem is it’s fbx exporter sucks, it doesn’t actually change the file units system of exported fbx, it always write fbx as “centimeter”. Not which scale multiplications inside Blender have been set.īlender’s 1 unit = 1m, UE‘s 1 unit = 1cm, they are hard coded, that’s how they work. Yet ultimately only the export scale multiplier should be the factor to remember. I absolutely agree that this value needs to be applied depending on the units and measures you set in the world settings. And that’s just unnecessary, I think, as it’s mostly a display issue of the gridsize. And from my experience of working with CAD files and smaller world scale values these problems mostly come from having to fiddle with either Unit- or Gridscale. in order to be consistent it needs to be solid and without any weird multiplication issues inside Blender. And that multiplier should be the only thing the user has to figure out and remember or save. If the work units inside Blender are consistent and easy to set up you only need to figure out the correct ratio to your target apps and create a preset for that. It’s the reason Unity has an importer file scale multiplier - to get FBX to be able to import at 1/1/1 scale from any other application. You will get 10x scale issues (usually ranging from 100x to 0.01x in 10 increments) as exchange problems in most 3D apps. That is a problem of every application and most exchange formats, though. The one from the exporter to the target app/engine. This also take a lot of guesswork out of the export because you only have one multiplier value to take care of mentally. Set the units to either scale unit and work with it. That way the user wouldn’t need to fiddle with gridscale or unit scale. Show the current grid scale in the 3D viewport just like in the orthographic view.That way the user doesn’t need to use weird grid scaling that messes with unit displays. When zooming out it works rather flawless. Give the 3D grid the ability so also have some close up zoom subdividion buffer.So it’s unit value, unit scale and/or percieved grid scale plus export multiplier.Īnd the solution is actually (at least logically) not that complicated: On top of that a multiplier value for exporting the object into your desired exchange format. Now the even bigger problem is what unit to set up in the export settings because now you have several values that push and pull on the object and scene size. Not to mention that the 3D perspective view simply never shows any values for current grid size. But what happens then is that the Orthos suddenly show a multiplier value:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |