Planetside Software Forums

Support => Terragen Support => Topic started by: Erwin0265 on November 03, 2014, 07:35:41 PM

Title: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 03, 2014, 07:35:41 PM
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...............
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 03, 2014, 07:47:32 PM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 03, 2014, 11:45:07 PM
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?...........

Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 03, 2014, 11:51:38 PM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 04, 2014, 12:24:31 AM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 04, 2014, 12:33:30 AM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 04, 2014, 02:58:50 AM
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.........................
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 04, 2014, 03:01:33 AM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on November 04, 2014, 03:16:29 AM
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.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 04, 2014, 03:24:44 AM
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)............
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 04, 2014, 03:42:50 AM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Matt on November 04, 2014, 04:32:14 AM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: 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.
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]......
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 04, 2014, 06:36:24 PM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Matt on November 04, 2014, 07:19:38 PM
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
Title: Re: Loading Xfrog OBJ's into T3
Post by: Tangled-Universe on November 05, 2014, 01:39:58 AM
Decimeters aren't really used in the Netherlands either. All Dutch learn about it at elementary school, but that's it basically and why they all know it.
Deciliters though is very common as a regular bottle of beer contains 3 dL :)
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 05, 2014, 05:24:10 AM
QuoteIt 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.

OK, good to know - I'll stop trying to confuse you........... :D

QuoteFirst, 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.

Wow; thanks for that comprehensive explanation; amazingly, I understand perfectly (and that's pretty unusual for me; good teacher, crappy learner).

QuotePlants *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.

For what they cost, you'd reckon Xfrog could place the anchor point in the right place to start with, wouldn't you?
Makes sense though; I know Vue .veg format plant generally have the anchor points for the leaves in the wrong spot; at one stage, I spent 2 days editing all of Vue's inclusive plants - only to find they're mostly crap anyway (unless viewed from a distance - and with that condition, we can all model plants...).
Looks like there's some more editing to be done in Xfrog (and then export to obj, import into Terragen, save as tgo....).

QuoteIt's a shame that the Xfrog library models are not the same as what Xfrog software outputs in terms of default scale,

Now that's just bloody stupid, isn't it?.............


QuoteI would guess maybe they're less popular because of the potential confusion between decimetres and decametres. Who needs them anyway?
.

It's kinda funny that we rarely use a decimetre when we use the decimal system...............
Because of that omission, I've always found it difficult to teach the decimal system to kids (and children too.. ;D); the decimal system is meant to work in units that increase by a power of 10 from one unit to the next:
10mm = 1cm, 10cm = 1dm, 10dm = 1m, etc......
With the decimetre missing in the kids' knowledge base, it doesn't make as much sense..........

QuoteIn 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.

It all looks so reasonable when you look back on it; "Why did I miss such a basic error?" - but when you've "lived it" for a while, we all can be convinced that white is black and vice-versa.......


QuoteDeciliters though is very common as a regular bottle of beer contains 3 dL

So is that 300mL? BTW; good to see you're using the correct symbols............. ::)
In Australia, it's millilitres or litres; nothing else (at least wrt volume).....

Oh look at us; geeking out over units in the decimal system............
Time to get a life.......... ;D
Title: Re: Loading Xfrog OBJ's into T3
Post by: Matt on November 05, 2014, 06:26:39 PM
Quote from: Oshyan on November 04, 2014, 06:36:24 PM
and then changing the label of the present "source in CM"

The label has always been "Source in cm" with lowercase.

Matt
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on November 05, 2014, 10:10:16 PM
I was just saying to change it to dm, not to lowercase, and pointing out that "dm" was lowercase. ;)

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on November 06, 2014, 04:44:23 AM
QuoteIt'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.

""Source in cm" (see, lowercase)" - funny how you made a point of using lowercase but then only did it that one time........
I think that's what got Matt confused between "Source in cm" and "Source in CM" when your point related onlyto unit changes between cm and dm.............

