Same Node settings , different render problem

Started by Kadri, August 31, 2010, 08:49:49 AM

Previous topic - Next topic

Kadri

Open the TGD below .
Make a quick render.
You will get something like the picture "planet_sun_test_01"
Then go to the "Planet 02" object and open its internal node part.You will see 4 nodes. One node -the Atmosphere 02- is in OFF position.
Take the "Cloud layer v2 01" node over this OFF Atmosphere and make it go directly to the Atmosphere shader input (bypass the OFF Atmosphere node).
Now make a quick render ones more. It should look like the second image here(planet_sun_test_02).
Now say you don't like this and want the same render as before.
Put the Atmosphere 02 in the same position as before (between Cloud Layer v2 01 and Atmosphere shader input).
Don't change its state (leave it OFF as it is)
Now make a quick render again.

What? "planet_sun_test_03"...

It should look like the first render (because everything is the same as you open the TGD), but it looks like the second render?
Is this a bug? We should make the same render with the same node states. If this behavior is in other places too it would make TG2 much more hard to use.

Can you guys test this too please. In case i make something stupid here ?  :)

I use : Free TG2 v2.1 (build 2.1.18.1)
          Windows 7 64 bit Home Premium Edition,
          Intel Core 2 Quad Q9400 ( 4 cores x 2.66 GHz)
          4 GB Ram , ASUS P5QD Turbo Mainboard and Ati 4870 Graphics card
          Nothing is overclocked !

dandelO

#1
I think it has to do with the 'heading, elevation, distance' parameters of planet 2. I never use these because I've had problems with this before, too.

Resetting the heading and elevations of planet 2 both to '0' returns the original effect, but, for some reason, the planet doesn't even need to occlude the sun anymore to still cast rays from its cloud layer into the main atmosphere, the cloud layer still occludes the sun, no matter where the planet is. Weird. Hopefully someone has a better explanation for why this happens.

Anyway, I'd avoid the 'heading, elevation and distance' parameters in a planet node and do it by hand, copying the sun's coord's(by mousing over the sun in the 3d preview) to the planet, then resizing the planet radius to your desired size.


dandelO

#2
Look at this shot, the planet is nowhere near the sun but its cloud layer still occludes the sun the original way(you can tell by the 'secondary ray' shadows on the ground that the sun is still actually shining through planet 02's cloud layer, even when the planet is nowhere near the sun).

[attachimg=#]

Definitely avoid the heading and elevation parameters in a planet, though. Unless someone can explain how to use them correctly in conjunction with the world coord's...
Sorry, it isn't an answer, just an advice! ;)


Kadri


Interesting , DandelO !
I tried to copy the "Default Planet" in older tests and had problems with the Atmosphere and clouds.
They were not where they should be mostly when i moved the planet . I wonder if this has anything to do with this problem here?
I thought that two same atmospheres did made TG2 go buggy. So i tried this -maybe more correct- approach (loading a second Planet from the menu directly).
I hope this is a limited kind of bug(if it is of course).

I tried what you did and yes the second planet and atmosphere behaves weird as in your test.
Thanks DandelO :)

Henry Blewer

You should not move the default Planet. The coordinates of any modifications are not tied to the default planet, but a center that the default planet occupies. When you add a 2nd planet, all the nodes associated to it need to connect to this new planets center, not the planet itself.

I ran into this problem more than a year ago. Before I started lurking here anyway. It took me quite some time to figure this out, and because I think I have it figured out, I'm probably wrong. But the concept works.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

dandelO

It's actually 'planet 02' that's being moved here, though, Henry, not the default planet.

I've been quite confused over this myself before. I ended up deciding to simply leave well alone any secondary planet's heading/elevation/distance parameters and translating its actual 3D world-coordinates.

I'm probably just not getting something simple but I can't work it out.
Hopefully there will be some support for this because, to me, it seems like a bug.

dandelO

BUT...

Actually, the second and third shots that Kadri has posted is actually the way that the scene should function.
In the first image, the cloud layer doesn't seem to be attached to the second planet at all. It seems to be suspended over 'planet 01'.
This is wrong, for the way the scene is set up. I don't know how you managed to get that cloud layer to appear as if it's around the default planet, Kadri! :D

dandelO

Nope, the only 'abnormal' thing I can see is that the clouds are plugged into the atmosphere node, not the other way around.
The atmosphere would 'normally' be plugged into the cloud node, in a regular setup.

Kadri

Henry i didn't quite understand you , but as DandelO said i move here only the new Planet.

But as i was trying to say , i did try to copy and paste the default Planet in the past and it was problematic.
Because of this i don't use this method anymore . Maybe you are referencing to this part , Henry ?

I saw your post now DandelO ! Yes this was one of my thoughts too . Thus i am more on the -how should i say- inconsistency part of this.
There is a problem ! But where . Before i saved this TGD or later ?
It looks like a bug although , but i am curious in which point it sleeps in !

But then it could be one of the weird things that happen as i scramble the nodes  :)
If i have time i will look to this a little more.

Henry Blewer

The atmosphere of each planet has its own 'pointer' to the atmosphere for that planet. I do not understand then who the atmosphere came to be separate from its planet. I will play with this after I get off work tomorrow.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

Henry Blewer

Yes somehow the atmosphere seems to have moved its location away from its planet. If I understand correctly. I have a couple days coming to see what is happening after work tonight/morning (I work from 12 am to 8 am).
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

Kadri

Quote from: njeneb on August 31, 2010, 07:58:02 PM
Yes somehow the atmosphere seems to have moved its location away from its planet.
If I understand correctly. I have a couple days coming to see what is happening after work tonight/morning (I work from 12 am to 8 am).

I had similar problems with a cloned Default Planet in the past as i said.
Thus i wonder Henry if something alike is happening here?
But the inconsistency is at least the same concern to me now :)

Henry Blewer

The cloned planet would have the same center coordinates as the original planet. Moving the cloned planet would not alter the center of it. It would just offset the 'sphere' of the new planet. All shaders and atmosphere calculations would be from the original  location.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T


dandelO

No, that's not right. When a planet is moved, any attached atmosphere node values move with it.

The height controls in an atmo' node are taken from the planet to which it is attached, likewise any attached cloud layer's altitude values. They come from the centre of the assigned parent planet.
This is how you can move around a ball of atmosphere/cloud via its parent-planet's coord's/bounding box, even if the planet has no visible surface.
Atmospheres and clouds must be linked to a planet to have any impact on a scene, at all. The coords of that planet are where these nodes take readings from, not the world XYZ coords. Without a parent-planet, an atmosphere/cloud layer will not appear in a scene.