Fragen zu: PRISM_C, SECT_FILL

Schlagworte:
  • 2013

Hallo Jörg!

Ich habe folgende Probleme:

1. PRISM_C
Wird ein Prisma mit PRISM_C inkl. Materialangaben innerhalb einer Gruppendefinition (GROUP) erzeugt und danach mit GROUP_PLACE abgesetzt, werden die Materialangaben zu PRISM_C ignoriert. Außerhalb einer Gruppe funktioniert der Befehl PRISM_C korrekt.
Edit: Anscheinend wird nur "top_material" unterstützt, "bottom_material" und "side_material" werden ignoriert.

Ist das beabsichtigt oder ist das eine Fehler in Allplan?

2. SECT_FILL
Ich nehme an mit "sectional surfaces" in der Dokumentation zu SECT_FILL, sind die Schnittflächen einer Schnittoperation gemeint. In meinen Versuchen mit CUTPLANE und GROUP_DIFF hatte ich aber keinen Erfolg die Darstellung einer Schnittfläche zu beeinflussen. Weder mit dem Index einer Füllfarbe (SECT_FILL 1) noch mit deren Name (SECT_FILL "midblue").

Wie bekomme ich nun anders gefärbte Schnittflächen?

3. CUTSHAPE

- CUTSHAPE 0 funkioniert nicht, löscht das gesamte Objekt.
- In der Dokumentation zu CUTSHAPE wurde U- und L-shaped vertauscht, L-shaped if d < 0, U-Shaped if d > 0

Danke für deine Hilfe!

Gruß
Manfred

Anhänge (1)

Typ: application/octet-stream
1738-mal heruntergeladen
Größe: 7,84 KiB

zu 2.
SECt_fILL setzt eine füllfläche für die Schnitterzeugung in Allplan.
OHNE Sect_Fill wird nur die hülle (3D-Körper) als linien in einem Schnitt angzeigt
MIT Sect_Fill wird die schnittfläche (Architekturschnitt oder Assoziativer Schnitt) gefüllt erzeugt.
gruß

Namenlos gezeichnet in vollem Bewusstsein - ignorant, in eigen Augen vermutlich höflich, dennoch unhöflichst, unfreundlichst wer einen/viele vermutete - sich von alters erschließende Namen nennt.
[b]

Hallo Manfred,

zu 1.
Leider kann in Allplan ein Körper nur immer ein Material(Oberfläche) haben. Unterschiedliche Oberflächen für Deck- und Bodenfläche sind also systembedingt nicht möglich.
In der Syntax-Hilfe ist das aber ausdrücklich vermerkt (syntax_help.png)

zu 2.
Wie schon Markus Phillipp bemerkt hat, werden die mit SECT_FILL gesetzten Flächen-Eigenschaften nur auf Schnittflächen appliziert, wenn man einen Architekturschnitt oder einen assoziativen Schnitt in Allplan erzeugt. Bei CUTPLANE wirkt SECT_FILL nicht. (Wie schon unter 1. beschrieben, kann ein Körper in Allplan nur immer genau EINE Oberfläche haben! Eingefärbte Schnittflächen sind deshalb leider nicht möglich!)

zu 3.
Das Verhalten bei CUTSHAPE 0 ist in der Tat ein Fehler.
In Deinem Script wäre allerdings das Löschen des gesamten Körpers korrekt, da dieser komplett
über der XY-ebene liegt, und damit entfernt würde. Erst

CUTSHAPE 0
TRANS -0.5,-0.5,-0.5
BOX ref_x, ref_y, ref_z
CUTEND

würde hier ein Fehlverhalten offenbaren...

Dafür kann/sollte man aber auch sinnfälligerweise CUTPLANE benutzen!
In der Dokumentation ist in der Tat L- und U-Shaped vertauscht. Danke für den Hinweis...

Gruß Jörg

Anhänge (1)

Typ: image/png
398-mal heruntergeladen
Größe: 57,99 KiB

Danke für die raschen Antworten, nochmal zu 1: Warum wird das Oberflächenmaterial von PRISM_C innerhalb von GROUP nicht verwendet?

Gruß
Manfred

Hallo,

auch das hat seine Ursache in der Beschränkung von Allplan, für einen Körper nur EINE Oberfläche verwenden zu können. Wenn man zwei Körper mit unterschiedlichen Oberflächen vereinigt (GROUP_UNION), müßte sonst EIN Körper mit ZWEI Oberflächen entstehen! Das ist nicht möglich!
Die Oberfläche, die mit der Direktive
MATERIAL "alu"
bestimmt wird, wird dem Ergebnis der GROUP-Operation zugeordnet, wenn dieses plaziert (GROUP_PLACE) wird.

Gruß Jörg

Hallo!

Die Materialzuweisung mit PRISM_C innerhalb einer Gruppe hat keine Auswirkung.

Nur 1 Körper - kein GROUP_UNION oder ähnliches ist beteiligt.

Wird PRISM_C ein MATERIAL in der Gruppe vorangestellt, funktioniert die Materialzuweisung auch innerhalb der Gruppe, aber dadurch ist PRISM_C = PRISM_.

siehe Beispiel uns ausfühlicher im Anhang.

DEFINE MATERIAL "orange" 7 , 1.000 , 0.667 , 0 
!!! PRISM_C innerhalb GROUP - Material hat keine Auswirkung
GROUP "orange_block" 
PRISM_C "orange" , "ignored" , "ignored" , 
!!! n wird ignoriert - find ich gut, erspart das Zählen bei komplexen Formen!
0 , REF_Z, 
0 , 0 , 0 , 
REF_X , 0 , 0 , 
REF_X , REF_Y , 0 , 
0 , REF_Y , 0 
GROUP_END 
!!! Block hat aktuelle Farbe und nicht "orange"
GROUP_PLACE "orange_block" 

Gruß
Manfred

Anhänge (1)

Typ: application/octet-stream
1626-mal heruntergeladen
Größe: 6,35 KiB

Hallo,

meiner Antwort ist nichts hinzuzufügen.
Es wird die Oberfläche verwendet, welche bei GROUP_PLACE aktiv ist.
Eine Material-Zuweisung innerhalb eines Befehls (z.B. PRISM_C) wird innerhal einer Gruppe ignoriert.
Und:
Diese Materialzuweisung innerhalb eines Befehls (auch ausserhalb einer Gruppe) wirkt nicht auf andere Körper, und ist keine Direktive! Das Material ist explicit mit
MATERIAL "orange"
zu setzen...

Hinweis:
"n" muss vorhanden sein (darf nicht auskommentiert sein), und wird nur bei bestimmten PRISM_-Befehlen nicht ausgewertet!

Gruß Jörg

Jetzt habe ich es verstanden!

Danke für deine Geduld!

Gruß
Manfred

EDIT: Da ich die Dokumentation nicht genau genug lese, habe ich nochmal nachgesehen.
Diese Anmerkung zum Befehl GROUP ist doch etwas verwirrend:
Attribute DEFINEs and SETs (pens, materials, fills) before group definitions as well as within group definitions are all effective.