cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
Developer forum

GDL COOR{3} with PLACEGROUP command

concepsys
Booster

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.

1 ACCEPTED SOLUTION

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.

Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest

View solution in original post

10 REPLIES 10

Dave Seabury
Enthusiast

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

 

 

AC 19-24 Windows 10 64 bit, Dell Prercision 7820, Xeon Silver 2414R ( 12 Cores), 64 GB Ram, Quadro RTX 4000 8GB

concepsys
Booster

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
Ace

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.

Mostly AC 26 on Mac | Author of SelfGDL | Developer of the GDL plugin for Sublime Text |
«Furthermore, I consider that Carth... yearly releases must be destroyed»

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...

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
Mostly AC 26 on Mac | Author of SelfGDL | Developer of the GDL plugin for Sublime Text |
«Furthermore, I consider that Carth... yearly releases must be destroyed»

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.

 

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?

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!

Mostly AC 26 on Mac | Author of SelfGDL | Developer of the GDL plugin for Sublime Text |
«Furthermore, I consider that Carth... yearly releases must be destroyed»

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.

Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest

concepsys
Booster

Sorry for my late reply. I hat to deal with other projects and only yesterday got back to this one.

I'd like to thank all the help that I got on this theme, specially from @runxel that took a lot of his time to help me with valid yet more complex solution. Your GDL knowledge is very impressive and if you don't mind I may bother you again in the future.

I marked Péter Baksa's post as the solution because in fact, althoug my inital question was itself more complicated than needed, his solution was the one that I ended up using, just because it was an easy solution for my actual problem, allowing to keep the project centralized in a file that calls simple macros and allows an easier way to manage diferent unique randomly shaded elements through different composition geometries. The result was great!

 

Again, Thank you all.

Still looking?

Browse more topics

Back to forum

See latest solutions

Accepted solutions

Start a new discussion!