What kind of date ranges are available for the time/date search function? Could we, say, search for June 15, 1215 at the town of Runnymede (or nearest large city), or a date from antiquity at Rome or Jerusalem? Or is it more focused on this century (Y2K and onwards)? it's a really cool idea either way, I was just curious.
I am doing a city and so I type London and choose London (Kentucky, USA). The time & data are looked at 02/Apr/2017 15:00 (however the real time where I am actually at is 22:31 02/Apr/2017) & my Sky turbidity is 5% but when I go to check my iRay Sun & Sky
SS Latiture: 0.00
SS Longitude: 0.00
Dome Rotation: 315 deg (I had already set that to that)
SS Day: 1/1/2000
SS Time: 00:00:00
SS UTC Offset (hrs): 0.00
SS Sun Disk Intensity: 1.00
SS Sun Disk Scale: nan
SS Sun Glow Intensity: nan
SS Physically Scaled Sun: On
SS Haze: 0.00
SS Blue-Red Tine -1.00
SS Horizon Height: 0.00
SS Horizon Blur: 0.10
So it looks like to me that iRay GeoLocation set those as some sort of init case on startup but is not making any changed when I select London, USA.
Second, it would be nice to type London, UK or London, England, London, England, United Kingon, London, USA, London, Kentucky, London, Kentucky, USA, London, Ontario and so on and the program would narrow down the list of cities to the correct subset but that's not that big a deal since the list of places is small.
I post it here for anyone else that has this problem but can sent you in an email too.
I picked this up right away as well. Will there be an issue if its loaded to a different drive by DIM? I haven't actually had a chance to try it, I am in the middle of rendering something and I doubt it will be done by bedtime.
I am doing a city and so I type London and choose London (Kentucky, USA). The time & data are looked at 02/Apr/2017 15:00 (however the real time where I am actually at is 22:31 02/Apr/2017) & my Sky turbidity is 5% but when I go to check my iRay Sun & Sky
SS Latiture: 0.00
SS Longitude: 0.00
Dome Rotation: 315 deg (I had already set that to that)
SS Day: 1/1/2000
SS Time: 00:00:00
SS UTC Offset (hrs): 0.00
SS Sun Disk Intensity: 1.00
SS Sun Disk Scale: nan
SS Sun Glow Intensity: nan
SS Physically Scaled Sun: On
SS Haze: 0.00
SS Blue-Red Tine -1.00
SS Horizon Height: 0.00
SS Horizon Blur: 0.10
So it looks like to me that iRay GeoLocation set those as some sort of init case on startup but is not making any changed when I select London, USA.
Second, it would be nice to type London, UK or London, England, London, England, United Kingon, London, USA, London, Kentucky, London, Kentucky, USA, London, Ontario and so on and the program would narrow down the list of cities to the correct subset but that's not that big a deal since the list of places is small.
I post it here for anyone else that has this problem but can sent you in an email too.
I have the same settings except of course the Dome rotation.
I checked and all the files are were they should be in the plugins folder.
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
What kind of date ranges are available for the time/date search function? Could we, say, search for June 15, 1215 at the town of Runnymede (or nearest large city), or a date from antiquity at Rome or Jerusalem? Or is it more focused on this century (Y2K and onwards)? it's a really cool idea either way, I was just curious.
The allowed date starts from 01/Jan/1753 (don't ask me why, it's what the SDK allows); future dates seem to be unlimited :D
The cities database is quite large but historical places or small towns aren't there.
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
In any case, the expected behavior is this one:
I'll be happy to test it, if you want me to :)
Excellent, please send me your email at info@alessandromastronardi.com
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
I'll be happy to test it, if you want me to :)
Excellent, please send me your email at info@alessandromastronardi.com
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
In any case, the expected behavior is this one:
I will. I will send you an email at your info address.
Also, in some cases, such as mine, DAZ Studio has somehow gotten installed with incorrect permissions for some parts of it running in Windows 10 64 bit. The solution it to remove & clean up your DAZ Studio install completely (except the libraries) or run DAZ Studio as administrator. I am running DAZ Studio as Administrator until I get time to make a clean install of DAZ Studio.
I ran DS as administrator and your GeoLocator performs perfectly! Thank you so much for your hard work and valuable time. As a PA you are tops in my book!
P.S. I picked up all three parts of your Squirrel yesterday. I have been following you on Artstation.
What kind of date ranges are available for the time/date search function? Could we, say, search for June 15, 1215 at the town of Runnymede (or nearest large city), or a date from antiquity at Rome or Jerusalem? Or is it more focused on this century (Y2K and onwards)? it's a really cool idea either way, I was just curious.
The allowed date starts from 01/Jan/1753 (don't ask me why, it's what the SDK allows); future dates seem to be unlimited :D
The cities database is quite large but historical places or small towns aren't there.
I ran DS as administrator and your GeoLocator performs perfectly! Thank you so much for your hard work and valuable time. As a PA you are tops in my book!
P.S. I picked up all three parts of your Squirrel yesterday. I have been following you on Artstation.
Thanks again my friend!
John
If you mean that literally, don't as it risks causing serious issues. Running from an administrator account is fine, but you should not use the "Run as Admimistrator" (or Mac equivalent) for DS or DIM.
I ran DS as administrator and your GeoLocator performs perfectly! Thank you so much for your hard work and valuable time. As a PA you are tops in my book!
P.S. I picked up all three parts of your Squirrel yesterday. I have been following you on Artstation.
Thanks again my friend!
John
If you mean that literally, don't as it risks causing serious issues. Running from an administrator account is fine, but you should not use the "Run as Admimistrator" (or Mac equivalent) for DS or DIM.
Why not, Richard? I AM the Administrator of my laptop, no other users involved. I am concerned about what serious issues you are referring to. I can't find anything about it online.
I ran DS as administrator and your GeoLocator performs perfectly! Thank you so much for your hard work and valuable time. As a PA you are tops in my book!
P.S. I picked up all three parts of your Squirrel yesterday. I have been following you on Artstation.
Thanks again my friend!
John
If you mean that literally, don't as it risks causing serious issues. Running from an administrator account is fine, but you should not use the "Run as Admimistrator" (or Mac equivalent) for DS or DIM.
Why not, Richard? I AM the Administrator of my laptop, no other users involved. I am concerned about what serious issues you are referring to. I can't find anything about it online.
Thanks.
John
Are we talking about right-click and Run as Adminsitrator (bad, can lead to folder permission issues) or running from an administrator account as normal (fine)?
My home town is on the list, but the sky it's showing for me is a good deal darker than the one outside my window. I wonder if the time used ignores daylight saving time? It's 19:50BST here in the middle of the UK, and not nearly as dark as Daz thinks it is, but if I ignore daylight saving and call it 18:50 GMT I get something nearer the mark.
I note also that the timezones aren't all that accurate. If you uncheck the "lock timezone" box and click east or west of London, you get an hour's time difference between them. If you click the UK, and then move your mouse south and click France, you get the same time. In reality, that's backwards. The whole of western Europe, with the exception of Portugal, are 1 hour ahead of the UK, even though parts of it a well to the West of the Greenwich meridian. I guess you've taken a simplistic model of how timezones work, just jumping an hour for every 15 degrees of longitude. Life's not like that:
I realise this is way too fiddly to implement in your plugin, but maybe, if you ever make an updated version, you could consider having the option to specify the date/time in UTC, which would be unambiguous.
Don't let the above detract from my opinion of the product - which is really excellent!
What kind of date ranges are available for the time/date search function? Could we, say, search for June 15, 1215 at the town of Runnymede (or nearest large city), or a date from antiquity at Rome or Jerusalem? Or is it more focused on this century (Y2K and onwards)? it's a really cool idea either way, I was just curious.
The allowed date starts from 01/Jan/1753 (don't ask me why, it's what the SDK allows); future dates seem to be unlimited :D
The cities database is quite large but historical places or small towns aren't there.
The reason why it only goes back to 1753 is that the Gregorian calendar was adopted in Britain and her (then) American colonies in 1752. So if you pick a date earlier than that (and you're in the anglocentric world of IT), it would be ambiguous whether you meant old style Julian or new style Gregorian dates. Getting a calendar for September 1752 can yield interesting results!
According to this converter, 15 June 1215 in the Julian calendar would be 22 June 1215 in the Gregorian. I don't think the year is all that important to the light levels (that's the point of the Gregorian calendar reform - to make the calendar consistent with the position of the sun), provided you pick a year that's at the same place in the four-year cycle of leap years. So the light settings for 22 June 2015, with a location just west of London, would be the same as those for the signing of Magna Carta (for extra bonus points, 2015 occupies the same point in the full 400-year cycle of the Gregorian calendar that 1215 does).
OK, I changed the security on the GeoLocator folder so that Daz Studio has full control to read/write/change the files in it. Now a simple double-click on the shortcut works a treat.
My home town is on the list, but the sky it's showing for me is a good deal darker than the one outside my window. I wonder if the time used ignores daylight saving time? It's 19:50BST here in the middle of the UK, and not nearly as dark as Daz thinks it is, but if I ignore daylight saving and call it 18:50 GMT I get something nearer the mark.
I note also that the timezones aren't all that accurate. If you uncheck the "lock timezone" box and click east or west of London, you get an hour's time difference between them. If you click the UK, and then move your mouse south and click France, you get the same time. In reality, that's backwards. The whole of western Europe, with the exception of Portugal, are 1 hour ahead of the UK, even though parts of it a well to the West of the Greenwich meridian. I guess you've taken a simplistic model of how timezones work, just jumping an hour for every 15 degrees of longitude. Life's not like that:
I realise this is way too fiddly to implement in your plugin, but maybe, if you ever make an updated version, you could consider having the option to specify the date/time in UTC, which would be unambiguous.
Don't let the above detract from my opinion of the product - which is really excellent!
Hello Chris thanks for the comments. Yes indeed you are correct on the time zone computation, which is done using a simplistic approach and is not accurate as it is in real life; daylight saving is also not modelled. As I was given to understand, with Qt5 (whenever will be supported by DAZ Studio), the SDK will offer enough geolocation tools to allow for more precise calculations and more features that I couldn't include in this first release. Cheers.
My home town is on the list, but the sky it's showing for me is a good deal darker than the one outside my window. I wonder if the time used ignores daylight saving time? It's 19:50BST here in the middle of the UK, and not nearly as dark as Daz thinks it is, but if I ignore daylight saving and call it 18:50 GMT I get something nearer the mark.
I note also that the timezones aren't all that accurate. If you uncheck the "lock timezone" box and click east or west of London, you get an hour's time difference between them. If you click the UK, and then move your mouse south and click France, you get the same time. In reality, that's backwards. The whole of western Europe, with the exception of Portugal, are 1 hour ahead of the UK, even though parts of it a well to the West of the Greenwich meridian. I guess you've taken a simplistic model of how timezones work, just jumping an hour for every 15 degrees of longitude. Life's not like that:
I realise this is way too fiddly to implement in your plugin, but maybe, if you ever make an updated version, you could consider having the option to specify the date/time in UTC, which would be unambiguous.
Don't let the above detract from my opinion of the product - which is really excellent!
Not to nitpick, and I do note your caveat, but isn't that how the real world works, as opposed to arbitrary political constraints? When the sun is in the sky at the same longitude point in England as in France its really the same time, not an hour difference for the convienence of continental dwellers. Sure, its an arbitrary decision to base it out of Greenwich, England, but there has to be some basic reference point. I don't know if there would be a great benefit for the huge amount of work it would be to trace every spot of Time Zone change. I would think it would it would be much easier for an end user to just calculate if the time is off by an hour if you are trying to recreate a historic scene.
Not trying to be a jerk, just wondering if its worth the effort for the artists to create such a thing. I note this product is inexpensive as compaired to similar products otherwise.
I wonder if this product works at the polar extremes? If I wanted a sky set near the north pole would it give me an accurate reading? Or is this too much for the program - it IS an extreme setting after all.
I wonder if this product works at the polar extremes? If I wanted a sky set near the north pole would it give me an accurate reading? Or is this too much for the program - it IS an extreme setting after all.
Hi Joe, that should work fairly well. For example setting coordinates to north pole (Lat.90°, Long.0°), 21 December will give you pitch black; setting date through entire summer will show the sun almost always at full sunlight. These calculations are inherited from the Iray engine itself.
I wonder if this product works at the polar extremes? If I wanted a sky set near the north pole would it give me an accurate reading? Or is this too much for the program - it IS an extreme setting after all.
Hi Joe, that should work fairly well. For example setting coordinates to north pole (Lat.90°, Long.0°), 21 December will give you pitch black; setting date through entire summer will show the sun almost always at full sunlight. These calculations are inherited from the Iray engine itself.
Seems I am getting the "black box" on my MAC. When I adjust the time, there is no corresponding update in the environmental settings. The "five" files mentioned earlier are in the correct place.
Seems I am getting the "black box" on my MAC. When I adjust the time, there is no corresponding update in the environmental settings. The "five" files mentioned earlier are in the correct place.
and unzip it (overwriting) in your /Applications/DAZ 3D/DAZ Studio4/plugins
This is the 1.1 version that I also sent DAZ and should be made into new installers. Feel free to email me at info@alessandromastronardi.com for support. Cheers
Works like a charm on my desktop after it got fixed . Thank you for making a fix so fast :)
I just downloaded and installed it on my laptop and it worked without me having to fix it. I have Daz Studio installed the same way on my laptop as on my Desktop. Maybe Daz already replaced the installer in DIM .
Comments
What kind of date ranges are available for the time/date search function? Could we, say, search for June 15, 1215 at the town of Runnymede (or nearest large city), or a date from antiquity at Rome or Jerusalem? Or is it more focused on this century (Y2K and onwards)? it's a really cool idea either way, I was just curious.
I am doing a city and so I type London and choose London (Kentucky, USA). The time & data are looked at 02/Apr/2017 15:00 (however the real time where I am actually at is 22:31 02/Apr/2017) & my Sky turbidity is 5% but when I go to check my iRay Sun & Sky
SS Latiture: 0.00
SS Longitude: 0.00
Dome Rotation: 315 deg (I had already set that to that)
SS Day: 1/1/2000
SS Time: 00:00:00
SS UTC Offset (hrs): 0.00
SS Sun Disk Intensity: 1.00
SS Sun Disk Scale: nan
SS Sun Glow Intensity: nan
SS Physically Scaled Sun: On
SS Haze: 0.00
SS Blue-Red Tine -1.00
SS Horizon Height: 0.00
SS Horizon Blur: 0.10
So it looks like to me that iRay GeoLocation set those as some sort of init case on startup but is not making any changed when I select London, USA.
Second, it would be nice to type London, UK or London, England, London, England, United Kingon, London, USA, London, Kentucky, London, Kentucky, USA, London, Ontario and so on and the program would narrow down the list of cities to the correct subset but that's not that big a deal since the list of places is small.
I post it here for anyone else that has this problem but can sent you in an email too.
I picked this up right away as well. Will there be an issue if its loaded to a different drive by DIM? I haven't actually had a chance to try it, I am in the middle of rendering something and I doubt it will be done by bedtime.
Well I have my DAZ Library on an external USB HDD but I don't think that that is the cause of the problem I'm having.
I have the same settings except of course the Dome rotation.
I checked and all the files are were they should be in the plugins folder.
I think for some there is an issue running the integrated .dse file that is responsible for setting all the parameters. I'm going to prepare an updated one, anybody volunteering to test it? :D
In any case, the expected behavior is this one:
The allowed date starts from 01/Jan/1753 (don't ask me why, it's what the SDK allows); future dates seem to be unlimited :D
The cities database is quite large but historical places or small towns aren't there.
Thank you, Alessandro!
I'll be happy to test it, if you want me to :)
Excellent, please send me your email at info@alessandromastronardi.com
Thanks :)
Done :D
I will. I will send you an email at your info address.
So it turned out that on some Windows systems that use customized documents/program paths related to DAZ, it may happen to get a black screen because one of the files couldn't be accessed.
Here is the proposed fix, there are two files in the zip: http://www.alessandromastronardi.com/downloads/IrayGeoLocator/IrayGeoLocatorFix1.zip
You have to replace:
- geoLocator.dll in ../Program Files/DAZ 3D/DAZ Studio4/plugins/
- setGeoLocation.dse in ../Program Files/DAZ 3D/DAZ Studio4/plugins/geolocatorAM/
If the guys that experimented issues can try this and report at info@alessandromastronardi.com, I'd really appreciate it. Sorry about this trouble.
Also, in some cases, such as mine, DAZ Studio has somehow gotten installed with incorrect permissions for some parts of it running in Windows 10 64 bit. The solution it to remove & clean up your DAZ Studio install completely (except the libraries) or run DAZ Studio as administrator. I am running DAZ Studio as Administrator until I get time to make a clean install of DAZ Studio.
AM:
I ran DS as administrator and your GeoLocator performs perfectly! Thank you so much for your hard work and valuable time. As a PA you are tops in my book!
P.S. I picked up all three parts of your Squirrel yesterday. I have been following you on Artstation.
Thanks again my friend!
John
As far as I am aware the date/time functions are as described at http://doc.qt.io/qt-4.8/qdatetime.html
If you mean that literally, don't as it risks causing serious issues. Running from an administrator account is fine, but you should not use the "Run as Admimistrator" (or Mac equivalent) for DS or DIM.
Why not, Richard? I AM the Administrator of my laptop, no other users involved. I am concerned about what serious issues you are referring to. I can't find anything about it online.
Thanks.
John
Are we talking about right-click and Run as Adminsitrator (bad, can lead to folder permission issues) or running from an administrator account as normal (fine)?
Playing with it now. Installed without problems, and it's a pleasant change to buy something from Daz that has some clear documentation on how to use it (here: http://docs.daz3d.com/lib/exe/fetch.php/public/read_me/index/36921/36921_iray-geolocator-readme.pdf if anyone's looking for it).
My home town is on the list, but the sky it's showing for me is a good deal darker than the one outside my window. I wonder if the time used ignores daylight saving time? It's 19:50BST here in the middle of the UK, and not nearly as dark as Daz thinks it is, but if I ignore daylight saving and call it 18:50 GMT I get something nearer the mark.
I note also that the timezones aren't all that accurate. If you uncheck the "lock timezone" box and click east or west of London, you get an hour's time difference between them. If you click the UK, and then move your mouse south and click France, you get the same time. In reality, that's backwards. The whole of western Europe, with the exception of Portugal, are 1 hour ahead of the UK, even though parts of it a well to the West of the Greenwich meridian. I guess you've taken a simplistic model of how timezones work, just jumping an hour for every 15 degrees of longitude. Life's not like that:
I realise this is way too fiddly to implement in your plugin, but maybe, if you ever make an updated version, you could consider having the option to specify the date/time in UTC, which would be unambiguous.
Don't let the above detract from my opinion of the product - which is really excellent!
Got you Richard. My brother who lives with me understands this better than I (retired engineer). He'll help me. Thanks.
The reason why it only goes back to 1753 is that the Gregorian calendar was adopted in Britain and her (then) American colonies in 1752. So if you pick a date earlier than that (and you're in the anglocentric world of IT), it would be ambiguous whether you meant old style Julian or new style Gregorian dates. Getting a calendar for September 1752 can yield interesting results!
According to this converter, 15 June 1215 in the Julian calendar would be 22 June 1215 in the Gregorian. I don't think the year is all that important to the light levels (that's the point of the Gregorian calendar reform - to make the calendar consistent with the position of the sun), provided you pick a year that's at the same place in the four-year cycle of leap years. So the light settings for 22 June 2015, with a location just west of London, would be the same as those for the signing of Magna Carta (for extra bonus points, 2015 occupies the same point in the full 400-year cycle of the Gregorian calendar that 1215 does).
We now return you to your normal programming...
OK, I changed the security on the GeoLocator folder so that Daz Studio has full control to read/write/change the files in it. Now a simple double-click on the shortcut works a treat.
Hello Chris thanks for the comments. Yes indeed you are correct on the time zone computation, which is done using a simplistic approach and is not accurate as it is in real life; daylight saving is also not modelled. As I was given to understand, with Qt5 (whenever will be supported by DAZ Studio), the SDK will offer enough geolocation tools to allow for more precise calculations and more features that I couldn't include in this first release. Cheers.
Not to nitpick, and I do note your caveat, but isn't that how the real world works, as opposed to arbitrary political constraints? When the sun is in the sky at the same longitude point in England as in France its really the same time, not an hour difference for the convienence of continental dwellers. Sure, its an arbitrary decision to base it out of Greenwich, England, but there has to be some basic reference point. I don't know if there would be a great benefit for the huge amount of work it would be to trace every spot of Time Zone change. I would think it would it would be much easier for an end user to just calculate if the time is off by an hour if you are trying to recreate a historic scene.
Not trying to be a jerk, just wondering if its worth the effort for the artists to create such a thing. I note this product is inexpensive as compaired to similar products otherwise.
I wonder if this product works at the polar extremes? If I wanted a sky set near the north pole would it give me an accurate reading? Or is this too much for the program - it IS an extreme setting after all.
Hi Joe, that should work fairly well. For example setting coordinates to north pole (Lat.90°, Long.0°), 21 December will give you pitch black; setting date through entire summer will show the sun almost always at full sunlight. These calculations are inherited from the Iray engine itself.
Thanks. I'll be testing that out soon enough
Good Day,
Seems I am getting the "black box" on my MAC. When I adjust the time, there is no corresponding update in the environmental settings. The "five" files mentioned earlier are in the correct place.
Any suggestions?
@whfield: hello,
please download this zip file: http://www.alessandromastronardi.com/downloads/IrayGeoLocator/IrayGeoLocator.macOS.1.1.zip
and unzip it (overwriting) in your /Applications/DAZ 3D/DAZ Studio4/plugins
This is the 1.1 version that I also sent DAZ and should be made into new installers. Feel free to email me at info@alessandromastronardi.com for support. Cheers
Works like a charm on my desktop after it got fixed . Thank you for making a fix so fast :)
I just downloaded and installed it on my laptop and it worked without me having to fix it. I have Daz Studio installed the same way on my laptop as on my Desktop. Maybe Daz already replaced the installer in DIM .
Anyway Great product!