Same Node settings , different render problem

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

Previous topic - Next topic

Kadri

August 31, 2010, 10:23:23 pm #30 Last Edit: September 01, 2010, 12:11:37 am by Kadri
I looked at the TGD with Notepad. We can not see it in TG2 directly but the Atmosphere and Cloud nodes have their own center and radius values !
They take these from the Planet they belong it seems ! When we delete the planet these values don't change when we attach them on an other Planet.

I don't know how much related these things are with the problem of course  :)

Edit: Couldn't sleep! I did copy and paste the Atmosphere and Cloud parts of the TGD in Notepad and changed the names and position a little.
       I had to make the inputs by hand(they were messed up) in TG2 . But i had 3 Atmospheres and Clouds with only one Planet .
       We could make so much we want it seems.
       I can not see for now a way to use this , this doesn't look like to have a practical use , but who knows  :)

Kadri

September 01, 2010, 07:45:27 am #31 Last Edit: September 01, 2010, 07:59:40 am by Kadri
Open a new project.
Change the camera to look at the sky.
Add a new Planet Object.
Go into the internal node part of this new Planet.
Disable the Power fractal shader in there (to make things easier to see).
Right mouse click and add a Cloud Layer .
Put this in the Atmosphere node (not in the Atmosphere Shader).
Now make a quick render.

Ooops! The Default Planet doesn't have Clouds attached but the clouds are over the Default Planet somehow!
(strange _01_Planet.tgd and strange_Planet_01.png)

Change the order of the nodes. Put the Atmosphere node on top and its output in the Cloud Layer node.
Then the output of the Clouds Layer node in the Atmosphere Shader input.
You can test them now with disabling them one by one. There are no problems now. The Atmosphere and clouds are over the New Planet as they should be.

Now comes the Last important part. Disable only the Atmosphere node.
When you render now you will obviously see only the Cloud layer of the New Planet.
Move the New Planet with this disabled Atmosphere  in any direction  and make a new render.
The Cloud did move with the New Planet without problem.They are in the new position.

Now enable the Atmosphere node and make a quick render the last time.
(strange _02_Planet.tgd and strange_Planet_02.png)

Voila ! The Atmosphere and the Cloud Layer are not in the same place. The Atmosphere node didn't move with the New Planet!

I think here could be the problem and if this is a problem there could be 2 of them at ones it seems !

Edit: If you put the enabled Atmosphere ones more between the Cloud Layer and Atmosphere Shader it works ones more as it should be .
       It seems that the Atmosphere node is updated in this way. (strange _03_Planet.tgd and strange_Planet_03.png )
       But we did put this Atmosphere the first time in the same node order and there were the cloud problem as i said above , but now not!
       It would be good if Planetside looked here , it is really confusing  :)


dandelO

Quote from: dandelO on August 31, 2010, 07:49:35 pm
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.


So, this is the reason for the way your original .tgd is displaying the second planet's clouds on planet 1, Kadri?
I still don't understand why this is happening but it seems that this is the way to force into existence Henry's explanation of offsetting only the planet sphere and keeping the attached atmo's at their default creation points(in your case, planet 01, because it was a clone of the default planet that created planet 02, I think).
The thing is, re-enabling or rearranging the said node connections seems to make it work 'correctly', the way it should.
A weird one, to be sure!

Good and thorough testing, Kadri! :) Still seems like a bug to me, though, one we should make use of and exploit! ;)
I'd also like some official clarification on the 'why' of it, though.

dandelO

QuoteThey take these from the Planet they belong it seems ! When we delete the planet these values don't change when we attach them on an other Planet.

I don't know how much related these things are with the problem of course


It relates exactly to your original problem. I think there should be some hidden function that resets those values as soon as the node is plugged into another planet. It isn't as if you can move the isolated atmosphere around with a handle or bounding box once the parent planet is deleted.

Henry Blewer

I found that grouping the nodes separately into Planet1 and Planet2 makes it easier to work with the node networks.
The way I understand how planet shading works is based on the planet coordinates. 0, -6.378e+006, 0 is the center point and 6.378e+006 is the default radius. The Base Colors and Default Atmosphere use this coordinate for everything. When you create a new planet, the new center location of the new planet becomes the origin for the new Base Colors and Atmosphere.

When the default planet is cloned, it inherits the default center coordinate, no matter where the cloned planet is placed.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

dandelO

As long as the secondary atmosphere/cloud *doesn't* plug directly into the new planet, it will stay with the original coord's it had before the second planet was deleted.
Plugging the secondary atmosphere into the default one keeps it where it was, if you plug the default atmosphere into the new one and then the new one into the default planet it will then reset the atmosphere values to match the following planet. You must keep something between the new atmosphere/cloud node and the default planet, to keep it in its previous position.
Putting it directly into another planet, with nothing between the two, will reset the second atmo/cloud coord's to the expected position.

I'm glad we got that sorted out! :D

Kadri

Yeah guys at least we know there is a problem and how to handle it  somehow :)
But it is still problematic of course.

DandelO now i remember why i use the mouse in the internal part of this New Planet node.
If you try to put a Cloud Layer from the menu they aren't created where they should be.
They are directly putted on the Default Planet Node. This is wrong too.

look at the picture .Can you see the differences?  :)
For new users it would be easier to show it.

The first and the last Node setup are the same. But the Clouds are in different places.
Ones on the Default Planet then on The New Planet .
If you put the Cloud node at first like in the first picture at top you have the problem.
When you change the Node input order (Cloud layer + Atmosphere ) and then put it exactly as in the first place (Atmosphere + Cloud Layer) it is where it should be.
It gets updated in some way as i wrote above .

I wonder if this has something to do with the problem that the internal node is created outside at first when we use the menu for the creation of the Cloud Node of the New Planet ?


dandelO

I normally always create secondary planet cloud layers or atmos'(in fact, every node, more or less) by right clicking in the network area.
Exceptions for me are, for example, creating a fractal terrain or, population on planet 1. With these, I seem to use the 'add etc.' buttons, it's easier to make a regular population this way because it will auto-link it to your planet and, with fractal terrains there is less editing to 'add terrain' than to right-click>>create shader>>displacement shader>>power fractal(you end up with a 1,1000,0.1m fractal this way, not a terrain scaled one.
Every other node I use is created via network context-clicks. I work almost exclusively in the node network. You can choose exactly where each node goes that way. I thought maybe you were using the node list buttons in each tab up-top and that that might be causing the problem.

Regardless of this, and the actual solution to your problem, I still never use the heading/elevation/distance controls in a planet node, it doesn't work the way I'd expect. If you'll notice, those parameters don't change when you drag a planet around with its translate controls but, the translate controls *do* change when you use the heading/elevation/distance parameters. Something doesn't mesh right with that, in my brain, at least. :D

I can't see much use for exploiting the 'stuck in space' atmosphere phenomenon when there's no connected planet node, you can't move it around or, do much else with it. You can always still disable the surface of a planet and then move it around that way, though. I think that should be tidied up so it doesn't happen but, it's no big deal to me really, I'd never noticed that this even happens before your intriguing problem last night. :D

Just make sure that you reset this uneditable value by plugging the desired node directly into the desired planet first next time, Kadri! With nothing between them! ;)

Kadri


This is all because of , Hannes. He mentioned a Big Red Sun in my last image LOL ;D