hc_proto.h
Macro Definitions
Functions
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
double |
|
double |
|
void |
|
void |
|
void |
|
void |
|
double |
|
double |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
int |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
double |
|
double |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
intptr_t |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
int |
|
int |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
bool |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
int |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
int |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
int |
|
int |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
Key |
|
bool |
|
bool |
|
Key |
|
bool |
|
bool |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
Key |
|
Key |
|
void |
|
void |
|
float |
|
double |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
void |
|
void |
|
int |
|
int |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
void |
|
bool |
|
bool |
|
void |
|
bool |
|
void |
|
bool |
|
void |
|
Key |
|
Key |
|
double |
|
double |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
bool |
|
Key |
|
Key |
|
void |
|
bool |
|
void |
|
bool |
|
void |
|
bool |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
int |
|
Key |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
long |
|
long |
|
void |
|
long |
|
int |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
int |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
bool |
|
void |
|
void |
|
Key |
|
Key |
|
Key |
|
void |
|
Key |
|
Key |
|
Key |
|
Key |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
bool |
|
void |
|
void |
|
Key |
|
int |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
bool |
|
bool |
|
int |
|
int |
|
int |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
int |
|
int |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
bool |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
Key |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
void |
|
Key |
|
Key |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
Key |
|
void |
|
void |
|
void |
|
Key |
|
void |
|
Key |
|
void |
|
Key |
|
void |
|
bool |
|
bool |
|
void |
|
Key |
|
Key |
|
void |
|
intptr_t |
|
void |
|
bool |
|
bool |
|
void |
|
void |
|
Key |
Detailed Description
Macro Definition
-
HC_PROTO_DEFINED
Function Documentation
-
void HC_Abort_Program(char const *message)
Function to create a map linking PrcIds and A3DEntities.
Prints an error message. Calls the defined exit handlers. Exits to the operating system with a final error status.
Provides an orderly way to terminate execution upon the discovery of an error.
- DETAILS
A standard HOOPS fatal error sequence is initiated. First, the currently defined error handlers are called. The list presented includes Report_Error() (unless you’ve specified otherwise), which causes message to be printed out where the user can see it. Then, the currently defined exit handlers are called, usually including Reset_System() . Finally, the operating system is called, with an “error” exit status, to terminate program execution.
See also
HC_Exit_Program, HC_Define_Exit_Handler, HC_Define_Error_Handler, HC_Report_Error
- Parameters:
message – A quoted string, or a string variable containing your error message. An empty string is permissible.
-
void HC_Append_Modelling_Matrix(float const array[])
Allows direct manipulation of the matrix transform applied against all picture elements and subsegments in a segment.
Appends the explicitly provided transformation to the cumulative modelling transform of the currently open segment, or to the named segment(s). The visual effect is that of the scene as it was, then this change. (The old array is multiplied on the left by this new array.)
- DETAILS
Use this routine only if your program organizes and keeps track of the net transformations applied to your objects.
The array should be stored so the column varies faster than the row as you proceed through consecutive memory locations. In C and Pascal, the first index of the array is usually the row index and the second index is the column.
- NOTES
If there was no previous transform, this operation becomes a plain Set_Modelling_Matrix().
The first, second, and third rows of the fourth column of array must be zero - no “perspective” transformation is allowed. The fourth row of the fourth column is usually 1.0 (it must not be zero.)
See also
HC_Set_Modelling_Matrix, HC_Rotate_Object, HC_Translate_Object, HC_Scale_Object, HC_Set_Camera, HC_Orbit_Camera.
- RESTRICTIONS
- Parameters:
array – Transform matrix provided by the user. Passed by reference in all languages. May need to be transposed in languages other than C.
-
void HC_DAppend_Modelling_Matrix(double const array[])
Similar to Append_Modelling_Matrix(), but accepts double-precision data.
See also
HC_Append_Modelling_Matrix
- Parameters:
array – Transform matrix provided by the user. Passed by reference in all languages. May need to be transposed in languages other than C.
-
void HC_Append_Texture_Matrix(float const array[])
Allows direct manipulation of the matrix transform applied against all shell and mesh (u, v, w) vertex parameters and subsegments in a segment.
Appends the explicitly provided transformation to the cumulative texture transform of the currently open segment, or to the named segment(s). The visual effect is that of the scene as it was, then this change. (The old array is multiplied on the left by the new array.)
- DETAILS
Use this routine if your program organizes and keeps track of the net transformations applied to your vertex parameters.
The array should be stored so the column varies faster than the row as you proceed through consecutive memory locations. In C and Pascal, the first index of the array is usually the row index and the second index is the column.
- NOTES
If there was no previous transform, this operation becomes a plain Set_Texture_Matrix() .
The fourth row of the fourth column is usually 1.0 (it must not be zero.)
See also
HC_Set_Texture_Matrix, HC_Rotate_Texture, HC_Translate_Texture, HC_Scale_Texture.
- RESTRICTIONS
- Parameters:
array – Transform matrix provided by the user. Passed by reference always. May need to be transposed in languages other than C.
-
void HC_Begin_Alias_Search(void)
These routines recall the name of each alias.
This set of routines allows the user to “dump” all the aliases that exist in the database. It returns both the user defined aliases and those defined by the system (e.g.: “?include library”). It returns only the aliases names - to find out what their expansions are use Show_Alias(). For example:
- DETAILS
Begin_Alias_Search () while (Find_Alias (alias)) { Show_Alias (alias, def) print (alias, def) } End_Alias_Search ()
prints all the known aliases names and their definitions. Begin_Alias_Search() initiates the search for each alias name.
Show_Alias_Count() finds out how many aliases will be returned. This is useful for determining the size of a data structure needed to store incoming items.
Find_Alias() retrieves the alias names, one at a time. The function returns false when all aliases have been returned.
End_Alias_Search() terminates the sequence and frees any involved memory.
If an alias search is in progress and an alias becomes undefined (via UnDefine_Alias() ), it will not be returned by subsequent calls to Find_Alias(). If an alias is added, it will not be returned until the next alias search begins.
- NOTES
Show_Alias_Count() is only valid between Begin_Alias_Search() and End_Alias_Search(). It will always return the total number of aliases defined not the remaining number of aliases.
Alias searches can be nested. A user program can call Begin_Alias_Search() and look at the defined aliases without interfering with an alias search, which might have been activated by another portion of the program. When End_Alias_Search() is called, the previously active alias search (if any) becomes current.
See also
HC_Show_Alias, HC_Define_Alias, HC_Show_Pathname_Expansion
- RESTRICTIONS
-
void HC_Begin_Callback_Name_Search(void)
Finds the names of all previously defined callback routines.
These routines are used to find all the callback name definitions existing within the database. For example,
- DETAILS
Begin_Callback_Name_Search () while (Find_Callback_Name (name)) print (name) End_Callback_Name_Search ()
prints all the known callback definitions. Begin_Callback_Name_Search() initiates the search for callback name definitions. If you need to know how many callback definitions will be returned (possibly to allocate a sufficiently large data structure to hold the results), call Show_Callback_Name_Count() after initiating the search.
Find_Callback_Name() returns the names, one by one. This function returns false when all the definitions have been returned.
End_Callback_Name_Search() terminates the search. This last step can be done anytime after initiating the search.
If a callback search is in progress and a callback becomes undefined (via UnDefine_Callback_Name() ), it will not be returned by subsequent calls to Find_Callback_Name() . If a callback definition is added, it will not be returned until the next callback search is initiated.
- NOTES
Show_Callback_Name_Count() is only valid between Begin_Callback_Name_Search() and End_Callback_Name_Search() . It will always return the total number of callback names, not the remaining number of definitions.
Callback name searches can be nested. A user program can call Begin_Callback_Name_Search() and look at the defined callbacks without interfering with a callback search, which might be in progress. When End_Callback_Name_Search() is called, the previously active callback search is resumed.
See also
HC_Define_Callback_Name, HC_Show_Callback_Name.
-
void HC_Begin_Color_Name_Search(void)
These routines recall all the defined color names.
These routines are used to find all the color definitions in the database. For example,
- DETAILS
Begin_Color_Name_Search () while (Find_Color_Name (first, second, third) print (first, second, third) End_Color_Name_Search ()
prints all the known names, in the style in which they were originally defined. Begin_Color_Name_Search() initiates the search for color names.
If you need to know how many color definitions will be returned (possibly for allocating a data structure to hold them) call Show_Color_Name_Count() after initiating the search.
Find_Color_Name() returns the names (one set at a time). The function returns false when all color names have been returned.
End_Color_Name_Search() terminates the process and frees any involved memory. This last step can be done any time after the initial call to Begin_Color_Name_Search().
If you want to examine the color name definitions, call Parse_String() (to take out the commas) on the results of Find_Color_Name(). Then call Show_Color_Name() on each name.
- NOTES
After calling Begin_Color_Name_Search(), if a color becomes undefined (via UnDefine_Color_Name() ), subsequent calls to Find_Color_Name() will not return it. If a color is redefined, the new definition will be returned. If a new color is defined, it will not be returned in this search sequence.
Show_Color_Name_Count() is only valid between Begin_Color_Name_Search() and End_Color_Name_Search() . It will always return the total number of colors defined, not the remaining number of color definitions.
Color name searches can be nested. A user program can call Begin_Color_Name_Search() and look at the defined color names without interfering with a color name search, which might have been activated by another portion of the program. When End_Color_Name_Search() is called, the previously active color name search (if any) becomes current.
See also
HC_Define_Color_Name, HC_Show_Color_Name, HC_Parse_String
-
void HC_Begin_Contents_Search(char const *segment, char const *filter)
These routines are used to “dump” the contents of a segment or certain types of geometry.
Many user applications must manipulate the geometry in the database to perform some type of analysis. For example, if a program needs to calculate the areas of all polygons in a segment, it would need to know the coordinates of the points in each polygon. A contents search (specifically, Find_Contents()) can be used to retrieve the keys of all of the polygons, and then Show_Polygon() can be used to extract the points.
- DETAILS
In a contents search, Begin_Contents_Search() initiates and defines the search. Only the types specified in filter are used in the search, and only the segment or geometry specified in segment are checked.
Show_Contents_Count() determines the number of entities returned. This is useful for determining the size of a data structure needed to store the incoming items.
Find_Contents() returns entities, one at a time, from the selected segment or geometry. Find_Contents returns a type (i.e. “window frame”) and, if appropriate, a key. (Geometry, segments, includes, and styles have keys. Attributes do not have keys.) The return value is false when all items have been returned.
End_Contents_Search() terminates the search sequence.
As with the other search routines, Begin_Contents_Search() operations can be nested. This feature can be used, for example, to “walk the tree” as sub-segments are encountered. A call to End_Contents_Search() terminates the current search context (segment specification and filter) and reactivates the previously active context (if any).
The segment parameter can take a number of valid location specifications including aliases, wildcards, and paths, as explained in the HOOPS/3dGS Programming Guide section on segment name syntax (see Fundamentals > Database Structure). The following are examples of valid usage:
“.” Searches the currently open segment.
“..” Searches the parent of the currently open segment.
“…” Searches the currently open segment and its child segments.
“….” Searches the currently open segment, its children, and any include segments below the current segment.
“?picture/model” Searches the segment “model”.
“?picture/model/…” searches the segment named ‘model’ and all of its subsegments.
“?picture/model/….” Searches the segment named ‘model’, all of its children, and any include segments below ‘model’.
“/…/model*” Searches all segments in the entire tree starting with ‘model’, but not their subsegments.
Geometry that can be inserted such as “images, lights, lines, markers, meshes, polygons, polylines, shells, string cursors, text”.
One of the attributes that can be set such as “color”, “marker size”, “color map”, “streaming mode”, etc. Attribute filters may be refined by adding sub-options to the string, such as “color=(lines)”, “user options = cost” or “visibility=faces”.
The word “geometry” matches all types of geometry.
The word “attributes” matches all attributes.
The word “style” matches style references.
The types “segment” and “include” match, respectively, child segments and “include references” to segments.
The word “subsegment” matches “segment” and “include”.
The word “inked line” selects the “currently being inked in” polyline (if any).
The word “ordered” returns only geometry brought to the front by Bring_To_Front() . The items are returned in drawing order. Successively returned items are drawn on top of previously returned items when the scene is updated.
The word “everything”, matches all types.
The word “self”, matches the subsegments themselves in a recursive search. This differs from the “subsegment” keyword in that it returns the parent instead of the children.
Any of the above types with “no” in front of them. For example: “everything, no geometry, no windows, no color maps” selects all types except windows, color maps, and all types of geometry. If specifications overlap (as in “geometry, no lines”), the last specification wins.
The word “hardware resources” matches display lists, textures, and vertex arrays that exist on the video card’s cache.
The word “follow references” means the search will dig through references as part of the search. Without it, you’d have to search for references explicitly, find what they’re pointing at and do a new search there.
Additional types accepted by this function are:
“distant light”, “local light”, “spot light”, “area light”, “includer”, “styler”, “style”, “color”, “callback”, “camera”, “clip
region”, “handedness”, “selectability”, “visibility”, “window”, “window frame”, “color map”, “driver”, “driver options”, “edge
pattern”, “edge weight”, “face pattern”, “heuristics”, “line pattern”, “line weight”, “marker size”, “marker symbol”, “metafile”, “modelling matrix”, “rendering options”, “text alignment”, “text font”, “text leader”, “text path”, “text spacing”, “texture matrix”, “user value”, “window pattern”, “texture definition”, “local texture”, “glyph definition”, “line pattern
definition”, “line style definition”, “condition”, “streaming mode”, “circle”, “circular arc”, “circular chord”, “circular
wedge”, “cutting plane”, “cutting section”, “light”, “ellipse”, “elliptical arc”, “grid”, “line”, “marker”, “mesh”, “image”, “pixel array”, “polyline”, “polygon”, “shell”, “string cursor”, “text”, “nurbs curve”, “nurbs surface”, “cylinder”, “polycylinder”, “sphere”, “include”, “reference geometry”, “user options”
The following code example sums the areas of all polygons in all segments that contain the word “plate”. It assumes the existence of a user written function that returns the area of a polygon given its key.
sum = 0.0 Begin_Contents_Search("/...*plate*", "polygons") while (Find_Contents (type, poly)) sum = sum + polygon_area(poly) End_Contents_Search()
The “type” variable in this example will always be given the value “polygon”.
The segment name passed to Begin_Contents_Search() can contain wildcards, a list of segments or both. In this case, subsequent calls to Find_Contents() do not distinguish which segment contains each object. Use Show_Owner_By_Key() to determine this. Also, when multiple segments are specified, the type “ordered” does not distinguish which objects in the segments will be drawn first.
The returned types are entirely lowercase and singular, for example: “line”, “selectability”, “polygon”. Normally, you would look at the type and make other calls ( Show_Visibility() , Show_Polyline() , etc.) to get more details about the object whose key was returned.
If an object satisfying the target specification is deleted while a segment search is in progress, it will not be returned by Find_Contents() . If a segment is renamed, the new name will be returned. If geometry is moved to a new segment, its key will be returned even if the new segment name no longer matches the original search specification. If an object is created after a call to Begin_Contents_Search(), it will not be returned in the current sequence of Find_Contents() calls.
- NOTES
Show_Contents_Count() is only valid between Begin_Contents_Search() and End_Contents_Search(). It will always return the total number of items not the remaining number of items.
The inked line returned from a streaming segment will contain only the portion added since the last “Set” command changed any attribute in that segment.
When “hardware resources” are found by Begin_Contents_Search, Find_Contents always returns -1. In other words, hardware resources have no keys associated with them. Shells and meshes can be opened and have their hardware resources flushed, but all other types of geometry (e.g. lines, polylines polycylinders and images) must have their hardware resources flushed from either their owning segment or some segment above.
See also
HC_Begin_Segment_Search, HC_Show_Existence, HC_Show_Key_Type, HC_Show_Segment, HC_Show_Owner, HC_Show_Polyline, HC_Show_Shell, HC_Show_Marker.
- Parameters:
segment – A string specifying the location(s) of the search.
filter – List of the types of objects you’re interested in.
-
void HC_Begin_Font_Search(char const *display, char const *filter)
Finds the names of all the fonts available on a particular device.
Begin_Font_Search() initiates and defines the search. Only the types specified in filter are searched for.
- DETAILS
A font search allows you to find out what fonts are available on a given display.
Show_Font_Count() determines the number of font names returned. This is useful for determining the size of a data structure needed to store the incoming items.
Find_Font() returns names, one at a time, from the selected display. The return value becomes false when all items have been returned.
End_Font_Search() terminates the search sequence. As with the other search routines, the Begin_Font_Search() operations can be nested.
The following choices are available for filter:
“Generic” tells you which of the generic font names (see Set_Text_Font() ) are available - in at least one size.
“Specific” tells you which individual fonts are available, with the names coming back in the style of the local system (for example, the operating system).
“Defined” tells you which user defined fonts are available, with the names coming back in the previously defined form.
“Family” or “families” tells you which name the system, or HOOPS, has picked to refer to the available sizes of a single typeface.
Any combination of choices can be given. Separate by commas. Uppercase versus lowercase is not important.
If you need more than the name of a font, call Show_Font_Info() to get additional details.
A simple coding example is:
Begin_Font_Search ("?Picture", "generic") while (Find_Font (name)) print ("Yes,?Picture has: ", name) End_Font_Search ()
If the device is not operating, Begin_Font_Search() might force a call to Update_Display() to get it started. See the note at the bottom of Show_Device_Info() for more information.
- NOTES
Show_Font_Count() is only valid between Begin_Font_Search() and End_Font_Search(). It will always return the total number of items, not the remaining number of items.
See also
HC_Define_Font, HC_Show_Font, HC_Show_Font_Info, HC_Set_Text_Font, HC_Show_Device_Info.
- Parameters:
display – Name of the segment connected to the display of interest. Often “?Picture” or “?Hardcopy”.
filter – A list of restrictions on the fonts of interest.
-
void HC_Begin_Glyph_Search(void)
These routines recall all the defined glyph names.
These routines are used to find all of the glyph definitions that exist in the database. For example,
- DETAILS
Begin_Glyph_Search () while (Find_Glyph (the_name)) Show_Glyph(the_name, definition) End_Glyph_Search ()
retrieves all the known names, in the style in which they were originally defined. If you need to know how many glyph definitions will be returned (possibly for allocating a data structure to hold them) call Show_Glyph_Count() after initiating the search.
Find_Glyph() returns the names (one at a time). The function returns false when all glyph names have been returned.
End_Glyph_Search() terminates the process and frees any involved memory. This last step can be done any time after the initial call to Begin_Glyph_Search().
After calling Begin_Glyph_Search(), if a glyph becomes undefined (via UnDefine_Glyph()), subsequent calls to Find_Glyph() will not return it. If a glyph is redefined, the new definition will be returned. If a new glyph is defined, it will not be returned in this search sequence.
- NOTES
If you want to examine the glyph name definitions, call Show_Glyph() on the results of Find_Glyph() .
Show_Glyph_Count() is only valid between Begin_Glyph_Search() and End_Glyph_Search(). It will always return the total number of glyphs defined as opposed to the remaining number of glyph definitions.
Glyph name searches can be nested. A user program can call Begin_Glyph_Search() and look at the defined glyph names without interfering with a glyph name search that might already have been activated by another portion of the program. When End_Glyph_Search() is called, the previously active glyph name search (if any) becomes current.
See also
HC_Define_Glyph, HC_Show_Glyph, HC_Parse_String
-
void HC_Begin_Line_Style_Search(void)
These routines recall all the defined line style names.
These routines are used to find all of the line style definitions that exist in the database. For example,
Begin_Line_Style_Search () while (Find_Line_Style (the_name)) Show_Line_Style(the_name, definition) End_Line_Style_Search ()
- DETAILS
retrieves all the known names, in the style in which they were originally defined. If you need to know how many line style definitions will be returned (possibly for allocating a data structure to hold them) call Show_Line_Style_Count() after initiating the search.
Find_Line_Style() returns the names (one at a time). The function returns false when all line style names have been returned.
End_Line_Style_Search() terminates the process and frees any involved memory. This last step can be done any time after the initial call to Begin_Line_Style_Search().
If you want to examine the line style name definitions, call Show_Line_Style() on the results of Find_Line_Style() After calling Begin_Line_Style_Search() , if a line style becomes undefined (via UnDefine_Line_Style() ), subsequent calls to Find_Line_Style() will not return it. If a line style is redefined, the new definition will be returned. If a new line style is defined, it will not be returned in this search sequence.
- NOTES
Show_Line_Style_Count() is only valid between Begin_Line_Style_Search() and End_Line_Style_Search() . It will always return the total number of line styles defined as opposed to the remaining number of line style definitions.
Line_Style name searches can be nested. A user program can call Begin_Line_Style_Search() and look at the defined line style names without interfering with a line style name search that might already have been activated by another portion of the program. When End_Line_Style_Search() is called, the previously active line style name search (if any) becomes current.
See also
HC_Define_Line_Style, HC_Show_Line_Style, HC_Parse_String
-
void HC_Begin_Open_Segment_Search(void)
Returns the pathnames of all open segments.
These routines are used to indicate all the segments that have been opened but not closed. A call to Begin_Open_Segment_Search() initiates the process. Each call to Find_Open_Segment() returns the pathname of a single open segment starting with the currently open segment (the most recently opened segment) and ending with the least recently opened segment. End_Open_Segment_Search() terminates the sequence and allows another series of open segment searches to be initiated.
- DETAILS
Once Begin_Open_Segment_Search() is called, Show_Open_Segment_Count() can be used to return the total number of open segments. This routine is useful for sizing an array large enough to hold all the pathnames returned by a sequence of calls to Find_Open_Segment() .
Once Begin_Open_Segment_Search() is called, all currently open segments will be returned by Find_Open_Segment() even if they are closed in the meantime. However, if any open segments are closed and then deleted, they will not be returned. Any open segments that are renamed will be returned with the new name.
- NOTES
You can use these routines with no segments open. The first call to Find_Open_Segment() will just return false.
Show_Open_Segment_Count() is only valid between Begin_Open_Segment_Search() and End_Open_Segment_Search() . It will always return the total number of open segments, not the remaining number of open segments.
Open segment searches can be nested. A user program can call Begin_Open_Segment_Search() and look at the open segments without interfering with an open segment search, which might have been activated by another portion of the program. When End_Open_Segment_Search() is called, the previously active open segment search (if any) becomes current.
See also
HC_Begin_Contents_Search, HC_Begin_Segment_Search, HC_Open_Segment.
-
void HC_Begin_Segment_Search(char const *segspec)
Finds all segments matching a search specification.
Begin_Segment_Search() initiates the search by specifying where to start looking for segments.
- DETAILS
The segment search routines provide the ability to determine the current segment structure of the database.
Show_Segment_Count() lets a program anticipate how many segments names will be returned from a sequence of calls to Find_Segment() in order that sufficient space may be allocated to receive them. Count is the total number of matching segments.
Find_Segment() is the routine that returns, one at a time, the segments which matched the specification given in Begin_Segment_Search(). When all segments have been returned, its function value becomes false.
End_Segment_Search() terminates the search sequence and reactivates any previously active segment search.
The segspec parameter can take a number of valid segment name specifications including aliases, wildcards, and paths, as explained in the HOOPS/3dGS programming guide section 1.2.6 “Segment-Name Syntax”. Wildcards in the segment specification will typically match more than one segment in the database. The following examples are valid usages:
“*” Returns the currently open segment and all children, but no grandchildren.
“.” Returns the currently open segment.
“..” Returns the parent of the currently open segment.
“…” Returns the currently open segment, and all subsegments.
“….” Returns the currently open segment, all subsegments, and any include segments below the current segment.
“?picture/model” Returns the segment “model”.
“?picture/model/..” Returns “?picture”.
“?picture/model/…” Returns the segment named ‘model’ and all of its subsegments.
“?picture/model/….” Returns the segment named ‘model’, all of its children, and any include segments below ‘model’.
“/…/model*” Returns all segments in the entire tree starting with ‘model’, but not their subsegments.
“/…/model/….” Searches all segments in the entire tree named ‘model’, their children, and any include segments below them.
level = 0 print_children (segment) { Open_Segment (segment) Begin_Segment_Search ("*") while (Find_Segment (child)) { Parse_String (child, "/", -1, pathname) print (level, pathname) level = level + 1 print_children (pathname) level = level - 1 } End_Segment_Search () Close_Segment () }
This example could also have been written using the “contents search” routines, replacing “Begin_Segment_Search (“*”)” with “Begin_Contents_Search (“.”, “segments”)”, and so on.
If a search is in progress and a segment satisfying the target specification is deleted, it will not be returned by subsequent calls to Find_Segment() . If a segment is renamed, the new name will be returned. If a segment is created, it will not be returned in the current sequence of Find_Segment() calls.
- NOTES
If no segments are found that match the specification, the first call to Find_Segment() returns false.
Show_Segment_Count() must be called between Begin_Segment_Search() and End_Segment_Search() . It will always return the total* number of segments, not the remaining number of segments.
See also
HC_Begin_Contents_Search, HC_Begin_Open_Segment_Search, HC_Show_Existence, HC_Open_Segment.
- Parameters:
segspec – A specification, often including wildcards, of the segment(s) to be searched for. Passed by reference always
-
void HC_Begin_Shader_Search(char const *search)
These routines recall the name of each shader.
Begin_Shader_Search () while (Find_Shader (shader)) { Show_Shader (shader, def, source) print (shader, def, source) } End_Shader_Search ()
- DETAILS
This set of routines allows the user to “dump” all the shaders that exist in the database. It returns only the shader names. To find the details for each shader use Show_Shader(). For example:
…prints all the known shader names, their options and source. Begin_Shader_Search() initiates the search for each shader name.
Find_Shader() retrieves the shader names, one at a time. The function returns false when all shaders have been returned.
End_Shader_Search() terminates the sequence and frees any involved memory.
See also
HC_Show_Shader, HC_Define_Shader
- NOTES
If a shader search is in progress and an shader becomes undefined via UnDefine_Shader(), it will not be returned by subsequent calls to Find_Shader(). If a shader is added, it will not be returned until the next shader search is begun.
- Parameters:
search – A specification of which custom shader implementation to search for: either “legacy” or “modern”.
-
void HC_Begin_Shape_Search(void)
-
void HC_Begin_Texture_Search(void)
These routines recall all the defined texture names.
NOTES
These routines are used to find all of the texture definitions that exist in the database. For example:
Begin_Texture_Search () while (Find_Texture (the_name)) Show_Texture(the_name, definition) End_Texture_Search ()
…retrieves all the known names, in the style in which they were originally defined. If you need to know how many texture definitions will be returned (possibly for allocating a data structure to hold them) call Show_Texture_Count() after initiating the search.
Find_Texture() returns the names (one at a time). The function returns false when all texture names have been returned.
End_Texture_Search() terminates the process and frees any involved memory. This last step can be done any time after the initial call to Begin_Texture_Search().
If you want to examine the texture name definitions, call Show_Texture() on the results of Find_Texture().
After calling Begin_Texture_Search() , if a texture becomes undefined (via UnDefine_Texture() ), subsequent calls to Find_Texture() will not return it. If a texture is redefined, the new definition will be returned. If a new texture is defined, it will not be returned in this search sequence.
Show_Texture_Count() is only valid between Begin_Texture_Search() and End_Texture_Search(). It will always return the total number of textures defined as opposed to the remaining number of texture definitions.
Texture name searches can be nested. A user program can call Begin_Texture_Search() and look at the defined texture names without interfering with a texture name search that might already have been activated by another portion of the program. When End_Texture_Search() is called, the previously active texture name search (if any) becomes current.
See also
HC_Define_Texture, HC_Show_Texture, HC_Parse_String.
-
void HC_Begin_Local_Texture_Search(void)
Begins a texture search on the currently open segment.
Begin_Local_Texture_Search() is similar to Begin_Texture_Search() , but operates only on the currently open segment. To find all textures with this function, use the following method:
HC_Begin_Contents_Search("/...", "segments"); while (HC_Find_Contents(type, &segKey)) { HC_Open_Segment_By_Key(segKey); HC_Show_Segment (segKey, pathname); HC_Begin_Contents_Search (".", "attributes"); while (HC_Find_Contents(type, &tempKey)){ if (!strcmp (type, "texture definitions")) { HC_Begin_Local_Texture_Search(); HC_Show_Texture_Count(&texture_count); HC_Find_Texture (texture_name); } } } HC_End_Contents_Search();
- DETAILS
See also
HC_Begin_Texture_Search
- NOTES
This behaves in a very similar fashion to Begin_Texture_Search() except that it only looks for locally defined textures. Also, since local textures are connected to a segment you must provide a segment from which the search should begin.
-
void HC_Bring_To_Front(char const *segment)
- Deprecated:
This function has been deprecated. It is superseded by setting the hsra rendering option to priority.
If the subject of a call to Bring_To_Front() , specified either by key or by name, is a segment that has a Window attribute, then you’re effectively asking to rearrange windows. A windowed segment that lies within a windowed segment is always drawn “on top” of the containing window. But when windowed segments lie side-by-side in the segment tree - when neither window is the owner of the other - the situation becomes ambiguous. If such windows don’t overlap no problem arises. If they do overlap, Bring_To_Front() allows for making a choice. Set_Window() automatically calls Bring_To_Front() for each newly-created window, so the default is “newest in front.” You might make an explicit call when, for example, the user’s interest has shifted from one window to another. This is often indicated by some action such as touching a rear window. In summary, Bring_To_Front() can be used to specify the precedence of overlapping sibling windows.
- DETAILS
This function forces a particular drawing order onto a collection of geometric primitives. Since it does not change depth values, however, it has only minor effects on scenes with hidden surface removal algorithms (e.g. z-buffer, the default).
If, on the other hand, the subject of a call to Bring_To_Front() is something other than a windowed segment - if it’s geometry or a non-windowed segment - then you’re forcing a particular drawing order onto the system. You would do this if you want to manually describe what’s to have the appearance of being in front. Forcing a drawing order is sometimes more efficient than using the system’s hidden-surface algorithm. It might be suitable for a paint program in which the user selects precedence, or useful for putting “annotations” on a scene that is otherwise all hidden-surfaced. You should not use Bring_To_Front() if you don’t really care about the ordering. The system works more efficiently if it is permitted to order objects as it pleases.
Using Bring_To_Front() on 3-D geometry and nonwindowed segments only works within those segments where the “hidden surfaces” heuristic is not in effect. Hidden surfaces take priority over bring-to-front. So, to mix hidden-surface items and bring-to-front items in the same scene, do something like the following:
Open_Segment ("window") Set_Heuristics ("no hidden surfaces") Open_Segment ("A") Set_Heuristics ("hidden surfaces") // regular hidden-surface picture, as needed Close_Segment () Open_Segment ("B") Set_Heuristics ("hidden surfaces") // regular hidden-surface picture, as needed Close_Segment () // now make "A" completely in front of "B"... Bring_To_Front ("A") Close_Segment ()
Note that “A” or “B” could have elected to continue with “no hidden surfaces”. It might also make sense, depending on what “A” and “B” are, to turn off lighting visibility in one or the other. In addition, Bring_To_Front() can only be applied to siblings “A” versus “B.” Bring_To_Front() does not apply to parent-child relationships.
This function can help resolve situations that arise with z-buffering where two surfaces have identical depth values but it is known which is supposed to be on top. For example, highlighting can be done this way, by drawing an extra copy with different attributes. This, combined with Control_Update() can be a powerful technique to highlight and de-highlight subsets of shells without ever incurring full updates.
- NOTES
If the object of the bring-to-front is a non-windowed segment or an include reference, the effect is of bringing forward that collection of geometry as a whole.
Once something has been brought-to-front there is no simple way to put it back where it was. More objects can be put in front of the first, though, and the system will remember the entire ordering.
If the wildcard construction is used on Bring_To_Front() (segment) and there are conflicts, the system’s choice of who really gets to be the one in front will not be predictable.
Entities within a streaming-mode segment can not be “brought-to-front”.
Bring_To_Front() only works on the local level of the segment tree. If window A contains window B which contains window *C, a bring-to-front of C will make C the foremost of all the windows within B. It won’t make B foremost of the windows within A. If you want that to be true say so, separately.
If polygons are displayed with no explicit drawing order (without hidden surfaces and without an explicit Bring_To_Front() ) and a “scoped” refresh happens (for example, a window-system window is removed from on top of half the HOOPS scene), the scoped refresh may redraw its part of the scene in a different order than the original. This causes an obvious suture line.
- RESTRICTIONS
See also
HC_Set_Window, HC_Set_Heuristics, HC_Set_Streaming_Mode, HC_Set_Camera, HC_Set_Visibility.
- Parameters:
segment – Name of the segment(s) to be shuffled forward.
-
void HC_Bring_To_Front_By_Key(Key key)
Similar to Bring_To_Front(), but operates on an object referenced by an HC_KEY.
- Deprecated:
This function is deprecated.
See also
HC_Bring_To_Front()
- Parameters:
key – Open_Segment() , or any Insert routine.
-
void HC_Close_Edge(void)
Closes the session that began with an opening call to Open_Edge().
See also
HC_Open_Edge()
-
void HC_Close_Face(void)
Closes the session that began with an opening call to Open_Face().
See also
HC_Open_Face()
-
void HC_Close_Geometry(void)
Closes the session that began with an opening call to Open_Geometry().
See also
HC_Open_Geometry()
-
void HC_Close_LOD(void)
Closes the session that began with an opening call to Open_LOD().
See also
HC_Open_LOD()
-
void HC_Close_Region(void)
Closes the session that began with an opening call to Open_Region().
See also
HC_Open_Region()
-
void HC_Close_Segment(void)
Closes the currently open segment.
See also
HC_Open_Segment, HC_Rename_Segment, HC_Flush_Contents, HC_Reset_System
- DETAILS
Closes the currently open segment (i.e., the most recently opened segment), which is then no longer ready and available for “Insert” and “Set” operations. If there was a previously open segment, that segment becomes current once again. There must (eventually) be a matching Close_Segment() for every Open_Segment() , but in between as many Open’s and Close’s and even Update’s as you please can occur.
-
void HC_Close_Vertex(void)
Closes the session that began with an opening call to Open_Vertex().
See also
HC_Open_Vertex()
-
bool HC_Compile_Shader(int key_count, Key const path_keys[], char const *options)
Defines a section of code that will be injected into HOOPS 3DF shaders.
The geometry suboption needs to be the type of geometry which we want to see the shader for, optionally followed by a filter to limit generation to a particular set of primitives. For example, you could specify “geometry = (shell = triangles)” to get only the triangle shader for the shell, “geometry = (shell = (lines, points))” to get only the lines and points shaders for the shell, or “geometry = shell” to get triangle, lines, and points shaders for shells. The following is a list of geometry choices with the primitive types they may generate:
“nurbs curve” - “lines”
“elliptical arc” - “lines”
“circular arc” - “lines”
“line” - “lines”
“polyline” - “lines”
“polygon” - “triangles”, “lines”
“circular chord” - “triangles”, “lines”
“circular wedge” - “triangles”, “lines”
“ellipse” - “triangles”, “lines”
“circle” - “triangles”, “lines”
“marker” - “points”
“shell” - “triangles”, “lines”, “points”
“mesh” - “triangles”, “lines”, “points”
“cylinder” - “triangles”, “lines”
“polycylinder” - “triangles”, “lines”
“sphere” - “triangles”, “lines”
“nurbs surface” - “triangles”, “lines”
“text” - “triangles”, “lines”
“grid” - “triangles”, “lines”, “points”
“infinite line” - “lines”
“image” - “triangles”
- Supported Options:
- DETAILS
[all] geometry
[all] stage [vertex | pixel]
The stage suboption will be either vertex or pixel if you wanted to restrict the shaders that are generated to a particular stage.
vertex format
The vertex format suboption can have the following options:
“position” - [on | off]
“double position” - [on | off]
“normals” - [on | off]
“diffuse” - [on | off]
“specular” - [on | off]
See also
HC_Show_Compilation_Results_Size, HC_Show_Compilation_Results
- Parameters:
key_count – The number of keys in the path
path_keys – An array of keys, from the target segment up to a driver. Also possible to pass a single segment key
options – A quoted string or a string variable containing a list of the desired options
- Returns:
true if it was able to find a custom shader on the given path for either the vertex or pixel shader and geometry, construct the shader source for any relevant primitive types, invoke the shader compile function, and the compilation is successful. Returns false otherwise.
-
bool HC_Compute_Circumcuboid(char const *segment, Point *min, Point *max)
Returns points defining a cuboid that circumscribes the geometry within a segment.
This function returns the axis-aligned bounding cuboid associated with a database entity. The bounding volume returned is computed on demand - it does not reflect the bounding volume stored at the segment, if any. The routine, Show_Bounding_Cuboid() , can be used for that purpose. The volume returned is expressed in oru.
- DETAILS
Compute_Circumcuboid, the standard variant, allows only for segments. The By_Key variant, however, allows for keys that refer to any sort of geometry (in addition to segments). The standard variant allows for the normal wildcards associated with a segment specification.
The By_Key variant will fail if the specified key in variant does not refer to anything valid. The standard variant will fail if the specified segment in the does not match at least one segment, or all matched segments are empty of any geometry.
Transform-dependent geometry (e.g. markers, text) contributes only its insertion point. A reasonable way to handle markers would be to add a small pad to the min and max result. Special handling is needed to account for text, however. HOOPS/MVO (distributed as open source) contains a good example of that special handling (hint: it involves Compute_Text_Extent() ).
Temporary geometry created “on the fly” in the midst of I.M. callbacks will never contribute to any bounding volumes. The computed bounding volume will be with respect to geometry that has been inserted into the database. When called on a large segment tree, this function can become expensive, so use sparingly.
See also
HC_Compute_Circumsphere, HC_Compute_Coordinates, HC_Compute_Transform, HC_Show_Bounding_Info, HC_Show_Bounding_Cuboid,
- NOTES
- Parameters:
segment – Segment name to use for the calculation.
min – The lower-most nearest diagonal point (xmin,ymin,zmin) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
max – The upper-most distant diagonal point (xmax,ymax,zmax) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_Compute_Circumcuboid_By_Key(Key key, Point *min, Point *max)
Similar to Compute_Circumcuboid(), but operates on an object referenced by an HC_KEY.
See also
HC_Compute_Circumcuboid()
- Parameters:
key – Key of the segment used for the calculation.
min – The lower-most nearest diagonal point (xmin, ymin, zmin) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
max – The upper-most distant diagonal point (xmax, ymax, zmax) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_Compute_Circumsphere(char const *segment, Point *center, float *radius)
Returns points defining a sphere that circumscribes the geometry within a segment.
See also
HC_Compute_Circumcuboid, HC_Compute_Coordinates, HC_Compute_Transform, HC_Show_Bounding_Info, HC_Show_Bounding_Cuboid, HC_Show_Bounding_Sphere.
- DETAILS The volume for Compute_Circumsphere() is a sphere instead of a
cuboid. For more information refer to the discussion for Compute_Circumcuboid() .
- Parameters:
segment – Segment name to use for the calculation.
center – The center position of a sphere that encompasses the geometry contained within the segment. Returned to user. Passed by reference in all languages.
radius – The radius length of the encompassing sphere. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_Compute_Circumsphere_By_Key(Key key, Point *center, float *radius)
Similar to Compute_Circumsphere(), but operates on an object referenced by an HC_KEY.
See also
HC_Compute_Circumsphere()
- Parameters:
key – Key of the segment or geometry to be used for the calculation.
center – The center position of a sphere that encompasses the geometry contained within the segment. Returned to user. Passed by reference in all languages.
radius – The radius length of the encompassing sphere. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_DCompute_Circumcuboid(char const *segment, DPoint *min, DPoint *max)
Similar to Compute_Circumcuboid, but accepts double-precision parameters.
- Parameters:
segment – Segment name to use for the calculation.
min – The lower-most nearest diagonal point (xmin, ymin, zmin) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
max – The upper-most distant diagonal point (xmax, ymax, zmax) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_DCompute_Circumcuboid_By_Key(Key key, DPoint *min, DPoint *max)
Similar to Compute_Circumcuboid_By_Key(), but operates on double-precision data.
See also
HC_Compute_Circumcuboid_By_Key()
- Parameters:
key – Key of the segment used for the calculation.
min – The lower-most nearest diagonal point (xmin, ymin, zmin) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
max – The upper-most distant diagonal point (xmax, ymax, zmax) of the cuboid to encompass the geometry contained within the segment. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_DCompute_Circumsphere(char const *segment, DPoint *center, double *radius)
Similar to Compute_Circumsphere(), but operates on double-precision data.
- Parameters:
segment – Segment name to use for the calculation.
center – The center position of a sphere that encompasses the geometry contained within the segment. Returned to user. Passed by reference in all languages.
radius – The radius length of the encompassing sphere. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_DCompute_Circumsphere_By_Key(Key key, DPoint *center, double *radius)
Similar to Compute_Circumsphere_By_Key(), but operates on double-precision data.
See also
HC_Compute_Circumsphere_By_Key()
- Parameters:
key – Key of the segment or geometry to be used for the calculation.
center – The center position of a sphere that encompasses the geometry contained within the segment. Returned to user. Passed by reference in all languages.
radius – The radius length of the encompassing sphere. Returned to user. Passed by reference in all languages.
- Returns:
success
-
bool HC_Compute_Color(char const *name, char const *out_type, RGB *out_value)
Allows access to the color-conversion routines used internally in HOOPS.
If in_type or out_type are not legitimate an error is signalled. Other errors are not signalled and are returned in the success flag.
- DETAILS These routines allow access to the internal color conversion routines used by HOOPS
in the normal processing of Set_Color() and Set_Color_By_Value() . Compute_Color() takes a normal HOOPS color name, such as “pinkish purple” and returns the numeric equivalent in the selected color space. Compute_Color_By_Value() takes a numeric color in one color space and converts it to the equivalent color in another color space.
- NOTES
Not all colors that can be represented in the HLS, HSV and HIC color space have an exact equivalent RGB value. For colors that can’t be represented, the nearest legal RGB value is returned instead.
The final RGB values passed to the device usually have a gamma correction applied - these routines do not include gamma correction.
See also
HC_Set_Color, HC_Set_Color_By_Value, HC_Define_Color_Name.
- Parameters:
name – A color-by-name color specification, in the style of Set_Color() .
out_type – Special constant - either “HLS”, “HSV”, “HIC”, or “RGB”. The constant is a quoted string. Uppercase versus lowercase is not significant.
out_value – A color triple that represents hue, lightness, and saturation, or red, green, and blue, etc., depending on the values of in_type and out_type. Returned to user. Passed by reference in all languages.
- Returns:
true if it succeeds in turning the input color string into a color value in the format specified by out_type; otherwise, it returns false.
-
bool HC_Compute_Color_By_Value(char const *in_type, RGB const *in_value, char const *out_type, RGB *out_value)
Similar to Compute_Color(), but operates with a color values rather than names or map indices.
See also
HC_Compute_Color()
- Parameters:
in_type – Special constant - either “HLS”, “HSV”, “HIC”, or “RGB”. The constant is a quoted string. Uppercase versus lowercase is not significant.
in_value – A color triple that represents hue, lightness, and saturation, or red, green, and blue, etc., depending on the values of in_type and out_type. Passed by reference in all languages.
out_type – Special constant - either “HLS”, “HSV”, “HIC”, or “RGB”. The constant is a quoted string. Uppercase versus lowercase is not significant.
out_value – A color triple that represents hue, lightness, and saturation, or red, green, and blue, etc., depending on the values of in_type and out_type. Returned to user. Passed by reference in all languages.
- Returns:
true if the function succeeds in turning the input color string into a color value in the format specified by out_type; otherwise, it returns false.
-
void HC_Compute_Convex_Hull(int pcount, Point const points[], int *fcount, int face_list[])
Given a set of points, determines the set of faces that minimally bind all the points.
For all but the simplest sets of points there are many possible hulls. However, disregarding degeneracies (coplanar/colinear points), there is only one possible convex hull surrounding any given set of points. Compute_Convex_Hull() computes this shape. The input is a list of points. The output is a face connectivity list suitable for passing to Insert_Shell() .
- DETAILS
A “hull”, as used here, is a closed wrapper around a set of points. The hull is a simple polyhedron, its vertices are chosen only from the set of points, and all the points end up either on the surface or within the hull.
Compute_Convex_Hull() only produces convex figures, by definition. However, there is nothing preventing you from artificially moving one of the points inward to form a concave figure after Compute_Convex_Hull() returns. Likewise, Compute_Convex_Hull() only produces closed figures, by definition. There is nothing preventing you from artificially removing one or more of the faces to form an open shell afterwards.
The algorithm used is O(n squared). In other words, it’s going to take a while.
- NOTES
The variable, face_list_length, is the number of entries in face_list that the system has used up. face_list_length is returned to you. It is not the total available space you’re passing in. The system assumes your face_list is “big enough” to hold any possible result. Allow for at least 8**pcount**sizeof(int) in face_list - in other words, the new face list contains up to 2**pcount* triangles.
Not all the points will necessarily be mentioned in the face_list. Depending on the shape of your object, many points might be completely interior to the hull and thus unconnected.
Another definition of “convex hull” is “the surface of the smallest area that encloses a set of points”.
See also
HC_Compute_Coordinates, HC_Insert_Shell
- Parameters:
pcount – Number of valid points in points.
points – Vector of x-y-z triplets for the coordinates of the vertices. (A simple N*3 can also be used.) Passed by reference always.
fcount – Total number of integers returned in face_list. Passed by reference always. Returned to user.
face_list – Encoded description of how to connect the points to build the faces of the hull. Same format as in Insert_Shell() . Passed by reference always. Returned to user. Potentially up to 8*pcount*sizeof(int) in length.
-
bool HC_Compute_Coordinates(char const *segment, char const *in_system, Point const *in_position, char const *out_system, Point *out_position)
Converts positions back and forth among the various coordinate systems.
The in_system and out_system parameters to Compute_Coordinates() can include one of the following:
- DETAILS
This routine examines the attributes present on segment and its owners and allows you to convert from in_system coordinates to *out_system coordinates.
local window
The value is in terms of the local window for segment. (The Z coordinate is usually zero.)
outer window
The value is in terms of the outermost window for segment. (“Outermost” refers to the first segment going up from segment,* which has a Driver attribute.)
screen range
The value is in window coordinates units based on the value of the screen range in Set_Rendering_Options() set on the segment. If no screen range is set, this is the equivalent to local window.
local pixels
The value is measured in screen pixels within the local window on segment. The upper-left of the window is pixel (0, 0). The pixels go down and to the right. (The Z coordinate is usually zero.)
outer pixels
The value is in terms of pixels within the outermost window on segment.
projection
The value is in projection space (Normalized device coordinates) and maps directly to the window.
viewpoint
A coordinate system based on the position of the observer (camera). The origin is at the camera position. The viewing direction is the Z-axis and the camera up vector is the Y-axis.
world
The value is in normal world coordinates (the coordinate system in which the camera is positioned; the coordinates of geometry after modelling matrices have been applied, but before projecting through a camera into a window.) A window Z value of zero maps to the current camera “target” plane.
camera
The coordinate system used in calls to Set_Camera_Position() . A synonym for world coordinates.
object
The value is in the coordinate system that real geometry lives in. This is similar to “world” coordinates, but does not includes the Modelling Matrices, if any.
If a conversion is ambiguous (one of the matrices is singular), the system will choose arbitrarily among the valid possibilities. If a conversion is impossible (the point is on top of or behind a perspective camera), a false function status will be returned and out_position will be unchanged.
- NOTES
Window Z coordinates are described at length under Show_Selection_Position() .
To generate the world coordinates of an eye-ray, given window or pixel coordinates, call this routine twice with two different window or pixel Z coordinates.
If you have many points to transform it is more efficient to call Compute_Transform() to get a transform matrix. Then call Compute_Transformed_Points() to do all the points at once. If you have just one or a couple points to transform, Compute_Coordinates() is more efficient because it doesn’t need to build the matrix.
Calling Compute_XXX() routines to obtain data associated with a display, generates an update. On most devices, this poses no problem. However, for hardcopy devices such as Postscript or CGM, this can generate a blank page. To avoid this problem, applications often open a temporary driver subsegment. The application calls the compute routine, and retains the computed information, and then discards the temporary driver subsegment.
- RESTRICTIONS
The Compute_XXX() routines that require information about display drivers, do not work if they are called from an included segment. Display information must be associated with a window to return information about the display.
See also
HC_Compute_Transform, HC_Show_Selection_Position, HC_Show_Polyline, HC_Show_Shell.
- Parameters:
segment – The name of a segment that provides the Window, Camera, and/or Driver attributes for the conversion.
in_system – Special constants for the input and output coordinate spaces. See details.
in_position – A 3-D coordinate position in the in_system coordinate space. Passed by reference in all languages.
out_system – Special constants for the input and output coordinate spaces. See details.
out_position – A 3-D coordinate position in the out_system coordinate space. Passed by reference in all languages. Returned to user.
- Returns:
success
-
bool HC_Compute_Coordinates_By_Path(int count, Key const keys[], char const *in_system, Point const *in_position, char const *out_system, Point *out_position)
Similar to Compute_Coordinates(), but concatenates the matrices along a segment path rather than the currently open segment.
See also
HC_Compute_Coordinates()
- Parameters:
count – The size of the keys array
keys –
The array of keys starting with the owning segment and following
long all the way back to the root segment or other desired segment.
in_system – Special constants for the input and output coordinate spaces.
in_position – A 3-D coordinate position in the in_system coordinate space. Passed by reference in all languages.
out_system – Special constants for the input and output coordinate spaces.
out_position – A 3-D coordinate position in the out_system coordinate space. Passed by reference in all languages. Returned to user.
- Returns:
success
-
void HC_Compute_Cross_Product(Vector const *vector1, Vector const *vector2, Vector *out_vector)
Computes the cross product of two vectors.
| i j k | | x1 y1 z1 | | x2 y2 z2 |
- DETAILS
Compute_Cross_Product() takes two 3-D vectors and computes their vector cross-product.
- NOTES
For a bit of linear algebra review, the way to compute a cross product is to calculate the determinant of the following matrix:
Where i, j, and k are the unit vectors along the X, Y, and Z axes, respectively. That works out to be equal to
i*(y1*z2 - z1*y2) - j*(x1*z2 - z1*x2) + k*(x1*y2 - y1*x2)
The result is always perpendicular to both inputs, and of length equal to the length(vector1) * length(vector2) * sin(angle
between vector1 and vector2). The order of the inputs matters. Switching the inputs will reverse the result.
See also
HC_Compute_Coordinates, HC_Compute_Dot_Product
- Parameters:
vector1 – input 3D vectors.
vector2 – input 3D vectors.
out_vector – output 3D vector returned to the caller. Can point to the same place as vector1 or vector2
-
void HC_DCompute_Cross_Product(DVector const *vector1, DVector const *vector2, DVector *out_vector)
Similar to Compute_Cross_Product, but operates on double-precision data.
- Parameters:
vector1 – input 3D vectors.
vector2 – input 3D vectors.
out_vector – output 3D vector returned to the caller. Can point to the same place as vector1 or vector2
-
double HC_Compute_Dot_Product(Vector const *vector1, Vector const *vector2)
Takes two 3-D vectors and computes their scalar dot-product.
See also
HC_Compute_Coordinates, HC_Compute_Cross_Product
- Parameters:
vector1 – Input 3D vector.
vector2 – Input 3D vector.
- Returns:
value
-
double HC_DCompute_Dot_Product(DVector const *vector1, DVector const *vector2)
Similar to Compute_Dot_Product, but operates on double-precision data.
- Parameters:
vector1 – Input 3D vector.
vector2 – Input 3D vector.
- Returns:
value
-
void HC_Compute_Identity_Matrix(float out_matrix[])
See also
HC_Set_Modelling_Matrix
- DETAILS
Compute_Identity_Matrix() produces a matrix that represents “no transformation”. It can be useful when program logic always assumes a previous transformation exists. The output array is always filled with [1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,1].
- Parameters:
out_matrix – Output transformation matrix, returned to the caller.
-
void HC_DCompute_Identity_Matrix(double out_matrix[])
Similar to Compute_Identity_Matrix(), but operates on double-precision data.
- Parameters:
out_matrix – Output transformation matrix, returned to the caller.
-
void HC_Compute_Matrix_Adjoint(float const matrix[], float out_matrix[])
See also
HC_Compute_Coordinates, HC_Compute_Matrix_Inverse, HC_Compute_Transform, HC_Compute_Transformed_Plane, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- DETAILS
Compute_Matrix_Adjoint() takes a general 4x4 transformation and computes its adjoint. The adjoint of a matrix is similar to the inverse of the matrix - the adjoint divided by the determinant gives the inverse. The adjoint is sometimes used in place of the inverse because it’s easier to compute and is never singular.
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
-
void HC_DCompute_Matrix_Adjoint(double const matrix[], double out_matrix[])
Similar to Compute_Matrix_Adjoint(), but operates on double-precision data.
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
-
double HC_Compute_Matrix_Determinant(float const matrix[])
See also
HC_Compute_Coordinates, HC_Compute_Matrix_Inverse, HC_Compute_Normalized_Matrix, HC_Compute_Transform, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- DETAILS
Compute_Matrix_Determinant() takes a general 4x4 transformation and computes its determinant. If the determinant is zero, the matrix is singular.
- Parameters:
matrix – Input transformation matrix.
- Returns:
value
-
double HC_DCompute_Matrix_Determinant(double const matrix[])
Similar to Compute_Matrix_Determinant(), but operates on double-precision data.
- Parameters:
matrix – Input transformation matrix.
- Returns:
value
-
bool HC_Compute_Matrix_Inverse(float const matrix[], float out_matrix[])
If the matrix is singular, Compute_Matrix_Determinant() would return zero. The adjoint (see Compute_Matrix_Adjoint() ) is similar and will always be defined, even for singular matrices. Consider using that instead where applicable.
- DETAILS
Compute_Matrix_Inverse() takes a general 4x4 transformation and computes its inverse. If the matrix is singular, the out_matrix will be unchanged and false will be returned.
- NOTES
See also
HC_Compute_Coordinates, HC_Compute_Matrix_Determinant, HC_Compute_Matrix_Adjoint, HC_Compute_Transform, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
- Returns:
success
-
bool HC_DCompute_Matrix_Inverse(double const matrix[], double out_matrix[])
Similar to Compute_Matrix_Inverse(), but operates on double-precision data.
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
- Returns:
success
-
void HC_Compute_Matrix_Product(float const matrix1[], float const matrix2[], float out_matrix[])
Given:
- DETAILS
Compute_Matrix_Product() takes two general 4x4 transformation matrices (from routines such as Compute_Rotation_Matrix() ) and computes their product. For compatibility with Compute_Transformed_Points(), specify the “inner” transformations (e.g., modelling matrices) on the left (as matrix1) and “outer” transformations (e.g., cameras, windows) on the right (as matrix2).
Compute_Matrix_Product(A, B, C);
C = AB
The result is that the following are equivalent:
1) Append_Modelling_Matrix(A);
followed by
Append_Modelling_Matrix(B);
2) Append_Modelling_Matrix(C);
See also
HC_Compute_Coordinates, HC_Compute_Transform, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- Parameters:
matrix1 – First input transformation matrix.
matrix2 – Second input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix1 or matrix2
-
void HC_DCompute_Matrix_Product(double const matrix1[], double const matrix2[], double out_matrix[])
Similar to Compute_Matrix_Product(), but operates on double-precision data.
- Parameters:
matrix1 – First input transformation matrix.
matrix2 – Second input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix1 or matrix2.
-
void HC_Compute_Minimized_Shell(int in_point_count, Point const in_points[], int in_face_list_length, int const in_face_list[], char const *option_string, int *out_point_count, Point out_points[], int *out_face_list_length, int out_face_list[], int vertex_mapping[], int face_mapping[])
-
bool HC_Compute_Normalized_Matrix(float const matrix[], float out_matrix[])
If the matrix is singular, Compute_Matrix_Determinant() would return zero.
- DETAILS
Compute_Normalized_Matrix() takes a general 4x4 transformation and divides by its determinant. If the input matrix is singular, the out_matrix will be unchanged and false will be returned.
- NOTES
See also
HC_Compute_Coordinates, HC_Compute_Matrix_Determinant, HC_Compute_Transform, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
- Returns:
success
-
bool HC_DCompute_Normalized_Matrix(double const matrix[], double out_matrix[])
Similar to Compute_Normalized_Matrix, but operates on double-precision data.
- Parameters:
matrix – Input transformation matrix.
out_matrix – Output transformation matrix, returned to the caller. Can point to the same place as matrix.
- Returns:
success
-
bool HC_Compute_Normalized_Vector(Vector const *vector, Vector *out_vector)
See also
HC_Compute_Coordinates, HC_Compute_Transform, HC_Set_Modelling_Matrix, HC_Show_Device_Info
- DETAILS
Compute_Normalized_Vector() takes a 3-D vector and divides by its length. If the vector is all zeroes, false will be returned.
- Parameters:
vector – Input 3D vector.
out_vector – Output 3D vector returned to the caller. Can point to the same place as vector .
- Returns:
success
-
bool HC_DCompute_Normalized_Vector(DVector const *vector, DVector *out_vector)
- Parameters:
vector – Input 3D vector.
out_vector – Output 3D vector returned to the caller. Can point to the same place as input vector.
- Returns:
success
-
void HC_Compute_Offaxis_Rotation(double x, double y, double z, double theta, float out_matrix[])
See also
HC_Compute_Offcenter_Rotation, HC_Set_Modelling_Matrix
- DETAILS
Compute_Offaxis_Rotation() produces a matrix that represents a rotation about an arbitrary axis passing through the origin.
- Parameters:
x – X coordinate of the vector that specifies the axis of rotation
y – Y coordinate of the vector that specifies the axis of rotation
z – Z coordinate of the vector that specifies the axis of rotation
theta – Angle of rotation.
out_matrix – Output transformation matrix. Returned to caller.
-
void HC_DCompute_Offaxis_Rotation(double x, double y, double z, double theta, double out_matrix[])
Similar to Compute_Offaxis_Rotation, but operates on double-precision data.
- Parameters:
x – X coordinate of the vector that specifies the axis of rotation
y – Y coordinate of the vector that specifies the axis of rotation
z – Z coordinate of the vector that specifies the axis of rotation
theta – Angle of rotation.
out_matrix – Output transformation matrix. Returned to caller.
-
void HC_Compute_Offcenter_Rotation(double alpha, double beta, double theta, double x, double y, double z, float out_matrix[])
See also
HC_Compute_Offaxis_Rotation, HC_Set_Modelling_Matrix
- DETAILS
Compute_Offcenter_Rotation() produces a matrix representing a rotation about an arbitrary center of rotation. This essentially consists of a translation of (-*x*,-*y*,-*z*) to the origin. The translation uses a rotation of alpha degrees about the X axis, a rotation of beta degrees about the Y, and a rotation of theta degrees about the Z. Then it does a translation back to (x, y, z).
- Parameters:
alpha – Angle of rotation about the X axis.
beta – Angle of rotation about the Y axis.
theta – Angle of rotation about the Z axis.
x – X coordinate of the centroid of rotation
y – Y coordinate of the centroid of rotation
z – Z coordinate of the centroid of rotation
out_matrix – Output transformation matrix, returned to the caller.
-
void HC_DCompute_Offcenter_Rotation(double alpha, double beta, double theta, double x, double y, double z, double out_matrix[])
Similar to Compute_Offcenter_Rotation, but operates on double-precision data.
- Parameters:
alpha – Angle of rotation about the X axis.
beta – Angle of rotation about the Y axis.
theta – Angle of rotation about the Z axis.
x – X coordinate of the centroid of rotation
y – Y coordinate of the centroid of rotation
z – Z coordinate of the centroid of rotation
out_matrix – Output transformation matrix, returned to the caller.
-
void HC_Compute_Optimized_Shell(int pcount, Point const points[], Vector const normals[], int flist_length, int const face_list[], char const *options, int *new_pcount, Point new_points[], int *new_flist_length, int new_face_list[], int point_mapping_list[], int face_mapping_list[])
Performs one of several computations to prepare shell data for improved rendering performance. The default computation is to remove redundant vertices and degenerate faces.
The HOOPS routine Insert_Shell() accepts a set of points, an encoded description of how to connect the points to form the faces of a shell. Insert_Shell() performs no interrogation of the data received. It has no provision for eliminating redundant points nor for ignoring disconnected points. Compute_Optimized_Shell() accepts data normally used to insert a shell and returns a new set of data with redundancies and discontinuities removed. This new data can then be used to insert a shell. The arrays point_mapping_list and face_mapping_list are available to help you refer to the new data, if given indices to the original data.
- DETAILS
Programs designed to work with geometric modelers often receive geometry in a stream. This means they cannot ascertain the overall connectedness of a shell’s faces. For instance, to define a diagonally-split quadrilateral using two faces, one needs only four vertices, with two of them referenced twice. While it is geometrically correct to redefine the “re-used” vertices, for a total of six, face-connectivity information is lost. This is because duplicated points, though equivalent, are still distinct - each face has its “own” vertices. Compute_Optimized_Shell() recaptures the connectivity by eliminating the duplicated vertices and forcing faces to share the remaining unique vertices.
Faces that refer to fewer than three unique vertices are eliminated.
Since shells are arbitrary collections of faces, Compute_Optimized_Shell() can be used to convert a group of polygons into a coherent shell. The advantage is less data must be sent to HOOPS. Performance is improved since fewer points must be transformed and clipped.
Compute_Optimized_Shell() does not allocate memory for you. All arrays passed to it must contain adequate storage.
The following choices are recognized for options:
fix handedness
This option is a convenience for converting a minority of faces to the handedness comprising the majority.
Determines the handedness of the majority of faces, and reverses the winding of the minority faces. Returns facelist data to the caller. Shell data is modified in no other way. Mutually exclusive to options “fix handedness”, “skin”, and “lod”.
This option will also fix the special winding of holes (and nested holes) in shell faces also. A limitation of fixing face handedness is that we cannot do better than the “majority wins” method for the general case.
reverse handedness
This option is a convenience for reversing the winding of shell faces if the option “fix handedness” gives you an inside-out shell and you prefer not to change the appearance with the Heuristic “polygon handedness”.
Reverses the winding of each face in the facelist provided. Returns facelist data to the caller. Shell data is modified in no other way. Mutually exclusive to options “fix handedness”, “skin”, and “lod”.
It should not be necessary to pass in point data.
[no] [level of detail | lod] [ = xx% ]
Causes Compute_Optimized_Shell to abandon the normal redundant-vertices calculation in favor of calculating a Level of Detail (LOD). Any other choice will cause the shell to be reduced using shell simplification instead of the standard code path. The default reduction when LOD is turned on is 50%. If a percentage is specified in the form of xx%, the number of triangles in the model will be reduced to to the given percentage of the original model. The options “skin” and “lod” are mutually exclusive.
The new point count is guaranteed not to be larger than the original, so the original length can be used as upper bounds for allocation. The same goes for the facelist if the input is triangles. If quads (or polygons of higher order) are provided, then the output facelist may be larger. This is because our LOD algorithm outputs triangles only.
With quad input and level of detail = 100%, we will output double the faces. Triangle faces have 4/5 the number of integers that quad faces do, so we don’t need to double the facelist alloc size, rather multiply it by 1.6. This factor shrinks by user-provided level of detail. For example, with quad face input and level of detail = 75%, the new facelist alloc size becomes 1.6*0.75 = 1.2x original.
Generally, for turning n-gon data into a LOD shell with level of detail x, you are safe if you alloc an array of size (Original_FaceList_Length * 4*(n-2)/(n+1) * x).
Alternatively, you can safely run Optimize twice - first just to generate the facelist length (no array passed in), next with the array after your accurately sized alloc. This, however will take more cpu time.
Not set by default.
lod algorithm = [fast | nice]
Use the fast-LOD algorithm, with some visual quality degradation, or the “nice” LOD algorithm, with extra generation time but a better representation. Default is “fast”. Default is “fast”, but only applies if the “lod” option is used.
[no] orphan elimination
If this option is set, points that are not referenced by any face are removed. The default is “orphan elimination”.
[no] skin
Particularly geared towards the needs of the finite element analysis community, this option causes Compute_Optimized_Shell() to abandon its normal goal of merging nearby vertices in favor of extracting the exterior surface from shells that also have interior vertices and faces. This special computation mode works its magic by looking for pairs of faces that reference 3 or more of the same vertex indices. If coincident vertices are not shared for adjacent faces, this computation will not do anything (though running the standard form of Compute_Optimized_Shell() on the data first would solve that problem. The options, “skin” and “lod” are mutually exclusive. When “skin” mode is used only “orphan elimination” has any meaning - the rest are ignored. As usual, the new face list length and new point count are guaranteed not to be larger than the original, so the original lengths can be used as upper bounds for allocation. Not set by default.
[no] tolerance [= nnn oru / nnn % fru]
“Tolerance” controls the identification of duplicate points. If a specification is given in object-relative units (oru), then the points that are separated by a distance less than this value are considered equal.
Often, one cannot ascertain a “good” value for an object-relative tolerance. In this case, specify the tolerance using “feature-relative units (fru)”. Feature size is defined to be the smallest non-zero distance between any two adjacent vertices on any face. It is calculated internally by Compute_Optimized_Shell() , and is constant for the entire collection of faces. The feature-relative tolerance is expressed as a percentage of this minimum distance. A setting less than “tolerance = 100%
fru” guarantees that unequal vertices on a single face won’t be eliminated.
“No tolerance” is the same as “tolerance = 0 oru”.
The default is “no tolerance”.
[no] normal tolerance [= nnn deg / nnn rad / nnn]
“Normal Tolerance” also controls the identification of duplicate points. Points which have an angular difference greater than the specified normal tolerance are assumed to be unique.
“no normal tolerance” is the same as “normal tolerance = 0 deg”.
The default is “no normal tolerance”.
[no] collapsible [= <defined callbackname>]
This option enables the user to replace the default distance measure, euclidian distance, with their own function to determine whether any given two nearby points should be merged or not. While it was originally designed to accept normals as its primary information, any sort of pointer that is passed as normals in the call to Compute_Optimized_Shell will be passed through to the callback.
If you are not interested in the mapping lists, pass a null pointer for either the point_mapping_list or the face_mapping_list. If you are not interested in using normal information as a criterion for collapsing points, pass a null pointer for normals.
- NOTES
This function replaces Compute_Minimized_Shell() , which is now obsolete.
It is not legal to pass the same pointer for both input and output.
EXAMPLES
The following example demonstrates passing a struct pointer in place of normals.
typedef struct { // contents of this structure are unrestricted float myparam1, myparam2; } optimized_shell_passthru; // returns 1 if points a and b are collapsible - // 0 if points a and b are not collapsible int are_collapsible_callback ( void *pts_in, void *norms_in, int a, int b, double tolerance_squared, double normal_distance_squared ) { optimized_shell_passthru *info= (optimized_shell_passthru *) norms_in; // use info to do any test here, and return the result } // and this is how the function is called optimized_shell_passthru info = { a, b, etc. }; HC_Define_Callback_Name( "are_collapsible_callback", are_collapsible_callback ); HC_Compute_Optimized_Shell( in_point_count, in_points, (void *)(&info), in_face_list_length, in_face_list, "collapsible = are_collapsible_callback", &out_point_count, out_points, &out_face_list_length, out_face_list, vertex_mapping, face_mapping );
The following example demonstrates using the vertex_mapping array to copy attributes from the old shell to the new one. Two things to note from this example:
a) that the check for “vertex_mapping >= 0” really is necessary, since unreferenced vertices from the original shell have vertex_mapping entries set to “-1”; and
b) that performance could be improved if the normals from the original shell were available a priori in an array so that the vertices did not have to be individually opened.
c) vertices in the new shell can potentially be touched more than once.
HC_Show_Shell( old_key, &point_count, points, &face_list_length, face_list ); HC_Compute_Optimized_Shell( &point_count, points, NULL, &face_list_length, face_list, "", &new_point_count, new_points, &new_face_list_length, new_face_list, vertex_mapping, face_mapping ); new_key = HC_Insert_Shell( new_point_count, new_points, new_face_list_length, new_face_list ); for( i = 0 ; i < point_count ; i++ ) { HC_Open_Geometry( old_key ); HC_Open_Vertex( i ); HC_Show_Normal( &x, &y, &z ); HC_Close_Vertex(); HC_Close_Geometry( ); if( vertex_mapping[i] >= 0 ) { HC_Open_Geometry( new_key ); HC_Open_Vertex( vertex_mapping[i] ); HC_Set_Normal( x, y, z ); HC_Close_Vertex(); HC_Close_Geometry( ); } }
See also
HC_Insert_Shell, HC_Show_Shell, HC_Show_Shell_Size.
- Parameters:
pcount – Number of valid points in points.
points – Vector of x-y-z triplets for the coordinates of the vertices that could be used to build the shell. (A simple N = 3 array can also be used.) Passed by reference always.
normals – Sequential list of vertex normals, x-y-z triplets. It is legal to pass NULL for this parameter, in which case normal information will be ignored. If non-NULL, however, the normals are assumed to be normalized to length 1. Passed by reference always.
flist_length – Total number of integers in face_list.
face_list – Encoded description of how to connect the points to build the faces of the shell. Passed by reference always.
options – A quoted string or a string variable containing a list of desired options. Passed by reference always.
new_pcount – Number of valid points in new_points after computation. Returned to caller. Passed by reference always.
new_points – Vector of x-y-z triplets for the coordinates of the non-redundant vertices that could be used to build the shell. (A simple N = 3 array can also be used.) Returned to caller. Passed by reference always.
new_flist_length – Total number of integers in computed new_face_list. Returned to caller. Passed by reference always.
new_face_list – Encoded description of how to connect the points to build the faces of the computed shell. Returned to caller. Passed by reference always.
point_mapping_list – Mapping of vertices from the original point list to the vertices in the new (computed) point list. In other words, for each old vertex i, point_mapping_list[i] represents the vertex in the new shell to which it has moved. Eliminated points are mapped to -1. Returned to caller. Passed by reference always.
face_mapping_list – Mapping of faces from the original face list to the new (computed) face list. In other words, for each old face j, face_mapping_list[j] represents the vertex in the new shell to which it has moved. Eliminated faces are mapped to -1. Returned to caller. Passed by reference always.
-
Key HC_Compute_Capping_Shell(int shell_count, Key const shell_list[], float const plane[])
Creates a shell in the currently open segment that contains an exact copy of the cap geometry that a plane would make when applied to the provided shells.
This function allows developers to access the cap geometry that 3dGS creates when cutting planes are inserted into the scene and capping geometry is turned on. The capping geometry is returned as a single shell and is inserted into the currently open segment. Users must ensure that there is a valid open segment before calling this function.
- DETAILS
This function does not apply any modelling transforms to the supplied shells. Users must translate the shells into world space to ensure correct results. Also, the shell provided is a copy of the capping geometry and so the deletion and/or modification of the returned shell will not affect the caps in the scene.
- NOTES
This interface currently supports shell generation for cutting planes only. This function must operate on manifold shells. Non-manifold shells will not work.
- RESTRICTIONS
See also
HC_Insert_Shell, HC_Insert_Cutting_Plane, HC_Insert_Cutting_Section
- Parameters:
shell_count – Number of shells in the shell list array.
shell_list – List of shells for which the cap(s) will be generated.
plane – An array of four floats that define the cap plane.
- Returns:
cap_key The key to the shell that will contain the capping geometry.
-
Key HC_Compute_Boolean_Shell(int target_pcount, Point const target_points[], Vector const target_normals[], int target_flist_length, int const target_face_list[], int tool_pcount, Point const tool_points[], Vector const tool_normals[], int tool_flist_length, int const tool_face_list[], char const *options)
Performs one of several boolean operations on two shells. IMPORTANT NOTE: This routine is primarily meant to provide a reasonable visual representation of the boolean result, and has limititions covered in the NOTES section which prevent this routine from being relied on to produce manifold shell results. The routine is provided AS-IS.
This function takes the definitions for two manifold shells and performs one of three boolean operations on those shells. The result is a new shell that gets inserted into the currently open segment. Valid choices for options* include the following:
- DETAILS
boolean type = [subtract | union | intersect]
Tells 3dGS which specific type of boolean operation to perform on the supplied shells. In the event of a union or an intersection, the order of target and tool does not matter. However, in the case of a subtraction the tool will be subtracted from the target shell.
plane coefficient = [float]
This value is used in the internal logic for determining the boolean result. Changing the value based on the scale of the object can give better results. For both the single and double precision version, the default setting is “plane coefficient = 0.000001”.
plane tolerance = [float]
This value is used in the internal logic for determining the boolean result. Changing the value based on the scale of the object can give better results. The default setting is “plane tolerance = 0.0003” for the single precision version. For the double precision version, the default setting is “plane tolerance = 0.000001”.
plane merge tolerance = [float]
This value is used in the internal logic for determining the boolean result. Changing the value based on the scale of the object can give better results. The default setting is “plane merge tolerance = 0.0003” for the single precision version. For the double precision version, the default setting is “plane merge tolerance = 0.000001”.
target handedness = [left|right]
The polygon handedness of the target shell. If not specified, “left” handedness is assumed.
tool handedness = [left|right]
The polygon handedness of the tool shell. If not specified, “left” handedness is assumed.
This function will perform a Compute_Optimized_Shell() on the resulting boolean shell data before placing it in the currently open segment. The shell will have left polygon handedness. The user may need to delete the tools and target in their scene depending on the intended behavior.
- RESTRICTIONS
The two shells that participate in the boolean operation must be closed and manifold bodies. There cannot be overlapping facets or other inconsistencies in the data. You must have consistent handedness in each input shell (though each shell can have it’s own handedness, e.g., the target can have right handedness and the tool can have left handedness) and you must specify the handedness in the options if it differs from the defaults, otherwise one can get unexpected results. The input shells must only contain convex faces.
The faces of the target and tool shells should not be co-planar.
The resulting shell of the Compute_Boolean_Shell() function may contain an excessive number of triangles in the region where the target and tool meet. If the boolean functionality is used for continuous surface removal (for example, recursive use of the boolean operation result as the input value for a subsequent boolean operation), this effect may become exacerbated.
- NOTES
Due to the nature of the algorithm, very small triangles may be produced which can lead to precision problems, such as missing faces or faces with wrong handedness. In extreme cases, these precision problems can lead to the creation of extraneous triangles.
See also
HC_Insert_Shell
- Parameters:
target_pcount – Number of valid points in targetpoints.
target_points – Vector of x-y-z triplets for the coordinates of the vertices that could be used to build the target shell. (A simple N = 3 array can also be used) Passed by reference always.
target_normals – Sequential list of vertex normals of the target shell, x-y-z triplets. It is legal to pass NULL for this parameter, in which case normal information will be ignored. Passed by reference always.
target_flist_length – Total number of integers in targetface_list
target_face_list – Encoded description of how to connect the points to build the faces of the target shell. Passed by reference always.
tool_pcount – Number of valid points in toolpoints.
tool_points – Vector of x-y-z triplets for the coordinates of the vertices that could be used to build the tool shell. (A simple N = 3 array can also be used) Passed by reference always.
tool_normals – Sequential list of vertex normals of the tool shell, x-y-z triplets. It is legal to pass NULL for this parameter, in which case normal information will be ignored. Passed by reference always.
tool_flist_length – Total number of integers in toolface_list.
tool_face_list – Encoded description of how to connect the points to build the faces of the tool shell. Passed by reference always.
options – A quoted string or a string variable containing a list of desired options. Passed by reference always.
- Returns:
key
- bool HC_Compute_Polygon_No