What I'm looking for 99.9% of the time is a lot simpler; just what part of a face is shaded at any time between 0900 and 1600.

Effectively, what the result would be if one used TIG's Shadowprojector for every minute of that time, (realistically, every half hour or even hour is plenty to connect the corners later) then combined all the results into a single shadow. Ideally, this would then be expanded to include the entire year, but I tend to find that doing the whole thing for the solstices, then a quick check of morning and evening on the equinoxes gives a pretty solid result, so I'm not averse to doing that.

One benefit of the all-or-nothing approach is that once a point has been determined to be shaded, it no longer needs to be checked for any remaining times in the test period.

Is there a way to pare things down in the settings of Chronolux to do this fairly quickly? Sometimes the areas can get rather large, so any savings is useful.

Any word on an update for SU2017? This was probably the extension that I most often forgot wasn't just an integral part of SketchUp, and I'm missing the functionality a lot.

Another thought on this one; not sure how hard it would be to calculate without saving, but a before and after file size, or percent reduction of the file size in the info box would be a handy bit of bragging if a user is wondering how much this saved them.

@slbaumgartner said:

This is one of the known problems SketchUp has with very high dpi displays:

If 1920x1080 is "very high dpi" then their first problem is that they haven't moved into the current decade yet.

@thomthom said:

That's strange... and troublesome. It means the issue stems from compound cleanup actions. hmm...

Possibly the order of the operations? Sounds like removing duplicate faces simplified it enough that whatever was crashing could handle what was left after that specific operation.

One thing I'm noticing is that, for example, the bicycles are 24 separate but apparently identical ~600kb groups. That adds a lot of complexity compared to having a couple dozen instances of a single component. Same thing with several doors, etc. How hard would it be to recognize identical groups/components/items, and replace all of the duplicates with instances of one? (Maybe with some minimum complexity and/or count so it's not making components of every triangle or rectangle that happens to have a single mate somewhere.)

@jessbarros said:

Hi guys! I can't download part 18 in any of the servers... can someone upload it again for me?

No luck; rapidshare is dead, and the 4shared links keep wanting me to "update" my "flash player" which is pretty much universal code for "download and install some malware."

Starting to think nobody understands that torrenting works for legal stuff too.

This is probably my most used extension, but there's one option I'd love to see added; removing the terrain layer.
I use the location snapshot on probably 95% of my models for placing ground mounts or having an easy reference to real world objects, but only about 1% of my models actually use the terrain. (For the most part, that's left to the installers to deal with on site.) That can end up being a huge amount of extra data. Currently, I end up having to turn snapshot off, turn terrain on, unlock and delete each imagery section, then delete the layer and turn snapshot back on. Having it happen automatically in an extension I run on every model anyway would save some time and eliminate those times when I just plain forget to do it and leave 2-3 extra MB of unused data in a model of, for example, an apartment complex or shopping center. Foregoing "clean with last settings" and unchecking the option on the rare occasion I actually want the terrain would be a small price to pay.

Can't get it to happen consistently, but this one is something of an annoyance.

Usually happens placing solar modules on a roof surface. I make each roof face a separate component with its own axes so the modules come in with the right orientation already. Usually the first time, when I import the module model, it will come up right, with the module's origin on the roof face so the module is sitting directly on top of the roof.

The problem comes about randomly when I go to other roof faces. Maybe 15-20% of the time, I click on the module component in the components list, then go to place it and it acts as if the origin is on the top corner instead of the bottom; i.e. it tries to place it inset into the roof with the face flush with the plane of the roof face. Then I have to place it, pull it out above the roof, grab a bottom corner and put it back onto the roof face.

Am I missing something here, or is SU just sometimes inconsistent in how it handles placing components on a plane?

We rarely use the imported terrain, just the snapshot layer to get the relative positions of buildings, solar arrays and such. That's a lot of junk in the file that we can do without, especially on large projects. Is there an easy way to purge all the terrain data, other than manually deleting each tile of it?

@tig said:

I've worked out the issue.
It IS to do with empty groups - there's an intersection needed but if there is nothing to intersect it was splatting...
With a % text it's NOT empty so no issues !
Now I have it trapped and so far in retesting there's not splatting.

That makes perfect sense now; even on the full model, it didn't splat on the first run, but after I'd exploded the shadow lines and marked the shaded areas, the remaining area was split into multiple faces, and apparently some of those were empty.

5.0 is working perfectly on a couple of the smaller sections. I'm tempted to test it on the full model when I have some free time.

@tig said:

But if a face is not receiving any shadows why include it in the process ?

Normally I wouldn't in a model this simple, but in something more complex, I tend to just select all the faces of interest on each run. Those faces would be shaded for the 16:00 run, so in a complex model I wouldn't be picking each one individually. I was only checking them one at a time this time because I wanted to narrow the problem down as much as possible to see if there was something goofy with my model first.