Small annoying things

[Eugen]

Thank you!

Next one:
Is there a reason why stairs sometimes show this excessive plane at the topmost step, or is this a bug?
Thanks!
Best regards
Eugen

[timglobal (Tim)]

Backing up

[fsalla (Francesc Salla)]

Yes, this is a bug. Please send us this model to visualarq@asuni.com and we will check it out to fix this.
Thanks,

[Eugen]

@fsalla

visualarq@asuni.com

Sent.
Cheers!
Eugen

[fsalla (Francesc Salla)]

Got it, thanks!

[fsalla (Francesc Salla)]

Eugen, if you edit that stair style, check the “draw the tread slab” option and add some nosing, that wrong plane on the top of the stair disappears, (We will take a look at this bug and fix it anyway.)

[Eugen]

Ok, thanks!!

[Eugen]

Hello!
This might be more than a “small annoying thing”, but:
would it be possible to have the vaPlanView and vaSectionView command translate text into text, not (often broken) curves?
Thanks!
Best regards
Eugen

[fsalla (Francesc Salla)]

Hi Eugen,
Do you mean when you explode the Section and Plan Views?

[Eugen]

No, in the vaPlanView already.
It might be a problem with that spectific font, because other fonts work without those artifacts.

Besides, the door opening seems to be off, too.

Thanks!
Eugen

[Eugen]

@fsalla

You are right, the Gumball doesn’t align well on some VisualARQ objects (Curtain walls, Railings, Stairs and Roofs) when it is set to Align to Object. (I had just tested it with the objects it works). I hope we can fix this soon.

Hello Francesc!
I just noticed that vaSections and vaSectionViews show the same behavior - in Object mode, the Gumball origin is placed in the scene origin, which can be very far off.
vaSections could have their origin on the line start point, and vaSectionViews in the bottom left of the bounding box, just like vaPlanViews do.
In the latter case I’m not sure, because in a section view one might want to easily refer to the 0-level. Anyway…
Thanks!
Best regards
Eugen

[Eugen]

Hello!
Next suggestion: VA parts could ignore other VA parts if they are on hidden layers.

It happened quite a few times already that a wall just disappeared after creating it, until I figured there were other walls on hidden layers that interfered,

Thanks!
Best regards
Eugen

[enric (Enric Marquès)]

Hi @Eugen,

I understand your point, but ignoring hidden objects doesn’t make sense to me. First of all, object visibility is just a flag that indicates if the object is shown or not, but it continues to exist in the model, so it will intefere with the rest of objects.

Ignoring objects hidden or that lie on a hidden layer will mean that toggling object or layer visibility will regenerate all objects that interfere or that are dependant on, which will make working with VisualARQ extremelly slow.

Moreover, in Rhino you can turn off layers per layout detail (using the HideLayersOnDetail command) which means that an object could be hidden in some details while it is visible on others. It will be too complex to regenerate and draw each object on each viewport/detail differently according to the visibility state.

Maybe we can do something that warns you when an object recenlty created or modified is being affected by hidden objects in the current view.

Regards,

Enric

[Eugen]

Hello!
You have a point. I don’t want to refresh everything when a layer is turned off or on. That thing with detail views sounds complicated, too.

How about introducing some some “active” flag in the VA object’s properties instead?
Since performance can be an issue, this could help optimizing a scene - deactivate VA parts, and they will be ignored in the next refresh.
(I don’t know what happens during a refresh, but i reckon you have to do a lot of bounding box testing wich VA objects actually overlap)

Why I came up with this in the first place: now you cannot have variations of VA building parts on different layers. Would be useful if you want to compare, make choices, go back and forth in the design process.

Best regards
Eugen

[fsalla (Francesc Salla)]

@Eugen

now you cannot have variations of VA building parts on different layers. Would be useful if you want to compare, make choices, go back and forth in the design process

We will study someway to achieve that in future versions.

[fsalla (Francesc Salla)]

@Eugen

Got another wish: those triangular edit points are rather small - I already had problems selecting them when they were amidst other lines or objects. Also, they are quite far offset, I think.
Since people will have different tastes: maybe add a preference in the VA Options?
Thanks!
Eugen

@Eugen In the VA 2.0 Beta we put the wall extension control points closer to the wall ends. You can already try it out: Download - VisualARQ
You can also control the size of these control points from the Display mode settings.

[Eugen]

Hello!
Thanks for the fixes!

Some details: one of the edit points does not point to the camera, like the others do. I guess that’s not by design.

Also, I could not manage to resize the points in Options > Display Mode… is this just me?

Cheers
Eugen

[enric (Enric Marquès)]

Hi @Eugen,

All control points should point to the camera. It could be a bug or that it is too small that the representation does appears to be just a line.

You can change the control point using this setting:

Regards,

Enric

[Eugen]

Oh, that’s the right parameter… thanks!

Regarding the screenshot:
It’s an arrow, seen from the side. It does not rotate with the cam. -> bug I assume (a small one)

Best regards
Eugen

[enric (Enric Marquès)]

Hi @Eugen,

Can you send me the 3DM file to enric@asuni.com with the wall and the view where the control point does not orient to camera? I cannot reproduce it here.

Thanks,

Enric