Editable height of mesh

Anonymous · ‎2009-04-18

Why the tool for height adjustment (3D Stretch Height) for the mesh is not working? It simply adjust the mesh elevation but not the Z values. It is very essential when you work with sloped terrains.
For example, when you import and create mesh from Google add-in, it always create mesh with center point in center of the terrain and elevate mesh to the desired height. So if you have mesh with level difference of 20hm on center altitude of 50m you will get the mesh with data:
-elevation 50m
-thickness 10m
-bottom -10hm
and it won't be solid until you change thickness to 20m minimum.
There is no way to change Z-value of the points respectively, if you try it with Heigh tool you only change elevation of mesh. That is problem with Archi Terra add-on, cause it got crazy when try to draw any object (try the wall) passing from minus point to plus point and contra. Also retaining wall doesn't work below zero point.
It should be very easy to implement height adjustment for the meshes. Just need to pass thru the Z-array and recalculate value for desired height.
I'm not sure how it works in version 12 but my remarks are for versions 9 and 11

Thomas Holm · ‎2009-04-21

rocorona wrote:
...Select the Mesh and click on the previous node, to edit it's height. It should read 7.00m now... but it is still 5.00.
This is because the Stretching command moves BOTH the top surface and the reference plane. Maybe we need two separate commands.

It reads 5.00 only when you've set the readout to use the reference plane as the origin. If you used project zero of any of the reference levels it will have changed according to your height stretch.

This behavior is simply because the Archicad mesh is stretchable only between the reference plane and the bottom surface. If this is a problem only for the add-ons, I think they would have to include routines to find out where the reference plane is situated. I have a hard time seeing this as an issue for average Archicad users like me.

I think there are more pressing issues. Terrain and site modeling in Archicad needs better tools, and the mesh editing in general also needs an improvement.

Also, I think Dragan is right in pointing out another issue: It would be very nice if it was possible to import a complex terrain from another application directly to a mesh.

Therefore I'd like to repeat my question - has anybody succeded in importing any Autocad mesh to an Archicad mesh the way I suggested earlier?

AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1

Anonymous · ‎2009-04-23

Thomas wrote:
The tracker readouts don't say much to me - they show the same in 2D and 3D here, I guess because I'm using different tracker origins than you do.

Yes, You absolutely right. I was using diferent tracker orrigin in 2D (to Mesh Reference Plane which is not available in 3D) but it is still recalculated Z-value.

Thomas wrote:
Another workaround you might try, to get the GDL object mesh back to a regular after editing, might be to export the object to DWG and then re-import it with the settings shown in the picture checked in the DWG translator settings file. I have not been able to test this, but it might work! Perhaps you need to make some change on the Autocad side though, I can't help with that.
(These settings are sparsely documented, but the shown Translator settings should suggest a way to import a 3D dwg polygon mesh directly into an Archicad mesh without going through the import as object routine . If somebody has tested this, I'd really appreciate a posting in the Data Exchange part of this forum!)

I tried to do something with Export-Import into DWG, but I'm not so happy about that Add-on. If you ask me it is very hostile, specially for the meshes.
I would say it on this way: God Export/Import function should give same or at least similar result when done in both ways, which is far away from DWG In-Out Add-on.
The only way I found so far is with ArchiTerra TXT Export-Rearange Heights in text editor-ArchiTerra TXT Import. Side efect is that this Add-on almost always reduce number of nodes in mesh, but it could be positive in some circumstances. Also that means that you need to engage Not-free Add-on for such a simple operation, which is I think unreasonable waste of resources.

That's why I vote for diferent tool, and also for decent TXT exporter in AC, specialy for the meshes.

Thomas Holm · ‎2009-04-23

Dragan, now I agree with you! Especially on this issue (my emphasis):

Dragan wrote:
I tried to do something with Export-Import into DWG, but I'm not so happy about that Add-on. If you ask me it is very hostile, specially for the meshes.
I would say it on this way: Good Export/Import function should give same or at least similar result when done in both ways, which is far away from DWG In-Out Add-on.

AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1

Anonymous · ‎2009-04-23

I would like to add just another similar issue:

If AC can export an object into his native format (which I think the .GSM is), why there is no option to import the same object into native format.

For example, if you export wall, or slab or mesh into .gsm, it should be an option to import it back (with or without any rearangement) to wall, slab or mesh respectively.

That would ease lot of conversion problems, because some other programs are able to export into .gsm too.

But, maybe the main problem is just the conversion ability itself.

owen · ‎2009-04-23

Dragan wrote:
For example, if you export wall, or slab or mesh into .gsm, it should be an option to import it back (with or without any rearangement) to wall, slab or mesh respectively.

That would ease lot of conversion problems, because some other programs are able to export into .gsm too.

Whist this would work with GSMs created by ArchiCAD (as the object will be constructed using native AC elements in the GDL) it is not so simple for GSMs created by other applications. They may not necessarily create a 'mesh' using MESH or a wall using the xWALL commands. It could just end up as a bunch of primitive definitions in the GDL script (ala the 3DS Import Add-On) in which case AC would have no idea what to turn it into as there really are no primitives modeling tools in AC.

I do support the principle though

cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5

Anonymous · ‎2009-04-23

owen wrote:
They may not necessarily create a 'mesh' using MESH or a wall using the xWALL commands. It could just end up as a bunch of primitive definitions in the GDL script (ala the 3DS Import Add-On) in which case AC would have no idea what to turn it into as there really are no primitives modeling tools in AC.

I don't expect anything more. But, if you create one slab, four walls and one roof in AC and export it into object, it should create .gsm with 3D script consists of one (x)SLAB(_) element, four (xi)WALL(xi) elements and one CROOF_ element. It would be very simple to import that back into AC as GS primitives (which MESH is NOT, MESH is just special type of MASS, but anyway also SLAB, WALL, ROOF are special types of PRISM)

Instead of that, this would create one CROOF, four XWALL_ and more than one SLAB (actually 9 CPRISM_) which is very tricky to import back, but not impossible. If you know the way to the place you certainly know the way back.

However, my point is 'keep it simple unless you need to complicate'
If my intention is to be transferable I would keep to GS primitives when writing GDL, if not, I will use GDL primitives and have script full of VERT, VECT, TEVE etc. so neither AC nor AutoCAD, 3DS... would be able to transfer my code into their primitives but will display it correctly in 3D.

I just wonder, if anybody wants to write Add-on for such a kind of Importer, would the GS approve it (cause one need their approval for valid Add-in) ??

Editable height of mesh

Still looking?

Browse more topics

See latest solutions

Start a new discussion!