I'm trying to find a way to rotate a hf searches on the forums seem to suggest it's impossible. Has anyone found a way or does anyone know of any external software that can rotate a .ter file?
You should see the manual. I guess it should be there. However, regardless of the version (by the way TG2 or 3?) I have a vague feeling that this can be done with the "Translate" controls. Since I don't have Terragen opened right now I am not being very precise. ::) I can post relevant image later.
Personally I never needed to rotate a heightfield. The best solution according to me would be saving the heightfield image as a .bmp file for example and then rotate it in the image processing program. Keep it simple.
Hmmm, I always thought that you could. Never tried though. But considering that I was able to rotate clouds and rock rings (made from simple shape shaders) using the translate (though it took forever for me to understand) Then why not here too? Lots of things in TG don't have rotate like I think they should. But they seem to rotate if you addd enough controlers to them.
You actually can't rotate heightfields in a really direct way, unfortunately. Even Transform Shaders don't work on them at present. This is something we do plan to address in the future. In the meantime a workaround is to use georeferencing in a Heightfield Load (if you're using an internally generated heightfield just right-click, Save As, make it a .ter for the extension of the output file, and then load it with a Heightfield Load). The manual georeferencing has corner positions measured in lat/long degrees that you can adjust and if you understand lat/long well enough you should be able to create rotation. I personally do not, and I don't think this workaround is an adequate solution at all, so it's something we'll certainly work on.
- Oshyan
Cheers Oshyan - that's what I thought. I do not really understand the geo referencing controls at all either so I'm hoping this gets sorted sooner rather than later.
Oh bother (keeping it polite).............
Seems like a rather basic parameter to not have; but then I'm not privy to the ins and outs of programming these types of features.........
Along a similar vein; I assume (as there is only X and Z coordinates available for heightfield positioning) that it's also not currently possible to raise or lower a heightfield shader in T3?....
You "raise" and "lower" by using a Heightfield Adjust Vertical. You cannot disconnect the heightfield from the planet, so it will be a continuous surface with the planet itself. But you could use an Image Map Shader with the same terrain and apply it to a floating Plane or Cube as a displacement shader if that's what you need.
- Oshyan
Would either Flip X or Flip Y not work?...and why no Fip Z? then crude 90 degree rotation would certainly be possible.
I've been exploring this a bit more and found that there is a rotation macro for WM1 that works with WM2 also (no idea why it isn't in the "standard" library).
Using this macro, as well as the flip horizontal/vertical has given me 10 different orientations.
This, of course, is only useful if you are using a MW terrain.. :o
I've also looked into the georeferencing function as some mentioned it as a workaround and I have no problem with lat/long coordinates; but I got stuck on another (for me) Terragen quirk - when I checked the georeferencing box, the terrain shifted [that was fine as the centre of the terrain was positioned at (0,0)and the lower lefthand corner (south west) was moved to that position] and increased in size by [at least] a factor of 10! But that appears to have been only in the (X,Z); there appeared to be no change in the Y (height) parameter......
To me, there also seems to be a mislabelling of Cartesian axes; the statistics section in the heightfield load node states the dimensions of my terrain as 7998 by 7998 (width by depth) but gives this to be the XY size... ???
I thought that Y was the up/down axis but here the Y coordinate is used to indicate the depth...
I think that this also links to Bobbystahr's question, "Why no flip Z?"
If Z is the depth coordinate (as it should be, given basic Cartesian geometry), it's a perfectly sensible question; however, as my terrain was given XY dimensions as being width and depth, this would imply that Z is, in this case, the height axis and flipping Z would mean that flip vertical will result in our HF terrain being turned upside down (a good reson for not having that parameter)...
So if someone can help me to understand why this is, I may be able to create a simple tute to help those who may want to use the georeferencing to rotate their heightfield terrains.
Apologies for any misuse of the correct terminology; I still have my training wheels on........ ;D
Here's a test I did with an initial terrain I made in Classic so we have an unambiguous terrain to test.
As I thought; X is left/right and Y is in/out.
I thought that Z was meant to be in/out with Terragen and that Y is up/down.
There appears to be some inconsistency with the Z & Y coordinates.
In this example, Y appears to in/out; whereas with water depth (for example), Y is the parameter to change to raise or lower the water.
Oh, I'm so confused............................. :o
Obviously, I'm misinterpreting something here.
Sorry, Bobby, I'm probably just stuffing up your investigation with my newbie interpretations/questions..................
Quote from: Erwin0265 on October 20, 2014, 08:05:28 AM
As I thought; X is left/right and Y is in/out.
I thought that Z was meant to be in/out with Terragen and that Y is up/down.
There appears to be some inconsistency with the Z & Y coordinates.
In this example, Y appears to in/out; whereas with water depth (for example), Y is the parameter to change to raise or lower the water.
Oh, I'm so confused............................. :o
Obviously, I'm misinterpreting something here.
Sorry, Bobby, I'm probably just stuffing up your investigation with my newbie interpretations/questions..................
Let me reassure you you're not alone in that confusion....and I think the reason for the no rotate has I'm sure to do with the fact that it's on a planet and not a plane like most 3D landscape traditionals and requires the coordinates of the planet to remain intact, so a 30 degree rotate wouldn't be rational...just the way I see it and I'm guessing....
It would be nice if someone in the know could clarify this; for every one person that says, ???, there are another 20 wishing someone had the nerve to ask the question (observations made from 25 years of teaching...).
At least it's nice to have company in ignorance.................. ::)
You're right, the coordinates used in that situation are not consistent with other internal coordinate use. As it happens that makes it more consistent with how other apps handle coordinates, which I think is largely the intent, but I agree the lack of *internal* consistency is confusing and it's something we'll reconsider.
Heightfield rotation is something that is technically possible, it just hasn't been implemented in any TG node functionality yet. It's something we can look at doing in the future. In the meantime you can certainly export a TG terrain and rotate it in another app. TG can read/write the widely supported TER format, as well as others that are compatible with apps like World Machine. So you could certainly make use of the World Machine heightfield rotation workflow you described.
- Oshyan
It's good to know my education wasn't for naught... :D
I know in Vue, you have the option to have either Y or Z to be the up/down axis. To be honest, I find it rather annoying; why can't "they" (the creators/writers of terrain generating software) stick with the basic Cartesian coordinate system?
Most of us at least learnt the X & Y axes in high school maths (some of us taught it... ad nauseum...).
It just seems (to me) to be change for change's sake.
To be clear; I'm not complaining about Terragen; at least there has been an obvious attempt to stay true to the Cartesian coordinate system (although changing some and not others has made the issue even more frustrating - but it's good to know about the inconsistency so we can deal with it when it pops up); I always get annoyed with this type of practice (change for change's sake, or, "Well they did it before we did so we're just following with the crowd"...): it's always been one of my pet peves.... (forgive me.... ;)).
Further to this issue; as I mentioned in a previous post, I got stuck on another (for me) Terragen quirk - when I checked the georeferencing box, the terrain shifted [that was fine as the centre of the terrain was positioned at (0,0)and the lower lefthand corner (south west) was moved to that position] and
increased in size by [at least] a factor of 10! But that appears to have been only in the (X,Z); there appeared to be no change in the Y (height) parameter...... - Why?
I forgot to add this:
QuoteTG can read/write the widely supported TER format, as well as others that are compatible with apps like World Machine. So you could certainly make use of the World Machine heightfield rotation workflow you described.
I found that using the Ter format gave a much more defined terrain than if I used, say, the Tiff(16-bit) format - both created in WM2.
Why is this ?
Is there any software that can edit ter files as an image (like a tiff, bmp, png, etc)?
I'm not entirely sure, but a georeferenced heightfield, or basically all .ter files contain their own height information. So if you resize X/Z, or the software does that for you, then you need to resize Y accordingly.
I can't tell you why it is not doing that ;) but it's probably related to the fact(?) that heightfields contain the height info themselves.
Cheers,
Martin
P.S. Just curious, Dutch too?
Uhhh....I can't.
The Heightfield load has only one area that relates to terrain dimensions and that is under statistics (which, in my case, is 7998 by 7998 metres) and that is not editable.
In the heightfield shader node dialogue box there is no mention of dimensions at all.
QuoteP.S. Just curious, Dutch too?
I was born there (Breda) but emigrated to Australia when I was six in 1968................
I never really learned the language, other than the vocabulary of a six-year old (and reading ability of a Monopoly game - the same one I still have in my bedroom cupboard; and it looks it's age)...........
I can understand most of what mum says as we spoke Dutch at home - to maintain our spoken language (she tends to speak in mingled Dutch/Australian nowadays) but I lost most of the spoken language when I went to Uni (living away from home for 4 years).
QuoteI thought that Y was the up/down axis but here the Y coordinate is used to indicate the depth...
Oh thank goodness I'm not alone in thinking this; I was blaming brain fade, perhaps it's not after all. :o
Quote from: RedSquare on October 23, 2014, 01:35:37 PM
QuoteI thought that Y was the up/down axis but here the Y coordinate is used to indicate the depth...
Oh thank goodness I'm not alone in thinking this; I was blaming brain fade, perhaps it's not after all. :o
I use the
Heightfield resize Operator and type the
actual size of the terrain in the meters area also
click Re-scale vertical or you'll have no height if you are scaling up and too much if you're scaling down.
Quote from: Erwin0265 on October 22, 2014, 07:03:56 AM
...I can understand most of what mum says as we spoke Dutch at home.. ).
I had a friend in college named Hector. His parents brought him to the states from Mexico when he was about a year old. His father died just a few months after immigrating, so Hector and his mother went to live with his fathers relatives. Hector's mother spoke little English so he learned to speak with her in Spanish while he learned fluent English in American schools. When he got into college he had to take a foreign language to graduate, so he signed up for Spanish, figuring it would be a breeze to pass. It turned out that, although he had learned to
speak Spanish, he had never learned to
read and write it, and damn near failed the course. ;D
Georeferenced terrain should automatically scale properly in all dimensions. What you may be seeing is *incorrect* height scaling when georef is not being used, in other words it is a correct height but relative to the area covered it is too tall, but when goereferenced it actually covers the appropriate area for its height; the height doesn't change in that case, just the area covered. I am just speculating here though.
TER format maintains terrain scales correctly (or should do), unlike pretty much any other image format, so that's why TER would generally be preferred; it has terrain-specific meta data basically. TIFF is an occasional exception when you're referring to GeoTIFF, but WorldMachine does not output GeoTIFF. But if you're using WM, something to be aware of is that WM's TER export is... well, I'm not sure it's fair to say it's "broken" per se, but it definitely doesn't work as the TER format was intended. This is why you sometimes get very weird vertical scaling. In that case you can look at the total height range of your exported terrain *in World Machine* and then use a Heightfield Adjust Vertical to set the correct range.
- Oshyan
QuoteI use the Heightfield resize Operator
Remember, newbie; aka:- ???
QuoteGeoreferenced terrain should automatically scale properly in all dimensions. What you may be seeing is *incorrect* height scaling when georef is not being used, in other words it is a correct height but relative to the area covered it is too tall, but when goereferenced it actually covers the appropriate area for its height; the height doesn't change in that case, just the area covered. I am just speculating here though.
To see if what I am seeing and what you are saying correlate (I have no idea; I got kinda lost after "Georefferenced terrain"... :o), I have attached a screencap:-
[attachimg=1]
This is of the same terrain I mentioned in previous posts (created in WM2, saved in .TER format {broken or not?}).
As you can see, there is a "slight" discrepency between the size of the non-GR vs. the GR terrain; there is also no detail to be seen in the GR version.
BTW, GR = "Georeferenced", not "Global Radiosity", in this example anyway....... ::)
Well, I should clarify: if it's a World Machine generated terrain, there is no georeferencing data in the file, so enabling georeferencing is not going to give you a "correct" result.
- Oshyan
Ahh, yes; of course.................. :o D'oh!
QuoteI use the Heightfield resize Operator
I looked it up; imagine - a complete entry (sorry, a bit of a dig at the wiki lack of comprehensiveness. I've been in hospital {again!}; that's my excuse and I'm stickin' with it).........