GDL COOR{3} with PLACEGROUP command

[concepsys]

Hello,

I am creating a geometry by creating a GROUP.

Inside this group I have for..next loop that CALLs a geometry.

I want to apply a texture over this construction, but I can't. No matter what I try the texture (that I placed in the beginning of the GROUP is still and won’t change.

I tried using COOR{3} inside the group (between GROUP and ENDGROUP commands)

I tried after ENDGROUP command

I tried after PLACEGROUP command

but cant control the texture.

How can I solve this?

(By the way, I am working in Archicad 22 to make sure they become compatible with all later Archicad/GDL versions. Could this be a problem that has been solved on a later version?).

Thanks in advance.

[Dave Seabury]

Consepsys

If you have a copy of the GDL cookbook David has a routine for textures 

that applies the texture and rotates if need be.  It looks like this............

GROUP "Block Cutter Left"
ADDy btmY
PRISM_ 5, 0'-1.5000",
0.0", 0.0", 15,
0.0", -1', 15,
2', -1' , 15,
2', 0.0', 15,
0.0", 0.0", -1
DEL 1
ENDGROUP

RESULT_HeelBlock = SUBGROUP("Heel Block Left","Block Cutter Left")
PLACEGROUP RESULT_HeelBlock
KILLGROUP "Heel Block Left"
KILLGROUP "Block Cutter Left"

ROTz pAng
Base
Vert 0, 0, 0
Vert 1, 0, 0
Vert 0, 1, 0
Vert 0, 0, 1
Coor 2 + 256, -1, -2, -3, -4
DEL 1
Body -1

GOSUB 999 !Surface Horizontial

ENDIF

RETURN

!=======================================================
!=======================================================

996:!Paint Pitch Angle
ROTy pAng + 90
GOSUB 999:!Paint Texture
DEL 1
RETURN

997:!Paint Pitch Angle
ROTy pAng
GOSUB 999:!Paint Texture
DEL 1
RETURN

998:!Paint upright
ROTy 90
GOSUB 999:!Paint Texture
DEL 1
RETURN

999:!Paint Texture
!Horizontally
BASE
VERT 0,0,0
VERT 1,0,0
VERT 0,1,0
VERT 0,0,1
COOR 256+2, -1,-2,-3,-4
BODY -1
RETURN

David

[concepsys]

Thank you, Dave, for your interest and reply,

I believe that way of working is deprecated.

Still, I have tried it but no result.

I also tried in the latest Archicad 26 and the problem still exists .

I confess I don't always fully understand the use of BODY or BASE commands, specially with COOR {3}. For now, I deleted all BODY and BASE commands from my code, both in the main code, and on gosub and call commands.

The structure of my 3D program command is something like this:

____________________________

group

   set material

   for ..

         position (next similar object)

               gosub..

        del (position)

   next

endgroup



placegroup

killgroup

end



gosub routine:

   position

     call (geometry gsm object)

   del (position)

return

_______________________________________

Somehow I get the material I defined inside the group command for all placed geometry objects but no matter where I place a COOR command I never get to control the direction and type of placement of the texture... 😞

Any help is much appreciated.

[runxel]

Yeah no wonder it does not work....

At the end of a script there will always be an implicit "body -1" being set. (Same goes for the beginning – there will always be an implicit "base")

So if you're calling another object you are doing just that. The COOR statement in the caller will never affect the macro, since a base/body statement will block its access.

Instead I suggest you should do the texture wrapping in the macro and append the necessary parameters along the macro call.

[concepsys]

Thank you for your reply.

The goal is to be able to attribute different textures (defined on the main program) to the geometry that results from these gosub+call routine.

Not only that, but diferent textures would need different placement (COORs).

In the macro I have no definition of material and I have no BODY or BASE commands, but if understand correctly, you say that it is implied that a texture placement is done inside de macro.

On the other hand, if that is the case, wouldn't that result in the texture being applied the same way in every instance of the macro?

Because now I am getting the texture applied and repeating over several instances. (as it is intend)... with the size defined in the main program (texture definition).

The texture that shows in 3D is the texture being applied on the main program so in fact it is affecting the macrto texture (that has none). Its just that it can't be controled.

On the other hand, I tried to use COOR inside the macro and it seems that it also doesn't change this texture in any way...

[runxel]

Don't conflate the texture with it's orientation!

The surface is assigned with "MATERIAL xxxx" (or "building_material" respectively). If you neither assign one of those, "MATERIAL 0" will be set implicitly at the beginning of the 3D script. A "material" statement in the caller object will trickle down. In general all macros will always inherit all attributes (active pens, fills, resol, values on the stack, etc...) since it's a linear flow – as long it is not overriden in the macro.

HOWEVER, there is one exception: The BODY statement. GDL assumes that a macro will always be a atomic element and thus introduce an implicit final BODY -1.

So you simply can't set the wrapping and orientation in the caller.

Again, I encourage you to solve this by providing the necessary data and call the macro with it 🙂

! Pseudocode
dim xcoor[3], ycoor[3], zcoor[3]
xcoor[1] = 1.0
xcoor[2] = 0.0
xcoor[3] = 0.0
...set the necessary data
call "m_geometry",
  parameters all, xcoor = xcoor, etc...
!-----------------------
! in the macro
....geometry generation...
gosub "texture wrapping"
end
"texture wrapping":
     coor{3} \
			2, 	! wrap mode Box
			0, 	! wrap flag
			0, 0, 0,	! origin
			xcoor,	! x
			ycoor,	! y
			zcoor	! z
	body -1
return

[concepsys]

runxel,

Thank you again for your interest.

I use macros because I like to keep things simple separated and easily interchangeable, but in this case, I am considering that maybe it will be simpler to bring the macro's geometry into the main program instead of bringing the main program into the macro...

My goal is to apply a big texture over several repetitions of the macro geometry. (Like a dirt texture, for instance).

By applying this texture inside the macro I am unsure if I will not get the same exact image placed on every instance, making the repetition very obvious, instead of a big texture that would make every instance different than the next...

As I said, the need to use of BODY (-/+), BASE, COOR, (wrap mode & wrap flag and even the texture coordinate system) are not very clear to me on the GDL manual and I always end doing trial and error to achieve the intended results.

Still, I fully understand what you propose and will test it. I'll get back to you to report my conclusions. 

Thank you so much for your help and suggestions.

[concepsys]

runxel,

I started testing your sugestion but the 3d wouldn't change. Then, It ocurred to me I was still using the material definition on the main program that would be overimposing any material that should(?) be set inside the macro?

The problem is that inside the macro there is no definition of this material (a set of materials, to be selected by the user) created on the main object and It seems that after defined on the main code, the material can't be simply passed through the CALL parameters.

Am I wrong?

One solution would probably be to create the material on a independent GDL Master object that would define textures for all objects, but unfortunatelly there are many other main objects in this library that now have the same code to define this material, with the same name, but different images from object ot object Instead of defining a single material per object I would have to define a lot of materials with different names for different objects...

Is it possible somehow that I am wrong and it is possible to pass a material defined on the main code to the macro?

[runxel]

No, you can set your material inside the caller.

Then do the "set material xxx" there.

If you use any more complex geometries where you need to reference a surface directly (e.g. CPRISM_{4}) you can also absolutely pass the local ID with "locid = ind(MATERIAL, "made_up_mat_name")".

So I just scripted that example in a couple of seconds. It's working and you should be able to do so easily! Godspeed @concepsys!

[Peter Baksa · Accepted solution]

Hi,

In GDL a macro is like a function in other languages. It is interpreted each time it is called, and can be called with different parameters each time. You could even use RND to randomize the texture.