VW 2023 Sitemodel bug

[david on orcas]

Has anyone noticed a bug (or change) with the sitemodel?  If you change the Z elevation of the layer that the site model resides on, then update the model, the model reports back contour elevations with respect to the internal origin (or original elevation) instead of the Z elevation of the layer.  The “Geometry lowest Z” value in the OIP also changes. Have been trying to change that number to see if I could create a workaround to get the values to appear correct in plan view,  but not having much success. . .

[Benson Shaw]

Found one workaround (there are probably others) on similar problem with stakes as DTM source.  I found need to remake the DTM, so might be best to work in a duplicate file.

• Select the original DTM, access Recreate from Source Data, Select/Copy All, exit the edit window.
• Create or make active a new blank Design Layer of desired scale and z value, then Paste in Place.
• The contours and other source objects should now report correct elevation, eg relative to the new layer.
• Or, if necessary, adjust z values en mass via Move 3d.
• When correct elevation achieved, use these contours to create a new DTM.

Depending on how Site Modifiers and other geometry are managed, either

• Reassign site mod effective layers to this new DTM via OIP>Site Model Settings>Use Site Modifiers On menu>Custom> enable the appropriate layers.
• Or, correct the z value of original DTM layer,  Paste in Place the new DTM into that layer and send the orig DTM to an archive layer (or delete it) and, if needed reassign the effective layers in OIP>Site Model Settings

 

Actually hope there is a better way.

 

-B

 

 

Edited September 15, 2022 by Benson Shaw
hanging around like a hungry hound

[Jeff Prince]

6 hours ago, david on orcas said:

Has anyone noticed a bug (or change) with the sitemodel?  If you change the Z elevation of the layer that the site model resides on, then update the model, the model reports back contour elevations with respect to the internal origin (or original elevation) instead of the Z elevation of the layer.  The “Geometry lowest Z” value in the OIP also changes. Have been trying to change that number to see if I could create a workaround to get the values to appear correct in plan view,  but not having much success. . .

That’s how it works in previous versions too, not a bug IMHO.

 

Personally, I put my data on a design layer where the layer elevation is 0 and the data is in real world elevations prior to building the site model.  The site model is really just a complicated container object.  If you move it in elevation, it reports the original elevation from which it was built…. That’s a good thing because it allows you to move the model in elevation, when needed due to limitations of Vectorworks and Twinmotion, but report the correct real world elevation.

 

The complication of moving a site model in Z is encountered when editing a moved site model, the values reported in the OIP will be based upon the source data + the elevation change, which makes every edit subject to human error.  Best to keep edits it in real world elevation to prevent confusion and use a reference in instances where you want to move the site model in Z.

[AlanW]

I agree with JEff, Site model references the survey data which i always set to design layer zero. that way all the survey data is measurable and if you get a .CSV file and use import survey data your mode is generated instantly relative to world co-ordinates.

Edited September 15, 2022 by AlanW

[Benson Shaw]

Yes, totally agree with @jeff prince and @AlanW - create the DTM with layer elevation = 0.  

 

My post above is for correcting if the source data was (inadvertently?) placed on layer with z value other than zero.

 

-B

[david on orcas]

I usually have a building file set to zero and a a separate site file set to zero then reference each file with a site reference layer set to El. negative 100’ if there building is at El. +100’ for example.  However that can get buggy, even after readjusting the site data to the internal origin. Certain Plug in objects when referenced in a different file, like spaces or floors, don’t like to be located  far from the user origin even if they are close to the internal origin.  So I often have to import the topo source data into my building file and reconstruct a site model close to the internal origin of my building file.  But the site layer needs to be at El. -100’.  Maybe I might have one at El. -99’ and one at El. -101’ as I compare how the building might sit on different portions of the site. In VW 2022 this was never a problem.  In VW 2023, if the site layer is at El. 0, then my building layers would need to be at El. 100.  To study how the building sat on different portions of the site I would then have to adjust multiple building layers up a foot or down a foot.  Pretty cumbersome during early design phases. VW 2022 was very nimble with respect to adjusting site layer elevations (at least with my workflow so worked perfectly.) So my sense is something in the coding changed.  Might have to do with new geo referencing improvements but haven’t investigated that. . .

[Jeff Prince]

37 minutes ago, david on orcas said:

