New status code for TUBE

[Anonymous]

I notice a new status code 128 for TUBE and TUBEA in AC12.

Previous to AC12, in case of a twisted TUBE, you had to script additional points for cross section polygon, to avoid artifacts in rendering.
This, for any cross section with sharp angles (facets).

Since AC12, adding a status code 128, allows to get rid of these additional points.
Great improvement, alas it seems undocumented.

Can someone confirm this.

[Anonymous]

This is really a big improvement! Thank you, Olivier, for pointing it out!

Previously this looked very bad when exported to Max. I had to manipulate the faces separately to achieve proper presentation!

Sorry, I do not have AC12 to confirm it now!

[Anonymous]

kliment wrote:
This is really a big improvement! Thank you, Olivier, for pointing it out!

Hi Kliment,

This is pure hasard.
Looking at another thread "Elliptical (oval) stair", i opened the "Curved Ramp 12" and noticed the change.
After some testing on old parts, it seems to work.

I am wondering if GS has some other hidden features like this one.
I think to the (in)famous sharp angle between two coplanar curved polygons, when scripting with primitives.
And additional points in general. No time for testing each tool.

If they solved it for TUBE, may be for other tools.
GS, please, some information?

[Anonymous]

Hi Olivier,

Thats good news! This behavior always made me mad...

Could you render this example with a brick texture?... Just to see the texture behavior with this new code...

Thanks for the post!

[Anonymous]

Braza wrote:
Could you render this example with a brick texture?...

Hi Paulo,

I don't see any difference in texture rendering between Curved Ramp 11 and 12 (brick texture).
Result is the same (bad in any case), because there is not any COOR statement for texture alignment in these objects.

Even with such a statement, texture alignment is bad into AC for curved objects,
in particular for TUBE elements. Better to use another rendering software.

I am a bit blind color, so i let renderings for those who know.
I can just see artifacts when they exist, but don't count on me for something else, sorry.

[Anonymous]

Thanks for the feedback Olivier.

I agree with you. Tube function has a bad behavior with texture mapping. IMO It should have its own texture mapping code.

Perhaps in AC13

While this... It would be nice to have some feedback about GDL improvements from GS.

[Anonymous]

Braza wrote:
While this... It would be nice to have some feedback about GDL improvements from GS.

Paulo,

I asked Greg Kmethy, via PM, if we could expect a short article on ArchicadWiki, to explain this new feature,
and if other tools are concerned. Wait and see.

I confirm it works fine with TUBEA. I mean, there are no artifacts in rendering, with or without texture.
For a curved ramp, Polycount is reduced by 2. That's interesting.

[Anonymous]

gkmethy wrote:
Oliver,

We'll try to document it on wiki - we're a bit overloaded now, but it will happen.

Thanks,
Greg

That's fast.
Thanks for that, Greg.

Cheers,
Olivier

[David Collins]

Braza wrote:
I agree with you. Tube function has a bad behavior with texture mapping. IMO It should have its own texture mapping code.

I recently replaced many TUBE objects in an old project with Complex Profile Walls. The texture mapping in the Complex Profiles works beautifully, while the behavior of the old TUBES was always a mess. Out of curiosity, I dragged the walls into a Library Object 3D Script window to see what was happening with the GDL.

Each segment of the "path" has a separate VERT COOR statement which redefines the origin and direction of the texture bitmap. Incorporating this strategy into TUBE would make for some very intense GDL scripting indeed. Hopefully, a more sensible solution will be found for some future version of TUBE. Surely, the path for each segment of a TUBE object provides enough information to sucessfully re-orient the texture at each joint. This should be part of the internal GDL behavior.

In general, the texture mapping behavior of both TUBE and MASS ( and probably many of the other more esoteric GDL shapes) need to be improved somehow.

[Anonymous]

Olivier wrote:
That's fast.
Thanks for that, Greg.

Hey Olivier... You are a GDL celebrity... Your voice is heard loud and clear in the GS offices...

Thank you Olivier.

David,

The complex profile walls are a good alternative for the tube... The only problem is the file size of the project... And probably with some SEO operations it would became a giant...

About the tube mapping... Some time ago I built an object with a loop (for next) of Sweep functions with individual texture mapping for each path... The object had a bit more polys than a tube... But the mapping was perfect...
If GS could condense this routine in a single function maybe it would work...