I've encountered a problem with my population. When I click for the location of the pop center and paste it in the populator (say 100/-20/300), the population partly floats when a minimum height is blended in. The lowest trees float.
If I manually set the center Y at 0, the whole population goes up. While the population is attached/sits on the last surface shader. Even when the compute terrain is set at 1; no difference. Shouldn't the population size and location be independent of the actual objects of the population, if they 'sit on the surface'?
I hope I make myself clear, I don't even understand myself.
Since I'm no expert at Terragen 2, I can't exactly tell what problem you're having. But I did do something like this a while back (image attached). I think if you want to have the trees sit on the terrain you can't fiddle with the trees X or Y or whatever. I usually leave those as default, and I make sure in the "Terrain" tab that "Sit on terrain" is checked. I'm pretty sure you've got a more complex problem though. ;)
Have you tried with a compute terrain after the last shader?
Strata can screw placement about too, if your using any try turning it off just in case.
Good luck and a great image, I can hardly see the floaters but the artist is always his worst critic :)
Richard
There is a possibility that the problem is in the object too..
I hook a Compute Terrain after the last shader all the time. I then plug this into the objects input which is hooked into the Terrain nodes Compute Terrain. The reason I do this is I can't break the habit of using displacement in the shader nodes. Works well.
If you don't set the pop' to 'sit on terrain' then there shouldn't be a problem. You confuse me here I think, Ulco.
Sorry if my post is nonsense to this topic...
If 'sit on terrain' and 'planet' is unchecked in the populator then, any input you place into a populator should keep position according to the world-space you are in.
I must be lost in this now as I seem to not understand what you mean.
Setting 'sit on terrain' is not the problem (I have done some TG2 work before ;) ), I think a distribution shader somehow 'throws dirt in the food'. I had it set at a minimum height, and at that height the trees indeed float, while the rest (upwards) is sitting alright. I'll try to make a less complicated tgd to see where it goes wrong. I sometimes manually drag the pop area to another location, and the Y would change then as well. But I cannot remember anything going wrong there.
A compute terrain at the end slows things down, I'd say, and shouldn't be necessary. But I'll try that.
And, no, it's not in the object.
Thanks for your comments, guys.
Quote from: cyphyr on April 07, 2011, 04:36:01 PM
......Good luck and a great image, I can hardly see the floaters ..... :)
Richard
What image are you referring to Richard? Is there an image I'm not seeing?
Quote from: Kevin F on April 08, 2011, 03:28:29 AM
Quote from: cyphyr on April 07, 2011, 04:36:01 PM
......Good luck and a great image, I can hardly see the floaters ..... :)
Richard
What image are you referring to Richard? Is there an image I'm not seeing?
Never mind, found it in another thread!
Still couldn't figure it out. Here's some screendumps. Maybe someone sees where I go wrong.
I've had this issue before as well, but forget how I solved it. Think the origin in the original model I was using was below the roots of the tree rather than roughly at ground level.
This is probably way off but from the picture it looks like maybe the trunks of the pinus bush are not being rendered at all. Are you using the raytraced objects option or do you have it off so that your bridge looks better?
It looks to me that the very last compute terrain in this case can cause trouble.
The "surface layer 01" goes to the planet node isn't it?
If you compute terrain after "surface layer 01" you can get mismatches with what has been calculated up to "surface layer 01" and is being fed into the planet node. See what I mean?
Quote from: Dune on April 08, 2011, 02:21:47 AM
...I had it set at a minimum height, and at that height the trees indeed float, while the rest (upwards) is sitting alright.
This sounds very puzzling...I usually use a surface layer, but I suppose it shouldn't make a difference because they should use the same 'key' to calculate altitude and slope.
It's not the trunks (RTO is on), and it's not the last compute terrain (without it it's just the same). I have now deleted many of the distribution shaders and set the max/min height in the surface shaders, but it's still the same.
If you put down a pop, and set a (copied) location of say 100/10/100, and later set the Y at 0, it shouldn't make a difference, should it? Because that's what's also happening ???
I would still suspect the problem is in the object. Origin somehow messed up. Have you checked it in an outside app?
Did you accidentally move the reference object (ie. to something other than 0,0,0)? (it appears in the objects list under the population itself)
No, either of that. But it is only in the lower parts where they float, so the Y must have been miscalculated for the pop to sit on. Might be the warped river, but still, that should have been taken care of in compute terrain...
I don't know if this will help, but this is how I use a 2nd Compute Terrain. I use the last Surface layer in the shaders node group, add the 2nd compute terrain, then connect this to the object nodes. The distribution shader is inside the object node (Sugar Maple 1). I then use the same distribution shader for each object which shares similar settings.
Thanks, Henry. That's what I tried after your first post, but it didn't make any difference. I just dumped the whole tgd and started a fresh setup (Valley and train). Now the grasses and trees behave fine.
Quote from: Dune on April 08, 2011, 01:16:47 PM
It's not the trunks (RTO is on), and it's not the last compute terrain (without it it's just the same). I have now deleted many of the distribution shaders and set the max/min height in the surface shaders, but it's still the same.
If you put down a pop, and set a (copied) location of say 100/10/100, and later set the Y at 0, it shouldn't make a difference, should it? Because that's what's also happening ???
The altitude coordinate in the populator node isn't important indeed. If you set it to 10m then nothing will change.
However, if you change any coordinate in the object loader for the populator then you'll offset each instance with the given value for that coordinate you've changed.
Yeah, I know, but that's what so strange here; the whole pop moves with the pop settings (not the object settings; they are 0/0/0), so contrary to what it should do and what you also write. If the pop Y is at -10 and I make that 0, then the whole pop moves up! It just shouldn't happen!
Ulco, can you make your files (all of them, complete scene) available to us to look at? We haven't seen any reproducible errors like this lately that don't have existing solutions. I'd like to see whether if we can figure out where the problem is.
- Oshyan
Has the populator become disconnected from the planet? I think that happens when you copy and paste populations. Make sure that the name of the planet is in the planet parameter on the populator's Terrain tab. Without that, the population doesn't know how much planet curvature to apply. Or even worse if the planet's surface doesn't pass through the origin anymore.
I haven't looked at the file recently, but I'll look it up and check it out. See if I can send it over..
Not sure this will help, but in practice I make sure that the object is getting the last changed layer in my node tree. This way the object population will spread across all of the lower terrain deformations. I wish I could be more specific, but sometimes this changes so it's not always 100% just one way to connect.
I always do that as well. Henry suggested an extra compute at the end, but that wasn't the solution. I think it has to do with a terrain warper, but the staff is going to have a look at the file.
Are you using a load default from the previous release? I had trouble with my personal default scene. You'll need to create a new default scene to load. There are changes in the new version which makes this necessary.
Just the default coming with TG2.
Ulco, I tested the stripped-down file that you sent us, and the problem was as I described above. The population was connected to the non-existent planet called "Planet 01", while your planet is called "Planet 01_1". I know this can happen quite easily when copying and pasting nodes, but that's the cause. Reassigning to the correct planet fixes the problem.
Matt
Oooh. Nice. Glad to see it was resolved. :-[ <-- Not me.
Quote from: Matt on May 18, 2011, 10:49:14 AM
Ulco, I tested the stripped-down file that you sent us, and the problem was as I described above. The population was connected to the non-existent planet called "Planet 01", while your planet is called "Planet 01_1". I know this can happen quite easily when copying and pasting nodes, but that's the cause. Reassigning to the correct planet fixes the problem.
Matt
Hey, thanks Matt! Was I that stupid??? >:( I'll take care not to do such things anymore.