Loading Xfrog OBJ's into T3

Started by Erwin0265, November 03, 2014, 07:35:41 PM

Previous topic - Next topic

Erwin0265

Hi all,
He's back with yet another question.............. :o

I'm having difficulty importing Xfrog OBJ's into T3.

I have the Agriculture set in .xfr format and I also have Xfrog 3.5 standalone.

In order to import any of these plant models into T3, I have openned the xfr file of a given plant and then exported as OBJ so as to import into T3.
When loading into T3 (Yes, I checked the "Is this object from Xfrog?" dialogue box), it appears that none of the materials are loaded and the warning dialogue states that the MTL file cannot be read.
In addition, even though the actual OBJ appears to have been imported; it hasn't (it's in the objects list, but doesn't show up in preview or render).

I tried to import as LWO format (again, from Xfrog) and, although no errors/warnings are shown, none of the textures load and the actual object is far smaller than the OBJ version (judging by the bounding box size).
Another peculiar "feature" of the LWO reader is that the name of the object remains "Lwo reader"; whereas with the OBJ imports, the object name changes to whatever object has been imported.......................

Is this still a bug (I read a fair bit about it in the forums but all of it was linked to T2, not T3) or has this issue been fixed and I'm doing something wrong?

NOTE: the African Doum Palm shown listed in the objects list is a tgo (showing all textures/shaders) so as to compare with the Ryegrass (AG12_1) obj model with no shaders/textures..............

As usual, I await the wisdom that is...............
OK, who farted?

Oshyan

The LWO reader is very limited and not recommended. It does not load textures, which is just a feature limitation, not a "bug" per se.

The OBJ import should work fine as long as a valid OBJ + MTL is being exported. Did you verify that an MTL file is present after export? Did you check the contents of it (you can view/edit it in a simple text editor of any kind)?

- Oshyan

Erwin0265

#2
Hi Oshyan, thanks for the speedy reply (I haven't even got a notification in my email yet!).
When you export an OBJ from Xfrog, you get a dialogue popup that asks if you want it to create an MTL file or a COL file (whatever that is); I chose the MTL file.
I did check the folder where it was saved and there was, indeed, an MTL file.
I openned it up in Notepad only to find it was a totally blank document.
Thinking that perhaps you had to save the OBJ/MTL file with the textures, I tried that; this time the MTL file contained the following information:
Quotenewmap BaseMap AG12brn1.tif

newmap LeafyoungMap AG12lef1.tif

I have no idea as to what this means, but I imported that OBJ and the textures were there! Yay!

Just a few observations (that may help other newbies):
1.In the object dialogue box, there's a tab entitled "OBJ Options". Click on that and there you will find 2 options - Source in cm & Source Z up. Make sure that both of them are checked or your object will import lying on its side (that's what had been happening to me and I suspect is the normal Xfrog coordinate system; Y is up; and this is why T3 has the popup asking whether the imported object is an Xfrog object).

2.Even if you have your object's preview mode set to show as textured; you also need to make sure that same can be said of the setting within the 3D preview (or you'll still end up with a bounding box). Within the 3D preview window, click on the icon that looks like a single blue cube; it's the "Change object display mode" button. Once you click on that, check the "Show as textured" choice and you'll (hopefully) see your object...

3.Plants can come in very, very (did I mention very?) small. My plant (Rye grass) was so small, the bounding box looked like a dot and it wasn't until I scaled it up to 100x that I could actually see it (this is with the camera at the default location and the object importing at (0,0,0)...

Anyway, I think I have it worked out now.
Just one more quick question; is there any documentation re. editing/reading an MTL file (I'm actually trying to understand the tgd file as well - but that's another post  :D)?

Further to plant importing/saving/etc; now that I have the textures, it is time to save each of my obj plants as tgo plants (it's OK, I worked that one out. Newbies; all you need to do is right click on your object in the node network and you'll get a popup where you can select, "Save object file" - click on that and there are your choices - in the "Save as type" box down the bottom...).

Now, I had my plants magnified 100x so I could see them but now that I want to save them to tgo, I need to reduce them back to normal size.
This may be OK for saving, but how on Earth can you get the camera close enough to see the damn plant?!
Every time I try, it seems to disappear from the preview window (?).
Vue has something similar called "Open GL clipping" (something that used to drive me crazy until I learned how to fix it) where, if you bring the camera too close, the object started to be "eaten away" by some mysterious force (but it still renders fine - but leaves a lot to guesswork)...
Is this similar or am I just a crazy guy talking to myself?...........

OK, who farted?

Oshyan

Glad you got it working, and good tips for others too. The scaling issue is odd though as the "Xfrog Compatibility" option on OBJ load is supposed to address exactly that issue. Perhaps you can try with different combinations of "source in CM" or with/without Xfrog compatibility enabled.

As for MTL editing, it's really outside the scope of Terragen documentation I'm afraid. There are various reference documents around, but OBJ is not as refined and clear a standard as one would like, unfortunately. I wish I knew of a single good resource to recommend...

- Oshyan

Erwin0265

#4
QuotePerhaps you can try with different combinations of "source in CM"
???

