Nested solid geometry operations ?

[Anonymous]

Hello,
A shape is made from several GDL commands such as PRISM_ that have been made to act on each other using solid geometry commands.

Is it possible to then use this "assembly" by declaring it as new GROUP
and use it to act on another GROUP in a solid geometry operation ?

Another way of saying it. Is it possible to declare a GROUP made up
of a collection of GROUPS that interact in solid geometry operations and
then use this new "super GROUP" in other solid geometry operations ?

Thank you,
Peter Devlin

[Anonymous]

Yes it is.

Just be aware if you use several commands into a same group, to separe them with a BODY -1 statement.

[Anonymous]

Olivier,
Thank you for your reply.
It is good to know that" super groups" are possible.

You have actually found that body -1 is necessary ?

We have all noticed that auto-scripted objects contain body -1 statements.
When I have deleted them it doesn't seem to affect anything.

The manual says "If the status value is negative, the engine will calculate
the status of the body". It is unclear to me what the term "status" means.

Body -1, it would seem, directs the engine to calculate the status in terms
of some default values. I very rarely use this statement and the engine
seems to make objects the way I want them so the default values are
what one would want in the majority of cases.

What happens when commands are not bracketed with body -1 statements
in scripts containing solid geometry operations ?

Thank you,
Peter Devlin

[Anonymous]

Peter wrote:
We have all noticed that auto-scripted objects contain body -1 statements.
When I have deleted them it doesn't seem to affect anything.

Hi Peter, i just follow the manual and the GDL technical standards.
"Modelling transparent bodies : Use the body -1 command between solid and transparent parts of an object
to make correct shadow casting with Internal Rendering Engine (e.g., window sash with grilles)".

Peter wrote:
The manual says "If the status value is negative, the engine will calculate
the status of the body". It is unclear to me what the term "status" means.

IMHO, this applies to scripts using primitives (vert, edges, pgon...). This is a particular situation.
If you don't declare the indexes of adjacent polygons for edge definition (pgon 1 = -1, pgon 2 = -1),
AC calculates them itself, and this can be very time consuming, even with fast processors. (cf StairMaker)
At the end of such a script, you have to specify the status of body (1, 2, 4...) or negative, according
to the previous definitions of edge and pgon.

Peter wrote:
Body -1, it would seem, directs the engine to calculate the status in terms
of some default values. I very rarely use this statement and the engine
seems to make objects the way I want them so the default values are
what one would want in the majority of cases.

"In general, separate bodies which require different texture coordinate systems with a body -1 command."
For scripted solid operations, i noticed some minor unexpected results when i don't use this statement,
to separate several commands into a same group. So i think the manual is right, and i do so.

Peter wrote:
What happens when commands are not bracketed with body -1 statements
in scripts containing solid geometry operations ?

In general nothing important, except for the previous examples (transparency and texture mapping).
If someone has different experiment or more info, he is welcome.

[Anonymous]

Olivier,
Thank you for your very careful and informative reply.

You have explained some things that have puzzled me,
like why the first statement in the manual concerning body -1
says "Composes a body defined with the above primitives".
The "above primitives" are COOR parameters, texture mapping!

I will, of course, use body -1 as you advise in the contexts you mention.
Thank you again,
Peter Devlin