[Kabe]

Ok, I really was sick of it. The sun seemed to be completely out of control, and i had no idea how the sun was calculated, and what worked, and what not.

These test were run with Cinemaxwell, but the principle and the texture used should work in any 3D app. All astronomical data are from http://www.calsky.com

So first I build a sun dial to read out the sun position in terms of rectacension (hour angle) and declination (~height). This was just a bitmap with circles and lines calculated for the different angles. You can download it here (1 MB):
http://klausbusse.de/Temp/Maxwell/TangensMap.zip
The fat circles are 5° lines, with the 15°, 30° marked in orange and the 45° marked in blue. Starting with 60° (which is again marked orange) every degree is marked with a thin circle. Combined with a proper cone to cast the shadow you can get the sun angles from the rendered image with enough precision to know what's going on. The cone has to have the same length as the distance of the blue circle and the center. Get a complete Cinema file here - 20 k, remember that you have to reassign the texture to the material!:
http://klausbusse.de/Temp/Maxwell/SunPosition.zip

Then I started rendering. To strip it down to the basics I started with a Latitude of 0 and GMT of 0. First I found out that the Cinema sun which I planned to use as a reference was hard to use, because it changed the hour angle based on Longitude and the current time settings of the local machine!
So, to get 12:00 for the Null meridian, I had to add 2 hours (which is my current time zone) and pu in 14:00 to make it work
Details see here: http://klausbusse.de/Temp/Maxwell/CinemaSunBug.jpg

Ok, then I looked up in Calsky the transit data for July 15th for that location, and came up with 71.5° at 12:06 for the transit. So I put in 12.1 for the time in Maxwell and rendered. Well, that was a loooong shadow I got here... about 62°, so the sun was at... (90-62=) 28°. That's was completely in line with my prvious observations that the shadows are much too long... Now I did the same with a longitude of -40 - and that was quite revealing:

That's interesting - the shadow is shorter (near 20°, so the sun was up at 70°+), and the image is much brighter - hey, that's it... actually it seems that someone flipped the wrong vector: The declination of the sun is calculated for the wrong hemisphere! In reality it's winter in the south hemisphere, so the shadow should be longer there, and the declinations match exactly what they should be in the other hemisphere!

Next I tried to get the influence of the month and found out that the month popup just do not work at all!

Then I checked for GMT compensation and latitude, and this seems to work ok as first tests show.

Sun rise and sun set are not calculated very well, the day seems a bit shorter - however, I think I'll test that later more thoroughly.

So, now everybody is invited to use this texture/scene to contribute more observations, and NL should make this work right after or while they fix the Cinemaxwell Mac beta...

It's not hard to fix, as the sun simulation is actually pretty good - there are two things to change:
The longitude coordinate must change sign to get to the correct hemisphere. As a side effect this will change the north/south vector (whatever axis that is), so the the north vector has to change sign so the sun is at the right position regarding north/south.

That's basically it - it really takes less time to fix it than to find it - so please, NL...


Regarding sun rise and sun set, there might be a little issue left, but it looks like that basic fix should take of anything that happens betwenn 1 hour after sunrise and 1 hour before sun set.

Kabe

[jc4d]

Hi
I'll try this texture/scene, and meanwhile you and the NL could check this link http://www.realestate3d.com/gps/world-latlong.htm I use it always when I want to use a sun.
Greetings.

JC

Maxwell Beta 1.2 (not working)
Cinemaxwell 0.5 (so so)
Cinema 4D 9
MacOS 10.3.9
G4 Dual 867

[jc4d]

Hi again.
I try your file and texture and this is my results:

1.-Cinema 4D 9 render:


2.- Cinemaxwell Beta (before the crash)
Settings: (same as Cinema sun settings)
Physical sky ON
Sky ON
Latitude 10.30
Longitude 66.56
Hour 12
GMT 100
June 27


3.- Cinemaxwell Beta (before the crash again)
Settings: (same as Cinema sun settings)
Physical sky ON
Sky ON
Latitude 10.30
Longitude 66.56
Hour 12
GMT 0
June 27


I hope that my test help.

P.S. Another thing that I could see is in cinema sun you can specify the North or South for Latitude and West or East for Longitude; And in cinemaxwell Sky tab you don't know if the Latitude is in N or S and the Longitude is in W or E and I think this is a Weak point on cinemaxwell sun Tab (this is for Wish List)