I added a bit of waffle to my earlier post; if you have the time, could you have another look please?

I just tried to import and checked "No" to the "Is this an Xfrog object" and it came in GIGANTIC! - perhaps the option has been inversed rather than multiplied?
BTW; is there anywhere that tells you how tall an object is?
I've tried the ruler but one plant came in at 4 plus km high; but that had to be due to being further away from the plant and the accompanied parallax error (which brings us back to "how on Earth can you get the camera close enough to see the damn plant?!" (I don't mean zoom, btw; that works fine)..............

I just had another play with the ruler and have attached a screencap to show what I mean regarding plant size.
I realise that, ideally (if you want an accurate height measurement), the slope should be 90 degrees - and I could use Trigonometry to calculate the actual height if I knew the distance of the camera from the plant (which I suppose I could work out from their respective coordinate)... but I'm sure there's an easier way............... :o
OK, who farted?

Oshyan

Not sure what you changed. I was just suggesting to try without "Source in CM".

As for the display limit, it is indeed a clipping issue. Just use the [ left bracket key while in the 3D preview and it should adjust the clipping plane. This does need to be done once per session though (i.e. the clipping plane setting will not be remembered if you close TG and re-open it later).

- Oshyan

Erwin0265

#6
QuoteNot sure what you changed. I was just suggesting to try without "Source in CM".

OK, it's obviously me; but what is  "Source in CM"?

I keep discovering new things between post replies and so have been adding bits and pieces here and there in my current post; I hope that's OK - I figure to post again (before receiving any reply) appears rude and impatient.............

Anyway, I tried the left bracket thing you mentioned (Newbies; it appears that all you have to do is click on the left bracket key once whilst you're interacting with the 3D preview and the issue is gone.) and it works! I'm sure that's no surprise to you... ;D.
Beats me why it's not just set that way as default; ie. what's the advantage of "losing sight" of the object you're dealing with in the preview window?

One more question; other than adjusting after import, is there a way to ensure your plant/object comes in ON the surface rather than In the surface?
One of the Xfrog plants I'm working with is more under the ground than above it.........................
OK, who farted?

Oshyan

Source in Centimeters, i.e. "The object being imported is using centimeters" or 1/100th the unit size of Terragen. So TG scales accordingly.

- Oshyan

Dune

Add a card (1m default) or landmark (200m default) and you have perfect reference for whatever you bring in at 0/0/0. And don't forget that from the default POV a clump of grass IS tiny (say 10-20cm high). You'd hardly see it in default.

Erwin0265

Ahhh.
It's due to the fact that I was a high school teacher for 25 odd years that I just didn't see that because the proper symbols for centimetres is "cm" (sorry, don't mean to be the "picky teacher")..............

Since your last reply, I have added yet another load of waffle to the post above (sorry).
If you have the time, could you have a look at that again, please?

Also - I just tried unchecking "Source in cm" (in the OBJ options - Newbies) and now the plant is HUGE.
However, I need a way of accurately measuring its height before I can comment on which one is correct.................

@Dune - thanks! That gives me something to work with..............
I'll get back and let people know what ends up being the correct one - I should also really check the Xfrog PDF (the smallest rye grass plant is only 14 cm tall)............
OK, who farted?

Erwin0265

#10
It looks like I'm posting again before any other replies - I'm just giving feedback (not being impatient).

It looks like the magical combination is to check "Yes" to it being an Xfrog object AND then, in the OBJ Options tab, unchecking "Source in cm".
OR
Check "no" to it being an Xfrog object and in the OBJ Options unchecking "Source Z up".

I think this is a programming error (?):
If you check "Yes" to the object being an Xfrog object, both the "Source in cm" AND the "Source Z up" are checked.*
This results in the plant being made too small but correcting its orientation.

If you check "No" to the object being an Xfrog object, neither of the above-mentioned options are checked.
This results in the plant being the correct size but lying on its side.

Obviously (from my, granted, VERY small sample size), what should be happening when checking "Yes" to the object being an Xfrog object, is "Source in cm" unchecked & "Source Z up" checked..................

*Newbies - "Source Z up" checked imports the plant upright rather than lying on its side.
[attach=1]
BTW. Kinda ironic that the only image file formats T3 can save in are all formats that can't be attached here.......... :o
OK, who farted?

Matt

The Xfrog compatibility options were setup for OBJs imported from the XfrogPlants libraries. Unfortunately they can be quite different from OBJs exported from Xfrog itself, in a number of ways.

By the way, there is a bug in the "Source in cm" option. It scales by a factor of 0.1 instead of 0.01. Unfortunately we can't fix this bug because it would affect all existing projects that have this option checked, but we could probably change the label to "Source in decimetres" in a future release. Nevertheless, enabling "Source in cm" seems to load objects in the XfrogPlants libraries at approximately the right scale (perhaps they are in decimetres?), but that is not necessarily the case for objects exported directly from Xfrog.

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

Erwin0265

QuoteBy the way, there is a bug in the "Source in cm" option. It scales by a factor of 0.1 instead of 0.01. Unfortunately we can't fix this bug because it would affect all existing projects that have this option checked, but we could probably change the label to "Source in decimetres" in a future release.

To my knowledge, decimetres are only really used in Europe; US users as well as Australian users generally have no idea as to what a decimetre is.
Having absolutely no knowledge of computer programming, is it possible to ADD that option?
By this, I mean, change the "Source in cm" to "Source in dm" and "introduce" a new (correct) version of "Source in cm". Set up in such a way that "older" tgds would reference the "Source in dm" parameter as being the setting saved within the tgd and the new "Source in cm" would simply be an unreferenced parameter that the user could opt for when resaving their tgd...............

If that makes any sense at all......................

BTW; the only reason I know of decimetres is because I was born in the Netherlands but grew up in Australia (the fact I was a maths teacher may have a bit to do with it but I know many maths teachers that are oblivious to the unit]......
OK, who farted?

Oshyan

It would be much better to my mind if you just add new replies, it doesn't look impatient, we know what you intend. :) Otherwise it gets confusing if you change a post I later replied to, just to add new information that my reply does not reflect.

Anyway, lots of stuff to reply to, let's see.

First, the clipping issue (left/right bracket keys, i.e. [ ], where right bracket *increases* the clipping plane distance). The reason this is useful/important is because Terragen portrays a *tremendous* range of scales, thousands or even millions of kilometers, all the way down to centimeter/millimeter scale. This requires high numerical precision to represent accurately and so requires lots of digits, i.e. 32 bit (or greater) precision. The problem is that the OpenGL z-buffer (depth buffer) has more limited precision, or at least historically has (I'm not sure if they improved it), and so when we display *in the 3D preview* (which uses OpenGL, while the main renderer does not), we are limited by that lesser precision and must specify a *range* of our total distances to represent in the 3D preview (i.e. the entire range cannot be accurately represented with the number of digits provided by a typical graphics card z-buffer, so we show a portion). The clipping plane adjustment settings change the bias of that range, either closer (so that you see lots of small stuff, accurately, but it clips stuff really far away), or further (so that you see really, really far, but it clips stuff closer to the camera). By default we have it set to what seems to be a reasonable range.

Plants *on* the surface: you need to make sure the anchor point for your object is at the point of your object that you want to be on the ground. TG has no other way of determining the boundaries of your object.

It's good that unchecking Source in CM is doing *something*, but as Matt explains it may be a known bug if it's not working quite right. If so, it would be a matter of simply changing by a factor of 10 I think, so at least it would be a known quantity. But indeed it is annoying, so *adding* an option for true "Source in cm" (see, lowercase! :D ) and then changing the label of the present "source in CM" to "source in dm" (dm?) should be possible, and probably a good idea.

I hope that helps. It's a shame that the Xfrog library models are not the same as what Xfrog software outputs in terms of default scale, it's making all this more difficult I think.

- Oshyan

Matt

#14
Quote from: Erwin0265 on November 04, 2014, 06:46:10 AM
QuoteBy the way, there is a bug in the "Source in cm" option. It scales by a factor of 0.1 instead of 0.01. Unfortunately we can't fix this bug because it would affect all existing projects that have this option checked, but we could probably change the label to "Source in decimetres" in a future release.

To my knowledge, decimetres are only really used in Europe; US users as well as Australian users generally have no idea as to what a decimetre is.

It's not common in the UK either. I was born in '78. In primary school the preferred units seemed to be the centimetre (and the metre of course). Millimetres seemed to get less attention than centimetres, which seems odd to me now, but I do remember that centimetres make nicely sized cubes for children to play around with :) Decimetres and decametres were a sidenote. I would guess maybe they're less popular because of the potential confusion between decimetres and decametres. Who needs them anyway?

Quote
Having absolutely no knowledge of computer programming, is it possible to ADD that option?
By this, I mean, change the "Source in cm" to "Source in dm" and "introduce" a new (correct) version of "Source in cm". Set up in such a way that "older" tgds would reference the "Source in dm" parameter as being the setting saved within the tgd and the new "Source in cm" would simply be an unreferenced parameter that the user could opt for when resaving their tgd...............

Yes that is a very reasonable way to handle it, and we could do that. The thing is, I don't know how useful it will be for most people. You can already control the scale of the object using the scale parameter.

Quote
BTW; the only reason I know of decimetres is because I was born in the Netherlands but grew up in Australia (the fact I was a maths teacher may have a bit to do with it but I know many maths teachers that are oblivious to the unit]......

I see. Yes, I wouldn't have deliberately chosen to single out dm over cm. In the early days of TG development I was working with a company that had standardised much of their pipeline around decimetres, but they were working in Maya with Maya's units set to centimetres. So Maya would call something a centimetre but the artists were building things at the scale where it was a decimetre. This is where the bug originated in Terragen. I thought I was scaling to centimetres, but accidentally scaled by 0.1 and never spotted my error because it just worked. At that point I hadn't twigged that the pipeline was treating centimetres as decimetres and that my code wasn't doing what it said it was. Later on when I added support for XfrogPlants OBJs, the incorrectly named "Source in cm" seemed to work correctly, again simply by accident.

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