Closed hzxie closed 2 years ago
It seems that PierCheck
does nothing.
Pier -->
case heightOverTerrain > 0:
split(v,unitSpace,0){ '0.15: NIL
| '0.70: PierStep2
| '0.15: NIL }
else: NIL
PierStep2 -->
alignScopeToGeometry(yUp,0,0)
# Make "feeler" for occlusion check in next rule.
# Extrude down to the terrain (must be mapped in layer attribute).
extrude(world.y,-heightOverTerrain)
# Align to yUp for feeler scaling.
alignScopeToAxes(y)
# Scale to go past regular pier shape.
s('1,'20,'1)
t(0,-0.5,0)
# Check if pier will hit something.
PierCheck
PierCheck-->
PierShow
PierShow -->
# Scale back occlusion feelers, reversing the feeler code.
s('1,'0.05,'1)
t(0,0.5,0)
split(y){2.2: PierBase | ~1: PierShafts | 1: BridgeSolid }
This feature was requested for removal by ESRI a while ago. The shadow models used to check this condition were generated regardless of whether the appropriate grammar tree was activated. This degraded performance of the rule for typical user cases. This might have been requested before the rules move GitHub, but you can check older releases for what the code might have been. @Richcng - @pascalmueller - this is still the case correct for occlusion queries?
Yes. I found the code here.
However, the overlaps(inter)
function does not always return the correct value. For example:
A key piece of information on occlusion queries in the ESRI CGA help is that they require volumes, not faces. You have to generate an invisible volume with opacity, or a volume that gets resetGeometry, whichever, with labels for the occlusion test, to run the bridge occlusion query.
It is not clear if there are gaps in the complete street rule generated geometry. They should be volumes as I understand it (I think they are based on extrusions). Is there some edit required to make it a volume?
If anyone knows where a hole is generated that is breaking occlusion checks, I will take a PR.
Personally, I don't think you should add occlusion to the "master" complete street code. Streets generate massive amounts of polygons as it is. Occlusion has a big performance cost.
But if you wanted to, you need to extrude the streets, sidewalks and assets up/down to some imaginary height (or exact height with assets) where the occlusion is tested. The bridge column has volume, that's not the problem.
Occlusion is very tricky even when you think you understand it. I often set up color changing cubes to test for occlusion results before building it into code.
As a workaround, I often just adjust the pier spacing, or create a node right over where the overlap happens, and use the code adjustments available.
@BrianWamsley - your comment jogged my memory. @hzxie - the rule no longer has this functionality as a result of a direct request from Esri. I suggest checking out earlier releases of the rule to see that functionality's sample code (2018 perhaps?). Fundamentally, the performance hit lead to Esri requesting these queries be removed from the rule entirely. Just having the occlusion code at compile time makes shadow models used for the query. I even asked if a conditional statement could hide this need, and the answer was no. This is from an old conversation, so have some mercy on the details.
@d-wasserman Thank you very much for your reply.
As shown in the figure below, the generated bridge piers intersect with the streets below. How to solve the problem?