GDL - Edges and Pgons

[ShaunTaylor]

Hi,

I was wondering, when using edge or pgon commands in GDL and you use the status' to automatically resolve polygons edges that they are linked to or automatic vector assignment, does it make the object generate at a slower speed.

This is just more for my curiosity wondering if you use these methods excessively, will it make objects run slow?

For example, I am referring to when set pgon1 and pgon2 to "-1" and when you set vect to "0".

edge vert1, vert2, -1, -1, status

pgon n, 0, status, edge1, edgen

Here is an example of a box I made that is driven by an array. I am just wondering I am taking the wrong approach to creating edges and pgons.

pen 4
shapeSurface = 60
dim shapeVertices[][]
    shapeVertices[1][1] = -0.1 / 2 : shapeVertices[1][2] = 0.1 / 2 : shapeVertices[1][3] = 0
    shapeVertices[2][1] = -0.1 / 2 : shapeVertices[2][2] = -0.1 / 2 : shapeVertices[2][3] = 0
    shapeVertices[3][1] = 0.1 / 2 : shapeVertices[3][2] = -0.1 / 2 : shapeVertices[3][3] = 0
    shapeVertices[4][1] = 0.1 / 2 : shapeVertices[4][2] = 0.1 / 2 : shapeVertices[4][3] = 0
    for i = 5 to 8
        shapeVertices[i][1] = shapeVertices[i - 4][1]
        shapeVertices[i][2] = shapeVertices[i - 4][2]
        shapeVertices[i][3] = 0.1
    next i

base
model solid
nVertices = vardim1(shapeVertices) / 2
for i = 1 to nVertices * 2
	vert{2} shapeVertices[i][1], shapeVertices[i][2], shapeVertices[i][3], 1
next i
startIndex = 1
n = startIndex + nVertices - 1
nEdges = 0
for i = startIndex to n
	if i < n then j = i + 1 else j = startIndex
	edge i, j, -1, -1, 262144 : nEdges = nEdges + 1
next i
startIndex = nVertices + 1
n = startIndex + nVertices - 1
for i = startIndex to n
	if i < n then j = i + 1 else j = startIndex
	edge i, j, -1, -1, 262144 : nEdges = nEdges + 1
next i
for i = startIndex to n
	edge i - nVertices, i, -1, -1, 262144 : nEdges = nEdges + 1
next i
for i = 1 to nVertices
	put i
next i
material shapeSurface
pgon nVertices, 0, 2, get(nsp)
startIndex = 1
n = nVertices
for i = 1 to nVertices
	if i < n then j = i else j = 0
	pgon 4, 0, 2, i, nEdges - nVertices + 1 + j, -(nVertices + i), -(nEdges - nVertices + i)
next i
startIndex = nVertices + 1
n = startIndex + nVertices - 1
for i = n to startIndex step -1
	put -i
next i
pgon nVertices, 0, 2, get(nsp)

body -1

[Piotr Dobrowolski]

Whenever I need to make low level model to be "some" parametric: meaning moving the vertices and so on, I have to make vectors to 0 and then body -1. It does not solve all the issues...if the model is complicated then moving some vertex may lead to model unsolvable.

From my observation "0" vectors do not slow down model at least in noticeable amount...ofc it would depend how complicated model is.

BTW sometimes it is a need to make "0" vectors: whenever having "bad" model from other formats loaded - ie. when the model has reverted normals.

Piotr

[runxel]

In my experience it makes no sense to use it. I never define normals. Edges can be set to auto (-1) as well. Never had issues with that.

I'm not sure if its a bug, but the normals make nearly no difference with "usual" objects anyway. Only when it comes to concave shapes it might make a slight difference, but it does not the other way around.

What I mean is: If the polygon edges are wronlgy defined* I was never able to correct it just by changing the normal direction, which makes them pretty useless for most cases.

*) Polygon edges always need to go CCW when viewed from outside (= for a simple box the floor plate will be defined as CW when looking from the floor plan – sometimes this can be deceiving. You really need to turn and rotate it in your head ;))

In theory – and the manual says so – you could define the correct normal and everything would be good, even when the polygon is defined inside-out. However for me it turned out not to be true at all.