I usually have a building file set to zero and a a separate site file set to zero then reference each file with a site reference layer set to El. negative 100’ if there building is at El. +100’ for example.  However that can get buggy, even after readjusting the site data to the internal origin. Certain Plug in objects when referenced in a different file, like spaces or floors, don’t like to be located  far from the user origin even if they are close to the internal origin.  So I often have to import the topo source data into my building file and reconstruct a site model close to the internal origin of my building file.  But the site layer needs to be at El. -100’.  Maybe I might have one at El. -99’ and one at El. -101’ as I compare how the building might sit on different portions of the site. In VW 2022 this was never a problem.  In VW 2023, if the site layer is at El. 0, then my building layers would need to be at El. 100.  To study how the building sat on different portions of the site I would then have to adjust multiple building layers up a foot or down a foot.  Pretty cumbersome during early design phases. VW 2022 was very nimble with respect to adjusting site layer elevations (at least with my workflow so worked perfectly.) So my sense is something in the coding changed.  Might have to do with new geo referencing improvements but haven’t investigated that. . .

All of that is a lot easier using referenced design layer viewports for your building, which can be placed in the site file.  No need to change the elevation of building layers, you simply move the entire building reference to study these relationships, everything comes along for the ride from foundation to roof. Similarly, you can reference the site into your building file and move it as needed.

This also allows you to use your preferred units for building and site independently.

[david on orcas]

3 hours ago, jeff prince said:

All of that is a lot easier using referenced design layer viewports for your building, which can be placed in the site file.  No need to change the elevation of building layers, you simply move the entire building reference to study these relationships, everything comes along for the ride from foundation to roof. Similarly, you can reference the site into your building file and move it as needed.

This also allows you to use your preferred units for building and site independently.

Hi Jeff,

that’s how we would like it to work,  but historically, it gets quite buggy.  With different user origins, one for the site tied to real world coordinates and one for the building at 0,0, the referenced design layer viewports can get huge and lead to all sorts of problems and crashes even with all geometry recentered on internal origins. Will try it out in V2023 to see if any of that has been fixed and send a screenshot of results on the weekend.

Need to also try out vw2023 georeferencing.

Thanks for the input!  

[Jeff Prince]

1 hour ago, david on orcas said:

Hi Jeff,

that’s how we would like it to work,  but historically, it gets quite buggy.  With different user origins, one for the site tied to real world coordinates and one for the building at 0,0, the referenced design layer viewports can get huge and lead to all sorts of problems and crashes even with all geometry recentered on internal origins.

That is strange and the opposite of my experience.  In fact, I have a thread here on the forum where I developed a referencing methodology for relocating mixed reference projects to z=0 for use in Twinmotion.  Building at 0, site at real world, both referenced into a separate file where each reference is positioned in their correct elevation, grouped and then moved to z=0 for Twinmotion.  You would think of something was going to get buggy and break, it would be in that scenario, but it works great.

 

I’m pretty sure the notion of building at z=0 and referencing it into the site was something I originally learned on VWX University.

 

Anyhow, all of this is to say I hope you are able to find a solution that works for you.  Perhaps there is something in your process that is breaking this tried and true method I have explained.

[Hans-Olav]

17 hours ago, jeff prince said:

I have a thread here on the forum where I developed a referencing methodology for relocating mixed reference projects to z=0 for use in Twinmotion.  

@jeff prince Do you have a link to the tread mentioned?

[rDesign]

51 minutes ago, Hans-Olav said:

@jeff prince Do you have a link to the tread mentioned?

I think this is the thread Jeff was mentioning:

 

[Jeff Prince]

7 hours ago, Hans-Olav said:

@jeff prince Do you have a link to the tread mentioned?

Looks like @rDesignhooked you up.  I tried to find the other discussion about it, but came up empty.

Edited September 17, 2022 by jeff prince

[david on orcas]

I ran some tests and took some screenshots. I know you all are not fans of site layers being on layers with different Z elevations, but I  wanted to show a couple of screenshots of a site file in VW2022 and VW2023 showing how the site model behaves differently between the two versions.  (Stakes correctly report the correct Z elevation height with respect to the layer elevation, but the site models report different topographic contour heights).  

 

FWIW  I also attach a VW2023 building model file that references a site file with data located in the "real world".  That site file has been re-centered about the internal origin and which puts the data far from the user origin. If the site file contains an object like a floor object, and if you open the building file and select "all" which includes the referenced site viewport, it selects something huge. This huge viewport will often leads to crashes.building file 2023.vwx 

site model study as a referenced file v2023.vwx