PDA

View Full Version : SunSpot



JonW
03-15-2013, 12:37 AM
I only spotted your question today when I was reading this massive thread to find out what card/mobo combo I should be looking at for this awesome plugin. Awesome work Juan. If I have a job in 2 weeks I'll be getting this for sure. So apologies for the derailment & late reply.

This was the sunspot issue prior to LW11. I'm not sure if it was problematic for the north hemisphere as well as the south ( I tested solstice times here in Melbourne) but I suggest you run some simple tests if you're really worried.

Hope that helps quilmequick.



SunSpot modifier - bug

I recently ran a bit of a comparison between shadow studies done in LW vs Sketchup & ran into a bug on the LW side of things.

Animated gifs explain it pretty well.
The texture on the ground plane is the LW SunSpot result (baked in), while the other shadows are from the respective packages.

In my setup (for Melbourne) the shadows for Jan 22 & Dec 22 are in exactly the same position in LW? Where as in Sketchup the Dec 22 shadow is shorter, as it should be since it's the local summer solstice.

Not satisfied, I re-did the test in Unity, using some code published on their Wiki (so I could tweak the variables & test things myself).
This code by the way appears to be almost identical to what Denis P. references on his site for the sunsky plugin, so I assume it's fairly standard / solid.

The Unity anim matches up the Sketchup anim almost identically.

Which at this stage probably means that the LW SunSpot model is most likely buggy in some respect. Maybe just buggy for us Aussies.

I used it recently & double checked with the setting sun, although not an exact test to the mm, it looked ok to me & is easy enough to check. Have you also got the correct year.

JonW
03-15-2013, 12:49 AM
In my setup (for Melbourne) the shadows for Jan 22 & Dec 22 are in exactly the same position in LW? Where as in Sketchup the Dec 22 shadow is shorter, as it should be since it's the local summer solstice.


I tried Jan 22 & Dec 22 for Melbourne & the shadow moves.

JonW
03-15-2013, 08:41 AM
Sun position, I’m sure others know exactly what is going on but my guess is:

The Earth’s tilt is about 23.5 but varies from 22.5 to 24.5 over 41,000 years.

But The Earth is not perfectly round (Equator 40,075 km & North/South 40,008 km) so it actually ranges from 22.04 to 24.45. So my guess for the perfectly round Earth of 23.5 average, it should really be 23.245 for a true Earth (not round).

Depending on which formula is being used there is a difference of 0.255 in the angle of the sun at the Tropic of Cancer & Capricorn.

Which software is using the "real" Earth or a "round" Earth model?

There are a few more things to factor in but that’s getting a bit complicated & unless one is launching satellites it probably doesn’t matter!