I think we may be getting just a TINY bit too involved in this........................ ;D
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 11, 2015, 07:22:40 AM
I don't know whether I should be starting a new thread for this but as it still relates to Xfrog OBJ imports into T3, I'll put it here until I'm told to do otherwise..........
I am now playing around with converting Xfrog xfr files to OBJ in C4D R15, using the Riptide plugin to allow C4D to also export an MTL file with the OBJ.
After hours of fiddling/tutorial watching & reading, I appear to have the plants coming into T3 at the correct scale, orientation and all textures applied correctly.
However, the preview shows the plant as totally black (if you zoom in really close, you can see the textures but it's as if you are viewing them on a moonless night in a cave - if you get my meaning........ ;) ); BUT when rendered, they appear to be fine.

Can anyone suggest why this is happening?
When I check the imported OBJ, all of the textures are there and in the right place and, when compared to other OBJ imports that show up correctly (ie. in colour) in the preview, all of the settings appear to be almost identical..............
Resaving as tgo makes no difference................
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on February 11, 2015, 07:24:48 AM
Normals might be flipped. TG is taking care of that now, but I don't know if the previes also does.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 11, 2015, 08:05:29 AM
You are a GOD!!
All I had to do was to check "Export Normals" in Riptide and that was it!
Problem solved!
Thank you.
I have attached a few screencaps in case someone else has a similar issue.
1. Refers to the preview window.
2. These are the Filter settings after changing the Normals setting (it was unchecked before).
3.Again, refers to the preview window.
4. Just a cropped render - it hasn't changed from before; only the preview has - but it makes scene setup so much easier...........
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 11, 2015, 09:00:29 PM
Well done figuring this one out quickly you guys! Definitely good info to have here.

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 12, 2015, 04:49:24 AM
Initially, I just tried to convert the xfr to obj in Xfrog 3.5 but I found that some parts were importing into T3 without textures AND without being in the list of parts so that I could allocate a texture manually!
I have been writing back and forth to Walli who has been giving me help well and truly above and beyond.....
Unfortunately, even when trying to use PoseRay in the pipeline, things did not work for me; the obj was coming in minus textures - and looking at the mtl files I was creating in Xfrog 3.5 and comparing them with what Walli was getting doing the same thing (we believe); his mtl files were totally different; perhaps a bug in Xfrog 3.5 (something I doubt that Greenworks would be all that interested in looking at considering the age of the software).
So I wanted to find a reliable method to convert xfr to obj and then finally save them out as tgo for immediate and future use - even though Walli had offered to send me his mtl files (what a great guy!) which would solve my immediate problem but not in the long run.........
As I have C4D R15 and am planning on learning it as my go to modelling package, I thought I'd get Xfrog 5.2 (not 5.02 which is for R13 & 14; or 5.3 which is for R16 - all easily confused and mixed up - careful to those who may decide to go a similar route) and have a go at using the power of C4D to help me with the issue.
Can you imagine my utter surprise when I discovered that C4D doesn't export obj export with textures (ie. no mtl file)!!
So, after a bit of searching, I learnt about Riptide Pro v2.5 (you used to be able to get a free version which also did the trick but as of R12 the free/old version doesn't work - so you have to use the Pro version) which is a plugin for C4D that enhances C4D's obj export capabilities.

I am in the process of writing myself a tutorial for the process I am now using that appears to work.
Although only the very last step involves using Terragen, I think it is quite relevant for many users - even if only to convert a handful of models for a project, using 30-day trials (or if you have an older version of C4D, the free version of Riptide is still available on the site).
Anyway, I am happy to share the tutorial with others.
Oshyan, is there a way that I can send the completed tutorial to you so it can be added somewhere to the wiki; or is it not TG2/3-centric enough?
I am not specifically writing it for others currently, so if you think members can benefit from it and there is a way to post it, lmk and I'll tweak it so it's suitable and understandable to others and not just me.........
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 14, 2015, 12:43:31 AM
It sounds useful to me, definitely. The Wiki is actually publicly writable with an account in the forums here (same login info). And it allows attachments, if you want to provide the tutorial in PDF and just write a short intro. So if you do feel like sharing it, please do! And let us know if you have any problems with that process.

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 14, 2015, 04:48:45 AM
OK, when I have ironed out all of the kinks I'll check out the process and upload it.
I have completed version 1 of the tute but have recently come up with an issue that I have yet to sort.
A friend shared a few Xfrog Asia plant files with me but they're all in obj format and import wrong scale, wrong orientation, no transparency and again totally black in preview.
I thought, "why not?", I'll have a go at running these thought the same process; but also use the Riptide plugin as import as well as the export.
I cab get everything right except for that damned black preview.
Following Dune's original clue, I import the normals when I use Riptide to, well, import (duh..) and also export the normals when I use Rip.. You get the idea.
Despite this, the preview is still black.
It's fine on render; so I guess it's workable, but it's just plain annoying............
As well as a screencap illustrating the issue (yeah, I know the render is dark; it's just so I can save a preview with the edited files - one of my filing quirks), I have also included the mtl file (as a .txt file as an mtl file can't be attached anyway - I found it easiest to read using Textpad rather than Microsoft's Notepad; for MAC, I have no idea) for anyone to knows what they're looking at to check out (it looks pretty right to me but then I'm not really a programmer.)..
Any ideas anyone?.......
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 14, 2015, 06:09:18 PM
Quite possibly the normals were inverted from the start, so importing then exporting them won't inherently correct them. This may be a situation where Poseray would be a better tool to fix the issue(s), rather than C4D + Riptide.

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 16, 2015, 06:26:05 AM
You were right, Oshyan.
Initially, I had tried the direct to PoseRay route but the model was importing without the leaves being visible.
Try again now, I played a bit more to discover that the wrong transparency map had been applied (the colour/diffuse map rather than the alpha); I hadn't thought too much about it as Terragen uses the colour/diffuse map as an alpha and it works fine; obviously in PoseRay, this is not the case.
Anyway, this time, I replaced the transparency map, using the alpha instead and viola! the leaves were visible.
I then used the help to find where the "flip normals" option was [Noobies; under the Group tab, bottom section, middle column, second down] and clicked on that to do just that (flip the normals, that is.....).
Funny thing though (and a definate potential panic point for noobies - I survived it...); the preview in PoseRay (which had been perfect after changing the transparency maps) turned totally black!!
It appeared as if I was editing the model to achieve the exact feature I was trying to eliminate!
But I thought, "FireTruck It" and imported my new, totally black, model and hey presto (or Viola! - whichever you prefer...); our textures were back!
Looks like PoseRay likes the Normals one way whilst Terragen likes them the other way (no accounting for taste.....).

Now it's time to start playing with converting Vue vob plants to Terragen tgo.
Some day, I may just get back to the project I had started before thinking, "Hey, some more variety in plants would be good"......

On another note, I have finished the tutorial write-up for the Xfrog xfr to Terragen tgo via C4D/Riptide workflow (it's actually easier than the title).
All I need to do is work out how to convert Word.docx to Adobe.pdf and then how to upload.
But that's for another day............
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 16, 2015, 02:12:52 PM
Depending on your version of Office there may be a direct Save to PDF option (or maybe under Export). Alternatively you can use a PDF writer printer driver like DoPDF: http://www.dopdf.com/
Then you just go to Print and choose DoPDF as your printer to output a PDF.

On a Mac there should be a built-in PDF writer.

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 17, 2015, 05:46:51 AM
OK, I'll check it out (I'm on PC)..........
Funny thing is when I went to convert another of the 9 Xfrog models I wanted to possibly use; the model imported at a tiny scale, on its side and minus all textures!
Now I have to work out what I did before because this was one of the reasons I went to the C4D Riptide route in the first place.
Perhaps I converted one of the already converted (ie. via the C4D-Riptide route) and so all I ended up doing in PoseRay was flip the normals (which is all that was needed to solve the black preview issue)...............
Oh well; at least I'm learning new stuff with all these issues............. ;)

BTW; how can you make the measuring tool work reliably?
I know; strange question, but in trying to determine the difference in scale for the 2 different PoseRay outputs, I thought to just use the measuring tool, lock the Y axis and measure away - but then I end up having trees that are 3 km tall because of the Z axis (ruler is behind the plant or starts off in front - ends up behind, yada, yada).
As you can't lock 2 axes at the same time; how do you prevent the parallax error?
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 17, 2015, 06:27:33 AM
Here's just a few screencaps to illustrate my issue.
I can see why my measurements are wrong; I just can't work out how to fix it............
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on February 17, 2015, 10:50:21 AM
You could try with an object with known size like TG's sphere.
Put it right next to your tree and scale away.You can even scale the sphere to
the desired height first and then your tree according to that.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 17, 2015, 07:25:59 PM
True; thanks for the suggestion, but surely there is a way to get the measuring tool to measure accurately?
I played with it a bit more and found that even though I locked it to Y (which means it SHOULD only be able to measure up/down), it could still move sideways (X) and in/out (Z); isn't doesn't that mean it's not working properly?
I know I had it working properly before but now it's a totally useless feature.....................
I think I have a tgd somewhere that allows for accurate measuring using props made in another app (downloaded from file sharing).
I'll use that for now.
Anyone use the measuring tool successfully and can give me some pointers, plmk.............
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 18, 2015, 07:22:34 AM
Oshyan,
I have completed the Xfrog to C4D/Riptide to Terragen tutorial (and converted to pdf via doPDF - saving to PDF in Word made the images virtually useless - none of the text in the images was readable).
I also wrote a simple Xfrog obj format to PoseRay to Terragen workflow (no screencaps but it's pretty simple - even I managed to work it out).
But I need a bit of guidance as to how to add it to the wiki as I can't find any location for this.
I'm happy to upload to you (with an intro included), so you can proofread it also and upload to the wiki if it's worthy and useful to others.
PLMK.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 26, 2015, 01:02:40 PM
Sorry for the delay, I'll be in touch with you soon about how to post it.

Thanks,

Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on February 27, 2015, 06:03:17 PM
That's OK.
My graphics PC is currently in the shop as I was unable to solve a BSOD issue when rendering a scene in Terragen (I imagine it'd be the same with any other software also when using the CPU to 100%).
The tutes are on that PC so there's no hurry; it could be a week (or more if it ends up being a hardware issue related to any of the new components I got 5 months back) or so (Wahhh; I miss my 'puter.....).......... :(
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on February 27, 2015, 06:31:58 PM
Ouch, sorry to hear that! I hope it comes back in good shape ASAP. :)

- Oshyan
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on March 08, 2015, 11:34:03 AM
Recently ran into something similar - the preview showing black or in my case dark gray in
smooth shaded mode -,but didn't pay too much attention at first.Two days ago I had that
again and remembered this thread and started to investigate,because in my case it could
not be inverted normals.My object had no normals at all.And that's what's causing the effect
apparently.Inverted normals don't.(see image)
I already knew ZBrush doesn't export normals (that's where my object was from),now it seems
that Cinema4d doesn't export normals,too,at least without that plugin.
Would be interesting to know what app Ulco had those problems with as he was the one
who mentioned the 'flipped' normals first in this thread.
You can see,if your object has normals or not by rendering it.Without normals it should
render as facetted,because the normal smoothing won't work.Another way would be to
look at the obj file in a text editor.
Sorry for being late.

Edit:The image shows how it is displayed in the preview window.
Title: Re: Loading Xfrog OBJ's into T3
Post by: jaf on March 08, 2015, 12:36:47 PM
I know with Lightwave (at least version 9.6) it's easy to build geometry that are non-planar or have poly's "flipped."

The three images below ........  the first (lw.jpg) is two 1m cubes built in Lightwave.  The cube on the right has one face "flipped".  The second (tg_135.jpg) shows the two cubes from Lightwave on the left and those same cubes processed and saved from Poseray (only "Recalculated Normals" and the save) rendered with sunlight from 135 degrees.  The third (tg_235.jpg) just has the sunlight from 235.  And the fourth has the Lightwave cubes swapped with the Poseray versions -- Poseray on the left.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on March 08, 2015, 12:50:39 PM
Indeed, it was LW in my case also. But TG can now deal with flipped normals, as before the objects turned dark and light effects were kind of inverted. But, indeed again, you need normals for smoothing.
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on March 08, 2015, 01:00:47 PM
jaf - It was about the shading in the preview not in renders.Just in case you missed it.

Dune - I know about the flipped (inverted) normal effects and that TG renders it now.
          It's missing normals and how that is displayed in the preview.
          If I'm not mistaken,that is.
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on March 08, 2015, 02:14:16 PM
To illustrate the difference between flipped faces and flipped normals.
The first pic shows flipped faces.Although the selectable side (and the normals)
points inwards you can still see the outer side.
[attach=1]
This next pic shows inverted normals.The flipped normals point inwards,but
you can't see the outer side anymore.This leads to the effect that can be seen
when you rotate such an object.Similar to looking inside a hollow negative mould.
[attach=2]
I know it's confusing. ;)
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on March 09, 2015, 03:15:02 AM
Thanks Jochen. I always thought (though I never really thought about it) that the normals pointed up from the positive face side, but now that you mention it, I've encountered the difference when working in Poseray.
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on March 25, 2015, 12:48:07 PM
Recently downloaded a free model that turned out to have no normals.
To my surprise it's texture was visible in TG's preview.
So I started testing again and here are the results.
[attach=1]
Seems to be there always,just a bit darker (no normals) and/or with wrong lighting (flipped).
For the above tests the diffuse color was set to 1 and the sun to 240° instead of the default
300°.
Maybe the effect Erwin and Ulco saw could be caused by too low a diffuse color (and a dark bark
texture) and light from behind?
Would be nice if someone could check that out with one of the problematic models.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on March 26, 2015, 03:09:43 AM
It seems you really need to take care to have normals ánd have them point the right way, but I always thought normals were always there, as a logical consequence of the face itself. I noticed in some DAZ stuff (like shoes) that they're flipped. I guess because they should more easily conform to the foot normals of the character, that's what they recommend in LW at least.
Title: Re: Loading Xfrog OBJ's into T3
Post by: j meyer on March 26, 2015, 12:15:37 PM
Normals are there as long as you are in the software,but some don't export normals
to keep the file size reasonable and since any decent modeler or package computes
normals it's usually no problem.Just TG does not unfortunately.
An example for the file size:the model I found recently had ca.22mb and after adding
normals it had ca.45mb.Sometimes it's a bit less,but at least a third more,depends
on the software,too.Makes a big difference using really high poly meshes.
Title: Re: Loading Xfrog OBJ's into T3
Post by: Dune on March 27, 2015, 04:00:06 AM
Ah, didn't know that. So there's another task for Matt  ;)
Title: Re: Loading Xfrog OBJ's into T3
Post by: Erwin0265 on April 04, 2015, 04:12:35 AM
Looks like there have been a few posts added since I last checked out this thread.
Oshyan, I have finally got my graphics PC back; the store I purchased some replacement parts from (By "some", I mean, a new MB, CPU, 32GB of RAM and a few extra fans - all of which needed replacing on a 5 year old rig! It's disgusting the "quality" of electronic components nowadays) were fantastic and methodically tested all of the RAM, etc (hence taking so long; 32GB of RAM alone, takes quite a while to test) as well as getting me in to show them exactly what was happening as they were unable to repeat the problem on the bench whilst testing (None of the technicians were graphic art savvy; graphic games was the depth of their knowledge in that area).............
So after testing for 3 weeks, they finally found the problem; it was the 5 month old CPU. Ironically, all of their usual bench tests showed the CPU to be fine; it was only when they tried to render a WIP image I had been working on in T3 that the problem arose.
Changing the CPU for a new one eliminated the problem.
So what was potentially going to cost me several hundred dollars for the testing alone (fortunately, they have set prices up to a certain number of hours; after which the price remained the same) ended up costing me nothing and they replaced the CPU straight away, even though the boss insists warranty items be returned to the manufacturer to await their response BEFORE replacing an item - which could have meant another month or so............................

Anyway, after all that, I'm ready to upload those tutorials I wrote relating Xfrog OBJ to T3.
When you have the time, could you get back to me to lmk how/where/etc to upload them for others to hopefully make use off............
Title: Re: Loading Xfrog OBJ's into T3
Post by: Oshyan on April 07, 2015, 01:29:30 AM
Fantastic! Glad you got through without a fee, sounds like a bit of an ordeal. I'll sort out the upload/link/share procedure and let you know the details as soon as I can. Welcome back. :)

- Oshyan