Loading Xfrog OBJ's into T3

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

Previous topic - Next topic


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 :)


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
OK, who farted?


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.

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


I was just saying to change it to dm, not to lowercase, and pointing out that "dm" was lowercase. ;)

- Oshyan


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
OK, who farted?


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................
OK, who farted?


Normals might be flipped. TG is taking care of that now, but I don't know if the previes also does.


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...........
OK, who farted?


Well done figuring this one out quickly you guys! Definitely good info to have here.

- Oshyan


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.........
OK, who farted?


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


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?.......
OK, who farted?


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


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............
OK, who farted?


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