Ontem, estava "soldando" umas linhas com a minha rotina MJ4 quando derepente ela me falha!! putz, fiquei cabreiro, afinal havia testando ela de todas as formas que eu pude imaginar!!! Curioso, foi tentar descobrir o que estava acontecendo...
mais...
Pra minha surpresa, tudo parecia estar em ordem, mas simplesmente não funcionava, não emendava as polilinhas.. pensei: deve ter erro no programa... mais ou menos...
Fiz o de praxe teste o programa passo a passo e estava tudo certo, até que cheguei numa linha onde é requerida a coordenada do início da linha... e tava lá: retornava uma coordenada que não tinha nada a ver com a coordenada que era esperada!!!
Corri ver a ELIST da polilinha (era uma lwpolyline) e estranho, os dxf 10 eram diferentes mesmo... e no final da ELIST tinha o mais que ignorado dxf 210 percebi que eram valores diferentes do usual: (210 0.0 0.0 1.0) e estava ali o problema!!! quando selecionei a entidade e tentei um stretch o UCS mudou totalmente, então fui ver o que o help me dizia: ele dizia que o dxf 10 das LWPOLYLINE são dados em OCS (object coordinate system)
então: eu estava comparando coordenadas de sistemas diferentes, WCS e OCS
para transformar de OCS para WCS é simples, basta usar a função trans:
(trans pt ent 0)
Onde PT é a coordenada, ENT é a ENAME da entidade (isso mesmo, ename) e 0 significa que estou convertendo para WCS
mas importante: no caso de LWPOLYLINE, o dxf 10 é 2d!! é preciso incluir o Z na coordenada, que é o DXF 38 (elevation)
Vejam um exemplo:
isso TEM que retornar T (true)
Bom, agora o MJ4 está totalmente funcional (espero...) a rotina que foi atualizada é o get-points-polig
Obs:
Quem estiver usando alguma das minhas rotinas que dela dependam, é só substituir esta última
mais uma coisa: façam o teste: desenhe uma LINE por 0,0,0 e 10,10,10, agora use o comando PEDIT nesta line, responda Yes quando ele perguntar sé é pra converter em PLINE. Em seguida obtenham o ELIST da pline criada... vejam que os dxf 10 não são 0,0,0 10,10,10 e o dxf 210 é diferente do 0,0,1 normal
Fiz o de praxe teste o programa passo a passo e estava tudo certo, até que cheguei numa linha onde é requerida a coordenada do início da linha... e tava lá: retornava uma coordenada que não tinha nada a ver com a coordenada que era esperada!!!
Corri ver a ELIST da polilinha (era uma lwpolyline) e estranho, os dxf 10 eram diferentes mesmo... e no final da ELIST tinha o mais que ignorado dxf 210 percebi que eram valores diferentes do usual: (210 0.0 0.0 1.0) e estava ali o problema!!! quando selecionei a entidade e tentei um stretch o UCS mudou totalmente, então fui ver o que o help me dizia: ele dizia que o dxf 10 das LWPOLYLINE são dados em OCS (object coordinate system)
então: eu estava comparando coordenadas de sistemas diferentes, WCS e OCS
para transformar de OCS para WCS é simples, basta usar a função trans:
(trans pt ent 0)
Onde PT é a coordenada, ENT é a ENAME da entidade (isso mesmo, ename) e 0 significa que estou convertendo para WCS
mas importante: no caso de LWPOLYLINE, o dxf 10 é 2d!! é preciso incluir o Z na coordenada, que é o DXF 38 (elevation)
Vejam um exemplo:
(setq ss (ssget ":S" '((0 . "LWPOLYLINE"))) ;selecione a pline
ent (ssname ss 0);pega a ename da pline
elev (dxf 38 ent);elevação
pt (dxf 10 ent));primeiro vertice em OCS
(equal ;os pontos obtidos abaixo são iguais?
(trans (append pt (list elev)) ent 0) ;coverte OCS pra WCS
(vlax-curve-getstartpoint ent))
isso TEM que retornar T (true)
Bom, agora o MJ4 está totalmente funcional (espero...) a rotina que foi atualizada é o get-points-polig
Obs:
Quem estiver usando alguma das minhas rotinas que dela dependam, é só substituir esta última
mais uma coisa: façam o teste: desenhe uma LINE por 0,0,0 e 10,10,10, agora use o comando PEDIT nesta line, responda Yes quando ele perguntar sé é pra converter em PLINE. Em seguida obtenham o ELIST da pline criada... vejam que os dxf 10 não são 0,0,0 10,10,10 e o dxf 210 é diferente do 0,0,1 normal
Nenhum comentário:
Postar um comentário