terrain scale

so, it's seeming that unity's terrain is operating on a 1 unit=1 metre scale, but my program works on a 1 unit=1 inch scale and i have no idea how i make the terrain work on that scale.

biggest limitation: the draw distance is maxed out at 1000, for meters that's a kilometre..fair enough, for inches thats about 83 feet, about 27 metres.and it starts culling long before that.

this is part of a larger program and the scale needs to be 1 unit=1 inch. is there anything i can do to scale the entire terrain trees and all?

 

what program are you making terrain in? just apply the scale conversion from inch to meter and export

 

Draw distance is set by the camera far clipping plane and is independent of the terrain or its scale.
But do keep in mind that anything over around 5000 units from origin becomes unstable due to reduction in floating point precision (eg animation and lighting issues start to become noticable).
So unless your environment is very small it’s probably not a good idea to deviate from the 1 metre scale as you would experience these problems from only around 125 metres from world origin.

 

Which one? Have you checked if it can be adjusted for metres?

There are a few bits of software that Im aware of that work with imperial units, and they're mostly CAD oriented, but all of them can have the units changed.

In fact, Ive been testing a lot of file export/import cycles from a number of 3D packages quite recently (albeit for Houdini), and most fbx/obj import processes dont actually compensate for the scale at all, they just use the number of units. So something at 10x10x10 with a 1cm scale is exactly the same as something with a 10x10x10 at a 1m scale: 10x10x10 in whatever the units are of the importing package. Getting packages like Blender and Rhino to export consistently with 1m = 1 unit and not need post-import scaling took a little bit of poking about in unit and grid settings etc.

 

technically i could convert the units from inches to metres, but the users are going to put the information IN in inches, so it adds an extra conversion step every time someone makes a change to the object. and there is formula parsing part which would be messed up by a unit conversion (the info they put in are just numbers to the system, their meaning is known only really to the user, except the values width,height, and depth)

also i have a wall that is made in...probably a very inefficient way (using voxels, i wanted to use CSG but all the CSG packages i could find either didn't work during runtime or didn't work with curves, so i create the wall out of 1 inch voxels...and i'm not entirely sure what changes i would need for them to be 1 cm voxels. i suspect there are some implicit 1's in the math)

the source is a CAM program...sorta...i made it myself for a client, it sends in the points a vectors through javascript from a source made in three js (i have thought about using three js to make the walls, it can do effective CSG)

now, maybe i can work in inches on the js side but convert every pixel to the 1 metre scale, but then i have photos which serve as textures and THEY are at 16 pixels=1 inch. the program uses this fact for mapping the UVs (and that the textures have a fixed size)

it would be a lot nicer if i could get terrains to work at the 1 unit=1 inch scale.

 

1 unit can represent whatever distance you want. You can set your camera to display much further distances than default. You just have issues regarding jitter of small objects and animations when far from origin. If the jitter is noticeable depends on how far and how small. You can use a technique called floating origin to resolve this problem though (you just periodically move everything in the scene so the player/camera are at scene origin).

Spoiler

In my game for example, my cameras have a far culling distance set to 300k, and the player routinely moves over 100k from origin. But I have real time shadows disabled, and don't have any small objects or animations which would show the jitter you'd expect at that distance.