Quote from: jaf on May 27, 2013, 09:20:22 PM
Just my opinion.... A tgo is a Terragen object (or object population) to be placed somewhere in a scene. Where it is placed, the orientation, etc., is a function of the scene (tgd) file via user interaction. I think it would be counter productive to store the tgo position/orientation information with the tgo file, since it's unlikely one would want it to always load in the same position/orientation in different scenes. Knowing it loads to 0,0 makes it easy to find and move. I keep a text editor open just for the purpose of recording positions of objects as I build/replace them.
[edit] I forgot to add... it would be nice to have a copy all object data button (or right click node function) for each object, and maybe a save option.
For what you suggest, I recommend loading a .lwo or .obj file as these formats do not store position, scaling or rotation information for Terragen (other than whatever was native to the modeler that created it). So, for what what you suggest, I recommend using one of those two formats instead of TGO. TGO is a native Terragen 2 container for a .obj or a .lwo. It is not an object format in and of itself. There is no way to make native TGO objects as there is not any modeler that I know of that supports this format. A TGO object should therefore retain and save rotation and scaling metadata along with even position. Otherwise, what's the point in using TGO over OBJ or LWO?
Note, when an object has no placement meta-information, it always loads the object the at the origin which is 0,0. So, loading an object at 0,0 or some other saved position, there really is no difference. You can always move any object to 0,0 easily. If you would prefer all your objects are saved/loaded at 0,0, it's simple to move it to the origin and before saving it as TGO. That way the object is always at 0,0 on loading just as if it had no positioning information at all. I would prefer to have the object to save rotation, scaling and positioning rather than not. It's far easier to reset the settings on saved objects after loading than it is to remember the settings a year or two later (Where did I put that text file? What were those settings again?) Storing this metadata in the TGO container is a best solution to allow for building a reusable object library.
As far as with a population, the object will be moved, positioned and populated to wherever its position should be based on the population information. For a population, hard stored positioning information should be discarded in favor of the positioning set up by the population. That's the point in a population. So, regardless of what hard position is stored in the TGO itself, the population should always disregard at least hard positioning and always assume 0,0 positioning to begin movement of the object to its populated position. Scaling and rotation should always be retained from the object (or as a preference option). You can always adjust and tweak these settings inside the population anyway.
Why is this important? It's important because different modelers use different axes and different scaling approaches. Some use centimeters some use MM and some use much bigger distance measurements. Worse, if Y is up in one modeler and Z is up in another and X is up in yet another, the orientation of the object will be whatever that specific modeler used. That means, generally, that trees can end up on their side or upside down. Some even end up with inverted normals in which case you have to un-invert them on loading or the object ends up inside-out / reversed.
After you've spent the time scaling, rotating, placing and possibly other settings, you'll want to store that object in your library for later use. Unfortunately, there is no native storage format (other than TGO) where that can meta information be stored. While a clip does work, clips cannot be used inside a population. So, loading an object from inside a clip means jumping through hoops to get that loaded object to be usable within a population later. Without this metadata, creating a reusable library is not an option.
There is definitely a whole lot of upside to storing rotation, scaling and positioning in TGO and there is absolutely no downside to this. If you're trying to build a library of objects that you've preconfigured, without this metadata support you simply cannot do it. It also takes you twice as much time having to pull out notes to remember which object had what scaling and what rotation.
So, you're saying you'd prefer to spend that extra time pulling out a README for each and every object in your library to remember rotation and scaling each time you want to use that object in a scene? That is, versus setting up your objects once in a library and reusing them over and over? Not me.
As for a single click to copy all positioning information for an object into the clipboard, agreed. I would also like to see this added.
Thanks.