TGO format doesn't save orientation information

Started by commorancy, May 26, 2013, 05:15:00 am

Previous topic - Next topic

commorancy

May 26, 2013, 05:15:00 am Last Edit: May 26, 2013, 05:30:47 am by commorancy
I import an object file, then resize, scale and rotate (i.e., orient) the object correctly. When I save the TGO file, these coordinates are not saved along with the TGO file and are lost.  On import of the TGO, this requires remembering and changing these orientation values again.  A TGO file should save and restore all orientation settings including, at minimum, scale and rotation of the object, but preferably all orientation coordinates.  Alternatvely, at least, prompt to restore these values on import.

A clip file does remember the coordinates of those items contained within, but a tgo file does not. While clip files may work okay in some cases, it is preferable to use tgo when setting up populations as they are easier to deal with rather than having to import a clip and then rework the population after.

Please fix.

Thanks.

jaf

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. 

Since I build most of my objects, I generally keep them in the obj format until I'm satisfied with the "look" and then save them off as tgo's for future work.  But I can't see where position/orientation and scaling would be that important -- the tgd file has that. 

Another technique if you model your own objects is to position your objects relative to each other in your modeling program and save them as one object.  When importing into Terragen, though it will import to 0,0, the individual models will keep the positions relative to each other.  For example, a house, garage. driveway, and car can be modeled separately and brought together in your modeling program in the proper orientation.  Then, when saved as a single object that orientation will be maintained in TG2 -- just the final positioning needs to be made (hope that's not too confusing.)

You could always build a default TG2 scene with all your objects positioned and scaled  to your desired values and disable them (if desired) -- when you start TG2 they will always be there.  But I really can't imagine a system with several hundred tgo's that you have to "find" when you load them to build a new scene.  But again, that's just my opinion.  :)

[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. 
(19oct19) Ryzen 1800x, 970 EVO 1TB NVME-M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 436.48 (02oct19), Win 10 Pro x64, Terragen Frontier 4.4.39 BMark 0:10:18

Oshyan

As jaf describes, this is basically by design. A TGO, like an OBJ, is intended just to store the object-specific (rather than scene-specific, or relative-to-scene) parameters. In fact, we are generally recommending that people save their objects and shader networks as clip files now *instead* of TGO as this preserves the OBJ editing capability that you might want, while also preserving the Terragen shader networks you have attached. Since you can save a clip file with just your object file or population in it and no other nodes/connections, it is functionally equivalent to saving a TGO, but has the benefits of saving position info, etc. that you seem to desire.

- Oshyan

commorancy

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.

commorancy

May 28, 2013, 03:47:01 am #4 Last Edit: May 28, 2013, 03:50:48 am by commorancy
Quote from: Oshyan on May 28, 2013, 03:31:44 am
As jaf describes, this is basically by design. A TGO, like an OBJ, is intended just to store the object-specific (rather than scene-specific, or relative-to-scene) parameters. In fact, we are generally recommending that people save their objects and shader networks as clip files now *instead* of TGO as this preserves the OBJ editing capability that you might want, while also preserving the Terragen shader networks you have attached. Since you can save a clip file with just your object file or population in it and no other nodes/connections, it is functionally equivalent to saving a TGO, but has the benefits of saving position info, etc. that you seem to desire.

- Oshyan


Hi Oshyan,

If this is what you recommend, then I'd suggest that you add TGC as a native object type for populations.  Having to load clips and then rehook up links to objects loaded from TGC into a population is not at all intuitive or easy to use. If you want to build a reusable library of objects, TGC is not optimal and neither is TGO.

Please correct.

Thanks.

jaf

Still don't understand why you want a library of specifically positioned objects other than if you worked on the same scene all the time.  If you change the terrain, there's a chance the non-population object could be underground or in the air.  A population could be trying to set on a cliff.  Seems like it would require a lot of moving objects around.

Maybe it would help if you could explain why you would want example.tgo having a location of x = 5342.10, y = 121.0,  z = -4215.3 plus scales and rotations?  I'm not saying you are wrong -- I'm just not understanding where a library of objects with all that information would be useful. 

Maybe explain your workflow if you were to build a new scene using objects that had the metadata already stored in your library and I'll understand.
(19oct19) Ryzen 1800x, 970 EVO 1TB NVME-M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 436.48 (02oct19), Win 10 Pro x64, Terragen Frontier 4.4.39 BMark 0:10:18

Matt

May 29, 2013, 02:05:19 am #6 Last Edit: May 29, 2013, 02:07:36 am by Matt
We'll improve TGC handling for populations in future. I can also see how it would be useful to store the transform information in TGOs so we will also consider doing that.

Matt
Just because milk is white doesn't mean that clouds are made of milk.