2022-03-16 03:44 PM - edited 2022-03-16 03:45 PM
Hello,
I am trying to create an object which is essentially just a block which uses A, B and ZZYZX to set the dimensions. Is it possible to be able to change the surface texture origin to something that isn't 0, 0? I have looked through the GDL reference guide as I thought I had seen it in there before but I can't seem to find it!
Any ideas?
Thanks
Solved! Go to Solution.
2022-03-17 02:50 PM
Yes.
VERT sets the co-ordinates and COOR does the wrapping.
Here is some code from my bath hop - only moves in x and y directions (not z, but that could be added in).
It is old so is only COOR and not COOR{3}.
I haven't looked into COOR{3{.
prism_ 5, hob_height,
0,0,15,
0,b,15,
a,b,15,
a,0,15,
0,0,-1!,
VERT 0+tile_fill_origin_x,0+tile_fill_origin_y,0 !Origin
VERT 1+tile_fill_origin_x,0+tile_fill_origin_y,0 !X direction
VERT 0+tile_fill_origin_x,1+tile_fill_origin_y,0 !Y direction
VERT 0+tile_fill_origin_x,0+tile_fill_origin_y,1 !Z direction
COOR 2+256,1,2,3,4
body -1
Barry.
2022-03-16 04:22 PM
Proper texture wrapping is a topic on its own...
Have a look at "coor{3}".
2022-03-16 06:09 PM
It looks like that is what I'm after, thank you! It is quite confusing so I'll have to try to wrap my head around it.
2022-03-17 02:45 AM
If you have the Cookbook 3 by David Nicholson-Cole, there is a good example of VERT/COOR in there.
It is a bit difficult because not only do you need to wok out how the co-ordinates work, you also specify the VERT/COOR command after the element you want to affect - not before like with a MUL, ADD or ROT command.
Barry.
2022-03-17 02:09 PM
Do you have to use both Vert and coor{3}? All I'm trying to achieve is to move the origin of the surface along, x, y and z, and for the texture to wrap as it usually would.
2022-03-17 02:50 PM
Yes.
VERT sets the co-ordinates and COOR does the wrapping.
Here is some code from my bath hop - only moves in x and y directions (not z, but that could be added in).
It is old so is only COOR and not COOR{3}.
I haven't looked into COOR{3{.
prism_ 5, hob_height,
0,0,15,
0,b,15,
a,b,15,
a,0,15,
0,0,-1!,
VERT 0+tile_fill_origin_x,0+tile_fill_origin_y,0 !Origin
VERT 1+tile_fill_origin_x,0+tile_fill_origin_y,0 !X direction
VERT 0+tile_fill_origin_x,1+tile_fill_origin_y,0 !Y direction
VERT 0+tile_fill_origin_x,0+tile_fill_origin_y,1 !Z direction
COOR 2+256,1,2,3,4
body -1
Barry.
2022-03-17 03:29 PM
That's perfect and makes it infinitely easier to understand than the reference guide.
Many thanks for your help
2022-03-17 03:47 PM - edited 2022-03-17 03:47 PM
No, If you use COOR{3} you don't need any VERTs. Thats because this command is self-sustained.
COOR{3} is basically superset of vert and the old coor, since it now handles everything in the same command.
I think there is even a warning of some kind in the GDL reference manual displaying that COOR{3} superseeds all other methods and that VERT and COOR are deprecated. (Of course it still works, tho.)
2022-03-18 03:07 AM
Thanks, as I mentioned I have not looked at COOR{3} so wasn't aware of that.
Looks like I need to start updating to COOR{3} then.
Barry.
2022-03-18 11:45 AM
I always wonder if there is any impact in this.
GDL keeps all the old stuff viable, and breaking changes are rare. (well yeah, there was the purge of the possibility of param/master script for some commands, but otherwise?)
This kind of backwards compatibility is nice since you technically can still use even 20 year old objects just fine. But still I'm wondering if this comes with a cost; like, do you have any benefit by updating your objects? You probably don't have to.