JC

Maxwell Beta 1.2 (not working)
Cinemaxwell 0.5 (so so)
Cinema 4D 9
MacOS 10.3.9
G4 Dual 867

[Kabe]

EDITED ________
Well, comparng the Cinema sun with the Maxwell sun does make sense, when you take care to compensate the Cinema time for both, your current local time and the local time of the scene. So if your computer is set to timezone +2, and would like to render an image taking place in timezone -3, then you have to add 5 hours. Strange, but true. In fact, it turned out that the Maxwell and the Cinema sun have indeed the same south direction.
_______

Also I would strongly suggest not to test any special locations as long as the basic transits and sun rise / sun set is not working for the zero meridian. If the sun simulations work for locations on the zero meridian, the rest is really a piece of cake. Testing different locations around the world - what we all did before - actually doesn't help much to see what is wrong specifically. We all noticed that the shadows were far too long, but we did not notice that there were calculated for the wrong hemisphere

Kabe

[Mihai]

With Cinemaxwell, or I forget what it's called, your south is up?? In Max south is down, so then I guess the Max plugin works ok?

[Kabe]

I think, when it comes to comparing the Maxwell sun with the diverse internal sun systems of the hosts, the first thing to do is to check if the host is calculating correctly.

To get them in sync is really just a matter of a rotation - which is what the plugin has to take care of.

[Kabe]

With Cinemaxwell, or I forget what it's called, your south is up??

Well, I was in error about this due to a specific oddity of the Cinema sun... anyway, a rotation of the whole sun system is just a matter of the plugin and quite trivisl.
As I found out in the meantime, actually you can place the Cinema sun into a null and rotate the whole thing

Kabe

[Thomas An.]

So if your computer is set to timezone +2, and would like to render an image taking place in timezone -3, then you have to add 5 hours

Kabe,

You did very good work figuring this out. It takes patience, methodical thinking, understanding of the underlying theory, and a good eye for mathematical detail. Thank you for your efforts !

EDIT: On a side note: This finding bellow confuses the heck out of me. There is no reason why the computer's time zone should have an effect.

So if your computer is set to timezone +2, and would like to render an image taking place in timezone -3, then you have to add 5 hours

[hdesbois]

So, finally, there wasn't any bug? Anyway, thanks for investigating. Accuracy of sun position is a matter of plugin. There was a bug in the early versions of Lightwave plugin, but now, it seems really ok, both by the sundial method and by comparison with real pictures.
HD

[iandavis]

I'm not sure why NL didn't include a basic control for the sun as well as the overly complex (though 'realistic') system. The basic control should be primary. We can enter the info directly, but it should update based on the user moving a virtual sun around the sky, not the OTHER WAY AROUND.

We shouldn't need to figure out... "gee, I want it lit like this.. hmmm... ok, in 1978, at 4pm in Calgary, Alberta..." No... Thats not right... perhaps Madrid at 4pm in the library with a candlestick... ugg... we just want to dial in 50 degrees from horizon, 250 degrees from north. PERIOD all done... time taken? 5 seconds.

a simple lit ball that you could drag the sun around on would also suffice. I mean, they got it perfect in Bryce and 20 other packages... Personally this sun system in Maxwell is just plain Microsoft. (that is, make it as complex as possible and just throw away the idea of a user interface). In fact, I don't often use physical sky with sun JUST because of the HORRIBLE sun system. It's very close to being totally unusable.

Sure, it's nice to be able to simulate for a client what their building would look like at a certain time of day. But how many clients have EVER asked for their setup to be lit at certain location on the planet. In fact, I challenge ANYONE to look at the renderings in the architectural gallery and guess where and when the sun was. It's nonesense. All you need is... noon, sunset, early morning, afternoon, etc.

All I can say, if something simple and usable doesn't show up in V1 I'll be pretty darn disgruntled.

Ian

PS. the above rant was based on the Lightwave plugin. I can't speak for the others, but from the comments on the forum they don't seem much better.

[Tyrone Marshall]

Kabe is the sun functioning still an issue with 0.7b by your test?

[Kabe]

The date function of the plugin completely ignores the month, , which makes
it rather hard to use. Definitely not ready to justify more test yet.

I don't get why they can't use the date code from Studio... well, let's wait and see.

Kabe

[Tyrone Marshall]

Thanks Kabe for the retest.