Wouldn't it be good if Terragen could read Xfrog files natively !:)

Started by cyphyr, May 06, 2009, 05:29:20 PM

Previous topic - Next topic

cyphyr

Wouldn't it be good if Terragen could read Xfrog files natively !:)

I was wondering about the old populator node which had a "Number of Vairations" setting on it. How was planetside planning to implement this? Then it came to me, what if that was a planned feature for reading the only format of plants that allows multiple vairations (via a random seed), the .xfr format. Wow that would be cool, true near infinate vairation, (including scale and rotation vairations) in our forrests and meadows, junk piles ;) etc, since xfrog allows animation in their models (I think) by loading in sequance (easily scriptable even now) you could have your veg blowing in the breeze!!!!

Planetside and Greenworks please keep up your realtionship :)

Just an idea :)

Richard

ps always wanted to do a MASSIVE pile of junk using the populator !!
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

neuspadrin

That would be pretty awesome, and make a purchase of xfrog software very tempting.


GioMez

Yeah! A sort of what I wrote (and still dream) in my top5
And you can see that there are already other plugins for other apps!
An offer like this would be much more attractive than a bundle! ;)

Oshyan

Certainly something we're thinking about. ;D But keep in mind it would require a good deal of development work to implement. So even once there is agreement between Planetside and Xfrog on the particulars, it has to be prioritized along with other important things like animation, 64 bit support, etc.

- Oshyan

cyphyr

Hehe yes I didn't think this would get in on the 2.x cycle, would be nice though :)
Just a ponderance on the reason behind the 9no longer included) "number of unique vairations" setting on the populator node, how could if have been intended to work? Seemed like the obvious solution.
Richard
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

pixelthekid

I would fully support this with my wallet. =)

By the way, I just got the XFrog bundle for TG2 and I am extremely happy with both Greenworks and Planetside (of course).  The quality I'm able to get with only a week worth of TG2 experience is pretty darn sweet.  The XFrog plants are just plain beautiful.  XFrog plants have saved my bacon several times and now that I have TG and a boatload of plants I'm in heaven.

Oshyan

Honestly I'm not sure how the 'number of variations' feature was intended to work. My guess, though, is that it was implemented as a general function for all instanced objects, and of course it works (or can work) for internal objects like the grass and rocks. But since it was implemented "globally" it appeared that it was supposed to be a feature for loaded objects too. Of course there would be no good, clean way to do this without procedural objects.

- Oshyan

Walli

I think it would be more practical - for the first steps - if you would simply be able to point the populator into a folder and it simply uses the tgo files from there. Of course you would have to pre produce those files.
And I would find it extremly useful, if the populator would know if its a "plant on the edge" or a "plant in the inner". For example taking a look at a real forest. The trees in the inner grow very slim and high and produce the foliage mostly in the upper area. Trees that reside on the "edge" look different - their side which is pointing towards the forrest is often bare, the side pointing away from forest is mostly densly populated, often from base up to the top.

So if you could offer "special" variations to the populator and the populator knew where to place them, that would be awesome. Much better then just automatic variations.

Mohawk20

Quote from: Walli on May 07, 2009, 04:31:43 AM
I think it would be more practical - for the first steps - if you would simply be able to point the populator into a folder and it simply uses the tgo files from there. Of course you would have to pre produce those files.
And I would find it extremly useful, if the populator would know if its a "plant on the edge" or a "plant in the inner". For example taking a look at a real forest. The trees in the inner grow very slim and high and produce the foliage mostly in the upper area. Trees that reside on the "edge" look different - their side which is pointing towards the forrest is often bare, the side pointing away from forest is mostly densly populated, often from base up to the top.

So if you could offer "special" variations to the populator and the populator knew where to place them, that would be awesome. Much better then just automatic variations.

Heheh, possible response: "We were thinking about the same thing, and are happy to inform you this functionality will be implemented in TG5!"  :P
Howgh!

sjefen

Would it be very difficult to just (for now ;)) make an color variation option for the leafs?
Maybe with a little cooperation with Xfrog?

- Terje
ArtStation: https://www.artstation.com/royalt

AMD Ryzen Threadripper 1950X
128 GB RAM
GeForce RTX 3060 12GB

RArcher

Some of the leaf variation issues can simply be solved by the modelers creating multiple leaf sections.  Most only have a single leaf texture for all the leaves on the tree, but if you take a look at the Oak tree that Klas created it has the possibility to add 8 individual leaf textures so what I have done is slightly vary the colour for each leaf section and it turns out pretty amazing.

For example:

http://www.archer-designs.com/zp/index.php?album=digital-art%2Fterragen-2&image=trees.jpg

or

http://www.archer-designs.com/zp/index.php?album=digital-art%2Fterragen-2&image=forest-canopy-v2-small.jpg

dandelO

Oshyan:
QuoteOf course there would be no good, clean way to do this without procedural objects.

Couldn't it be implemented (for imported objects) to apply a varied specified range of of X and Z rotation parameters?
It would remove the need to edit the parent object rotation values in the population if you wanted leaning trees.
Currently, you must edit the X or Z rotation values in the parent object to get this effect but the downfall of this is ALL instances will now be tilted as you only have the option to specify Y rotation in the populator, as it is now.

Populator v.4, anyone? ;)

Oshyan

dandelO, I think it's pretty hard to make manipulations like that on polygon data and still make it look realistic. Walli's approach is probably more realistic, and also probably easier to implement. Believe it or not the UI would probably be the most difficult thing to implement. Something to think about.

- Oshyan