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.

OK, consistent splat on this one. I can run Shadowprojector on the two at right for 12/21 09:00 and it works, but either of the left ones, which shouldn't have any shade anyway, will splat.

VTest.skp

@tig said:

Since 'shadow-projection' is usually relating to 'massing' studies, have you considered making some simple massing blocks [grouped] on their own layer[s], then switch off those layers belonging to the complex parts of the model you no longer need, and then retry shadow-projection

That's essentially the point my buildings are already at; simplified down to less than a couple hundred faces each. Can't go much farther, since the actual buildings are fairly complex in footprint and roofline, which of course both affect the shadows.
If it helps, what I have is basically an apartment complex of 2-3 story buildings, 86 buildings of about 8-10 floorplans in all, with roughly 150 9' tall carports. The client wants to know, based on our typical shading criteria, (no shade at all between 9AM and 4PM local time any day of the year) which carports are good candidates for solar installation. Complicating matters, though the buildings are clustered, no two clusters are alike, and many are so close together that a carport in one cluster can be shaded by a building in an adjacent cluster.
Obviously, even just selecting 150 unconnected faces isn't practical each time, so my usual solution in a situation like this is to create a single face at the relevant level and find shadows over the whole thing. That doesn't work so well when that face is 55 acres. Even trying to do it a few carports at a time sometimes crashes.
This is the first time doing this on something this large and complex. Usually I can just trace out a few simple shadows by hand, but obviously having a tool to do that simplifies things greatly.
What I've been doing with ShadowProjector on simpler, smaller models is the following:

1. Create a plane where I want the shadows if one doesn't already exist, and make it a component for ease of handling later.
2. Select the whole plane.
3. Run ShadowProjector for 0900 12/22.
4. Explode the component SP makes within my component, and fill the shaded area with whatever my "don't use" material is.
5. Selecting only the remaining parts of the face, rerun SP for 1200 12/22
6. Repeat the explode-and-fill, running projections for 1600 12/22, then 1600 6/22 and 0900 6/22, adding in times as needed to get a reasonably accurate shading pattern.
7. Check morning and evening shadows for 3/22 and 9/22, and run more projections if needed
   This way, the area of interest gets smaller with each run, and I have a fairly accurate picture of the areas that are never shaded during the best daylight hours.

I did at one point, and one relatively small section (2-3 buildings, maybe 1/2 acre) still crashed it every time. Will try to reproduce that and post the file to see if there's something squirrelly going on with the geometry in it.

Still getting fairly consistent crashes on a large and moderately complex (29,500 faces on an area of interest of about 55 acres) model. It seems to get through a few steps, though, as it never crashes until a few minutes in. Is there a log file somewhere that might show what is causing the splat, or at least what stage it's happening at?

Thread necromancy here to point out that getting rid of the terrain layer if you're not using it in a geolocated model can manage a huge reduction in file size.

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.

Been using Edit->Copy View Location and pasting into the geolocation box for a while now, but the last few days, I keep getting "could not understand your address." Did GE change something, SU change something, or what?

GE Pro 7.1.2.2041
SU Pro 16.0.19912 64 bit

@jeff hammond said:

try doing this manually:
[attachment=0:294p5trl]<!-- ia0 -->screen 2012-04-20 at 9.17.04 PM.jpg<!-- ia0 -->[/attachment:294p5trl]

a random line floating in space (not on any particular axis).. then draw a circle perpendicular to it..

with the rotate tool, you can quickly orient the tool to this way.. with the circle, you can't..

This is exactly the situation I use the perpendicular face tool for daily; when I need a circle (or more often a cylinder) to pass through a plane centered on an exact spot, but not perpendicular to the plane itself. Draw a line where I need the cylinder's access, then create a circle perpendicular to the line and push/pull it through.

@gaieus said:

I know the feeling however there are "constrained line" (magenta) then "on face" (blue) and all those other inferencing - which one tu turn off then?

All the wrong ones, obviously. SU could figure that out using the same logic it uses to always pick the wrong corner to snap to.

@gaieus said:

you can imagine that this has been suggested even in better places - to no avail for the time being.

Isn't it amazing how responsive the SU team is to customer concerns? I expect we'll have this by roughly the time SU has a direct brain interface driver.