SunSpot year range is from 1950 to 2050, I looked at Sydney but used -33.86 (it rounds to 2 decimal places, should be 33.859972222...). Rotation "P" seems to range from 79.45 to 79.47 (I didn't check every year) So I used the average of 79.46. So the difference for the Equator is 23.32, so unless my calcs are wrong I am guessing LW is using a "real" Earth model.

shrox
03-15-2013, 10:32 AM
Sun position, I’m sure others know exactly what is going on but my guess is:

The Earth’s tilt is about 23.5 but varies from 22.5 to 24.5 over 41,000 years.

But The Earth is not perfectly round (Equator 40,075 km & North/South 40,008 km) so it actually ranges from 22.04 to 24.45. So my guess for the perfectly round Earth of 23.5 average, it should really be 23.245 for a true Earth (not round).

Depending on which formula is being used there is a difference of 0.255 in the angle of the sun at the Tropic of Cancer & Capricorn.

Which software is using the "real" Earth or a "round" Earth model?

There are a few more things to factor in but that’s getting a bit complicated & unless one is launching satellites it probably doesn’t matter!


SunSpot year range is from 1950 to 2050, I looked at Sydney but used -33.86 (it rounds to 2 decimal places, should be 33.859972222...). Rotation "P" seems to range from 79.45 to 79.47 (I didn't check every year) So I used the average of 79.46. So the difference for the Equator is 23.32, so unless my calcs are wrong I am guessing LW is using a "real" Earth model.

On top of that, the earth has a slight pear shape, an encircling bulge in the southern Hemisphere and a bulge at the North Pole.

adk
03-15-2013, 01:26 PM
Cheers for starting this thread JonW

Just to clarify ... this has been fixed in LW11.xx

Not everyone will have access to these but this is the initial post ...

http://forums.newtek.com/showthread.php?117352-SunSpot-modifier-bug

And this is the other one where it got looked at & fixed

http://forums.newtek.com/showthread.php?122324-SunSpot-modifier-bug


My test as you know was quite simple ...

"In my setup (for Melbourne) the shadows for Jan 22 & Dec 22 are in exactly the same position in LW? Where as in Sketchup the Dec 22 shadow is shorter, as it should be since it's the local summer solstice."

Do this in any other package, Sketchup, MAX, UNITY (with the code I cobbled together) & you get shorter shadows for December - local summer solstice here in Melbourne. In all versions prior to LW11 you didn't. Again this is for Melbourne only as that's where I was doing the studies. If you're not looking at solstice times you'd not even notice this I imagine but those are the times that are important for the stuff that I was doing. It might be perfectly correct for the North hemisphere, who knows. I did not test it there as I had no time.

PS: I'm not sure what those images are meant to show nor how they test accuracy JonW.

adk
03-15-2013, 01:51 PM
I used your scene to test in LW 10.1 (left dongle at work so it's in discovery mode :( )
This looks at Jan [email protected] & Dec [email protected] in Sydney - shadows are in almost exactly same spot & they simply shouldn't be.

In LW 11 they move from month to month - as they should. I will test LW 11 vs Sketchup / MAX when I get a chance but I assume that the fix is correct.

adk
03-15-2013, 01:54 PM
I tried Jan 22 & Dec 22 for Melbourne & the shadow moves.

That means you're in LW 11.xx :)

JonW
03-15-2013, 03:16 PM
I tried LW10 on the Mac & it's the same as your image above LW_10_JAN_DEC.gif. LW11.5 looks OK.

I'm not happy that LW10 is wrong as I have used it for Shadow Diagrams, I don't want to think of the repercussions!

I haven't compared June as that's what I've needed.

This is not a good situation & needs to be fixed very quickly regardless, & everyone should be notified of this whether your on LW10 or LW11.

Also, LW11 SunSpot needs a confirmation by Newtek that it's correct! Even if LW11 is ok I am still not confident that every aspect is ok. I've got some current work using Shadow Diagrams, I'm going to have to check every one for my one peace of mind!

JonW
03-16-2013, 07:28 AM
Attached is LW 10.1 November 21 to January 10. December 1 to 30 has moved along the path of the sun, but Dec 31 2013 matches up with one day before Dec 1 (it's not Jan 31 as the space is wrong) It's more like December "0" if there was such a date.

JonW
03-16-2013, 02:31 PM
Attached is LW 10.1 November 21 to January 10. December 1 to 30 has moved along the path of the sun, but Dec 31 2013 matches up with one day before Dec 1 (it's not Jan 31 as the space is wrong) It's more like December "0" if there was such a date.

I got my wording wrong "(it's not Jan 31 as the space is wrong)" Dec 31 is in the position of Dec 0 if there was such a date, in relation to the Dec plots, but all of Dec is still in the wrong position as there is a gap from Nov 30.

I hope that is a bit clearer! In other words there is a stuff-up in SunSpot for every day of December.

adk
03-17-2013, 11:20 PM
I've used LW / MAX / Sketchup for a heap of shadow studies so I totally understand where you're coming from Jon. Some of those are for very big buildings (40+ floors) & the results from small errors could be very interesting!
What can you do in any such situation tho when you use software & code to test against the real world ? How can I assume that MAX or Sketchup are correct without actually doing proper calculations & test ?
I would guess that that's what 99.9% of the architects out there would do & very few of them would actually do manual calculations for shadow studies these days.

I've used LW in a multi million dollar lawsuit that went to the supreme court a few moons ago, twice.
We won & they lost as the result of the things I was able to construct & show. Nothing to do with shadows btw.
I did the best I could to check & re check all the calculations & results & it all matched up perfectly.
If the raytrace function used by LW to calculate lengths was somehow shown to be buggy or inaccurate would/should I be worried ?
My simple view on this is - I'll cross that bridge if it ever appears on the horizon. Up until then I'm satisfied that I did the best job I could, with the tools at hand & the time that I was given.

I'm glad I found this bug & that when it was raised as an issue NT (James) fixed it.
How far back NT should go to rectify the problem is their call.

JonW
03-18-2013, 12:52 AM
I've used LW / MAX / Sketchup for a heap of shadow studies so I totally understand where you're coming from Jon. Some of those are for very big buildings (40+ floors) & the results from small errors could be very interesting!
What can you do in any such situation tho when you use software & code to test against the real world ? How can I assume that MAX or Sketchup are correct without actually doing proper calculations & test ?
I would guess that that's what 99.9% of the architects out there would do & very few of them would actually do manual calculations for shadow studies these days.

I've used LW in a multi million dollar lawsuit that went to the supreme court a few moons ago, twice.
We won & they lost as the result of the things I was able to construct & show. Nothing to do with shadows btw.
I did the best I could to check & re check all the calculations & results & it all matched up perfectly.
If the raytrace function used by LW to calculate lengths was somehow shown to be buggy or inaccurate would/should I be worried ?
My simple view on this is - I'll cross that bridge if it ever appears on the horizon. Up until then I'm satisfied that I did the best job I could, with the tools at hand & the time that I was given.

I'm glad I found this bug & that when it was raised as an issue NT (James) fixed it.
How far back NT should go to rectify the problem is their call.

I have made LW shadow diagrams that have gone to the Land an Environment Court. It's not good enough that tools like SunSpot produce mistakes.

Something I'm working on at the moment is a result of shadow diagrams supplied by an architect that are all wrong, no one would have noticed the errors but I was familiar with the site. I think all hell is going to break loose, (image at start of this thread, part of a check I did) The job is full of shadow diagrams, including multiple views with every hour of the day and every month. I did a couple of physical checks to make sure the shadows are ok. But it would take me forever to check enough of a range of sun positions to be totally confident. I'm not that proficient with maths, but with cross checking and my HP calculator I could eventually get there. But I should not have to do this.

This whole situation makes me very nervous, some tools don't really matter if there is a problem, it's just a pain if they don't work. But tools like SunSpot have to be correct. Nothing more nothing less! They also need to explain what formula is used.

In this situation Newtek has to inform users there is an issue & fix all problems urgently!

I would suggest that SunSpot is mostly being used for shadow diagrams.

I would also do some cross checking with other software.

Attached a previous image:

adk
03-18-2013, 05:26 PM
That there was a bug somewhere in the sunspot code prior to LW11 - you have no argument from me.
The extent of how that bug affects folks with earlier versions of LW, it's repercussions, and what NT should and should not do is very much beyond me to comment on.

All I can add is that - as far as I know none of the other packages/renderers ie MAX, Sketchup, Archicad, modo, kray, vray etc explain what formula they use for their sun model. I'm not 100% on that but fairly certain. One can probably ask & they might tell you.My cobbled UNITY code & check (purely from a visual perspective) happened because Denis Pontonnier mentions his references in the SunSky page.

If, in doubt, it's important, you need to be bang on with what you're showing, you cross check, & you can easily cross check LW against Sketchup (whose primary focus is Architecture).

I'm not sure when sunspot appeared on the scene (I've been using LW since version 5) but I have regularly used it for things other than shadow studies/diagrams.
Most of my light rigs for archViz include Denis's SunSky plugin coupled with sunspot.

One could also pose the argument that if sunspot was used extensively & primarily for shadow studies/diagrams that this bug would/should have been spotted way way earlier.

I feel your discomfort Jon, I had some too when I spotted this bug.
To me, the fact that none of the stuff that I did over the years has come back to bite me, probably means that ... I checked it ( I always do), no one else checked it / spotted it (bad on their behalf), it wasn't significant / important enough to raise as a concern, I did it in MAX or Sketchup or something else, or most likely ... it's a combination of all those things.

quilmequick
03-19-2013, 11:44 AM
I'm trying to get our team to tests in 9.6,11.5, Maxwell, Modo and Max to see how they compare. Even if the bug has been fixed, it would be great to know the difference between programs, and for us to know if our previous work could be subject to litigation, (unlikely but not impossible)
But a few questions,

In the test scene the sun distance is set to 1495978.7377 Mm, Surely this is incorrect? *(prob should be km but I have no real idea)

What difference does the distance setting have while dealing with a distant light? (I always presumed that it made no difference, unless you are using a non distance light)

Do other programs take the distance as being an average distance of the sun? Or do they adjust for the orbit throughout the year. (I'm really out of my depth when it comes to celestial synchrony!)

Also slightly off topic, but is there a reason that the SunSpot controls are upside down, I can enter 100s of values into it over a week, and it's always seemed odd that the list starts with seconds and ends in years. To me the list seems inverted, not a major problem but I always wonder why.

Also Would it be possible to auto extract the info from a backplates metadata, a bit like the 'from image' setting in the real lens camera. Cheers

EDIT--- Just realised that Mm is Million meters not Miles, makes sense now. But Still, does it make any difference having it a 1m vs 1495978.7377 Mm

JonW
03-19-2013, 03:55 PM
Agree, SunSpot layout needs tidying up. YMDHMS

Distance for area light, though still not ideal.

Newtek is pushing LW with LWCad, which is a great plugin, its geared towards architectural work. There is a huge market out there who are all welded onto other programs. LW has do to its part to compliment LWCad in Layout & have good tools to entice people.

I bought LW years ago ($4k LW6.5 for Mac), then it sat in a cupboard & I used Max (on a PC). But for a long time now have been using LW, but it is often a pain getting data from architects into LW, & if architectural tools don't work right it just adds to the list of issues.

As each year goes by people are demanding more & more accuracy. It would make life easier if one could just let it roll off the tongue, LW uses XYZ parameters & you can be confident in saying so. I don't think this is asking too much, even more so that LWCad is such a key plugin for Modeler & LW as a whole.

adk
03-19-2013, 04:55 PM
Heya quilmequick,

It's a good idea that someone from the North :) test this as I'm not 100% how far this bug extends. I don't think we need to be Galileo precise about this (crude reference to sunspot(s) :D ) & it can be a simple visual check as per my previous post I guess.
I'm flat out on other stuff atm but will endeavour to test this in whatever package I can & report back (for north & south).

Distance setting will have no effect when using distant lights.

What do you mean by backplate metadata ? If it's a photo you should be able to extract the metadata.

quilmequick
03-20-2013, 03:43 AM
I just mean getting the time of day and date from the backplate, then populating the fields with the info with one click. Instead of manually entering it every time.
Just a button that says 'use time from backdrop image' etc. Would be nice to see it in future updates, as we are on the subject. Its not crucial, but if it is easy to do, it would be a nice feature. Again I'm also quite busy but it on my departments list of things to do.

It would make most sense for my tests to be focused around GMT, but If you use Australia then I think we are going to have a good coverage.

quilmequick
03-20-2013, 03:43 AM
Sorry double post