I've seen posts on this before but I haven't found how to stop it (if you can). When I'm building up terrain and mainly when I start to move the mouse a random location starts to build up terrain and creates a giant mountain... is there any way to stop this or do I have to just keep my mouse still why creating terrain? It's a pain when trying to create smooth terrain
If you are talking about the sporadic mouse movements while doing things in the editor I am not aware of any fix. However I have found that moving the mouse downhill doesn't cause issues any where near as much as up hill. Although I haven't used the editor in over a year, so that issue may have been fixed.
Please take a look at this thread, I address what I think will help in post #6: https://www.beamng.com/threads/terrain-growth.34280/
Yeah I saw that while looking for a fix and it helps, I was just wondering if there was any way to stop it all together.
You could try building your terrain in external software and then import it as a heightmap when you are ready. However as far as I am aware exporting and reimporting repeatedly has issues. This means you can't work in iterations. So you would have to get the heightmap as good as you can (in external software) and then once you have imported it to Torque3D any changes would have to be made in Torque3D after that point.
Hmm, sorry. I see now that my advice doesn't really help at all... this is a very similar but definitely different issue as compared to what I thought was going on. I'd say that the editor is definitely broken right now and needs to be fixed.
Whenever the editor SKIPS (hitches, lags), the editor drops the cursor to 0,0,0 and your modifications happen at that while it's skipping. Don't build at 0,0,0 until you're done with the map.
Dont you also want to move the terrain to cords that correspond with its size too? so if your terrain is 256, you move it to the cords -256,-256,0 or 256,256,0? that used to help, but its been a while since i did any map making source
I don't think that jammin2222 was quite right in his post. If your terrain is 256 and your square size is 1 I think that you should be locating it at -128,-128. The idea is to reduce floating point errors by making the outer bounds of the map as close to 0,0 as possible.
This is generally how things are done, as you say. For the most part, I tried to center my humongous-monster-huge-too-big-for-the-game-what-was-i-thinking-map (Roane County), if I hadn't, that floating point visual discrepancy would have been 2x as bad, and it's still bad, though you can't tell if you're moving. You won't notice this on maps that are 2048x1.5 square size or smaller, only past 4096x1 do you even start to notice it.
I'd say that following best practice is definitely the way to go in any case (eg use the negative 50% offset). While I haven't experimented the effects of floating point precision errors vs map size, here's my take. (a) there is no good reason not to minimize FP precision errors, (b) there may be existing edge cases where even small ones will make a difference, (c) there may be future needs from the game which depend on high precision without errors.
I have been assured by the developers that the errors you see are merely that, visible only, and that it in no way affects the usability of the game in a realistic sense (e.g. does not change outcome of the accident), even on large maps like mine. I have spoken to the devs about it, and to increase the trailing digits of the equation would increase the amount of processor time spent on the subject, in other words, it's not realistic to expect this fixed at the moment. Floating point is basically speedy math that's slightly rounded, and done in bulk. Processors since the 486 (and possibly 386) era of the DX (not SX) class, had an FPU built in just for math co-processing (it was called a 387/487 math co-processor chip). My first PC was 486 dx/2 66mhz chip from AMD, it was decent, but the FPU wasn't as good as Intel's, or oddly, Cyrix's. These FPU's, which you can read about on wikipedia (where they explain it a lot better than me), do a sort of rounded math, where the small differences from the regular non-rounded number not being used would be invisible, but miles out it becomes exponentially worse, and hereby visible to the naked eye. Again, I've been reassured this is only 'visual' and I have bashed my car into a 'Honda Accordian' or a 'Toymotor Crammy' many many times with no ill effects from it. So it's safe to say you can ignore it, if you don't mind the visual, otherwise the car looks like one of your vacuum lines has come off on a 4cyl engine :x Sorry to derail the thread a bit, but it is pertinent to the conversation.
Just my 2cents on it... the devs have offset their 2km maps by -50%. I suppose it's for one of the reasons we've discussed.
Yes, it is, I spoke with them about it last summer. The just 'edit the center of the map last'. My map was 'murdah' before I centered it (it's maybe 1~1.5km from being perfectly centered, or less, but it's close). I ended up having to lower the size of my map by about 6% from it's real-life counterpart to fit it in the 8gb memory model, with the forest brush and all. The physics model of the forest brush is the biggest memory eater, after-all. That being said, yes, you're right.
