On dev, Levels by Envelope seems to be creating lot of levels with close spacing. In the image below you can see levels that are slightly offset from other levels.

Structural members currently only span in the shortest direction of the cell. You should be able to override them to align to a grid direction, the longest direction of the cell, or a specific edge of the cell.

• Is staged.
• Is live.

• Is staged.
• Is live.

Disconnected structures cause SkyCiv analysis to run forever, causing a timeout on Hypar. Because we're setting down beam center lines to sit below floors, we're causing the lowest level beams, if they are created to be set below the bottoms of the columns, causing a disconnected structure.

• Is staged.
• Is live.

• Is staged.
• Is live.

If you draw a roof outline with Roof By Sketch and do not define any interior points with elevations, Hypar throws a null reference exception. Defining even 1 point causes this error to go away.

Can't make the BuildingBlocks repo public with a valid MapBox key in the repo history.

Just stumbled across this, I think length (height) and area would have different conversion factors. It appears METRIC_FACTOR is the area conversation between m^2 and ft^2, so you'd want Line 88 to be something like:

roomEntry.height = Math.Round(roomEntry.height *= Math.Sqrt(METRIC_FACTOR), 3);

You can display member sizes in the Structure function currently by labeling by Name, but the tags are all aligned the same way. The LabelConfiguration has been extended with a property Direction that is set to the world-space direction of the member. We should update Hypar to show the labels oriented according to the direction property.

In the image below you can see seams between the tiles. The same effect was observed when creating a tile-set in the client and was fixed by averaging the vertex locations at the seams. The same needs to be done for the topos generated by the Location service.

Hi,

I am trying to use mixed-mode ai example (https://lnkd.in/e28GVqvt). The structure block is not working. I am getting this error: No LevelVolumes found in your Levels model. Please use a level function that generates LevelVolumes, such as Simple Levels by Envelope

I have levels block but structure block is not recognizing or accepting it. I just stuck here. Could you please help me?

• The “basement height” for Envelope By Sketch should be 0 by default.
• The “Building Height” property should be called “Height” and shouldn’t reference a building in its description.
• The “Height” property should have a minimum of 0, or something really small.

• Is staged.
• Is live.

The tributary area should be automatically calculated for a beam based on its subdivision of a cell. Tributary areas could be visualized using panels, and used by SkyCiv for loading.

The picked Location in the location input is located southwest of the origin eventually placed on the topography. In the image below, the picked location in the location input is at the outer corner of the bend in the road. In the generated topography the origin is to the northeast. This is true for all northern hemisphere locations that I've tested.

In the image below, the same behavior occurs for the southern hemisphere. This suggests that it's not a skew based on something like the radius of the earth (one of the variables in the mercator calculations).

Reported by @cdriesler

Object reference not set to an instance of an object.: NullReferenceException
   at EnvelopeBySketch.EnvelopeBySketch.Execute(Dictionary`2 inputModels, EnvelopeBySketchInputs input) in /Users/ikeough/Documents/Hypar/BuildingBlocks/Envelope/EnvelopeBySketch/src/EnvelopeBySketch.cs:line 37
   at Hypar.Functions.Execution.InvocationWrapper`2.InvokeAsync(TInput input)
   at EnvelopeBySketch.Function.Handler(EnvelopeBySketchInputs args, ILambdaContext context) in /Users/ikeough/Documents/Hypar/BuildingBlocks/Envelope/EnvelopeBySketch/src/Function.g.cs:line 45
   at lambda_method(Closure , Stream , Stream , LambdaContextInternal )

Two recent changes to "Envelope By Level" should be discussed as they paint a picture of how Hypar will break in the future when function authors change the interface of their function.

1. The Envelope schema has a Profile property which has recently started returning null. This breaks all functions which currently use that profile (ex: Facade).
2. The "Envelope By Sketch" function now generates elements of type Elements.LevelPerimeter. Functions which consume "Levels" don't know anything about this type so they ignore it during deserialization.

Neither of these changes were obvious to consumers of "Levels". The code generator correctly generated updated class files for the updated schemas, and the compiler identified locations where API calls needed to be adjusted. In the first case, nothing in the tooling can identify when a function author decides to stop using a property. This may be an oversight, or an attempt at deprecation, but the consuming function needs to know. In the second case, a new type was introduced into the system but we do not currently track type dependencies so the "Facade" function could not know that the "Envelope by Sketch" function had begun generating a type that it did not understand.

The easiest short term solution is to update the documentation to the "Envelope By Sketch" function to say something like: "This function generates Envelope and LevelPerimeter objects. To get the perimeter of an envelope, use the LevelPerimeter object at the corresponding level." For properties which are deprecated, the property should not be removed and a deprecation message should be included in the property's description.

@anthonyhauck @mattc

Reproducible case:
https://hypar.io/workflows/cdca9811-fa1e-4a67-9012-c4529f67f81b

https://hypar.io/workflows/51d48337-4be0-4143-8b04-ad1d1d6cf2b1

Rename to structureProblem.json and place in /BuildingBlocks/TestOutput/ to run StructureTest and reproduce these results locally:
structureProblem.txt

Mapbox allows 3D context buildings to be downloaded via their API.

In the following image the origin, inidicated by the crosshair, is in the lower right of the tile set. The logic for choosing the surrounding tiles should have it closer to the center. As the tiles to the right and below should be picked.

In the image below, you can see the origin in the southwest corner of the map tile. In this configuration, the tiles to the south, southwest, and west of the origin should be loaded. Instead we're getting the tiles to the south, southeast, and east.

https://hypar.io/workflows/8bfcf7c4-756a-446f-9f64-a0c66442054c

CoreFail - Copy.txt
(rename to *.json to reproduce failing model)

https://hypar.io/workflows/8bfcf7c4-756a-446f-9f64-a0c66442054c

• Is staged.
• Is live.

https://dev.hypar.io/workflows/e3579575-fce7-486d-8d6d-50fb04194d77\

Rename to *.json:
GHoneModel.txt

• Is staged.
• Is live.

Open a new workflow. Place a Location function. Lights are dark. This is because we're currently fitting the sun position around everything except the topo (using a 1km test width). We need to fit the scene to the topo if it's the only thing in the scene.

Structural steel is currently placed at or below the level. In the case of a roof, the structural steel often has to slope to support a slanted roof. Given a roof defined by points, we should be able to project the steel vertically onto that roof.